4 March 2020

MDT & Joining the Domain

An important part to any OS deployment is joining the computer to the domain. The whole point of Microsoft’s Deployment Toolkit (MDT) is to automate as much of your deployment process as possible. So it is no surprise that MDT, when properly configured, can automagically join your newly deployed machine to the domain. It’s actually pretty easy to setup.

Part 1

The first part of allowing MDT to join machines to the domain is to setup a unique service account specifically for the task of joining machines to the domain.

Microsoft has helped to make things easier for us and has created a PowerShell script that can be downloaded, placed on your Domain Controller, and run to set a service account up with all of the necessary account permissions to manage computer objects in a specified OU. The script and instructions can be found under ‘Step 1’ at this link: https://docs.microsoft.com/en-us/windows/deployment/deploy-windows-mdt/deploy-a-windows-10-image-using-mdt

Part 2

The second part is going to be adding the correct values into your CustomSettings.ini file. There are the four variables that we need to add to automate the domain join, and one recommended value to skip the corresponding Domain Membership page in the Task Sequence wizard;

  • JoinDomain = The domain we are wanting to join.
  • DomainAdmin = The username of the service account we created earlier.
  • DomainAdminDomain = the domain that the service account resides. It’s typically going to be the same as the ‘JoinDomain’ value, but depending on how your AD Forest is configured, it is possible that it could be a different domain.
  • DomainAdminPassword = The password to our service account.
  • SkipDomainMembership = Yes/No. A ‘Yes’ value will skip the wizard page that asks about domain membership. A ‘No’ value will show the domain membership page.

Here is an example of how it would look when entered into the CustomSettings.ini file.

JoinDomain=MyDomain.tld
DomainAdmin=MDT_DJ
DomainAdminDomain=MyDomain.tld
DomainAdminPassword=Abc123456&!
SkipDomainMembership=YES

One additional item you may want to add to your CustomSettings.ini file is a value to specify which OU object you want the newly joined machine to be added to.

  • MachineObjectOU = Active Directory OU object you want machines to added to. It’s where you would have specified when creating the service account and running MS’s PowerShell script.

Which would look like this in the CustomSettings.ini file.

MachineObjectOU=OU=Workstations,OU=Computers,DC=MyDomain,DC=tld

You’ll want to make sure the OU is properly set for your domain. However, if you prefer to not specify an OU, your machines will all end up in the default ‘Computers’ OU of your domain, no harm there, you will just need to then manually move them into their correct OU.

Here’s what all the combined values I covered in this post would look like when added to the CustomSettings.ini .

JoinDomain=MyDomain.tld
DomainAdmin=MDT_DJ
DomainAdminDomain=MyDomain.tld
DomainAdminPassword=Abc123456&!
SkipDomainMembership=YES
MachineObjectOU=OU=Workstations,OU=Computers,DC=MyDomain,DC=tld

With the service account setup and the values added to our CustomSettings.ini, your deployments should now have no problems getting joined to your domain. Congratulations! You’ve streamlined one more deployment task.

19 February 2020

MDT Screen Resolution Setting

Johan Arwidmark is basically a guru in the world of Windows deployment. His blog (deploymentresearch.com) is a literal treasure trove of information for all things deployment related and it is where I found this tip.

By editing your CustomSettings.ini file you can actually set the resolution values to be written to your unattend.xml file during deployment. How handy is that!?!

Set the resolution to 1280×1024

[Settings]
Priority=Default

[Default]
BitsPerPel=32
VRefresh=60
XResolution=1280
YResolution=1024

Even cooler is the fact that you can actually set it to auto detect the resolution.

[Settings]
Priority=Default

[Default]
BitsPerPel=32
VRefresh=60
XResolution=1
YResolution=1

The auto detection works because Windows realizes how silly it would be to have a screen resolution that was only 1×1. Now that’s a neat trick!

14 February 2020

UEFI, NTFS, and Bootable USB

When using Microsoft’s MDT for deployment, sometimes you need to create a bootable USB to boot your machine into a LiteTouch deployment. Well Thanks to an application named Rufus, that could not be any simpler. Rufus is a utility that helps to format and create bootable USB flash drives, such as USB keys/pendrives, memory sticks, etc.

  • After creating your MDT iso, copy it onto your workstation, or whichever machine you are creating the bootable USB on.
  • Download and install Rufus (at the time of writing this is at v3.8). https://rufus.ie/
  • In Rufus;
    • Select your USB from the Device dropdown menu
    • Click on SELECT, and choose the MDT iso you copied to your workstation
    • If desired, modify the Volume_Label to the name of your preference
    • Under the File system dropdown menu, select NTFS
    • Click on START to begin formatting your device

Now, as long as secure boot is disabled, you can boot direct from your UEFI enabled thumb drive and get to your MDT task sequences.

31 January 2020

Importing an OS into MDT

MDT is a powerful tool but it really needs an operating system, to deploy or capture, if you really want to utilize it’s full potential. Match that with Microsoft’s release schedule of Windows and you will find yourself needing to import a new OS at least once year, if not more. Today we’re going to take a look at importing Windows 10 v1909 into our MDT server.

The first thing that you will need to do is acquire a Windows Installation ISO or or use a captured custom install. Ultimately, we will need a file that is in the Windows Image (.WIM) format. FWIW – Microsoft has been using the WIM format in it’s installation media (DVDs and ISOs) since Windows Vista. Once you have acquired your installation media, either insert your DVD into your machine, or mount the ISO file so it can be accessed.

Open your Deployment Workbench and open the deployment share that you wish to import the OS into. Drill down into it’s folder and click onto Operating Systems. In the Actions pane on the right side of the console, click on New Folder, and create a folder appropriately named for the OS you wish to import and complete the wizard. I’m only importing the 64-bit iso, but if you were import both 32-bit and 64-bit, you might want to specific that in the folder’s name.

In the Deployment Workbench, right-click onto the new Windows 10 folder that you just created. Once selected, Import Operating System.

That will open the Import Operating System Wizard. Unless you are using a custom installation file, you will be selecting Full set of source files to import the WIM file from your DVD or ISO, then click NEXT.

Select your source folder. As i mentioned above, this will be your DVD or mounted ISO, click OK, then click NEXT.

Give your Destination directory a name and click NEXT.

Click NEXT on the Summary page.

You’ll see a progress window as MDT imports your OS.

When the import is complete, you see a message the the process was successful and you can click FINISH.

Because I’m importing from an ISO that has Enterprise, Education, and Profession in it, you can see that that it imported about ten different WIM files. Thats okay… We can delete the versions which we know we won’t use. Select and highlight the versions that you don’t want, right click and select Delete.

There will be a wizard that you can click NEXT through to complete the removal of the unwanted versions of the OS.

That completes importing an OS into MDT. Now we can use the newly imported versions of our OS in our Task Sequences.

18 December 2019

MDT loading to cmd prompt

I was running an MDT LiteTouch deployment and the computer kept getting stuck at a command prompt after loading into MDT environment. Normally it should have launched right into the LiteTouch wizard, but for whatever reason, it just didn’t want to go beyond this point on its own. I discovered two possible ways to circumvent it.

I had used this same means of deployment on other machines of the same make and model, with the same Task Sequence, so I knew it wasn’t a driver issue as many eluded to in the various forums I looked at. However, I went ahead and did an “ipconfig” and also tried to mount the MDT share using “net use“, just to make sure there was no network issues. net use z:\\<servername>\deploymentshare$ Well, it turned out that I did already have an IP address and the mapped drive was already in use. So how can I now get on with my deployment?

The first and possibly the easiest way was to just manually launch the LiteTouch. It is as straight forwards as it sounds. I entered the command below into my command prompt, and viola! The LiteTouch wizard came right up and I continued on my way. X:\windows\system32> Z:\scripts\LiteTouch.vbs

The second method, really isn’t any more difficult than the first. Sometimes a folder named “MININIT” already exists on the computer’s C: drive and it can cause issues when trying to do a new deployment. The way around that is just to wipe the drive and essentially start back at square one. Warning though – Following this method WILL erase the drive and wipe any data that is on it. While it probably doesn’t matter, as you’re stuck anyways, but it is just something to be aware of.

At the first Wizard window, press F8. Then type:

  1. Diskpart (enter)
  2. List disk (enter)
  3. Select disk 0 (choose your main OS disk) (enter)
  4. Clean (enter)
  5. Reboot and start your imaging process again.

After wiping the disk of any pre-existing partitions your next deployment attempt should go smoothly as it now has a blank HDD to work on.