Manifests and UAC Issues

[keslaa]

Hello,

I have built a package that will update the license information for an application we have on about 250 machines. The only way I can get this to run properly is to launch the script as a user with local admin rights. I have tried monkeying around with wntRunAsUser and RunWithLogon to no avail. This has to be deployed through SCCM 2007, which has two options to run the package: With Administrative rights (as the System account) and as the Logged On User. If I try setting the package to run with administrative rights, it kicks off fine but the actual executable I am trying to run fails as it does not recognize the "user" that is trying to run it. If I set the package to run as the logged on user, it bombs immediately. (One of the first thing the script needs to do is to copy a file into the Windows folder, a no no for a non-admin.) However, if the logged on user also happens to be a member of the local administrators group, everything runs fine. Unfortunately for this package, only about 6 people have that privilege.

I was reading up on manifests and UAC and the like, but I'm not sure I am getting it. Any advice?

[Deana]

Manifests and UAC can be a bit confusing. 

In short, if any part of the script requires admin privileges, then you should manifest the script using RequireAdmin. Which means the script can only be run by Administrators.

You mentioned you have a deployment option to run with admin rights. However you state the script fails because it not running as a logged in user. This suggests to me that you may need to deploy two scripts. One that handles the admin procedures (manifested with RequireAdmin) and one that runs as the standard user (manifested with AsInvoker).

NOTE:  It is very common to start launch an application at the end of an installation script. Unfortunately, the application is often started under the wrong user context because the user provided elevated credentials to perform the installation and the application is created with the elevated user token. One recommendation is to create a bootstrapper EXE manifested AsInvoker. Read this section of the article for details: http://msdn.microsoft.com/en-us/magazine/cc163486.aspx#S15

I recommend carefully reading the 'Manifest' topic in the WIL help file. Also another good resource can be found here: http://msdn.microsoft.com/en-us/magazine/cc163486.aspx. I highly recommend reading through the entire article. There is a lot to factor in when dealing with 'installations'.

[keslaa]

Nothing like an immediate reply...

In reading through the material, it seems for my problem above, I should have written and compiled two scripts: the first, compiled with the manifest "AsInvoker", would call the second, compiled as "HighestAvailable" or "RequireAdministrator" (straight from here).

What about calling a third party executable that needs to run as the local administrator? This executable - created by the hardware manufacturer - installs a series of hardware device drivers and can ONLY be run as the local administrator account. I would imagine I would need to still create the bootstrapper, but I have no idea how the device driver executable was compiled. I can make assumptions, but I don't know for sure.

[td]

Obviously, if your 3rd party executable is manifested to run as an admin or highest available, you don't need to do anything other than using the bootstrap script.  Of course, you will need someone around to answer the UAC prompt, if the system has UAC prompting turned on.  If the executable is not manifested, you will need to create a second script that is manifested as requiresAdministrator and have that script start your third party exe.  You could run the second script from the bootstrapper script.  This would only be useful if the system was set to admin consent mode, otherwise, a user would have to provide admin credentials even with the bootstrapper.