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.

Andy

Advertisements

Automatic Updates behaviour during Task Sequenced Windows 7 Build

I’ve come to the conclusion that whilst in the Post-Install phase of a Task Sequence, it’s probably not a good idea for the machine being built to go swanning off to Windows Update and start automatically applying minor updates.  As well as undermining the whole concept of centrally managing updates – it throws up the risk of upsetting your ‘Install Software’ task sequence steps as they fight for Windows Installer time.

Thus, I find myself trudging with my wading gear into the murk of the unattend.xml file to yet again change what I feel is behaviour that just shouldn’t be switched on by default.

The setting we are concerned with is the “ProtectYourPC” option in the “x86_Microsoft-Windows-Shell-Setup_neutral” section.  We change this to have a value of “3” which effectively turns off the automatic nature of Windows 7 so that our build can complete exactly as per the plan.  Corporate Group Policy settings come down to lock down the behaviour of Windows Update when all is finished.