Forum Discussion
Local administrator created during OSD doesn't get administrator access
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 th...
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.
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.
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.
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.