Take the 2-minute tour ×
Server Fault is a question and answer site for system and network administrators. It's 100% free, no registration required.

I need to manage my IIS7 (Windows Server 2008) remotely with a WMI IIS6 API. So I added the IIS6 WMI Compatibility and IIS6 Metabase Compatibility roles to access the root\MicrosoftIIsv2 namespace.

I have a domain account which is not administrator on the remote machine ; with this right, everything is ok.

I configured these rights for my domain account to access the root\MicrosoftIIsv2 WMI namespace remotely ; note that these rights work perfectly on a IIS6 and Windows Server 2003 :

DCOM :

  • Account in Distributed COM Users > Remote & local access to DCOM

WMI :

  • Root\CIMV2 (I need access here too) > Execute methods, Enable Account, Remote Enable
  • Root\Default (I need access here too) > Execute methods, Enable Account, Remote Enable
  • Root\MicrosoftIISv2 > Execute methods, Enable Account, Provider Write, Remote Enable

IIS Metabase (Metabase Explorer) :

  • LM > Full Control (W3SVC inherits these permissions)

I tried to give some access on C:\Windows\System32\inetsrv too ; don't know if needed.

My issue is :

I can't list the IIS WebSites (\root\MicrosoftIISv2:IIsWebServerSetting.Name="W3SVC/*"). I don't get an 'access denied' but nothing is returned.

  • My API and powershell tests can connect and execute queries in the root\MicrosoftIISv2 namespace
  • I can read the IIsComputer class
    • ex: Get-WmiObject IIsComputer -namespace "ROOT\MicrosoftIISv2" -authentication PacketPrivacy | SELECT *
  • I can't read the IIsWebServerSetting, IIsWebServer ... to list the WebSites : the query returns an empty collection
    • ex: Get-WmiObject IIsWebServerSetting -namespace "ROOT\MicrosoftIISv2" -authentication PacketPrivacy | SELECT ServerComment
  • All queries work perfectly if the account is administrator as already said
  • I am using PacketPrivacy authentication

FI: I got a Warning Event 5605 with the Administrator right or not, that does not seem to have an impact :

The root\MicrosoftIISv2 namespace is marked with the RequiresEncryption flag. Access to this namespace might be denied if the script or application does not have the appropriate authentication level. Change the authentication level to Pkt_Privacy and run the script or application again


Ok, I have some more informations, when I use IIS 6 Metabase Explorer with my administrator account I can see the rights are correctly inherited for my non-administrator account.

But when I try to connect using my non-administrator account, I can list the LM node, but get an "access denied, failed to get a key's data" when I try to browse the child nodes.

I'll check further.


I tried to Trace the WMI Activity, and everything seems OK ; this tends to confirm that the problem lies in IIS Rights.

share|improve this question
    
I am confused..."My API and powershell tests can connect and execute queries", including listing sites? –  Kev Jul 27 '12 at 16:54
    
Yes, the queries works (no error) but the one listing the sites returns nothing. –  JoeBilly Jul 30 '12 at 9:31
    
You state that you're using PacketPrivacy authentication, but the PowerShell query to list the websites that you've given as an example doesn't include the -authentication PacketPrivacy switch. Is that just a typo? –  Chris McKeown Aug 1 '12 at 10:10
    
Yep, I'll correct this : I tried with -authentication 6 and same result. –  JoeBilly Aug 1 '12 at 12:35
    
I'm getting a 'Class not registered' error - was thinking this is related but am confusing myself. –  Brett Rigby Mar 3 at 10:03

1 Answer 1

up vote 1 down vote accepted

Resolved.

The WMI and IIS Metabase rights have to be set as you would do on an IIS 6. So they were correct for me.

The specifity is on the IIS Metabase. First of all, in IIS 7 the W3SVC rights are completely inherited from the root while you have to set the W3SVC/AppPools rights on IIS 6 if you want to handle the application pools.

Since there's a 'compatiblity', the main difference resides in IIS 7 metabase file system. On IIS 6, the read rights on the inetsrv folder (which is the default for Users) and the Metabase ACLs are sufficient.

On IIS 7, the rights have to be set on the IIS Metabase AND the IIS 7 configuration folder : %SYSTEMROOT%/system32/inetsrv/config (and .config files then). By default, only Administrators (thats why it is perfectly working with the Administrator right) and some other reserved groups can access this folder.

Another point, if you need to execute methods like a Stop on an application pool, this feature require the Write rights on the configuration folder.

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.