Deploying Windows 10 with Microsoft Deployment Toolkit (MDT)

Microsoft Deployment Toolkit is a collection of tools for automating desktop and server deployments. MDT performs deployments by using the Lite Touch Installation (LTI), Zero Touch Installation (ZTI), and User-Driven Installation (UDI) methods. Only MDT is used in LTI deployments, while ZTI and UDI deployments are performed using MDT with Configuration Manager.

Once downloaded, you will find the tools inside C:\Program Files\Microsoft Deployment Toolkit\. It then creates the deployment share at C:\DeploymentShare which mimics the Deployment Workbench:

Deployment Workbench

The Deployment Workbench is an MMC snapin and will be the main area used to configure the deployment.

Configure MDT to Create the Reference Computer

1. Download Windows ADK
2. Open the Deployment Workbench (DeploymentWorkbench.msc)
3. Import the Operating System (.ISO)
   
   
4. Update any required Out-of-Box Drivers or Packages
5. Create a Task Sequence
   
   
6. Update your deployment share
   
   
7. The Deployment Workbench creates the C:\DeploymentShare\Boot\LiteTouchPE_x64.iso and LiteTouchPE_x64.wim files

Deploy Windows / Capture Image of Reference Computer

You can burn C:\DeploymentShare\Boot\LiteTouchPE_x64.iso to a DVD or you can add it to Windows Deployment Services, which is a server role that gives you the ability to deploy Windows through PXE.

Now boot your reference computer with LiteTouchPE_x64.iso

Once Windows PE boots up, go ahead and choose your Task Sequence that you created earlier

Since you are deploying this from the original operating system, out-of box drivers, applications, etc. you really want to capture a .WIM of this deployment and bring it back into the Deployment Workbench to deploy again so that it is all compacted into one neat file.

The task sequence deployment will begin

Now there will be a .WIM file of this Task Sequence deployment process ready for you to import into the Deployment Workbench.

Configure MDT to Deploy Windows to the Target Computers

During this task sequence process you chose to capture an image of your reference computer. Microsoft recommends you do this. Once you capture the image, you will have a .WIM file that you can import back into Deployment Workbench and start he whole process again (import WIM, create task sequence, boot PE, etc.) to finally deploy to your target computers

1. Add the captured image of the reference computer to the Deployment Workbench
   
   
   
   
2. Create a Task Sequence
   
   
3. Again, boot from LiteTouchPE_x64.iso and this time choose your new Task Sequence you created for this WIM

Deciding to Use the Default Image or a Captured Image

Default image

The default image install.wim is included with the Windows ISO. This image is a basic operating system image that contains a standard set of drivers.

• Advantages
  • The image size is smaller than a captured image.
  • Installing apps and configurations with task sequences is dynamic
• Disadvantages
  • Takes more time

Captured image

With a customized image, you build a reference computer, install apps and configure settings. Then, you capture the image from the computer as a WIM file.

• Advantages
  • The installation can be faster than using the default image
• Disadvantages
  • Not dynamic
  • OS install portion takes longer

In this tutorial, I provide an overview of Process Monitor (ProcMon), a powerful Windows monitoring tool. I explain how to start and filter ProcMon, find changed values, enable boot logging, and run ProcMon against a remote machine. I created this tutorial to practice key concepts for my upcoming interview for the Senior Solutions Architect position at Microsoft. By mastering ProcMon and other tools in the Windows Sysinternals suite, I was able to showcase my troubleshooting and diagnostic skills to the Microsoft hiring team.

Process Monitor (ProcMon) Overview

Process Monitor is a monitoring tool for Windows that shows live file, Registry and process/thread activity. It is a combination of two older Sysinternals utilities, Filemon and Regmon.

Process Monitor is a part of Windows Sysinternals which is a set of utilities to manage, diagnose, troubleshoot, and monitor Windows. Sysinternals was originally created in 1996 by Winternals Software and was started by Bryce Cogswell and Mark Russinovich. Microsoft acquired Winternals on July 18, 2006, which included Sysinternals and the utilities within it.

The set of tools is now available on any Windows computer by opening \\live.sysinternals.com\tools\ in file explorer. This UNC path is a service provided by Microsoft and is referred to as Sysinternals Live.

Starting Process Monitor

You must run ProcMon.exe from an elevated command prompt, so that it opens in administrative mode as it needs to install Filter Drivers. As soon as you start it, it will begin capturing, and quite quickly will start taking space from your paging file. Therefore, only run it for the necessary time as leaving it running will likely cause your computer to crash unless you run it to Drop Filtered Events against a certain filter. More on this under Filter Process Monitor

Filtering with Process Monitor

ProcMon can be run for days if you chose to have it filter for a certain type of event. Start by selecting Filter -> Drop Filtered Events.

Choosing this option means that only what is filtered will be saved to the log file, as opposed to only filtering will filter what you see, but will log all to the log file. Now, filter to only view processes where the result is Access Denied by opening Filter -> Filter:

You can also filter right from the main console by selecting a Process, right clickign and choosing one of the filtering options. For example, if we choose to Exclude Events After this event, we can also see that it automatically creates a filter for this choice which we can choose to remove later.

Once you have a specific filter set that might be useful for a certain troubleshooting task, you can choose to Save or Load the filters under the Filter menu:

Advanced Filtering with Process Monitor

In some instances, you may want to view all events, including those by default that are filtered out of ProcMon. You could opt to manually remove all of the built in filters, but an easier way to do this is to simply select Filter -> Enabled Advanced Output

How to Find Changed Values

Some people will use ProcMon to try and see what changes a process makes, but it can become daunting. An easier method is to try and utilize ProcMon in a way where you can filter for events happening. Let’s say for example we want to see what registry values are set when we disable Automatic Restart on system failure. To do this, first stop and clear the trace, then filter ProcMon to only show RegSetValue Operations:

Now, begin the capture and make the desired change:

Stop the capture once the change has been made. Now, we can easily see the registry value change that was required to make this change:

Enable Boot Logging

A very useful feature of process monitor is to trace events during logoff, shutdown, startup and login. There is a special feature to do this ProcMon to do this under the Options menu. Select Enable Boot Logging and then reboot your system. The next time you open ProcMon, you’ll be prompted to save the boot log events to a file.

ProcMon Tools: Process Tree

ProcMon has several tools available by selecting Tools from the menu. For example the Process Tree shows you the processes lifetime and how long they lived during the trace.

Running ProcMon against a Remote Machine

Utilizing psexec, 23 can run ProcMon against a remote machine if we do not or cannot be at a remote site for monitoring.

To start the trace on a remote computer run:

Psexec \\ /s /d procmon.exe /accepteula /quiet /backingfile c:\hostname_trace.pml

Now, to stop the trace on the remote computer run:

Psexec \\ /s /d procmon.exe /accepteula /terminate

Finally, copy the log file to your remote machine for viewing:

xcopy \\\c$\hostname_trace.pml c:\TEMP

You can then view the log file in ProcMon locally by running:

Procmon /openlog c:\temp\hostname_trace.pml

ProcMon Filter Drivers

If ProcMon has some issue connecting to the filter driver and gets stuck opening, you can run it to not connect to the filter driver:

Procmon /noconnection

To view the filter driver that is associated to Procmon, run

fltmc

In this Netsh Networking Shell Tutorial, I explain how to use the Netsh command line scripting utility that has been around since Windows Server 2003. Although somewhat depreciated by cmdlets available in PowerShell, Netsh can allow you to view or change the network configuration of your local computer or a remote computer. The tutorial takes you through how to browse around the tool, open contexts, and use sub-contexts to navigate through commands. It also covers how to use Netsh to manage remote servers and workstations, popular Netsh commands, and even provides an example batch file. The reason I created this tutorial was to help me improve my understanding of Netsh before my then-upcoming Microsoft interview to be a Senior Solutions Architect.

Netsh Overview

Netsh, pronounced just as it’s spelt as “netch”, is a command line scripting utility that’s been around since Windows Server 2003. Although somewhat depreciated by cmdlets available in PowerShell, Netsh can allow you to view or change the network configuration of your local computer or a remote computer. Netsh can be run at the command line or built into a script inside of a batch file.

To start Netsh, open a command line shell or PowerShell and type:

Netsh

How to Browse Netsh

Once inside Netsh, type “?” to see a list of commands available to you:

Note how it describes the list as “commands in this context”. Contexts are groups of commands available to you once you are inside of their context. Contexts can be nested in other Contexts and you’ll see it lists what sub-contexts are available. To get inside a context, just type its name, such as interface, and again a “?” will show you what commands area available to you in that context.

This is generally how you browse around. By opening contexts, typing “?” to see what is available, and typing sub-contexts to get even deeper until you find the command you want.

Also, note how it mentions that PowerShell should be used rather than Netsh for TCP/IP commands. This is true for most Netsh commands, so just keep in mind that, although useful, PowerShell has largely taken over Netsh.

Using Netsh to Manage Remote Servers and Workstations

While you’re still at the cmd line shell (net yet into Netsh), you can invoke Netsh against a remote computer by following this format:

Netsh -r  -u <domain\user> -p  

In this example, we can see the IPV4 information on the remote computer 63769:

For the -r argument, you can supply the hostname as either the IP address, the hostname, or the FQDN of the remote host.

Running Commands in Netsh

The general syntax to run a netsh command is:

netsh[ -a AliasFile] [ -c Context ] [-r RemoteComputer] [ -u [ DomainName\ ] UserName ] [ -p Password | *] [{NetshCommand | -f ScriptFile}]

For example, to open a firewall port on a remote computer:

netsh –r WORKSTATION001 –u DOMAIN\User –P P@ssw0rd! advfirewall set portopening tcp 445 smb enable

Additionally, some commands require a parameter string. In the case where the parameter string requires a space, be sure to include it in quotes:

interface="Wireless Network Connection"

Popular Netsh Commands

1. Show the IP configuration

   
   netsh interface ip show config
   

2. Show IPv4 or IPv6 information

   
   netsh interface ipv6 show address
   

3. Open a Firewall Port

   
   netsh advfirewall firewall
     add rule name="HTTPS"
     dir=in action=allow protocol=TCP localport=443
   

4. Show Network Adapter Status

   
   netsh interface show interface
   

5. Configure adapter for static IP Address

   
   netsh interface ip
     set address "Local Area Connection"
     static 192.168.0.100
     255.255.255.0 192.168.0.254 1
   

6. Configure adapter to use DHCP

   
   netsh interface ip 
     set dns "Local Area Connection" dhcp
   

Example Batch File

This is an example batch file:

netsh wins server 192.168.125.30 add name Name=MY\_RECORD EndChar=04 IP={192.168.0.205}

netsh wins server 192.168.125.30 add partner Server=192.168.0.189 Type=2
  
netsh wins server 192.168.0.189 add partner Server=192.168.125.30 Type=2
  
netsh wins server 192.168.125.30 init push Server=192.168.0.189 PropReq=0
  
netsh wins server 192.168.0.189 show name Name=MY\_RECORD EndChar=04

Windows 10 Servicing Model

With Windows 10, a new model was introduced called “Windows as a service – WAAS”. Rather than new features being added only in new OS/every few years, WAAS will continually provide new capabilities. The Semi-Annual Channel is a twice-per-year feature update release targeting around March and September, with 18-month servicing timelines for each release

Starting October 2016, Windows also changed it update model to have a single Monthly Rollup that takes care of security and reliability issues. The update will be published to SCCM/WSUS automatically. Each month’s rollup will supersede the previous months, so there is only ever the most recent update to install to be up to date.

Deploying Windows 10

Deploying Windows 10 is easier than with previous versions of Windows because now it supports a simple in-place upgrade process from 7 -> 10 and 8 -> 10. This automatically preserves all apps, settings, and data. Then, once you’re running Windows 10, 10 -> 10 deployments of Windows 10 feature updates, such as Windows 10 1703 -> Windows 10 1706 is the new way to go

Additionally, Windows 10 is compatible with most hardware and software capable of running on Windows 7 and Windows 8. Software compatibility is so high because Win32 application programming interfaces were not changed very much between versions. As a result of this, the app compatibility testing process is simplified. Finally, most hardware drivers that functioned in 7 or 8 will continue to function in Windows 10.

Feature Updates (“A New OS”)

Released twice a year, one in March and one in September. Since feature updates contain an entire copy of the OS, they are also used to install Windows 10 on existing devices running Windows 7 or Windows 8.1, and on new devices where no operating system is installed. Examples include 1703, 1709, aka March 2017, Sept 2017

Monthly Quality Rollup Update (Monthly Update)

In addition to larger feature updates, Microsoft will publish regular monthly quality updates on Patch Tuesday. These smaller updates are similar to the monthly security updates and patches that you have been used to before Windows 10, but there are some significant differences. For one, the new quality updates are specific to the Windows 10 versions you are currently running. Secondly, expect Microsoft to publish as many of these as needed for any feature updates that are still in support.

No longer will you see individual KB updates, but rather the Monthly Rollups as such:

Servicing Channel (previously called Branches)

Servicing Channels are determined by the frequency with which the computer is configured to receive feature updates. In other words, it defines when a “Feature Update / A New OS” is available to you after it is released by Microsoft.

Deploying Windows 10 via SCCM

With all the latest versions of the Configuration Manager console (see my other article New Features in SCCM) the Windows 10 Servicing Dashboard is now available to you to begin deploying Windows 10 feature updates. This will be used to deploy Windows 10 in SCCM.

Deployment Rings

First, let’s take a closer look at the area on the Windows 10 servicing dashboard defined as a Deployment Ring. A ring is a groups of PCs that are all on the same branch and have the same update settings. Rings can be used internally by your company to better control the upgrade rollout process.

Deploying prior versions of Windows required you to build groups of users/computers to deploy the new OS out to in phases. These typically ranged from the most adaptable and least risky (like your IT staff) to the least adaptable or riskiest (like executives). Now with Windows 10 deployment Rings, a similar tactic exists, but the ideas is a little different.

Deployment Rings, in the simplest sense, are a way for you to separate machines into your deployment timeline. The idea is to have each deployment ring reduce the risk of issues derived from the deployment of the feature updates by gradually deploying the update to entire departments, just like you had before.

Creating your Deployment Rings should only really need to occur once, but revisit from time to time to assure everything is still how you want it.

Here is an example of a set of deployment rings you could create in your environment

You could additionally have a ring for the LTSC Serving Channel for things such as ATMs if you were a bank.

Create SCCM Collections Based Off Your Deployment Rings

You must start the Windows 10 servicing process by creating collections of computers that represent the deployment rings we defined above. In this example, you create four collections:

• Windows 10 – Pre-Pilot
• Windows 10 – Pilot
• Windows 10 – Production
• Windows 10 – Executive

Limit these collections to only hold Windows 10 computers. If you don’t already have a Windows 10 collection to limit from, simply create one with a query such as:

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client
from SMS_R_System
where SMS_R_System.OperatingSystemNameandVersion = "Microsoft Windows NT Workstation 10.0"

Finally, after you have created your four collections, add the computers inside of those collections that you would want represented in each deployment phase.

Use Windows 10 Servicing Plans to Deploy Feature Updates

There are two ways to deploy Windows 10 feature updates with SCCM.

1. Use Windows 10 Servicing Plans, which are similar to Automatic Deployment Rules for software updates.
2. Use a Task Sequence, which is the old way.

For this article, we are going to focus on Windows 10 Servicing Plans as Task Sequence deployments can be covered in other areas. For example, let’s create the serving plan for the collection, Windows 10 – Production. Creating the serving plans for the other collections will be a similar process.

1. In SCCM console, go to Software Library -> Overview -> Windows 10 Servicing, and then click Servicing Plans.
2. On the Ribbon, click Create Servicing Plan.
3. Name the plan Windows 10 – Production (Servicing Plan), and then click Next.
4. Next, select/browse to the Windows 10 – Production collection, and click Next.
5. On the Deployment Ring section, choose the Business Ready (Semi-annual channel) readiness state, set the delay to 120 days, and then click Next.
6. On the Deployment Schedule page, click Next to modify the values if you wish, but the defaults of making the content available immediately and requiring installation by the 7-day deadline are fine for this example.
7. On the User Experience section, choose Software Installation and System restart (if necessary). Select Workstations, and then click Next.
8. On the Deployment Package section, select create a new deployment package. In Name, type Windows 10 – Upgrades, select a UNC path for your package source location, and then click Next.
9. On the Distribution Points section, add the Distribution Points you want this deployment package to be available from (preferably the same ones these computer’s Boundary Groups would be associated to)

Excellent. You now just created a servicing plan, for the Windows 10 – Production collection, which is based off the Windows 10 –Production Deployment Ring. As you can see as we created the serving plan, your Production users will get the Windows 10 Feature Update automatically deployed to their computer’s 120 days after it is released by Microsoft. That’s pretty simply, right?

Finally, you could elect to create your Windows Update ADRs to deploy Monthly Quality Rollups to this same collection 7-14 days after they are released on patch Tuesday, completing the criteria we reviewed in the Deployment Rings table earlier. Servicing plans use only the “Upgrades” software updates classification, not cumulative updates for Windows 10. For those updates, you will still need to deploy by using the software updates workflow.

Converting from BIOS to UEFI without Wiping Harddisk (MBR2GPT.EXE)

UEFI Convergence has been a big issue, and required a “wipe and load” until Windows 10 1703 released MBR2GPT.EXE. This tool is used to Shift from MBR to GPT so you can go from BIOS to UEFI without having to reformat. Usually, MBR + BIOS, and GPT + UEFI go hand in hand. This is compulsory for some systems (eg Windows), while optional for others (eg Linux).

Windows 7 (BIOS) -> Windows 10 (UEFI)

Mentioned in the 1703 feature updates below, MBR2GPT.EXE converts a disk from the Master Boot Record (MBR) to the GUID Partition Table (GPT) partition style without modifying or deleting data on the disk. The tool is designed to be run from Windows PE or from the full Windows 10 OS by using the /allowFullOS option.

MBR2GPT.EXE is located in the Windows\System32 directory on a computer running Windows 10 version 1703 (Creators Update).

“Use this tool for in place upgrade.”

Example Use of MBR2GPT

X:\>mbr2gpt /convert /disk:0
MBR2GPT will now attempt to convert disk 0.If conversion is successful the disk can only be booted in GPT mode.

These changes cannot be undone!

*After the disk has been converted to GPT partition style, the firmware must be reconfigured to boot in UEFI mode.

MBR vs GPT

Compared with MBR disk, A GPT disk can support larger than 2 TB volumes where MBR cannot. A GPT disk can be basic or dynamic, just like an MBR disk can be basic or dynamic. GPT disks also support up to 128 partitions rather than the 4 primary partitions limited to MBR. Also, GPT keeps a backup of the partition table at the end of the disk. Furthermore, GPT disk provides greater reliability due to replication and cyclical redundancy check (CRC) protection of the partition table. GPT disk partitioning style supports volumes up to 18 exabytes in size and up to 128 partitions per disk

BIOS vs. UEFI

UEFI enables better use of bigger hard drives. Though UEFI supports the traditional master boot record (MBR) method of hard drive partitioning, it doesn’t stop there. It’s also capable of working with the GUID Partition Table (GPT), which is free of the limitations the MBR places on the number and size of partitions. GPT ups the maximum partition size from 2.19TB to 9.4 zettabytes.

UEFI may be faster than the BIOS. Various tweaks and optimizations in the UEFI may help your system boot more quickly it could before. For example: With UEFI you may not have to endure messages asking you to set up hardware functions (such as a RAID controller) unless your immediate input is required; and UEFI can choose to initialize only certain components. The degree to which a boot is sped up will depend on your system configuration and hardware, so you may see a significant or a minor speed increase.

Windows 10 Feature Updates – What’s New

This section is meant to provide a broad overview of the changes in the latest Windows 10 Feature Updates.

Windows 10 1709

Below is a list of some of the new changes in Windows 10 1709, also known as the Fall Creators Update. 1709 also contains the features from version 1703.

Deployment

• Windows AutoPilot – a zero touch deployment for Windows 10 devise, is now configurable with Configuration Policies.
• Windows 10 Subscription Activation – lets you deploy Win 10 Enterprise without the need for keys or reboots.
• Windows Automatic Redeployment – similar to Steady State (oh I how I loved and miss Windows Steady State) or DeepFreeze, which allows you to wipe the OS back to a known state you set.

Mobile Device Management (MDM)

• MDM in Intune has been expanded to include domain joined devices with Azure Active Directory. Group Policy can be used with AD joined devices to trigger auto-enrollment to MDM.

Application Management

• Windows Mixed Reality Introduction – VR headsets such as Samsung HMD Odyssey now integrate into Windows 10

Windows 10 1703

Below is a list of some of the new changes in Windows 10 1709, also known as Creators Update.

Configuration

• Windows Configuration Designer – Let’s you provision devices such as needed for bulk enrollment in InTune
• Windows Spotlight – New MDM / Group policy settings made available to turn it off

Deployment

• MBR2GPT.EXE – Used to Shift from MBR to GPT so you can go from BIOS to UEFI without having to reformat. Usually, MBR + BIOS, and GPT + UEFI go hand in hand. This is compulsory for some systems (eg Windows), while optional for others (eg Linux). Windows 7 (BIOS) -> Windows 10 (UEFI). Because this is such an important feature, I cover it more above.