RTR01

Routing between subnets and access to the Internet (required for Windows Activation) is handled by RTR01, a Windows server running Routing and Remote Access (RRAS). This should be the first virtual machine to be built and configured as machines on the other subnets will need this server in place for them to successfully build.

This virtual machine will have 5 network adapters, one on each network. The build will create a basic Windows server. To configure the server you will need to run some PowerShell as well as manually configuring RRAS.

In this first installment we’ll work on getting the foundation set for building up the lab. We’ll configure the virtual networks, the host networking and get our MDT environment installed and configured. We are going to use a number of tricks that I’ve learned from others.

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.

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.

The blog posting uses SCCM 2012 to upgrade a machine to Windows 10. That is where I will start. Later I’ll set this up inMDT 2013.

Pre-Requisits

Working SCCM 2012 R2 infrastructure (I’ll use the VMs created with my MDTLabBuilder)

A Windows 7 (or 8.x if you prefer) machine that is joined to the domain and has a healthy SCCM client

Download the Windows 10 Technical Preview (I’ll be using build 9879)

Download the Zip file with the task sequence template from the SCCM Team blog

If you want, to make things a little easier you can create a quick task sequence to deploy your Windows 7/8 machine.

First, you need to prepare you Windows 7/8 target system. It does not have to be complex, just a simple domain joined workstation or VM. In my case I’m using virtual machines. I just set up a machine and for demonstration purposes staged it with some user data and system changes.

Changes made to the target system:

Changed the wallpaper

Installed Microsoft Word

Customized Microsoft Word

Pepper some user files on the Desktop, user’s documents and a folder off the root of the C: drive

Follow the instructions from the SCCM Team’s blog on importing the task sequence and staging your files and run your test system through the upgrade process.

Start:

Finish:

The demo documents were are still in place. But you can see that the user’s wallpaper was not retained. Could just be the TechPreview build.

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.

Known Issue:
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.

It will:

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 THENran 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.

Multiple Subnets
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.

Windows 10
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.

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.

Prerequisites:

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.”

-Les Brown

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.