So we've got another MOSS environment to brand for my customer. This time it's an extranet environment for partner collaboration that has some very minor changes from the Intranet branding implementation I've described in the initial series of posts. Changes are pretty superficial - swap the logo, remove certain components that are only applicable to the Intranet environment, and update the header and footer.
Implementing the actual branding tasks isn't anything new. What is new is that I've taken a different approach this time around to ease configuration management headaches - mostly due to having adequate time in the project schedule and complete ownership of the development tasks. The implementation design changes are based on two major changes:
I'll post the gory details in the next few weeks, once I've finished prepping for delivering SharePoint Academy classes, but below is a quick summary of the tactics and some lessons learned.
This is basically a revisit of the tactics described in part 3 of my initial series of branding posts. We used KB944105 method 1 (taking a backup copy of the LAYOUTS directory) for a handful of files that needed updating, like CORE.CSS, SPTHEMES.XML, some IMAGES files, and the various WEBTEMP*.xml files (there were a few sitedefs we wanted to hide from end users), but the branding of the LAYOUTS pages was accomplished via redirects.
We used the following set of redirects (read my previous posts and you'll see why these were selected):
<redirect pattern="/_layouts/SiteManager.aspx" destinationPageUrl="/_layouts/customizations/SiteManager.aspx" />
<redirect pattern="/_layouts/templatepick.aspx" destinationPageUrl="/_layouts/customizations/templatepick.aspx" />
<redirect masterPageUrl="~/_layouts/customizations/NEW_simple.master" originalMaster="simple.master"/>
<redirect masterPageUrl="~/_layouts/customizations/NEW_application.master" originalMaster="application.master"/>
While unit-testing the ResourceRedirect, I found a couple of bugs and flaws in the approach:
Important Update: Contrary to the contents of this post, you'll likely need to deploy your branding code as a combination of a Web Front End solution and an App Server solution. I'll have an updated post on this topic by late April.
I can't overstate how much easier this makes the deployment process, or how much I wish I would have had the time to implement this approach with the Intranet branding before handing off the prototype to the dev team... :( Anyways, I used WSPBuilder to prepare the solution, which saved many many hours of tweaking a solution manifest and reduced the activity of prepping a solution to copying a bunch of files to a temporary directory. It's my new hero.
You'll still need to perform a backup of any "12" directory files that you might customize. Beyond that, you've got several options for how you structure, deploy, and undeploy the solution. They differ in how you handle NEW components and REPLACEMENT components (overwriting OOTB files in the "12" directory):
I'm sticking with Option 3 for now, since it puts the "12" hive originals in source control, spells out very clearly to the development team which components have been customized, and minimizes installation effort. Option 2 sounds a little dangerous, since you could destroy "12" hive files if you didn't capture the original backup.
Along with the solution, I wrote a simple batch file to install the solution and activate the feature stapler. There's still some manual effort involved in updating the web.config to include the ResourceRedirect configuraiton, but it's a very minimal amount of low-level configuration work. There's also an uninstall script that's step 2 from Option 3. Note that both include PAUSEs, since it's essential that you wait for the solution deployment/retraction to complete before the script executes all tasks. The install script also uses the BrandingUpdate application from my previous posts.
The install script also uses the BrandingUpdate application from my previous posts. Note that you'll need to execute the IISRESET on ALL farm servers, so you might want to include another PAUSE there to allow admins to complete that step on all servers.
echo Adding solution to farm...
stsadm -o addsolution -filename customizations.wsp
echo Deploying solution...
stsadm -o deploysolution -name customizations.wsp -immediate -allowgacdeployment -allowcaspolicies -force -allcontenturls
echo Please navigate to "Central Administration > Operations > Solution Management" to confirm deployment.
echo Once Customizations.wsp indicates a status of 'Deployed', hit any key to proceed with the installation.
echo Activating feature stapler...
stsadm -o activatefeature -name BrandingStapler -url http://sites.contoso.com
echo Resetting IIS...
echo Updating branding on existing sites...
echo Branding installation complete. Please update web.config settings for branding redirects in all applicable web applications.
Note that you'll need to execute the IISRESET on ALL farm servers, so you'll need to perform that on any other WFEs after the script completes. You still need to manage the deployment of "12" directory replacements as described above, either manually or through other scripts.
echo Retracting solution...
stsadm -o retractsolution -name customizations.wsp -immediate -allcontenturls
echo Please navigate to "Central Administration > Operations > Solution Management" to confirm retraction.
echo Once Customizations.wsp indicates a status of 'Not Deployed', hit any key to proceed with the uninstall.
echo Deleting solution...
stsadm -o deletesolution -name customizations.wsp
echo Branding uninstall complete.
echo Please update web.config on all applicable web applications to remove branding redirects.
echo Please restore all original "12" hive files from backup copies.