Update – Michael Niehaus took an interest in my problem and was able to reproduce it in one specific scenario.
Here is his email explaining how he was able to reproduce the problem:
I tried it and it worked fine. But I didn’t give up like most auto mechanics do J
So I was able to reproduce the error in one specific scenario:
· Create a task sequence through the MDT wizard, specifying an admin password (saved as plaintext in the Unattend.xml).
· Edit the Unattend.xml and save it (you don’t need to change anything, just save).
· Deploy with either the admin password wizard pane enabled (SkipAdminPassword=NO) or a non-blank AdminPassword variable value (specified in CustomSettings.ini, database, etc.).
In this particular case, MDT injects the value of AdminPassword into the Unattend.xml but doesn’t reset the plaintext value. Definitely a bug.
In this case I had done exactly that. I had set an admin password when I created the task sequence through the wizard. I also edited the unattained.xml file. And finally, I had an admin password specified in the [Default] section of my CustomSettings.ini. So, I managed to find the one way to shoot myself in the foot with this.
Stumbled onto an issue yesterday after upgrading my MDT 2013 deployment share to MDT 2013 Update 1. My existing task sequences would fail during OOBE.
Windows could not parse or process unattend answer file [C:\windows\Panther\unattent.xml] for pass [oobeSystem]. The settings specified in the answer file cannot be applied. The error was detected while processing settings for component [Microsoft-Windows-Shell-Setup].
If I created a brand new task sequence and modified nothing it would work perfectly.
So I compared my original Unattend.xml with the factory default one to look for differences in oobeSystem. The only difference was that in my original XML the passwords for the Administrator account and the autologin account were not in plain text while the factory XML was.
My original XML is on the left while the factory default is on the right.
I used the Windows System Image Manager, triggered by editing the XML through the MDT console, to modify the “ProtectYourPC” setting and turn off auto updates. That was the only setting I modified and never touched the passwords. My guess is that WSIM set the passwords to be encrypted by default.
I took my original XML and using Notepad replaced the password sections and left the ProtectYourPC setting untouched. Ran a test build with it and it completed successfully.
I’ve updated my MDT Lab Builder with the addition of building a virtual router using Windows Server 2012 R2. I referenced this article from Johan when setting it up. You do not need any additional software, the build of the router will use the same Server 2012 R2 source used in building the other VMs.
The VM (RTR01) will not be joined to the lab domain. I keep it in a workgroup so that it isn’t reliant on the existence of the lab domain and can be used with other projects. The configuration of Routing and Remote Access will allow your lab machines to reach the Internet (as long as your external network has access to the Internet). You can use this VM to explore routing using a Windows Server. You could hang additional virtual switches off of it and configure your own lab network with multiple subnets. Experiment with using DHCP relay on the router. Use Distribution Points in other LANs or even grab an evaluation copy of Nomad Branch from 1E and see how that works.
It’s a learning tool. Give it a shot and see what you learn.
Next up, MDT 2013
Now that we’ve done this in SCCM porting it over to MDT should be much simpler seeing that we don’t have to worry about knocking the SCCM client over and then standing it up again.
- A working MDT server (does not necessarily have to be in a domain)
- An existing Windows 7/8 client
- Download the Windows 10 Technical Preview (I’ll be using build 9879)
- Optionally, download the Zip file with the task sequence template from the SCCM Team blog
The task sequence template from the blog is for SCCM, but it’s handy to have as a reference.
When creating the task sequence in MDT most of what is being done by the PowerShell scripts in the download is not necessary. The sequence and scripts from the SCCM Team blog are geared towards deploying with SCCM (of course).
For the sake of my test I re-created the sequence as close to identical to the SCCM one.
I commented out the SCCM related portions of the various PowerShell scripts and when it was all said and done there really wasn’t much left.
Along these same lines Michael Niehaus did a demonstration during one of his TechEd Europe sessions (WIN-B338) where he used MDT to upgrade a Windows 7 machine to Windows 10. It’s about 30 minutes into the presentation. The task sequence used in his SCCM demo is the exact one that the SCCM Team made available on their blog. He shows the MDT sequence details around the 39 minute mark. Comparing the sequence he used in his demo with the one I re-created from the SCCM Team blog, I preferred his.
I don’t know why though it throws a warning at the end of the sequence. I’m sure it’ll be something simple though.
I recommend his TechEd presentation. There’s a lot of good stuff in it. Some really cool stuff coming down the line for deploying Windows 10.
With Windows 10 Microsoft is heavily promoting the in-place upgrade. In fact, Microsoft used the in-place upgrade internally when moving their systems from Windows 8 to Windows 8.1.
I first heard about this during a TechEd Europe session (EM-B326). Shortly after the session was made available the System Center Configuration Manager team posted a blog entry explaining the basics on doing this.
I thought I’d dig a little deeper and try to tie together the SCCM blog posting and the information from the TechEd presentation.
[Update: Possibly why the script doesn’t work when run as part of the task sequence (See below)]
It took a little longer than I had planned but it’s ready. I haven’t finished the Windows 10 in-place migration portion yet, so this version will build:
- DC01 – Domain Controller
- MDT01 – Microsoft Deployment Toolkit Server
- CM01 – Configuration Manager 2012 R2 site server
- DP01/DP02 – 2 SCCM 2012 R2 Distribution Point Servers
[Download MDTLabBuilder v 1.1 here]
If you’ve already downloaded and used v 1.0 you can just replace the files with the ones found in this version. The MDT prep script as well as the Hyper-V lab build-out script have both been updated to handle existing components. If you have modified any of the configuration files (i.e. customizing the domain or IP information) then be sure to back up the configuration CSV files so they are not overwritten.
There is a problem with the script that configures SCCM. My original intent was to be that during the build of the site server the DPs would be added automatically. That’s why the DPs are built first, so that they exist when CM01 is built. I’ve fought with it for the last few nights with no success. If I run the script manually it works, but when called from within the task sequence it executes but does not add the distribution points.
So, tonight I decided that I’m probably too close to the problem at this point and need to step back and just let it be as it where. When the build for CM01 completes, you fill find a PowerShell script on the Desktop. Open an Administrative PowerShell prompt and execute the script. It will perform the initial configuration of CM01.
- Create a Distribution Point Group
- A,dd DP01 and DP02 as distribution points
- Add all three servers to the DP Group
- Configure the discovery methods
- Initiate an AD Forest Discovery
- Create some Boundary Groups
I’m going to take a break from the SCCM configuration script problem for a bit and focus on getting the Windows 10 in-place upgrade working within MDT.
Update: Possible reason why the script does not work when run during the task sequence.
I have a theory, but it’s a bit of a long shot. When the script executes during the task sequence the ConfigMgr PowerShell drive does not exist yet. So the script is unable to execute the required PowerShell commands.
I did a test build using the builder. When CM01 completed I logged in and attempted to run the configuration script. It threw several errors that the PSDrive (PS1) wasn’t present. Only after I opened the ConfigMan console and THEN ran the configuration script did it work. Looking back I would always open the console first thing to check to see if somehow I had been able to get the script working in the sequence.
So, maybe the PowerShell drive isn’t initialized or available during the running of the task sequence and that is why the script doesn’t work?
I thought I’d lay out some of the ideas that I have for the direction I plan to take my lab builder. I”m wrapping up version 1.1, which handles standing up a basic Configuration Manager infrastructure (1 Primary Site and 2+ Distribution Points) and should have it ready in the next day or so.
NomadBranch and PXE Lite from 1E
We use this where I work and I think that it might be useful for others to see how it works. My lab builder relies entirely on evaluation software, so I’ll have to see if an eval version of the software is freely available from 1E.
This would make demonstrating NomadBranch and PXE Lite much easier, particularly when used for OS deployment. Having a “remote” office where 1E’s software handles the PXE booting and content sourcing would be helpful.
I’d like to be able to put Windows 10 deployment and management through its paces, using both MDT as well as SCCM.
System Center Orchestrator
This one is for me. Orchestrator has interested me but I’ve never really gotten a chance to really try it.
Thoughts? Any suggestions as to what you would like to see?
Version 1.0 of my MDT Lab Builder is ready to go.
I scraped my original idea (see here) and I started over working towards something a little more substantial. I felt that if someone was going to go to the trouble of downloading and using something I created then I should make sure that it was going to be worthwhile and something new.
[All of the deep-dive details as well as the download can be found on this page.]
This first version is pretty basic to start with, it will build a domain controller and an MDT server. Future versions will expand upon it, adding SCCM, SCORCH and other servers.
- Hyper-V (I’ve tested using both Windows 8.1 and Server 2012 R2)
- Microsoft Deployment Toolkit 2013
- Windows ADK 8.1 Update
If you are going to use a different hypervisor then you will need to create and boot the VMs manually. Details will be in the included documentation.
“When life knocks you down try to land on your back. If you can look up, you can get up.”
Last Fall Microsoft announced that they were discontinuing the TechNet subscription service. Needless to say that honked off a lot of IT-Pros, myself included. On top of that nobody at Microsoft seemed to be either explaining why or answering the concerns of subscribers. The company line was to just use the evaluation software. My argument was that I didn’t have the time to spin up a full lab every 180 days or so.
(Looking back that does seems a little whinny.)
It is true though. Balancing work, family and my crazy hobby of computers. 🙂
So what I decided to do was to stop complaining and do something. I may not be able to build a permanent lab in the future (System Center v.NEXT) so the best thing would be to automate building one using eval software. I borrowed heavily from the Hydration kits that Johan Arwidmark has created and several components from Mikael Nystrom. (Okay, I’ll admit I outright plagiarized a lot of it.)
What I tried to do was to take the best of what was out there and pull it all together into an MDT environment that would not only build the lab servers but also configure and stage them. For example, it would not only build an SCCM 2012 primary site server, but also distribution point servers which would automatically be added to the SCCM hierarchy. I’m also tried to make it modular, so if you want to change IP addresses or the domain name for example you just change it in one place and my scripts will take care of the rest.
Anyway, that was my original goal.
I asked Johan and Mikael if I could share what I had “created” and they graciously agreed. I then started looking at what it was exactly that I had created and it didn’t seem right. It really wasn’t more than their work with some added scripts and some name changes.
That just didn’t sit right with me. I decided that if I’m going to do this I need to do it right. I need to create something worthwhile and significant. I needed to push myself and learn something new.
So I’ve started over. What did I really want to accomplish using this? What would make it easier for others to use? From there I started working out what I thought would be the best way to do that. What I will be sharing is a modular lab builder. It will still use MDT and there will be pieces that you recognize from Johan and Mikael’s work, but it will be something different, something flexible and expandable.
It will be modest to begin with, but I will expand upon it. For example, I would like to create multiple subnets, include Nomad Branch and PXELite from 1E, allow creating an SCCM 2007 and/or 2012 environment, etc. I also would like to add in some training work, some hands-0n labs. Maybe stage up some workstations to do USMT hard-link migrations? That sort of thing. As I firm up my vision for how it will work I’ll create a dedicated page for all the deep-dive details.