nitashav

Diagnose Failures with Remote Management

NitashaV — Tue, 18 Dec 2007 21:52:00 GMT

Diagnose Failures with Remote Management

Good place to start if you want to learn about how to configure remote administration for IIS Manager: http://learn.iis.net/page.aspx/158

This is a long overdue blog entry. It's an attempt to help you all diagnose any issues you might come across while using Remote Manager. My assumption is that you know how to get started and have run into issues while using the Remote Manager. This is based on frequently asked questions on iis.net forums. This troubleshooting applies to all remote management (i.e. downlevel --> 2K8 and 2k8-->2k8).

1) Cannot connect to the remote server?

Make sure the client and the server are using the same build. For example, Server Beta 3 Remote Manager client will not work with a RC1 server build and so on...
Refer to the blog about Remote Management Behavior Matrix located at: http://blogs.iis.net/nitashav/archive/2007/04/23/remote-management-behavior-matrix.aspx ; there might be problems because of acls.
Look at the Event Viewer (eventvwr.msc) log: *wmsvc has a good supportability story; events are logged with detailed error message and stack trace. Most of the time, looking at the Event Viewer will tell you what the problem might be.

2) Cannot connect to the remote server after updating *wmsvc bindings?

If this happens after you updated the port on which wmsvc is configured to run, check if the firewall is turned on for the server. If it is, add a new exception rule for the port on which wmsvc is running (default value: 8172). Now try connecting to the server again.

If this does not solve the problem, run the following commands from cmdline

netsh http show sslcert

Ensure that the port 8172 (the one on which wmsvc is running) has ssl certificate bindings. Also make sure the cert hash matches the one to which wmsvc is bound to (in the Management Service UI)

Sample output:

c:\>netsh http show sslcert

SSL Certificate bindings:

-------------------------

IP:port                 : 0.0.0.0:8172

Certificate Hash        : f06ae62a5275a818338f05ecc80707335be1e204

Application ID          : {00000000-0000-0000-0000-000000000000}

Certificate Store Name: MY

Verify Client Certificate Revocation    : Enabled

Verify Revocation Using Cached Client Certificate Only: Disabled

Usage Check    : Enabled

Revocation Freshness Time: 0

URL Retrieval Timeout   : 0

Ctl Identifier          : (null)

Ctl Store Name          : (null)

DS Mapper Usage    : Disabled

Negotiate Client Certificate    : Disabled

netsh http show urlacl

Ensure that the url https://*:8172/ (port on which wmsvc is configured to run on) shows up in the list of reserved urls

Sample output:

c:\>netsh http show urlacl

URL Reservations:

-----------------

Reserved URL : https://*:8172/

User: NT SERVICE\WMSvc

Listen: Yes

Delegate: No

SDDL: D:(A;;GX;;;S-1-5-80-257763619-1023834443-750927789-3464696139-1457670516)

If you see that bindings are not correctly configured (using netsh commands in the previous paragraph), the problem might be that the machine key does not have permissions for the administrator trying to tweak wmsvc bindings. In that case, try the following --

Take ownership for the machine key

takeown /F %ProgramData%\Microsoft\Crypto\RSA\MachineKeys\bedbf0b4da5f8061b6444baedf4c00b1* /R

Acl the machine key such that administrators group has read permissions

icacls %ProgramData%\Microsoft\Crypto\RSA\MachineKeys\bedbf0b4da5f8061b6444baedf4c00b1* /grant Administrators:(R)

Reserve the port 8172 for wmsvc

netsh http add urlacl url="https://*:8172/" User="NT SERVICE\wmsvc"

Associate the cert with the port

netsh http add sslcert ipport=0.0.0.0:8172 certhash=<certHash> appid={d7d72267-fcf9-4424-9eec-7e1d8dcec9a9}

3) Do not want to see the prompt on client every time you connect to the remote server?

Make sure your server uses a trusted root certificate for wmsvc. Basically create a trusted root certificate (if you don't already have it) and on the Management Service feature page assign this certificate to be used by the service. This will ensure the client does not get a prompt asking if they trust the server (since the certificate isn't trusted).

4) If all else fails:

Post your issue on iis.net forums (http://forums.iis.net/) with repro steps and details. It would be great if you could send the eventvwr.msc log along with exception and call stack (see below for details on how to get the exception and call stack)

Attach windbg to wmsvc.exe

windbg -pn wmsvc.exe

Load the sos.dll and set a break point if a managed exception happens

.loadby sos mscorwks

sxe clr

Then hit go

g

When it breaks, print the exception and the call stack and send it to us @ iis.net/forums.

!pe

!clrstack

*WMSVC is the service for Remote administration on the server side and can be configured in the UI in the Management Service Page. You can get some more information about this at http://learn.iis.net/page.aspx/158/remote-administration-for-iis-manager/

Remote Management Behavior Matrix

NitashaV — Tue, 24 Apr 2007 01:09:00 GMT

Introduction

Have you tried to use the IIS7 UI for remote administration? There is a matrix of scenarios remote administration caters to. Read on to see how powerful and rich this story in IIS7 is...

I find this remote management behavior matrix to be very useful to get the different remote administration scenarios to work and also to help diagnose 401's. Knowing what identity does what in each scope (server, site, application) helps me ensure the correct set of acls needed at different paths; instead of "give full control everywhere and make it work".

Prerequisites

A pre-requisite for remote management via the IIS7 UI is to start the remote administration service (wmsvc) on the server machine. The configuration of wmsvc deserves another blog which I will post soon.

Getting Started

General rules of thumb (valid for every item in the matrix below):

 Redirection.config, applicationHost.config and administration.config are always read (even when you connect to site and app)

 Redirection.config is always read using the identity in which the service wmsvc runs (by default: NT Service\WMSVC)

 If (configurationRedirection is enabled in Redirection.config)

o Server Config files (applicationHost.config, administration.config) are always read using the username and password specified in redirection.config

Else // configurationRedirection is disabled

o Server Config files (applicationHost.config, administration.config) are always read using the identity in which wmsvc runs (NT Service\WMSVC by default)

 UI does nothing special when trying to read Root web.config (asp.net counterpart of applicationHost.config)

Now let's get to the matrix for other specifics:

Connect as:

Windows Administrator

Windows User

IIS Manager User

Out of the box experience

Server connection:

- UI impersonates as the windows admin when writing to the server config files ( applicationHost.config, administration.config and root web.config)

Site connection:

- UI impersonates as the windows admin when reading from and writing to the site's web.config

App connection:

- same as the site connection

Server connection: N/A

Site connection:

- UI impersonates as the windows user when reading from and writing to the site's web.config

App connection:

- same as the site connection

Server connection: N/A

Site connection:

- Site's web.config file is read from and written to using the identity in which wmsvc runs (NT Service\WMSVC)

App connection:

- same as the site connection

Site or app on UNC

Server connection:

- UI impersonates as the windows admin when writing to the server config files( applicationHost.config, administration.config and root web.config)

Site connection:

- If unc credentials are specified for the unc share, UI will read the site's web.config file using those unc credentials and write as windows administrator

- If unc credentials are not specified for the unc share, UI will read from and write to the site's web.config file as windows administrator

App connection:

- same as the site connection

Server connection: N/A

Site connection:

- If unc credentials are specified for the unc share, UI will read the site's web.config file using those unc credentials and write as windows user

- If unc credentials are not specified for the unc share, UI will read from and write to the site's web.config file as windows user

App connection:

- same as the site connection

Server connection: N/A

Site connection:

- If unc credentials are specified for the unc share, UI will read the site's web.config file using those unc credentials and write using the identity in which wmsvc runs (NT Service\WMSVC)

- If unc credentials are not specified for the unc share, UI will read from and write to site's web.config using the identity in which wmsvc runs (NT Service\WMSVC)

*( see note below)

App connection:

- same as the site connection

*( see note below)

Configuration Redirection is enabled in Redirection.Config

Config files:

applicationHost.config administration.config

Server connection:

- Server files are read using the username and password specified in redirection.config

- UI impersonates as the windows admin when writing to the server config files( applicationHost.config, administration.config and root web.config)

Site connection:

- UI impersonates as the windows admin when reading from and writing to the site's web.config

App connection:

- same as the site connection

Server connection: N/A

Site connection:

- UI impersonates as the windows user when reading from and writing to the site's web.config

App connection:

- same as the site connection

Server connection: N/A

Site connection:

- Site's Config is read from and written to as the identity in which wmsvc runs (NT Service\WMSVC)

App connection:

- same as the site connection

*NOTE: If NT Service\WMSVC does not have permissions to the UNC share (which will be the case for unc shares on another machine, wmsvc means nothing outside the realm of a local machine), update the identity of Web Management Service (services.msc) to be a domain user that has access to the server as well as the unc share.

Recommendation: do *not* use Network Service identity – it is a possible security risk since that's the identity asp.net apps run under. With acls to this account, you have just opened your content/configuration up for anyone to access via an aspx page (ouch!)