I ran across the following catch22 in my workstation installation script while trying to automatically add a domain group to the local administrators.
The catch I’m experiencing is the following:

  • When I’m using the local admin I have the rights to add users to a local group but need to provide domain credentials to connect to the domain
  • When I’m using a domain user I can connect to the AD, but the user doing this is not yet a local admin so I can’t yet modify local groups.

I’m in a GMP environment so rules and regulations are !really! strict which limits other possible paths.

  • Roles are split so I don’t have access to the domain admin.
  • No changes are allowed to OU’s which could push the group from Group Policy
  • Using PowerShell with remote scripts is not allowed

This is fairly easy to manually get around when using compmgmt.msc and provide the necessary credentials when asked … but I’d like to avoid adding manual steps and just automate the entire installation as much as possible.

A few details:

  • The workstation's OS is Windows 10
  • The script I'm using is PowerShell
  • The script is running with a local admin account with elevated privileges
  • The workstation is already joined to the domain
  • The account used to join the workstation to the domain is not a domain admin
  • To have admin rights with my domain account I need to add our department’s group to local admin group

The code I use to add a group to the local admin group is $de = [ADSI]"WinNT://$Env:ComputerName/Administrators,group" $de.psbase.Invoke("Add",([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path)
This code works like a charm when run with a domain account and is a local admin.

Since this is used for installation of a brand new workstation I can run this either as domain account or local admin.
With the former the $de.psbase.Invoke("Add", part fails
With the latter the ([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path fails

I tried using start-process cmdlet with –verb runas options to get a different security context but I ran into the same problem as above.

Is there any way I can

  • only resolve ([ADSI]"WinNT://MyCompanyDomain/MyDepartmentGroup").path in the security context of a domain user and pass that to the rest of my script running in the security context of the local admin (This is much the way compmgmt.msc does it)


  • build the [ADSI] object from hardcoded data without the need to connect to the domain


  • something else blindingly obvious I haven’t thought of
  • You can do this with unattend.xml, eliminating the need for any script. Is that feasible in your environment? – Patrick Seymour Jan 27 '16 at 14:21

You can add a domain group to a local group via the unattend.xml file, eliminating the need for any scripting.

Editing Unattend.xml via System Image Manager (SIM)

After opening your unattend.xml in SIM, in the lower-left corner of the window, find the node for Microsoft-Windows-Shell-Setup. (Note: You should use the node corresponding to your image's architecture, i.e., amd64 for 64-bit platforms.) Expand the Shell-Setup node, then UserAccounts, DomainAccounts, and DomainAccountList. Right click the DomainAccount node, and choose to add the setting to pass 7 (oobeSystem).adding DomainAccount node to unattend

In the center of the SIM window, you need to configure the newly-added nodes. In the DomainAccountList node, enter the name of your domain in the Domain value.

In the DomainAccount node, the Group value should be set to the name of the local group you want to modify, in this case Administrators. The Name value should be set to the name of the domain group that you want to add to the local group.

Editing Unattend.xml Manually (not recommended)

You can also edit the unattend.xml file manually, in your favorite text editor. Locate the <settings> node for the oobeSystem pass. You can copy the DomainAccounts node below, and place it in your unattend.xml after the AdministratorPassword node. Be sure to modify the Group and Name nodes in the DomainAccount node, along with the domain name specified in the Domain node.

  <settings pass="oobeSystem">
    <component name="Microsoft-Windows-Shell-Setup" ... >
          <DomainAccountList wcm:action="add">
            <DomainAccount wcm:action="add">
  • This would indeed work on the condition I'm allowed to join the domain in the unattend.xml ... which unfortunately I'm not. The reason for this is (a) the password for automatic domain join cannot be encrypted in the unattend.xml, (b) our passwords need to be changed ever 6 months which would mean I need to create a new qualified build (read: lots of paperwork) every 6 months and (c) we're not allowed to use general service accounts, everything HAS to be named. Otherwise this is an excellent answer which (to be honest) I haven't thought of. – GapWim Jan 27 '16 at 16:12
  • You should be able to use the above settings independent of whether you join the domain via unattend. Our domain join process is not in unattend either, and this method works for us. – Patrick Seymour Jan 27 '16 at 17:23
  • In that case I'll give it a try and come back to this later (may take a few days). When you see your reply has been marked as answer you'll know what the outcome was ;) . edited to add: I'll have to find the equivalent in ICD though, not SIM. But if memory serves right I do remember something similar in there. – GapWim Jan 27 '16 at 17:46
  • I'm not sure what you can share, but I work in a pretty open environment, and I'd be curious about processes you have to go through if you can share anything. – Patrick Seymour Jan 27 '16 at 23:57
  • No big secret, just a heavily regulated environment. I’m currently doing a project in a ‘Big Pharma’ company. Government regulations enforces them to use GMP which stands for ‘Good Manufacturing Procedures’ … which is not without reason nicknamed ‘Great Mountains of Paper’. Extremely simplified this means that all actions that could in the slightest way impact production has to be documented, time stamped and signed. So a change to a customized build need to be documented and it needs to be logged who joined a PC to the AD. This results in the practice ‘If it works we don’t touch it, EVER!!!’ – GapWim Jan 28 '16 at 10:06

Your Answer

By clicking "Post Your Answer", you acknowledge that you have read our updated terms of service, privacy policy and cookie policy, and that your continued use of the website is subject to these policies.

Not the answer you're looking for? Browse other questions tagged or ask your own question.