none
Modifying the Unattend XML to create a different user RRS feed

  • Question

  • I know by default MDT uses Windows built-in admin account to run and install everything because of the privileges that it has by default. At the end, that is also the only user created.  I have been looking for a way to have a different user created and be the only profile available at completion.

    Looking through the Unattend.xml I found where the built-in admin gets enable and setup.  My question is, could I change this so that a different user is created and given the necessary privileges to run?  Or is there another way to do what I am looking for?

    If so, what would be needed/recommended to change?  If not, why not?

    By the way, this is all standalone, done a single computer.


    • Edited by jleggett81 Friday, September 20, 2019 6:48 PM
    Monday, June 24, 2019 10:06 PM

Answers

  • As I recall from Win7, you can modify the unattend to 'set' the password for that other user.
    In Win10, I've found that you must 'state' what the password is within the VM. When I created my VM as a different local user, I had to use that password in my XML for Win10.

    I tried this yesterday, setting the unattend to autologon as a local user with a password, but it failed the autologon, stating the password was incorrect. However, once I typed it in, it went on to the desktop.
    You can mess with it and get it to work for you. I wouldn't suggest creating a VM under this user, that seems old-school today. However, if you wish to omit the administrator account, delete out the part in your XML, if it's there, under Specialize, RunSynchronous, EnableAdmin. That obviously enables the admin account.
    (I have the Command there:   cmd /c net user administrator /active:yes ) 

    • Marked as answer by jleggett81 Monday, October 21, 2019 3:55 PM
    Tuesday, September 24, 2019 12:10 PM

All replies

  • Does anyone know if there is a way to do this?
    Monday, September 23, 2019 2:40 PM
  • From my experience, if I'm correct, the only way to have a different user sign on, other than admin, is if the VM was logged on as that user to create the VM.

    I used to build a VM as a local admin other than administrator. In my unattend, I would activate the admin account and assign a p/w (under Specialize) but under AutoLogon I would specify the other account with its p/w right below.

    This other account would log on while administrator would be set to active but no user profile created (unless you actually did sign on as admin manually later).

    I've never set it up this way where I did not create the VM as the other local account, but you can test your unattend this way.

    Monday, September 23, 2019 7:50 PM
  • Will this also keep the default admin account from creating a user profile? 

    This looks interesting.  Definitely going to give it a go.  Will probably start playing around with the unattended a little more.  If it breaks, I have backups.

    Thanks for the suggestion.

    Monday, September 23, 2019 8:44 PM
  • As I recall from Win7, you can modify the unattend to 'set' the password for that other user.
    In Win10, I've found that you must 'state' what the password is within the VM. When I created my VM as a different local user, I had to use that password in my XML for Win10.

    I tried this yesterday, setting the unattend to autologon as a local user with a password, but it failed the autologon, stating the password was incorrect. However, once I typed it in, it went on to the desktop.
    You can mess with it and get it to work for you. I wouldn't suggest creating a VM under this user, that seems old-school today. However, if you wish to omit the administrator account, delete out the part in your XML, if it's there, under Specialize, RunSynchronous, EnableAdmin. That obviously enables the admin account.
    (I have the Command there:   cmd /c net user administrator /active:yes ) 

    • Marked as answer by jleggett81 Monday, October 21, 2019 3:55 PM
    Tuesday, September 24, 2019 12:10 PM
  • the1rickster,

    This worked great!  Did exactly as I needed.  I made a little tweak to have the username that I wanted to use be created instead of the admin activated.  Then in autologin have it sign in with that name without a password.  This worked great.  

    Thanks for the help.

    Monday, October 21, 2019 3:57 PM
  • One more question, is there a way to do this in the TS or custemsettings.ini?  Some other way?
    Monday, October 28, 2019 3:04 PM
  • Are you trying to add a local account or domain user name?
    Monday, October 28, 2019 3:11 PM
  • Trying to add a local account.
    Monday, October 28, 2019 3:27 PM
  • Save this below as CreateLocalUser.ps1 
    Add it to your Deploy/Scripts folder.
    Just under Tattoo, add a PowerShell Script and point to this.
    In the same screen, under Parameters, add: -user #### -password ####  (fill in the #'s).

    Within this script, replaced all of the ### with username and password where it should be.
    I will also add a PS to make that user a local admin if you need it to be. Let me know.

    param($computer="localhost", $user, $password, $help)
    
     
    
    function funHelp()
    
    {
    
    $helpText=@"
    
    DESCRIPTION:
    
    NAME: CreateLocalUser.ps1 
    
    Creates a local user on either a local or remote machine.
    
     
    
    PARAMETERS: 
    
    -computer Specifies the name of the computer upon which to run the script
    
    -user    Name of user to create
    
    -help     prints help file
    
     
    
    SYNTAX:
    
    CreateLocalUser.ps1
    
    Generates an error. You must supply a user name
    
     
    
    CreateLocalUser.ps1 -computer MunichServer -user myUser 
    
     -password Passw0rd^&!
    
     
    
    Creates a local user called myUser on a computer named MunichServer
    
    with a password of Passw0rd^&!
    
     
    
    CreateLocalUser.ps1 -user #### -password #### with a password of ####
    
     
    
    Creates a local user called #### on local computer with 
    
    a password of ####
    
     
    
    CreateLocalUser.ps1 -help ?
    
     
    
    Displays the help topic for the script
    
     
    
    "@
    
    $helpText
    exit
    
    }
    
     
    
    if($help){ "Obtaining help ..." ; funhelp }
    
     
    
    if(!$user -or !$password) 
    
          {
    
           $(Throw 'A value for $user and $password is required. 
    
           Try this: CreateLocalUser.ps1 -help ?')
    
            }
    
          
    
    $objOu = [ADSI]"WinNT://$computer"
    
    $objUser = $objOU.Create("User", $user)
    
    $objUser.setpassword($password)
    
    $objUser.SetInfo()
    
    $objUser.userflags = 65536
    
    $objUser.description = "YOUR DESCRIPTION GOES HERE"
    
    $objUser.SetInfo()

    Monday, October 28, 2019 4:09 PM
  • I do need it to be a local admin.   Do any of these lines need to be commented out?
    • Edited by jleggett81 Monday, October 28, 2019 5:32 PM
    Monday, October 28, 2019 5:31 PM
  • No just as is. Here is another script to make them a local admin:

    Save below as AddToUserGroup.ps1
    Add to your scripts folder, then add the script in your TS and add these parameters:

    -user #### -group Administrators
    Same with this script, nothing to omit and nothing to change in this one.
    Just place this PS right under the Create one.

    <#
    
       .Synopsis
    
        Adds a local user to a local group on either a local or remote machine.
    
       .Description
    
        This script uses [adsi] type accelerator to use ADSI to create a local group.
    
        It will throw an error if $group is not present. It uses the WinNT provider to 
    
        connect to local SAM database. This is case sensitive. This script must run with 
    
        ADMIN rights to create local groups.
    
       .Example
    
        AddUserToGroup.ps1 -computer MunichServer -user myUser -group mygroup
    
        Adds a local user called myUser on a computer named MunichServer to a local group called mygroup
    
       .Example
    
        AddUserToGroup.ps1 -user myUser -group mygroup
    
        Adds a local user called myUser on local computer to a group called mygroup
    
       .Inputs
    
        [string]
    
       .OutPuts
    
        [string]
    
       .Notes
    
        NAME:  Windows 7 Resource Kit
    
        AUTHOR: Ed Wilson
    
        LASTEDIT: 5/20/2009
    
        KEYWORDS: ADSI
    
       .Link
    
         Http://www.ScriptingGuys.com
    
    #Requires -Version 2.0
    
    #>
    
    param(
    
          $computer=$env:computerName, 
    
          [Parameter(mandatory=$true)]
    
          $user, 
    
          [Parameter(mandatory=$true)]
    
          $group
    
    ) #end param
    
    # *** Functions
    
    function New-Underline
    
    {
    
    <#
    
    .Synopsis
    
     Creates an underline the length of the input string
    
    .Example
    
     New-Underline -strIN "Hello world"
    
    .Example
    
     New-Underline -strIn "Morgen welt" -char "-" -sColor "blue" -uColor "yellow"
    
    .Example
    
     "this is a string" | New-Underline
    
    .Notes
    
     NAME:
    
     AUTHOR: Ed Wilson
    
     LASTEDIT: 5/20/2009
    
     KEYWORDS:
    
    .Link
    
     Http://www.ScriptingGuys.com
    
    #>
    
    [CmdletBinding()]
    
    param(
    
          [Parameter(Mandatory = $true,Position = 0,valueFromPipeline=$true)]
    
          [string]
    
          $strIN,
    
          [string]
    
          $char = "=",
    
          [string]
    
          $sColor = "Green",
    
          [string]
    
          $uColor = "darkGreen",
    
          [switch]
    
          $pipe
    
     ) #end param
    
     $strLine= $char * $strIn.length
    
     if(-not $pipe)
    
      {
    
       Write-Host -ForegroundColor $sColor $strIN
    
       Write-Host -ForegroundColor $uColor $strLine
    
      }
    
      Else
    
      {
    
      $strIn
    
      $strLine
    
      }
    
    } #end New-Underline function
    
     
    
    function Test-IsAdministrator
    
    {
    
        <#
    
        .Synopsis
    
            Tests if the user is an administrator
    
        .Description
    
            Returns true if a user is an administrator, false if the user is not an administrator        
    
        .Example
    
            Test-IsAdministrator
    
        #>   
    
        param() 
    
        $currentUser = [Security.Principal.WindowsIdentity]::GetCurrent()
    
        (New-Object Security.Principal.WindowsPrincipal $currentUser).IsInRole([Security.Principal.WindowsBuiltinRole]::Administrator)
    
    } #end function Test-IsAdministrator
    
     
    
    # *** Entry point to script ***
    
    If(-not (Test-IsAdministrator)) { New-Underline "Admin rights are required for this script" ; exit }
    
     
    
    if(!$user -or !$group) 
    
          {
    
           $(Throw 'A value for $user and $group is required.')
    
            }
    
          
    
    $OBjOU = [ADSI]"WinNT://$computer/$group,group"
    
    $objOU.add("WinNT://$computer/$user")

    Monday, October 28, 2019 5:55 PM
  • Let me know how the scripts below works for you.
    Wednesday, October 30, 2019 1:11 PM
  • It sort of accomplished what changing the unattended file was doing.  The Administrator account was still getting created, which I was trying to avoid.  If I put the scripts higher up would the do the same thing?  Maybe add to it to disable the Administrator account after the new account is created?  

    Looking like I may just need to stay with modifying the unattend file and document the crap out of what I did.  

    Wednesday, October 30, 2019 1:23 PM
  • I added these two PS's in my TS and in the unattend I deleted the 4 Specialize/Run Synchronous, Enable Admin entry. This stops the admin from being activated. Then the first PS creates your local user. The 2nd PS adds that user to the administrators group.

    I've found this the simplest way of creating local accounts and adding them to the admin group during Deployment.

    • Edited by the1rickster Wednesday, October 30, 2019 1:46 PM
    Wednesday, October 30, 2019 1:45 PM
  • Just wondering if you've tried either the first PS or both and if they succeeded for you.
    Thursday, October 31, 2019 3:10 PM
  • Haven't had a chance yet.  Got pulled into a project for a couple of days.  Probably be middle of next week before I get a chance to get back and try.
    Thursday, October 31, 2019 7:53 PM
  • Oh great. I'm waiting to see how it works for you. It does exactly what you said you need to happen.
    Monday, November 4, 2019 4:29 PM
  • The Administrator account still gets created even with the entry in specialize removed.(Create, set HKEYs, etc)  I tried adjusting the autologin section to have the new username and password.  That stopped the Administrator account from being created.  But then when it trys to logon it fails with the password being wrong.  Even the one I created for the user account shows as wrong.  
    Wednesday, November 6, 2019 7:09 PM
  • So my scenario was that I created a VM under the user administrator.

    In my TS, I added the first PS into my TS with -user ###### -password ######

    Then the next entry in my TS was the 2nd PS from above, and in the parameters I added -user ##### -password ##### (and I edited the ### within the PS).

    If it doesn't matter to you about the admin account, then if you remove the Enable Admin from Specialize in the Unattend, the admin account will always be there, just disabled, without a folder structure under Users.
    Until you enable it and sign on as admin. So, just add the user(s) you want with the PS and remove the Enable Admin from the unattend. All that does is prevent it from being enabled, not having anything to do with it being created.
    Lastly, in your unattend, edit the 7 oobeSystem in unattend:
    for Autologon, use the name you've created in your TS, with the password. As long as you add the AdministratorPassword in UserAccounts, then the admin account will sit and wait forever until you decide - or not- to sign on as admin. The password is what you set in UserAccounts. Hope this makes sense.

    Wednesday, November 6, 2019 8:45 PM
  • Still running into the password issue.  Deleted the step under the 4Specialize>RunSynchronous. Edit the 7 oobesystem in unattend like you said.  However, the passwords keep changing.  I change the password in Autologon and UserAccounts to match the password from the script.  But then when the TS runs, the password changes in those 2 areas.

    Any ideas?

    Thursday, November 7, 2019 7:24 PM
  • As you said on Oct 21, you got it to work, so the only thing you probably need to add is making the user acct an admin of the pc, the 2nd PS.
    Thursday, November 7, 2019 9:06 PM
  • I got it to work then by just strictly modifying the unattended.  Since that worked, I am going to stick with it for now.  I'll circle back to this.  Need to do some more on this.  

    Thank you for your help.

    Monday, November 11, 2019 6:40 PM