Setting up a lab can be a pretty time consuming project. A number of people, myself included, have created various hydration kits in an attempt to make it easier. One thing that they many have in common is that they use the Microsoft Deployment Toolkit (MDT) to generate a large build ISO to be used for building each virtual machine.
Using an MDT build ISO has both advantages and disadvantages. It is portable. It is simple. But it takes massive amounts of disk space and changes are very time consuming.
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?