To Unghost or To Not Unghost, That Is the Question!
Before you dismiss this as a dev topic. Let me tell you why you should care about this as an upgrade topic and a manageability and governance topic. Your policies around customization may have the biggest impact to how difficult it is to upgrade, maybe even more so than how much content you have. It can also impact availability, and you ability to provide consistency and standardization. What I'm not saying here is that every desktop needs SharePoint Designer. I'm simply trying to educate you on the impact (positive and negative) of customizations and help educate you with enough depth that you can make informed decisions.
Over the life of the product, unghosting or customizing pages (Unghost=Customize=Branching (making a page dirty and not inherited)) with FrontPage and now SharePoint Designer (One of FrontPage's successors) has been a topic of debate. For a quick history lesson.
In SharePoint Team Services, the first full fledged Microsoft Collaboration product and successor to Office Server Extensions/FrontPage Server Extensions, the question around using FrontPage never really had a question about what would happen to the pages at upgrade time, it was more around how do I add my logo, pictures, or apply a theme. There were no page layouts, no master pages, no web part zones even. You did have web parts in SPS 2001 based on script, but those server side script based web parts you had to rewrite to make them .NET compatible. Some did do extensive page editing in those days and when smigrate came around and upgrade time happened, the home page was simply renamed to default_old.htm and the new default page (default.aspx) with the new look and feel of Windows SharePoint Services 2.0 was there and in your face. Those sites that were upgraded were thought of as gone, unless it was communicated that, hey, it's in the same directory and you can rename it back to default.htm if you so choose. For the 1000 or so sites I upgraded my first weekend, I got more than a few questions about what happened to my site. (They didn't read their mails!)
Then the whole question of customization on WSS 2.0 was really big. Do I allow my users to edit their sites? If I let them customize their sites then the look and feel will not be guaranteed and the page will be unghosted aka branched or customized. True and true. Many resorted to either not allow FrontPage editing for the majority of sites, or instituted custom site definitions. Although custom site definitions seems to have made the solution a quick and easy fix to maintaining a connection between the site definition and the sites with the company "brand." Unghosting or Customizing the page would still block the inheritance from the site definition and create a branch a modified page sitting in the database for the site. What to do? This question was a big one and there is no right answer.
First group, some companies went with an out of the box look and feel and allowed the users to use FrontPage to add look and feel. Second, others created site templates with added logos and simple chrome or navigation for look and feel. The third group, created custom site definitions, blocked Front Page editing as a policy and attempted to prevent all page editing, (To clarify it's not FrontPage that unghosts or customizes pages, all editors including notepad using WebDav to access the pages, would have this same impact) and kept consistent look and feel likely with the help of consultants or systems integrators.
Now with upgrade to WSS 3.0, which group has fared best. The first group, with the out of the box site definition and 30% of site collections with unghosted home pages. The second with custom site templates. The third with custom site definitions. Let's look at it. Let's first assume they all used gradual upgrade, my recommendtion for 90% of deployments. Why this. Let me take a quick shot to break down this thing that need not be nebulous...
My breakdown on how I see upgrade methods
1% - In Place Upgrade - Use it on Dev, Test, Staging type environments if you need a quick and dirty upgrade that is fast. I do not recommend it's use in production, it may fail for a number of reasons outside of it's control. More on this in my post on why not to use in place upgrade.
90% - Gradual Upgrade - The MOST flexible option allowing you to use existing hardware and hand hold or upgrade many sites while being in control of the process. You can always do this first, then attach your upgraded databases your new farm. If gradual is too slow for you and you get comfortable, then look at database attach. Even if you bought new hardware, starting slow and converting a database site by site on the original farm and then bringing over the completed upgraded v3 database may not be a bad idea for you.
9% - Database Attach Migration/Upgrade - Bought a new farm, lots of data, no major investments in customizations that you need to worry about. Others... Scalable hosting mode deployments, host header deployments, large environments looking for data rates & pure speed where they are very comfortable with upgrade.
Ok, back to the gradual upgrade for our 3 groups.
Group 1... Those that had 30% of sites with unghosted home pages. This upgrade has a decision, do we revert to site definition or do we not? MS IT faced with this decision decided to put a top FAQ in place explaining how to revert to site definition and opted to NOT doing the revert to site definition for anyone. So in a sense, when this upgrade takes place only those in the ghosted state (default) immediately saw the new look and feel and saw the breadcrumbs, top nav, security trimmed UI, etc... Those with customized/uhghosted sites could either go to site settings and reset to site definition for the entire site or page by page simply using the site actions, revert to site defintion option on the site settings menu. The gradual upgrade which is really the upgrade which provides the most options gives you granular control. One often overlooked upgrade option is to reset the site definition on the sites as they are upgraded. The administration is via the central admin, operations, Site Collection Upgrade, then under the Actions menu click upgrade settings. Choosing this option will reset *ALL* pages in the sites upgraded while this is enabled. If you decide to do this afterward that is a decent option as well. Remember, with gradual upgrade you are in the drivers seat.
What are your options as a recap?
1. Run upgrade without this option checked (default) all sites that are customized/unghosted will look like they did in WSS 2.0 and miss out on breadcrumbs, navigation, recycle bin (at least they can't see it), workflows, etc... (This is what MS IT did, it provides the most flexibility to the site owners, but leaves the choice up to the user to reset back to the WSS 3.0 site definition when they are ready. Not recommended for a non technical audience.)
2. Reset to the site definition during the gradual upgrade. This puts everyone back to the site definition. All sites will look out of box until new themes and master pages are deployed. Sites that are highly customized will be very suprised and potentially shocked. You'll need to work with these folks to either have them remigrated as #1 or convince them of the value, or wait till a later date and try again. You're not going to want to keep the redirection going for extended periods of time. This means potentially months in some companies, years in others.
3. Mix of 1 and 2. You go with 1 initially, then educate users on the way to reset to site definition in designer or in site settings. This is really what MS IT did, but they wait until someone asks, with info on their FAQ on how to reset pages or all pages in the site to the site definition.
(Thanks Shane Young for these snapshots)
Experience overall? Not bad. With some training and some getting use to it, with a few help desk calls, the upgrade impact was much less than the STS to WSS 2.0 than from WSS 2.0 to WSS 3.0 by far. Discussions lists, and site groups did raise a few questions.
Group 2 with their custom site templates. This IT group found that the zones became particularly important. Any site templates with custom named zones did not upgrade well. Using the site template upgrade toolkit was a bit complex, but overall these tools, scripts and advice did help. Ultimately using the gradual upgrade and some temps (hired contract labor) during the upgrade, the company was able to get through the upgrade somewhat smoothly. Although somewhat apprehensive around templates, they have looked at the new Application templates and the company is already planning on leveraging some key templates with the hope of leveraging this funcationality more broadly.
Group 3 with their custom site defintions. Ouch. The upgrade schema mapping failed the first time they tried. They've hired a systems integrator to come back in and map out what they had built with their site defintions. It didn't seem that complex. They are now trying to get back to either 1) using the out of the box site definition for upgrade or 2) creating their new site definition on v3 and creating the mapping file with simple dropping of what they had build that was custom. They found that what they were doing with their site definition they can now do with master pages. After some frusteration, and some excitement around what they can do with Master Pages, Features, and Solution deployment, they're more excited than ever. They've built out their new infastructure and teams are already jumping on the bandwagon of the new farm. Some are suggesting dumping the old environment, but looking at it across the hundreds of sites, there are about 20 they still want to migrate. So they will either migrate the data with an import export or migrate the data. Getting to the out of the box site definition seems like the easiest solution, but the data migration simply getting the data to disk and copying it to the V3 document libraries is super easy, but it will loose their meta data. They are investigating all their options.
What are they doing now?
Group 1, they love SharePoint Designer and have embraced it. The company does want to push out a common master page to get some common branding across the sites. They will be creating a feature to drop and apply the master page when the new feature is created. It will be deployed by using a solution deployment package. This is currently the only planned top down customization they plan to do. (See Andrew Connell's awesome sample code on this which comes out of one of his WCM Internet Sessions.
Group 2. They have embraced Designer for a select few, those with training and business design needs with plans for simple workflows, dataforms, and UI page layouts and master pages. They have about 10 site templates and have eased up on branding. They have come up with plans to create their own set of application templates based on company needs. They have setup a site to gather feedback on the application templates and are interested in gaining best practices around the platform and its use inside the company.
Group 3, They haven't yet embraced Designer. They are curious about the master pages and workflow design aspects as a tool for the business design folks, but not sold on having this broadly deployed. Visual Studio is their developers choice and having them using SharePoint designer is still a stretch. They do love features and solution deployments, and these will all come from Visual Studio projects. They are blocking designer and any customizations outside of those that the business development team rolls out. This may change as the business learns about what it can do with workflows and dataforms. There may be some level of compromise with policy on design.
I've heard many say. Unghosting or Ghosting doesn't apply anymore. It's true that unghosting a page doesn't break all the laws of inheritance anymore, but it is still a consideration. If you unghost or customize a page and add custom zones, do expect the question when you upgrade, do I reset to the site definition or not. SharePoint Designer is much much smarter about how it unghosts a style or page, it will not unghost a page and all its elements just by opening and clicking save (something that happens with Frontpage and WSS 2.0).
My advice? Don't be afraid of unghosting, cause now you do have the ability to reghost, it's called revert to site definition. If you're afraid of what the reset to site definition might do to a page to a site that was customized before it was upgraded or even after, my suggestion is to do it in SharePoint Designer. If you do this, check it out, make you changes, if you like them then check them back in, otherwise you can reject them and roll back to the customized version (if you use check out and have versions enabled). (Steps below.) This is something you can't do if you do the reset page or reset site via the browser.
Those that tell you the considerations around unghosting is performance related, I'd argue that it is actually faster when the page is unghosted. In my testing, an unghosted page is faster to retrieve if it is exactly the same size as the one on disk? Why, it appears to be a call to the database to see if the page is unghosted anyway. I did do some perf testing, expecting to see that the default (ghosted) state was faster, they are both in the milliseconds, but the unghosted page was faster. As well, if it's any consolidation, MS IT fits scenario one pretty close, they did allow some site templates, but you don't see many of them now days. They are about as out of the box as you can get when it comes to their main "SharePoint and Team" farm. When site hosting is seen as a commodity and like hosting a mailbox, then running things out of the box REALLY scales and is very hands off.
I do want to suggest a new best practice that I may have mentioned before. If you don't HAVE to modify the site definition and can in any way shape or form can do this with a feature in a solution deployment package. I STRONGLY suggest it. The gist of it. Assume you CAN do what you want with the out of the box site definition and custom features including master pages, page layouts, etc... You'd be amazed what you can do. I'd love to see a list of what you can't do with a "Feature" in a list on some blog. Custom Site Definitions are extremely powerful if you know what you're doing, but know you should plan on spending some portion of what you pay to build to upgrading those definitions to the next version. I highly recommend adding supportability and upgrade in your development agreement if with an external consulting or services firm. This may be revealing to you.
Going back to the original topic of To Unghost to Not to Unghost, let me share some a decision that you do have in your upgrade. If you do your upgrade via the command line you can CHOOSE, whether you revert the sites to the site definition during upgrade! The Upgrade sites by using the command line reference is on TechNet, but I'll distill a couple of samples here. Much of the text and commands below are taken from TechNet.
How do I reghost during upgrade? There are a few ways. The optional -reghost when used with the operation -upgrade specifies whether to reghost pages (reset pages to site definition).
To configure the farm to be setup to reghost on upgrade for your gradual/side by side upgrades:
psconfig.exe -cmd upgrade -sidebyside -reghostonupgrade
STSADM Upgrade Options:
stsadm.exe -o upgrade [-inplace | -sidebyside] [-url <url>] [-forceupgrade] [-quiet] [-reghost] [-farmuser <farm user> -farmpassword <farm password>] [-sitelistpath <sites xml file>]
To specify specific web applications or sites to be reghosted.
Reghost In Place (dev/test environment):
Reghost: stsadm -o upgrade -inplace -url http://myv2webapp -reghost -forceupgrade
Reghost Web Application during Gradual Upgrade
stsadm -o upgrade -sidebyside -url http://myv2webapp -reghost -forceupgrade
Reghost Site Collections during Gradual Upgrade
stsadm.exe -o upgrade -sidebyside -url <url> -sitelistpath <path to XML file>
Example: stsadm.exe -o upgrade -sidebyside -url http://myv2webapp -sitelistpath c:\mysitelist.xml
If you don't want to upgrade all the sites in a web app you can leverage the redirects functionality, target databases, all through a simple commandline. With Gradual/SidebySide you can specify a site list and even target the database the sites can be upgraded to. The format of the XML file is:
<RedirectedSites Count="2”> <Site Url="http://server_name" TargetDatabase="DB1" /> <Site Url="http://server_name/sites/site1" TargetDatabase="DB1" /> </RedirectedSites>
The “Count” and “TargetDatabase” attributes are optional. Specify just the set of sites you want to upgrade from a single content database. Running stsadm -o enumsites -url http://yourv2webapp will give you output you can use to create the XML sitelistpath.
Alternatively as you get going, you can use the command “stsadm -o enumsites -url <V3url> -redirectedsites” to produce this same XML for site collections that require upgrade. You can then remove the sites you don't want upgraded, and use it as your xml input for your sitelistpath.
Don't forget to check your logs: The Upgrade.log file and the trace log file are located at %windir%\Program Files\Common Files\Microsoft Shared\web server extensions\12\LOGS. The trace log is: Machine_name-YYYYMMDD-HHMM.log
Additional Resources:
DLC Team Blog: Customizing SharePoint UI info on SharePoint Designer customizing MasterPages, CSS Great quote from here... As well a few good references to the new "reset" options including a nice screenshot of the message asking you if you want to customize a page making it different than the site definition. Customize = Unghost. "To determine [if a page or style sheet is unghosted/customized], right click on the file from the "Web Site" view in Designer. If you see the "[Reset] to site definition" menu option, then this is an un-ghosted copy. If not, then this is the ghosted file." italics added for emphasis.
Office.Microsoft.com: Reset a Customized Page to it's Site definition (referred to above) "The Reset to Site Definition command is not available for every page in a site. If the page was not created by customizing an existing page, but instead was either created from a blank page or created in another program and then imported into the site, then the page has no association with the site definition, and therefore you cannot reset it to the site definition. " This is a really good tip. If you have deleted you home page and replaced it with another from say a sub site, you cannot reset it!
The complete how to set a page to it's site definition is on that page, here's an anchor to the section on setting a page to its site definition.
How do I find out what pages are customized? In WSS 2.0 or SPS 2003 you could run prescan.exe or Ghosthunter (part of the web part toolkit), in WSS 3.0 or MOSS 2007 you can use SharePoint Designer, for more info see Track Customized Pages
Heather Solomon has some of the more complete sets of info on Site Definitions that I've ever come across. She is highly recommended when it comes to SharePoint site design and customizations, knowing what to do and doing it right.
A good drop into the old debate... Maurice (Bluedogunlimited) has great insight with interesting comments. He has an excellent post on an explanation of what unghosted and ghosted pages are and what they look like from a database perspective. Referring to unghosted pages - "This effectively means that for each [page], you will find a row in the docs table... The actual file is stored in the Content column."
