Creating Your Own Personal Hydration Solution – Part 4: Configuration Manager Infrastructure

Part 0 Introduction
Part 1 Setting Up
Part 2 First VM – Windows Router
Part 3 Domain Controller
Part 4 Configuration Manager Infrastructure

Configuration Manager 1511

After completing the first three parts of this series you would have a virtual lab with 4 separate network segments all connected to and routed through a Windows 2012 R2 server (RTR01) acting as the router. This server will also provide Internet access to any virtual machines that are connected to the 4 network segments.  You also would have an Active Directory domain controller (DC01) that provides DHCP and DNS services to the lab.

In Part 4 we are going to build out a Configuration Manager 1511 infrastructure.  This will include a Primary site server (CM16) and 2 Distribution Points (DP16a & DP16b).

Advertisement

Creating Your Own Personal Hydration Solution – Part 3: Domain Controller

Part 0	Introduction
Part 1	Setting Up
Part 2	First VM – Windows Router
Part 3	Domain Controller
Part 4	Configuration  Manager Infrastructure

DC01

After completing parts 1 and 2 of this series you would have a virtual lab with 4 separate  network segments all connected to and routed through a Windows 2012 R2 server (RTR01) acting as the router.  This server will also provide Internet access to any virtual machines that are connected to the 4 network segments.

In Part 3 we are going to build a domain controller (DC01).  This server will provide not only Active Directory Domain Services to the lab but also DHCP and DNS services as well.

Creating Your Own Personal Hydration Solution – Part 2: First VM – Windows Router

Part 0	Introduction
Part 1	Setting Up
Part 2	First VM – Windows Router
Part 3	Domain Controller
Part 4	Configuration  Manager Infrastructure

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.

Creating Your Own Personal Hydration Solution – Part 1: Setting Up

Part 0	Introduction
Part 1	Setting Up
Part 2	First VM – Windows Router
Part 3	Domain Controller
Part 4	Configuration  Manager Infrastructure

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.

[This is going to be a long one.]

Creating Your Own Personal Hydration Solution: Introduction

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.

Task Sequences Fail After Upgrading to MDT 2013 U1

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.

Thanks,
-Michael

---

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.

[Updated]
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.