This documentation is archived and is not being maintained.
Inside Microsoft.com Web Site Configuration Management
The Microsoft.com Operations Team
© 2008 Microsoft Corporation and CMP Media, LLC. All rights reserved; reproduction in part or in whole without permission is prohibited.
The Microsoft.com Operations Team
Download the code for this article: InsideMSCOM.exe (117KB)
The Microsoft.com operations team is responsible for some of the busiest IIS-based Web sites on the Internet, including Microsoft.com, Windows® Update, MSDN®, TechNet, Microsoft Downloads, and many more. The Microsoft.com Web site alone accounts for daily activity of more than 70 million page views resulting in more than 10,000 HTTP requests per second. That capacity is distributed over 80 identically configured servers that are broken out into 10 network load balanced (NLB) clusters (eight servers per NLB cluster). The resulting infrastructure is positioned in two regionally distributed datacenters. From an IIS 6.0 configuration perspective, the www.Microsoft.com Web site includes more than 350 virtual roots and 190 Web applications broken out into 12 application pools.
So how do we synchronize configurations across all 80 servers? The answer is scripting. The scripting we’ll discuss here allows our team to efficiently build and deploy a new server, as well as roll out changes across the entire array of servers. In this column we’ll present the scripts we use at Microsoft for the tasks you’ll frequently perform as an IIS administrator.
Web Site Configuration Scripts
One way we use scripting across the Microsoft.com family of Web sites is to set baseline IIS configurations on our servers. This allows us to consistently build out servers using all of our customized IIS settings. These settings cover IIS application pool properties, Web extensions, logging, and ISAPI filters (URLScan), to name a few. We package the task of setting those values into a basic loop function to update multiple server hosts simultaneously. In the code download, you'll find several scripts which you can use today to perform many of these same tasks.
The Windows Server 2003 Tech Center provides the following pertinent documents:
Using the Adsutil.vbs Utility
One important script we use is Adsutil.vbs, a powerful administration tool that shipped with IIS 6.0. It uses VBScript along with Active Directory® Service Interfaces (ADSI) to manipulate the IIS server configurations and modify the IIS metabase. Adsutil.vbs requires use of the Windows Script Host (WSH). That means you’ll need to preface each command with cscript.exe or configure WSH to run cscript.exe as the default scripting host. To configure cscript as the default script host running in interactive mode (as well as disable the normal banner), you can issue this command:To get a full list of this utility’s features and syntax, just type:
c:\windows\system32> cscript //H:cscript //I //NoLogo //S.
The primary commands available in adsutil.vbs include ENUM, which enumerates all parameters for a given metabase path; GET, which displays only a single parameter; SET, which assigns a new value to a specific parameter; and DELETE, which deletes a given path or parameter.
Now let’s dig into a few specific examples of tasks you’ll perform using adsutil.vbs.
Application Pool Settings
Microsoft.com divides application pools based on the trust level of the code being placed in each pool. In other words, we place trusted code and untrusted code in separate application pools. We define trusted code as Web applications that have gone through a formal software design lifecycle (SDLC) within the Microsoft.com group. Untrusted code includes everything else, including code that has been developed by other content providers throughout Microsoft and its partner organizations. This may or may not be the way you choose to divide your application pools. You may find that separating application pools by customer, by application, or by some other means altogether more useful for your organization.
Creating a new app pool Regardless of which organizational structure you choose, you can use the following adsutil.vbs command to create your application pools:
adsutil.vbs CREATE W3SVC/AppPools/<apppool_name> "IIsApplicationPool" –s:<server_name>
Viewing app pools on a remote server Once you have created your application pool structure, you can programmatically view all application pools on a remote Web server by issuing the following command:
adsutil.vbs enum W3SVC/AppPools –s:<server_name>
Moving Web app pool membership Now that your application pool structure is in place, you may want to move your Web applications to match this structure. You can do this by changing the AppPoolId entry within the IIS metabase. Adsutil.vbs will allow you to change the AppPoolID with the following command:
adsutil.vbs SET W3SVC/1/root/<web_app>/AppPoolId "<apppool_name>"
The path that follows the SET command in this example (W3SVC/1/root/<web_app>/AppPoolId in this case) specifies the Web server on which to set the Web application’s AppPoolId value. The W3SVC portion of the path tells the script to access the Web server. A value of 1 tells the script that you’re interested in the first Web site on that server. The root is the top level of the Web site virtual root hierarchy.
By default, the application pool recycling setting is based on elapsed server uptime. However, we have modified our application pool recycling setting to be based on virtual memory limits. This is due to the large volume of traffic and the characteristics of the code we have running in each of the app pools on Microsoft.com. In our configuration, a recycle happens when an application pool reaches a virtual memory threshold of 2GB. Just remember that our settings are tuned to our specific environment; you will need to track trends in your site performance and adjust your settings appropriately.
Figure 1 Memory Recycling Settings
Setting the default Web site app pool recycle Figure 1 shows how you can set the default Web site application pool recycle based on a virtual memory limit of almost 2GB in the application pool properties, and here’s the command-line statement:
adsutil SET W3SVC/AppPools/PeriodicRestartMemory 2048000
Set the single Web site app pool recycle You can also set a single application pool recycle setting based on a virtual memory limit of 2GB with the following command:
adsutil SET W3SVC/AppPools/<apppool_name>/PeriodicRestartMemory 2048000
Other Scripted Tasks
Many administrators manage secure sockets layer (SSL) certificates manually, which can be difficult. To make it a little easier, our strategy is to use the IIS 6.0 Resource Kit script IISCertDeploy.vbs to import and bind an existing certificate to the IIS Web site.
Binding an SSL certificate This is a task we perform using the following command:
IISCertDeploy.vbs -c WebServerCert.pfx -p CertPassword -q ON
URLScan is an ISAPI filter that will drop anomalous or predefined requests to your server. There has been debate in the field of whether or not this filter is required, but at Microsoft.com we make this a standard part of every Web site.
Deploying URLScan to a server Our engineers have written a script called URLScanSetup.vbs (which you can find in the code download that accompanies this column). To run it, simply issue this command:
Now that you’ve seen the basic settings we use when configuring Web servers on Microsoft.com, you can begin to script all of your site-specific options in preparation for deployment. Just make sure to document all your configuration settings and institute a plan to track future changes. This is critical in maintaining tight control of your site configuration.
Deploying Configurations to the Enterprise
Once you have configured a "golden" image of your server, make sure you have tested your site functionality. In our case we always deploy the golden image to a pre-production environment to ensure everything is functioning properly prior to a full production deployment. Once we have validated our scripted image, we publish the hosted Web content and code to an NLB cluster and synchronize the IIS metabase.
Copy content from a source to a cluster Publishing content means copying the Web data from a single source to multiple production servers. We use the following command line to copy content from the source location to an NLB cluster of multiple servers:
/f %i in (servers.txt) do xcopy \\sourceserver\share\*.* \\%i\webroot\
Once the content is up to date across all production servers, the IIS metabase will also need to be synchronized. For this task, we use the IISCNFG.vbs script, which was shipped with IIS. This script allows you to export an IIS metabase configuration to an XML file and then deploy or import those settings to a remote server. A few of the parameters you’ll use with this command include: /sp, which specifies the metabase path of the Web site; /children, which is used to export all subkeys of that configuration path; and /inherited, which is used to include inherited properties in the exported file.
Export metabase to a local XML File Before you can go any further, you’ll need to export the metabase to XML, like so:Now that that’s done you will need to import those settings to the targeted production servers. First, you will need to copy the XML file to the targeted server’s local disk. We recommend using the XCopy command you saw earlier but with the updated path to the location of your exported metabase XML file.
iiscnfg /export /f c:\scripts\IIS.xml /sp /lm/w3svc/1 /children /inherited /d Y0urP@$$Wo5d
Import metabase to a remote cluster of servers Once the copy process is complete, run the following command to import the metabase on all of the production servers in your enterprise:
for /f %i in (servers.txt) do iiscnfg /import /f \\%i\scripts\IIS.xml /sp /lm/w3svc/1 /children /inherited /d Y0urP@$$Wo5d
Copy metabase to a target server You can also use the following command to copy the metabase settings directly to the target server. Note that this will replace the target server’s metabase settings, so this is a change you’ll want to make during a planned maintenance window. Here is the command:
iiscnfg /copy /tu domain\user_name /tp P@$$Wo5d /ts <server_name>
Once the content and metabase settings have been synchronized on the target cluster of servers, make sure you test the servers to ensure everything is working properly. Also make sure that you have the appropriate level of monitoring in place (including monitoring of your IIS and system event logs) to catch any problems that may arise.
Once you have deployed your custom site configurations and your sites are handling live traffic, you’ll need to focus on more day-to-day administrative tasks such as managing the state of the Web services and recycling application pools.
Starting the default Web service There will almost certainly be times when you must start, stop, pause, or unpause the Web service. The adsutil.vbs utility allows you to handle these tasks with ease. For example, you can start a Web server by issuing the command:
adsutil.vbs START_SERVER W3SVC/1
The path that follows the START_SERVER command (W3SVC/1) specifies the Web server to be started. The W3SVC portion of the path tells the script to access the Web server. The value of 1 tells the script that you’re interested in the first Web site on that server. To run this command on a remote machine or cluster, (both commands are shown here), add the -s switch.
Remotely start the default Web service There are plenty of times where you will need to start the service remotely, especially in emergencies. To do so, use the following command:
adsutil.vbs START_SERVER W3SVC/1 –s:<server_name>
Remotely start the default Web service on a cluster To remotely start the default Web service on a cluster of servers, you can use this command:
for /f %i in (server.txt) do adsutil.vbs START_SERVER W3SVC/1 –s:%i
In addition to START_SERVER, other adsutil.vbs management options include STOP_SERVER, PAUSE_SERVER, and CONTINUE_SERVER. (See the documentation outlined in the "Adsutil.vbs Resources" box for the complete list of commands along with the proper syntax.)
Remotely recycle an app pool on a target server Remote recycling of IIS application pools is another management task you may need to perform on a remote server or cluster of servers. The custom Windows Management Instrumentation (WMI) code that we use to perform this administrative procedure is also included in the code download on the TechNet Magazine Web site. Using this script, you can remotely recycle a specific application pool on a remote server. If you don’t specify a specific application pool in the command line, all application pools on the Web server will be recycled, with a five-second (5,000 ms) pause in between the cycling of each application pool.
To remotely recycle an application pool on a target server, issue the following command:
recycleapps.vbs <server_name> <apppool_name>
Wrapping It Up
We have covered a lot of ground on how our team configures, deploys, and manages the Web servers for Microsoft.com. The functions outlined here represent the most common tasks that our engineers perform while running the Microsoft.com enterprise. Add these strategies to your Web site management arsenal and you’ll be sure to realize increased operational efficiency. Let us know how it works out for you—we look forward to receiving your feedback!