Thoughts about IIS (and now SharePoint!) : IIS

So, your IIS Manager comes up blank, too?

jamesbl — Fri, 29 Feb 2008 00:33:51 GMT

Have you ever opened the IIS Manager MMC (quick shortcut - Start/Run/inetmgr) only to find it comes up completely blank? Also, keen eyes will notice it takes a lot longer for the MMC window itself to appear as well, when this problem occurs. This phenomena appears to only occur if you have MOSS installed.

In any case, if you have seen this problem on one or more servers in your farm, you can work around it by simply restarting the OWSTimer service ("Windows SharePoint Services Timer" service). This is fairly acceptable to most since it does not require you to reset IIS or reboot the server (i.e. no downtime).

The good news is there is now a hotfix that should resolve this issue! Give Microsoft Support a call if you're experiencing this issue.

Script for enabling full IIS logging

jamesbl — Sun, 03 Feb 2008 11:23:21 GMT

Nothing overly fancy, but useful enough to warrant sharing. This is something you can use to get your SharePoint farms set up to turn every IIS logging option on. The good news is each web site in a MOSS farm shares the same web site ID, so it should be pretty easy to batch up:

Option Explicit

On Error Resume Next

Dim CmdLineArgs

Dim CurrSite

Dim CurrSiteObj

' Obtain all command line args

Set CmdLineArgs = WScript.Arguments.Named

' verify args

If (Not CmdLineArgs.Exists("SiteID")) Or _

(Not CmdLineArgs.Exists("Server")) Then

Wscript.Echo "Error: Invalid number of command line arguments specified."

Wscript.Echo

Wscript.Echo "Usage: ""cscript FullLogging.vbs /Server:<ServerName> /SiteID:<WebsiteID>"""

Wscript.Quit

End If

CurrSiteObj = "IIS://" & CmdLineArgs.Item("Server") & "/w3svc/" & CmdLineArgs.Item("SiteID")

Set CurrSite = GetObject(CurrSiteObj)

If Err.number <> 0 Then

Wscript.Echo "Error querying IIS provider: " & CurrSiteObj

Wscript.Echo "Error = " & Err.number & " - " & Err.Description

WScript.Quit

End If

CurrSite.LogExtFileDate = True

CurrSite.LogExtFileHost = True

CurrSite.LogExtFileTime = True

CurrSite.LogExtFileClientIp = True

CurrSite.LogExtFileUserName = True

CurrSite.LogExtFileSiteName = True

CurrSite.LogExtFileComputerName = True

CurrSite.LogExtFileServerIp = True

CurrSite.LogExtFileMethod = True

CurrSite.LogExtFileUriStem = True

CurrSite.LogExtFileUriQuery = True

CurrSite.LogExtFileHttpStatus = True

CurrSite.LogExtFileWin32Status = True

CurrSite.LogExtFileBytesSent = True

CurrSite.LogExtFileBytesRecv = True

CurrSite.LogExtFileTimeTaken = True

CurrSite.LogExtFileServerPort = True

CurrSite.LogExtFileUserAgent = True

CurrSite.LogExtFileCookie = True

CurrSite.LogExtFileReferer = True

CurrSite.LogExtFileProtocolVersion = True

CurrSite.LogExtFileHttpSubStatus = True

CurrSite.SetInfo

wscript.echo "Done!"

Set CurrSite = Nothing

Set CmdLineArgs = Nothing

Have fun.

Edit: If you want to trim the log size down, do not enable the Cookie field, since this can cause the logs to grow rather large over time:

CurrSite.LogExtFileCookie = False

Thanks, Todd.

What Application Pool does this W3WP.EXE belong to?

jamesbl — Wed, 22 Feb 2006 07:58:00 GMT

During the course of working through issues, I get asked at least twice a week how to determine which application pool maps to a particular worker process PID (Process ID) on a server. I suppose there are lots of ways to determine this, but here two that come to mind to determine the answer.

The first way, and by far the easiest, is to use one of the new scripts that come in the box called IISAPP.VBS. It is located in the %SystemRoot%\system32 directory. For example:

C:\WINDOWS\system32>cscript iisapp.vbs
Microsoft (R) Windows Script Host Version 5.6
Copyright (C) Microsoft Corporation 1996-2001. All rights reserved.

W3WP.exe PID: 1172 AppPoolId: StsAdminAppPool
W3WP.exe PID: 2656 AppPoolId: MSSharePointAppPool
W3WP.exe PID: 2148 AppPoolId: WMS App Pool
W3WP.exe PID: 3604 AppPoolId: defaultwebsite

As you can see, this script makes it very easy to determine what the PID is of each specific Application Pool. This is nice to use when trying to determine which PID you may want to snap a dump of for debugging purposes.

There are others that are cool as well. For more details on the various other scripts that are also included, see this link. I also encourage you to open a command prompt, navigate to your system32 directory on your IIS6 machine then run a "dir iis*.vbs" command and check out the new scripts.

The second way is a bit more obscure and requires that you run the tlist.exe command, which comes with the Debugging Tools for Windows. Here is an example of that, which is fairly interesting:

C:\Program Files\Debugging Tools for Windows>tlist -v
0 1172 w3wp.exe
Command Line: c:\WINDOWS\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipmec19a7d8-c08d-42f4-b2c9-69d7cfe28c74 -ap "StsAdminAppPool"
0 2656 w3wp.exe
Command Line: c:\WINDOWS\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipm4bc52071-9ebb-4e39-9ba5-b256b4be4014 -t 20 -ap "MSSharePointAppPool"
0 2148 w3wp.exe
Command Line: c:\WINDOWS\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipmfa132134-c1ed-47d4-be52-417ce5a59e63 -t 20 -ap "WMS App Pool"
0 3604 w3wp.exe Title: OLEChannelWnd
Command Line: c:\WINDOWS\system32\inetsrv\w3wp.exe -a \\.\pipe\iisipmdd93382a-645a-467c-bdbd-07c3ad6833a4 -t 20 -ap "defaultwebsite"

Note: I snipped all other processes and only left the 4 W3WP.EXE processes that we're interested in.

If you look carefully above, you will see the name of the Application Pool specified directly on the command line for W3WP.EXE! You mean you can call this thing directly? Interestingly enough, there are documented command line options for it. Interesting? No? Bonus points if you can tell me why the last application pool has a Title of "OLEChannelWnd" :)

For those interested parties still left reading, here are the command line options for W3WP.EXE that are documented via -?:

C:\WIN2003\system32\inetsrv>w3wp -?
Usage: w3wp [options]

        -debug
                 This option is required for launching from the command line.
                 If not provided the app pool name, default url, and site id
                 will be defaulted to
                         AppPoolName = StandAloneAppPool
                         URL list    = http://*:80/:80/:80/
                         Site Id     = 1

        -ap <Application Pool Name>
                 Indicates the application pool name
                 that will queue requests for the
                 worker process. No other worker processes
                 with this name can be running at the
                 same time as this one

        -d <URL List>
                 Indicates the urls to listen to.
                 Examples:les:
                         http://*:80/:80/
                         http://HostString:80/
                         http://111.11.111.11:80:111.11.111.11/
                         http://HostString:80:111.11.111.11/

        -s <#>
                 Which site are the urls provided associated with.
                 The site number is used to access data from the metabase
                 for processing the requests.sts.

Good night...for now.

IIS6: "Supposed" Metabase Corruption

jamesbl — Fri, 13 Jan 2006 19:59:00 GMT

Prologue (required boredom)

I recently worked on an issue where the IIS Admin service would not start after a reboot. The customer had just finished installing a set of patches, and thought that might be related (we'll soon see that it wasn't related). The error was:

Event Type: Error
Event Source: Service Control Manager
Event Category: None
Event ID: 7024
Date: xx/xx/2005
Time: xx:xx:xx PM
User: N/A
Computer: xxxxx
Description:
The IIS Admin Service service terminated with service-specific error 2148073478
0x80090006).

After much initial troubleshooting by more than enough people, metabase XML files were backed up, renamed, re-copied, scrubbed, analyzed, scrutinized, and investigated. Machinekeys were then targeted, checked for proper ACLs, etc. and after nothing worked, the conclusion was metabase corruption, and IIS should be uninstalled and reinstalled. This solved the issue, but for all the wrong (and unknown) reasons.

This had occurred, however, on 3-4 other occasions in the customer's environment, so it was time to find out why. Like clockwork, the problem occurred again, so thanks to a friend in Exchange (you know who you are) asking me to give my .02 cents, I got my chance to look at it.

Epilogue (the good part)

In my experience, the reason IISADMIN fails to start in this scenario is because of a failure to decrypt secure data in the metabase, which, of course, brings us back to our old friend Machinekeys. The machine key is a file that IIS uses to decrypt secure data in the metabase. There can be many machine key files in the MachineKeys directory, but the IIS specific one starts with "c2319", which I remember thanks to the memorable quote in Monsters, Inc. (and now you will too).

There's a little known fact that the machine key file IIS uses can be stored in one of two locations. The typical one everyone seems to know is:

%ALLUSERSPROFILE%\Application Data\Microsoft\Crypto\RSA\MachineKeys

The other location that is not so well-known is:

%windir%\Profiles\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys

This is almost always due to the fact that the machine had been originally upgraded from NT4. We looked in the registry under the following key:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Shell Folders

and confirmed the Common AppData value was, indeed, pointing to the C:\Windows\Profiles directory! Now we're getting somewhere!

Next we made copies of the multiple sets of machine key files, deleted the "c2319" machine key file in the \Windows\Profiles\...\MachineKeys folder and then copied the one from \Documents and Settings\...\MachineKeys into the \Windows\Profiles\...\MachineKeys folder and voilà this was a match! IISAdmin started just fine.

The keen reader should notice this means IIS WAS using the \Documents and Settings\...\MachineKeys folder initially and something changed it after the fact. This is the reason for my almost comment above. Upon further inspection, it appeared the customer had installed a piece of older software (NT4 version, perhaps?) that actually modified the registry to point to the \Windows\Profiles\...\MachineKeys directory. OUCH!

One other tidbit I noticed during the course of working on this issue is if you delete the machine key IIS uses, then attempt to start IISADMIN, another "c2319" machine key file will be created using the same filename. The problem with this is the data/private key inside will not match what was used to encrypt the metabase data initially, therefore, it's completely useless and IISADMIN will not start. This leads me to ask why it's created in the first place. If you know, I would love to hear...