How can I make a local user created during MECM OSD have administrator access before OSD is completed?
This is in regard to the product which currently appears to be known as Microsoft Endpoint Configuration Manager (MECM), and was formerly known as System Center Configuration Manager (SCCM). I have not managed to identify tags, or a product entry, which seem to clearly correspond to this product rather than to e.g. Microsoft Endpoint Manager Configuration Manager (which may or may not even be a distinct product, rather than another name for the same one).
Within that product, 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 - which may not be entirely synonymous with the one in the subject line - 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.
==>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.
Do you mean you are using a nested task sequence to install the application? If yes, it may be a known issue fixed in Configuration Manager current branch, version 2111. If you are using an earlier version, it's recommended to upgrade to the latest Configuration Manager. Refer to the official article:
Summary of changes in Configuration Manager current branch, version 2111
Hope it helps. Thanks for your time.
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
Sign in to comment
Yes, it does mean that; I thought I indicated as much fairly clearly.
We're already running 2111, so I doubt that this is related.
I would also doubt it based on the wording in that partial screenshot. This is not about service window availability, or about computer restarts; this is about local-machine local-user local-Administrators-group membership checking. There are computer restarts involved (one to get out of WinPE, one to let a domain join take effect, one added here in case it fixed things which it didn't, possibly others), but no other application installs seem to be failing, just ones which attempt to run as a local administrator that was created during the task sequence.
I would expect the issue referenced in that line to manifest when you perform a task-sequence deployment at such a time that the incorrect service-window checking leads the system to think that it is operating outside of a valid service window, and so that restarts are not permitted. To the best of my awareness, we have not defined any service-window limits of that nature, and I don't see any other indication that this might be related.
I appreciate the response, but it doesn't seem to be leading in a useful direction.
Thanks for your reply and comments. I will do more research about this issue, if there is any update, I will let you know. Thanks for your understanding.