MDT Task Sequencing: Where are my unattend.xml Local User Accounts?

I have been digging deeper and deeper into the functionality and relationships between ConfigMgr Task Sequencing, the unattend.xml/unattend.txt files and the MDT Scripts to better understand how these all come together – as opposed to just referring to all of it as ‘Witchcraft’.

A simple task, you might think, would be to automate the creation of additional local user accounts during an integrated MDT task sequence, so you could imagine my frustration when it seemed that the Local Accounts portion of the unattend.xml file I was pushing down with my ‘Apply Operating System Image’ step was being ignored completely.

It transpires, that the MDT “ZTIConfigure.wsf” script was working against my efforts and removing my customisations related to Local User Accounts, and we can see why within the script;

I can immediately understand the need to remove any AutoLogon and Run-Once entries, as we do not really want anything interfering with the Task Sequence steps – however the action of removing any local account entries perplexes me and I cannot think of any reason why this has been stipulated.

I commented out the offending lines in the ZTIConfigure.wsf, as shown above, saved my changes, updated the MDT Toolkit Files package on my DP’s and re-ran my task sequence – et voila; additional user accounts!

I investigated and contemplated other solutions prior to this, such as using task sequence ‘Run Command Line’ steps with the relevant ‘NET USER / LOCALGROUP’ commands, however I was not so keen on having the desired account password in plain text.  Another suggestion was to use a masked Collection Variable containing the password and referencing this variable during the task sequence – however this would not be practical in environments which have multiple OSD collections.



ConfigMgr 101: Using DOS commands and RunFromDP

I recently responded to a cry for help in troubleshooting an issue with a simple program that just did not want to do what it should.  It is a common scenario for the ConfigMgr guy to be asked to deploy shortcuts or files to systems and the easiest way to do this is usually with our old friend XCOPY.

Utilising programs such as XCOPY work fine when the client is caching the content locally and running from there, however when the advertisement is set to “Run from Distribution Point” then nothing seems to happen even though a success code is often returned.  What gives?

Well, XCOPY, like most MS-DOS born command utilities, relies on an instance of the windows command processor and this itself does not support UNC paths as the ‘working directory’.  This is not a ConfigMgr issue as such – it is a limitation of the command processor and you can easily replicate the problem by creating a simple .bat or .cmd file on a network share containing just a ‘pause’ command and try running it directly from the network share…

The result is that the working directory for the program launched by ConfigMgr is being set to the “c:\windows\system32” folder instead of the SMSDP location – and in the case of an XCOPY command line like ours it is likely that the files to be copied will not be found.  “File not Found” with XCOPY generates an exitcode of 0 (zero) which as far as ConfigMgr is concerned is a success.  Even worse, is that if your command line is to XCOPY everything using wildcards (*.*) then you could end up trying to duplicate everything in the windows\system32 folder!

So how do we workaround this?  Well you could of course move into this decade and write a VBScript that performs your file copies etc. and there are numerous examples and guides available on the net and so I won’t be writing one here.

You could also make use of the little known “%~dp0” variable, which stores the SMSDP location being used – however this cannot be used directly on your ConfigMgr program command line and you will need to instead use it within a .bat or .cmd file and call that instead.

@echo off

xcopy %~dp0*.* %public%\desktop

Note that the %~dp0 variable will contain a trailing “\” so do not add one yourself.

A third solution, is to enable the “Requires Drive Letter” option in the “Environment” tab of your program.

This will cause ConfigMgr to temporarily map a spare drive letter to the SMSDP, setting it as the working directory and running your program command line.

I hope this information serves you well one day!