So here is the last installment in this series, the Extra's... In Part 1 we installed the product and did the base configuration... In Part 2 we configured the SharePoint Server Shared Services and got rid of that annoying Red warning test on the Central Admin Site. In this installment, we are going to look at above and beyond functions, like:
- Creating additional Web Apps
- Enabling Self-Service Creation
- Alternate Access Mappings
- Managed Paths
- Installing Features and/or WebPart Packs
- Attaching Content DBs
Creating additional Web Apps is very simple. We use the same command we used earlier, ExtendVS. This is valuable in many places. For a new farm, you can have it create your root web as well, although this is generally something I recommend against. The reason is that configuring your Web Application Creation Scripts without the Root Web prepares your script for Disaster Recovery in the future.
If you have existing content and are using your install scripts to recover, you must make sure that you do NOT create the root web... Doing so will prevent the ability to recover your original root web via attaching Content DBs. I use this as a standard, and manually create the Site Collections (either via GUI or STSADM Script with CreateSite or CreateSiteInNewDb).
Again, if you are preparing your script for DR, I recommend creating the Web App with a dummy Content DB, and adding a command to remove that DB at the end of the script, after your attach DB command(s). If you want to remove that DB manually, make sure you add a comment at the end of your DR script to remind yourself, or you may be in for a surprise a few days after a DR recovery!
Self-Service Creation is for "team" or self-provisioned environments, and is enabled using the EnableSSC command:
stsadm -o enablessc -url http://sharepoint.domainname.pri:80
This is handy to enable automatically on setup, but for DR purposes, you have to remember that this cannot be enabled unless the root web exists. If recovering Content DBs, you need to create the Web App with no Root Web, Reconnect the Content DB(s), and then enable SSC, once the Root Web is online again.
As you setup your Web Applications, it is good to configure any Alternate Access Mappings you may need (ie, Extranet, Intranet, etc.) The AAM can be configured per Web App by script using the AddAlternateDomain command, which looks a bit like this:
stsadm -o addalternatedomain -url http://sharepoint.domainname.pri:80 -incomingurl http://intranet:80 -urlzone intranet
Which would allow your SharePoint site to respond to http://intranet as well as http://sharepoint.domainname.pri. This does not do anything for name resolution though. All DNS/NetBIOS resolution is still up to you to configure on your network, this just allows SharePoint to respond to it when it reaches your servers. A number of different "urlzone" parameters can be used here, including intranet, internet, and extranet.
In the same vein, configuring the Managed Paths of a Web App are also important. Including all Wildcard Inclusions or Explicit Exclusions will save you time and heartache, especially in the case of minimal documentation. Reattaching a Content DB with a Site that lives on a Managed Path that is not configured will not appear accessible until the path has been added to the Web App. I strongly recommend making each Managed Path change by script (rather than manual) and adding that to your master DR script as your first form of documentation. Additional environmental documentation is definitely desirable, however, if you are religious about your inclusion of all farm configuration changes to your DR script, you now have enough to get by.
Managed Paths are modified using the "AddPath" command. It looks something like this:
stsadm -o addpath -url http://sharepoint.domainname.pri:80/project -type wildcardinclusion
Also make sure to remove the "sites" wildcard inclusion if you don't normally use it, or you will find they sprout up quickly in an SSC environment.
With all the Web Apps created and configured, you are almost ready to attach Content DBs. Before doing that, you should install any solutions required by your farm. Installing solutions (and deploying them) is something that, like Managed Paths, should always be carefully documented. I include all custom code (non-OOB software) in this category. If there is a Feature-set that is a commercial product with a full installer, I put a set of comments detailing what versions and service packs of that product are installed, with an echo line to remind the script-runner that there is additional activities required at that point. If it is required prior to the content being restored (or earlier in the process), I recommend inserting the echo statement with a pause. The ideal would be a silent install option scripted right in, but that is not always possible.
For those third-party and home-grown Feature-sets that are compiled in to SharePoint Solutions, you can install them with the "AddSolution" command, and deploy them with the "DeploySolution" command:
stsadm -o addsolution -filename MyCustomFeature.wsp
stsadm -o deploysolution -name MyCustomFeature.wsp -url http://sharepoint.domainname.pri:80 -force -immediate
Lastly, attach your Content DBs to your farm again using the "AddContentDb" command. I strongly recommend issuing an IISReset command prior to this to make sure all changes have taken affect. the Command is formatted like this:
stsadm -o addcontentdb -url http://sharepoint.domainname.pri:80 -databasename WSS_Portal_Content_01 -databaseserver DBServerName\NamedInstance -sitewarning 50 -sitemax 70
This can also be used to deploy schema changes with less farm disruption for larger farms... When deploying schema change patches and service packs, the first node must finish updating the entire farm before things come back online. This can take hours for larger databases, even on big hardware. To minimize this impact, the DB's can be removed from the Web App, taking all the sites offline, then the patches can be applied, then the DB's can be re-attached. this updates the schema in the Content DBs one at a time, bringing each online and accessible after it has finished the update. Although the total time is about the same, the downtime for the farm is less, as you can selectively bring the most critical data online first and roll-through the DBs in a business-criticality order.
Well, this does it for the automated installation series... Hopefully your gotten something useful out of it, as I did while learning about this process. If you want to automate the process of making these scripts, take a look at the CodePlex project I've been working on for this... It is still in an Alpha state, but try it out and see what you think:
NSOT SharePoint Office Server Installation Script Generator
