Tag Archives: mdt

MDT – WinPEshl.ini what does it do?

Published / by Rens Hollanders / 2 Comments on MDT – WinPEshl.ini what does it do?

Something I’ve had on my blogroll for a long time and now finally found some time to write about it.

This little ini file is very important in the process of MDT doing what it does. As some of you may know, MDT uses a standard WinPE image which will be modified on the fly during the “update deploymentshare process” where boot images are generated, drivers embedded, the wallpaper and extra files are set.

After booting the WinPE image it will automatically start a VB script and call the parameters trying to connect with the deploymentshare. This all starts with WinPEshl.ini.

After installing the MDT software on your workstation or (management) server, you will find the ini file on a special location: C\Program Files\Microsoft Deployment Toolkit\Templates.

When you open the file the contents are as following:

Now for instance let’s say you would want something to execute prior to starting the process of connecting to the deployment share, you have some options:

  1. Modify the WinPEshl.ini
  2. Modify the MDT generated boot image after deploymentshare update
  3. Modify the default boot image

The default boot image which MDT uses as base for the modified MDT boot image can be found in the following two locations:

  1. x64: C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\amd64\en-us
  2. x86: C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\Windows Preinstallation Environment\x86\en-us

In my opinion it is best to stick with modifying the WinPEshl.ini for several reasons:

  1. Its traceable, easy documented by saying locating there and there is modified with x and y
  2. Its consistent, if you are altering a MDT generated and updated boot image, you need to do this every single time when you completely regenerate the boot images. I believe that when you are merely updating the existing images nothing changes
  3. It’s considerably faster to modify the ini file, then mounting a wim image with dism providing its customizations.

So what customizations are we talking about here, well I have encountered the following requests:

  1. Running scripts such as placing DNS suffix priority in a multiple domain environment
  2. Running scripts to wipe the disk entirely (for particular machines) preventing the dirty environment found error pop-up
  3. Running diagnostic tasks, password scripts etc.

So to end this, I think WinPEshl.ini is a need little file that has a huge responsibility in the process of MDT which can easily be altered to accomplish things that need to go outside and before the deployment process takes place.

For more info please see: Winpeshl.ini Files

Cheers! Rens

Download Windows ADK: The numerous versions of Microsoft Windows ADK (Assessment and Planning Toolkit)..and where to find them!

Published / by Rens Hollanders / 28 Comments on Download Windows ADK: The numerous versions of Microsoft Windows ADK (Assessment and Planning Toolkit)..and where to find them!


…You get my point right?

As a core prerequisite for Microsoft’s Deployment Toolkit Windows Automated Installation Kit (WAIK) successor: Assessment and Deployment Kit (ADK), count’s numerous versions out there wandering the interwebs. As I’m always looking for the latest version available whenever I perform a Microsoft Deployment Toolkit implementation, I thought it would be nice to create and maintain a list of the most recent versions of ADK out there.

I went on a little investigation and came to the following table:

Name Installed Version URL Release Date
Windows ADK for Windows 10 v1607 10.1.14393.0 Download Sept. 2016
Windows ADK for Windows 10 v1511 10.1.10586.0 Download Oct. 2015
Windows ADK for Windows 10 RTM 10.0.26624.0 Download July. 2015
Windows ADK for Windows 10 10.0.10240.0 Download July. 2015
Windows ADK for Windows 8.1 8.100.26866 Download Sept. 2014
Windows ADK for Windows 8.1 update 8.100.26629 Apr. 2014
Windows ADK for Windows 8.1 update 8.100.26020 Oct. 2013
Windows ADK for Windows 8.1 RTM 8.100.25984 Sept. 2013
Windows ADK for Windows 8 8.59.25584 Download Dec. 2012
Windows ADK for Windows 10 v1703 10.1.15063 Download March. 2017
Windows ADK for Windows 10 v1709 10.1.16299.15 Download Sept. 2017
Windows ADK for Windows 10 v1803 10.1.17 Download March. 2018

I will continue to expand this list as new versions come available. If you have any missing info like download links of the versions listed above. Please do not hesitate to contact me!

Cheers! Rens

MDT – requirements sheet

Published / by Rens Hollanders / 6 Comments on MDT – requirements sheet

Hi my friends, very very long time no see. I sincerely apologize for my period of absence, however this is partially due to lack of new content to write, which is caused by a period of not working with deployment tools.

In previous blog posts, I’ve set out some default settings to configure MDT with, such as the CustomSettings.ini and Bootstrap.ini, and then there is this script which configures your MDT environment automatically with PowerShell.

This time I thought it would be useful to write about the requirements you need for implementing MDT on (a customers) site:

table 1.1 Server Details:
Server Details
Operating System Windows Server 2012R2
(v)CPU 2
(v)MEM 4 Gb
Disk 0 50 Gb
Disk 1 100 Gb

If you want to incorporate the MDT database integration, you’ll need a database on a SQL server, with service accounts with the following permissions:

table 1.2 Database Details:
Object Details
Database Microsoft SQL 2005 or higher
Database permissions MDT Database Service Accounts; dbo_owner
Database permissions MDT Administrators; db_datareader, db_datawriter

If you install Windows Deployment Services to transport your MDT boot image with PXE boot, you’ll need to configure certain scope options in DHCP, take notice that the DHCP option 60 is only needed to be configured when DHCP and WDS run on one and the same server:

table 1.3 DHCP Details:
Scope Option Option Value
60 Client identifier PXEClient
66 Boot Server Host Name
67 Bootfile Name \Boot\x64\wdsnbp.com

The IP helper address needs to be configured, when your DHCP and WDS server are not on the same subnet. This prevents the boot image from being loaded into and over the memory of the network device, but point’s directly to the WDS server.

table 1.4 Network Details:
IP Helper Address

Next up, service accounts, based on least privileges needed to function, and, for setting the OU permissions for the domain join account, there is this very neat little script from MDT guru Johan Arwidmark:

table 1.5 Service Account Details:
Account Name Permissions Object
SA-MDT NTFS: Read & execute, List folder contents, Read Share: Read Folder: DeploymentShare
SA-MDTDomainJoin Create Computer Objects; Delete Computer Objects; Read All Properties; Write All Properties; Read Permissions; Modify Permissions; Change Password; Reset Password; Validated write to DNS host name; Validated write to service principle name; Active Directory: Organizational Unit
SA-MDTDB dbo SQL Server: database user mapping

You can put accounts in groups and give permissions to groups if more people need the same permissions to work with MDT:

table 1.6 Domain Group Details:
Group Name Type Member of Members
DM-MDT Domain local - Security n.a. GM-MDT
GM-MDT Global - Security DM-MDT SA-MDTDB
DM-MDT-Admins Domain local - Security n.a. GM-MDT-Admins
GM-MDT-Admins Global - Security DM-MDT-Admins Individual Active Directory users

Lastly again folder permissions based on least privileges, and also the SQL Share for authentication of unknown users during Operating System Deployment – WinPE phase

table 1.7 Folder permission Details:
Folder Account / Group NTFS Permissions Share Permissions
DeploymentShare SA-MDT Read & execute, List folder contents, Read Read
DeploymentShare Authenticated Users n.a. Read
SQL Share Authenticated Users n.a. Read

So next time you’re going to implement MDT, keep in mind some (preferably all) of the mentioned requirements, and hopefully this will make life again much easier.

~Things not working, privileges wrong? Don’t hesitate to let me know!

Cheers! Rens

MDT – Use MDT cross domain / workgroups

Published / by Rens Hollanders / 2 Comments on MDT – Use MDT cross domain / workgroups

Hi there,

Just a short post of something I had to deal with very recently, an MDT environment that is cross domain / workgroup connected.

Basically I had two challenges:

  1. Connecting to different shares based on DefaultGateway
  2. Connecting to shares in a domain and in a workgroup

The following example of the bootstrap.ini, does just that:

As you can see here, I use the DefaultGateway section to process from which location the machine is going to be deployed, to choose the designated deploymentshare for this particular location.

Next thing, is making sure the authentication of the shares is going smoothly. My first try was using the “LocationServer.xml“, this seemed to solve my problem of having multiple shares. Unfortunately, when you use LocationServer.xml it will destroy your authentication settings, since they are not parsed through while processing the xml file. Leaving you with a question to authenticate (again!) with the target share.

/rant the not parsing of the credentials while using LocationServer.xml is something that goes back since 2010. A thread on social.technet answered by Keith Garner, reports that a bug was filed, but it did never make it to any new release of MDT 🙁

So how did I get around this, by putting all the common denominators in the default section, and all the anomalies in the DefaultGateway subsection. Giving me the opportunity to use the same account, but use a different UserDomain. This means you can use the same account (a domain account for the machines in the domain, and a local account for the machine in the workgroup)

Also since the deploymentshare outside the domain, cannot be resolved by DNS, you’ll need to map this share based on an ip address.

Now doing the same thing for the CustomSettings.ini, gives me to opportunity, to put logfiles for each machine on the same location where it has been deployed.

Happy deploying 🙂

Cheers! Rens

Office 365 – Updated deployment guide

Published / by Rens Hollanders / 53 Comments on Office 365 – Updated deployment guide

I still very often receive questions about how to deploy Office 365 the best way. In a blog I’ve written february 2014 I explain how to deploy Office 365 through MDT.

At the time the installer of Office 365 didn’t wait untill Office 365 was fully installed, instead the installer was initiated and the MDT task sequence proceeded to continue executing other tasks with the impact as a result that if the machine was being rebooted due to a task in the task sequence the installation of Office 365 failed.

Very recently I’ve downloaded the latest version of Office 365 ProPlus Retail, version: 15.0.4745.1001 which I’ve noticed waits during installation until the installation of Office 365 is complete.

In my previous post, I’ve devised a construction, that copied the Office 365 installation files from the MDT deployment share, to the local computer and be executed on the local machine. With the following configure.xml and install.cmd this isn’t necessary anymore:

Second you’ll need to have an Install.cmd that can be called by MDT to execute the installation of Office 365:

This will make sure Office 365 is installed directly from your deploymentshare, without copying files to the local computer and having to clean up those files later.

Just make sure the Office 365 are imported as an application, with the following files residing in the Office 365 folder:


Cheers! Rens