1

We've just added a new development server to our office network running Windows Web Server 2008 with IIS7.5 and SQL 2008 R2.

We don't RDP to the server, instead we run IIS Manager and SQL Mgmt Studio remotely and the WWW folder is shared that we have mapped to our computers. Everything is working perfectly apart from one thing.

When we add a new website (and a new app pool is created) we can't set permissions for that new app pool through our shared drive or via RDP. We can see the app pool in IIS though and the super admin for our network can do this without any issues.

Example
User creates a new website/apppool called TEST. In the WWW folder, TEST -> Properties -> Security we try to add IIS AppPool\TEST but it can't find the object. Same thing happens via RDP. User has access to IIS AppPool\DefaultAppPool though.

Super Admin logs in to Dev server and can set permissions for all app pools.

This is quite weird since we're all local admins on the dev box and it's the users creating the AppPools.

Anyone have an idea how to resolve this?

Thanks

Marko
  • 103
  • 1
  • 1
  • 10

1 Answers1

0

Sounds about right, if I'm parsing the question correctly, but you say "via RDP" and "not using RDP", which makes it tricky to understand.

If I recall correctly, the "IIS AppPool\" provider is the Application Host Helper service, which runs on the local box.

I don't know if that's remotable, I'd assume not, but if it is remotable via RPC, that might explain why admin man can do it.

TristanK
  • 9,073
  • 2
  • 28
  • 39
  • Well put it this way, the super admin can see ALL app pools, while the local admin can only see the Default ones. Very weird. – Marko Nov 30 '11 at 01:16
  • The RDP question was the one I was hoping you'd answer. Does it behave correctly when you're logged on to the computer locally (via RDP)? – TristanK Nov 30 '11 at 05:26
  • no it doesn't. Same results as via IIS Manager unfortunately. We have a production server with a similar set up (except it's not in our corporate domain) and different users can use the app pools to set permissions without any issues. – Marko Nov 30 '11 at 19:50
  • Well, by examining GPRESULT /Z (from an elevated CMD prompt) on the broken one with the working one, you can hopefully work out which policies are applying that might be interfering with the defaults. For example, permissions/service state forcibly applied to the App Host Helper. – TristanK Dec 01 '11 at 22:14
  • not sure how I'm meant to use that GPRESULT.. could you provide a little instruction? (Sorry for my lack of knowledge in this area) – Marko Dec 01 '11 at 23:18
  • Start, type CMD (Ctrl+Shift+Enter so it's elevated to admin), type GPRESULT /Z > gpo.txt and then open GPO.TXT in notepad. This lists all the policies applied to the machine. Better to get a corporate admin type involved if you don't have control of or knowledge of Group Policy - essentially any security setting on the box can be modified, and you're looking for the one that breaks your local access to a specific feature that doesn't have a well-defined object associated with it. – TristanK Dec 02 '11 at 05:18
  • I haven't tried the GPRESULT command yet however after adding each developer to the Local Administrators group we can now set permissions for the ApplicationPoolIdentity but only when logged in via RDP. It still doesn't work locally though. Tried logging off and back on but it still fails to "find" the AppPoolIdentity. Once it's added to the security list via RDP though I can see it locally. Very weird. – Marko Dec 05 '11 at 01:13
  • "This is quite weird since we're all local admins on the dev box" is in the question - what's different now? – TristanK Dec 07 '11 at 03:18
  • Sorry I thought that might sound confusing. Each developer is part of the Development Team security group and via GPO we've assigned local admin rights to that group on the dev box. What I now did though is I added each developer as an administrator manually inside "Control Panel - User Accounts - Manage User Accounts". Does that make sense? – Marko Dec 07 '11 at 03:30
  • Sounds like the Development Team isn't a member of Administrators, but that someone tried to assign similar rights and permissions; otherwise, if their group is in local Administrators, they should be local Administrators – TristanK Dec 07 '11 at 04:56