All the issue of this have finally been created, so here is a shortcut list to get to all three issues:
Part 3: Advanced Configuration and DR
So there have been a number of posts put out on the web about automating the installation of WSS and even MOSS for development desktops and test servers, but I haven't seen much written about production farms, so here's my 2 cents.
There is a huge gain waiting to be realized in repeatable, dependable process with automated installation. On major gain is in Disaster Recovery. Time saved in manual procedures vs. automated installation processes can be as high at 2x.
Recently, in an effort to clean up some residuals surrounding a number of farm changes that were not done correctly, as well as to test our DR plans, we flattened our entire farm down to bare metal, and rebuilt. In doing so, we found that we saved over 8 hours of recovery time vs. our dry runs with a manual process. Our process installed MOSS, configured the basic farm options, configured some advanced options we needed in our farm, recreated all Web Apps, and reattached all content DB's (which had already been restored from tape).
After executing this script, we only had two additional activities to perform which could not be scripted out-of-the-box: configuring and scheduling the SSP Profile Import, and configuring the content sources and crawl schedules.
So what steps are required for something like this? You're in luck, because I'm going to give it to you...
1st: Install MOSS. The easiest way to get this done is to have a local file source for installing the application on your server. I like to create an "install" source on a utility server that I copy to my servers, with the x64 (or i386 if you are still 32-bit) dir along with any utility apps (I always install Notepad++ and PowerShell on my servers for troubleshooting and configuration) and patches. You can also include custom SharePoint Solutions or WebPart Packs.
At the root of the x64/i386 folder, I create my script. I start with the installation. You need to make an XML document that dictates what your configuration will be. It looks something like this:
<?xml version="1.0" encoding="utf-8"?>
<Configuration>
<Package Id="sts">
<Setting Id="LAUNCHEDFROMSETUPSTS" Value="Yes" />
<Setting Id="REBOOT" Value="ReallySuppress" />
<Setting Id="SETUPTYPE" Value="CLEAN_INSTALL" />
</Package>
<Package Id="spswfe">
<Setting Id="SETUPCALLED" Value="1" />
<Setting Id="REBOOT" Value="ReallySuppress" />
<Setting Id="OFFICESERVERPREMIUM" Value="1" />
</Package>
<Logging Type="Verbose" Path="c:\moss_logs" Template="Office Server Setup(*).log" />
<Display Level="None" CompletionNotice="no" />
<PIDKEY Value="Your Product ID Here" />
<Setting Id="SERVERROLE" Value="APPLICATION" />
<Setting Id="USINGUIINSTALLMODE" Value="0" />
</Configuration>
You obviously need to replace your PIDKEY with whatever your licensing number is. This is the XML required by a MOSS installation for an Application server. By changing the "ServerRole" key to "WFE" you can install a Web Front End server. You can also use the ServerRole of SINGLESERVER, but I recommend against this in most cases. Single Server setups can never be expanded at all. you're normally better off installing as APPLICATION, which includes the WFE and App (SSP/Admin) roles so you can add servers to the farm later. If you know it will never grow, then use SINGLESERVER.
You can script the installation with your xml like this:
SETUP.EXE /config MySettings.xml
This will give you the base MOSS files, without and system configuration.
2nd: System Configuration is done in a script using the PSCONFIG.EXE utility. There are a few commands that must be used, and they are as follows:
Configdb, HelpCollections, SecureResources, Services, InstallFeatures, AdminVS, and ApplicationContent.
In your install script, it make life much easier if you add a pth statement like this:
path %path%;"C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\BIN"
...before you start in with PSCONFIG and STSADM commands. PSCONFIG will always have a "cmd" that dictates what part of the utility we are executing. The first PSCONFIG command, ConfigDB is the key command for either creating, or connecting to the config database for the farm. The command looks something like this:
psconfig -cmd configdb
-create
-server MyServerName\InstanceName
-database MOSSFarmConfigDBName
-user Domain\FarmAdmin
-password FarmAdminPassword
-admincontentdatabase MOSSCentralAdminContent
The key parameter's here are as follows:
Create: This is to make a new DB. To connect to an existing one, "Connect" would be used.
Server: This is the SQL Database Server that will hold the Config DB for the Farm. If it is a named instance, be sure to include the instance name.
Database: The name of the database to create or connect to. If creating, it must not exist currently.
User: The name of the farm admin account that will be used to connect to the ConfigDB. It needs to have permissions on the local server, as well as on the DB server.
Password: The password for the farm admin account.
AdminContentDatabase: The name of the admin content DB on the SQl server that houses the config DB.
There are other parameters, but these are the most commonly used. The AdminContentDatabase parameter is not needed on a "Connect", and the user and password are not needed on a create for a SINGLESERVER deployment, as Network Service is used for the farm admin account.
After running the ConfigDB command, a few other commands need to be issue to complete the system configuration:
psconfig -cmd helpcollections -installall
psconfig -cmd secureresources
psconfig -cmd services -install
psconfig -cmd installfeatures
psconfig -cmd adminvs -provision -port 5555
-windowsauthprovider onlyusentlm
psconfig -cmd applicationcontent -install
There is a parameter on the AdminVS command that is handy that I like to specify (it is optional)... The -port parameter. It allows you to specify which port the central admin app will live on. Obviously if this is not a server that will have central admin on it, you do not run this command.
Well, this ended up much longer than originally anticipated, but that is because I like to know "why", so I added some "why". Part two will be coming soon, and will include stuff like provisioning Shared Service Providers, and creating Web Applications... Until then...
0 comments:
Post a Comment