Local administrator created during OSD doesn't get administrator access

[Andrew_Buehler]

This is an issue at the intersection between application deployment (via task sequence) and operating-system deployment.

I have a setup.exe installer (actually, several of them, all part of the same collection - but the issue can be illustrated by talking about just one) which works fine when run as an ordinary local administrator, but fails with error 1619 when run as SYSTEM. As best I've been able to determine, the installer detects that the embedded MSI would be extracted to a location under the Windows folder, decides that's a security violation, and intentionally does things in a way that will result in this error.

To work around this, I have created a task sequence (without a boot image) to run the installation as a temporary local administrator account. Specifically, this task sequence has the following series of actions:

* A Run Command Line action to create a new local user account, by running 'net user TEMPORARYUSERNAME PASSWORD /add'.

* A Run Command Line action to add that user to the local Administrators group, by running 'net localgroup Administrators TEMPORARYUSERNAME /add'.

* A Run Command Line action to invoke the setup.exe from its package, with the "run this step from the following account" box checked, the username set to '%computername%\TEMPORARYUSERNAME', and the password entered accordingly.

* A Run Command Line action to delete the temporary local user, by running 'net user TEMPORARYUSERNAME /delete'.

If I create a deployment of this task sequence to a collection, and invoke it manually from the Software Center, it works; the program is installed as intended, and the user is created and cleaned up along the way. Event Viewer does log a warning (or perhaps an error) indicating having failed to load the user profile for this account, but that doesn't seem to do any harm, and I haven't yet found any way to avoid having it happen.

If I then go to an OSD task sequence and add a Run Task Sequence action (after rebooting out of Windows PE and into Windows proper) which invokes the above task sequence, and then deploy that OSD task sequence to a computer, the embedded task sequence fails. More specifically, it gets as far as the action which invokes setup.exe, and then records that the installation failed with error 1603.

As best I can determine based on analyzing the logs, the 1603 in this case is a simple "access denied" error, and means that the account which is being used to run the program does not have write access to the install location. However, because the user has been added to the local Administrators group, that user should have Administrator-level access to the entire system - including the install location. The fact that this install succeeds when invoked from Software Center seems to indicate that this user *does* in fact get such access in that environment - but in the post-WinPE OSD environment, it apparently does not.

I have gone so far as to add a reboot step in between the step which adds the temporary account to the local Administrators group and the step which invokes setup.exe, in the hopes that the reboot would lead the system to recognize that the temporary account is a member of that group. However, this did not appear to produce any change in the behavior of the setup.exe step.

My first question is:

How can I get Windows to properly grant local Administrator access (and, as a consequence, write access to the install location) to this user no matter which environment the "inner" task sequence is run from?

If there's no apparent way to do that, my second question is:

How else can I get this install to run as a non-SYSTEM user with local administrator access?

Running as the built-in administrator account itself is not really an option. We manage that account's password with LAPS, so while I know what that password is at Windows install time, as soon as we join the domain (which, for various reasons, will have happened by this point in the task sequence) there's a possibility that the password will have changed; as a result, I can't specify that password in the Run Command Line action.

[#2]

This doesn't directly answer your questions but.

Local system account should have full access to everything. There is likely a missing environment variable or something like that.

What I would do is test your install as local system account, interactively and see what errors popup.
https://www.recastsoftware.com/resources/how-to-access-the-local-system-account/

MSI 1603 is a generic error message and you need to create an MSI log file to see the real error.

[#3]

The SYSTEM account does, in fact, have full access. That's not the issue. The issue with the 1619 error appears to be that the specific setup.exe installer system involved has detection measures to ensure that it's not being used for malicious purposes, and one of those measures is detecting when the MSI would be extracted to a location under the Windows folder, and the value of %TEMP% for the SYSTEM user is under the Windows folder, so the MSI would be extracted there, so the installer detects that and changes its behavior in some way which leads to that error.

I haven't gone so far as to use psexec or the like to test the application install that way, but from the research which I *have* done I think I can just about guarantee that the above is what's happening, and since I don't have control over the installer or its behavior it's not worth trying to fight against. (I've looked for ways to tell the installer to extract to another location, and considered trying to extract the MSI and use that directly - but I haven't found the former, and trying to do the latter for the number of installers that are actually in this collection would be enough extra work relative to just using a different user account that I don't consider it worth the bother unless no other method can be found.)

I'm quite well aware that 1603 is a generic error message, and I *have* enabled full voicewarmupx logging and examined the resulting log file. The log file in question is basically empty (it has the boilerplate type of lines emitted by msiexec at the start and end of a session), is less than one page long in Notepad on a 1920x1080 display at 100% scaling, and contains no useful information except that it's exiting with code 3. Other research, based in part on that log file and in part on the fact that (as I said) this works when invoked from Software Center rather than a Run Task Sequence action, has led me to the conclusion I stated: that the problem is that the user account is not being granted local-administrator access, even though it's a member of the group that should be granting it that access.

I asked this same question elsewhere, and have already gotten a suggestion that this might be a known issue that's fixed in 2111; that'd be a pain to deal with if so, but might be worth pursuing, so in the absence of alternative suggestions I'm probably going to lean that direction.