views:

444

answers:

1

Here's the scenario:

  • Win2003 Build Server (CCNET)
  • IIS7 target deployment server

The various MSBuild tasks (Sdc.Tasks, MSBuild Community, MSBuild Extension Pack) for doing this (creating VDirs, setting AppPool properties) are not suitable for at least one or more of the following reasons:

  • No support for IIS 7.
  • No possibility to pass domain username/password to perform the operation.
  • Microsoft.Web.Management.dll is not available on build server.
  • 'Access Denied' error.

There are no issues creating Vdirs on IIS 6 - though we're actually shelling out to iisvdir.vbs, as using any of the MSBuild task as described above seem to either not support domain username/password auth when performing the operation or will simply throw a basic 'Access Denied' message (despite having the appropriate permissions on the IIS 6 metabase).

Also - bear in mind that the various methods work perfectly on IIS 7 if not specifying a specific domain user/pw as long as the current authentication context has the correct permissions, but for obvious reasons we don't want all of our CCNET build to run in that context.

I've even used psexec.exe to run appcmd.exe on the box remotely, which also works fine if the current security context has appropriate permission, but as soon as you specify username/password on psexec, you get an error message saying "Cannot read configuration file due to insufficient permissions." The user specified is a domain account, and is part of the local Administrators group on the 2008 server.

Also - I've ended up rolling my own RunAs MSBuild task, inheriting from the Exec task and using programmatic impersonation. I then use this to call psexec without specifying the username and password in psexec, but by impersonating when shelling to psexec, but I'm simply getting an exitcode of 1 - without any more details.

As you see, I've pretty much exhausted all options, or so I reckon.

If you can think of anything else, or have achieved managing IIS7 remotely, from an automated process on a non IIS7 box (using a specific non local admin user), please let me know.

+1  A: 

Right. After a bit more messing around, it looks like Windows 2008 User Account Control (UAC) is getting in the way. If you are using any other administrator account than the built-in Administrator, the UAC's Admin Approval mode kicks in.

Obviously in an automated script (non-interactive mode), you will be denied access, as you do not have an option to click 'Continue' on the UAC dialog.

The only alternative is to edit the Security Options for the local machine in Group Policy (gpedit.msc) and set 'Run Administrators in Admin Approval Mode' from Enabled to Disabled.

Reboot, and you're fine.

It would actually be better and more secure if you could set UAC exceptions for Admin Approval mode on specific Administrator accounts. If you're reading, MS - put it on the feature list!

Wim Hollebrandse