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 – Get Office 365 wave 2016 now!


Microsoft has released Office 2016 officially a couple of days ago, and this also includes the Office 365 version of the Office 2016 suite.

If you already have deployed Office 365 wave 2013 before, you’ll know the Office 365 Deployment Tool (download the latest 2016 compatible version). This tool extracts two files in a folder which allow you to download the Office 365 click-to-run suite for preinstalling the software on computers.

When the tool is downloaded, run it and extract the files to a folder. From there, modify the download.xml as following:

The difference between the previous 2013 version, is that you can specify the update branch. Read more about it here. Basically it’s similar to Windows 10, do you want to be in the fast ring or the slow ring. So by specifying the branch you”ll decide between monthly updates or every four months!

For installing Office 365 I use a second dedicated installation XML:

And I call the installation of Office 365 from a cmd file, so it can be incorporated in MDT, System Center Configuration Manager or RES Automation Manager:

Want to read more about deploying Office 365? Please check my previous posts on this topic! #Office365

Questions, comment’s, or just want to give your appreciation? Let it hear in the comments!

Cheers! Rens

MDT – Updated Powershell scripts for Windows ADK 10 and MDT 2013 update 1 Build 8298


Hi there,

So the word is out, Microsoft has re-released MDT 2013 update 1 after several bugs and errors have come forward during the deployment of Windows 10.

Each new version means that if you use scripts which have a dependency with tools such as MDT, you’ll need to check it for compatibility.

Since two years now I rely on configuring an entire deployment share environment by powershell. Since clicking and mouse pointing my way through ADK and MDT setups were killing my brain cells one setup at a time.

I’ll save you the deep dive into the script’s but here’s a short explanation:

Script 1 will: Automatically download Windows ADK for Windows 10, and MDT 2013 update 1 Build 8298 to the folder from where the script is executed and create a “Software” folder where the content’s are stored.

Once the downloads are completed both tools are installed with default settings silently. And lastly the script will enable the .NET framework and WDS feature / role to configure the server as a MDT deployment server.

Script 2 will: First ask you if you want to split wim files prior to configuring the deployment share. I’ve incorporated this question, since 4 Gb is the FAT32 file size limit and this is a need little option to instantly make your FAT32 UEFI deployments work! Next it will automatically configure an entirely new deployment share in a matter of seconds, with a logical folder structure. Selection profiles, the configuration of WinPE settings and the overall Settings.xml, read more about it here: MDT2013 – Configure everything with Powershell!!!

Now how does this look?

figure 1.1: Software folder created by download and installation scriptMDTDownload002
figure 1.2: The download and installation script doing it’s magic MDTDownload003
figure 1.3: Behold the installation of ADK, MDT and WDSMDTDownload004
figure 2.1: Execution of the Configure DeploymentShare scriptMDTConfigure001
figure 2.2: Script in progress..MDTConfigure002
figure 2.3: Script completeMDTConfigure003

figure 2.4: MDT Environment configured completelyMDTConfigure004

You can find the script’s here:

MDT Download and Install v1.0:

MDT Configure DeploymentShare v3.0 for MDT 2013 Update 1 Build 8298:

Questions, improvements, or want to show your appreciation, just give me a shout out in the comments

Cheers! Rens

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

MDT – MDT 2013 update 1 released


Just a short notice to everyone concerning operating system deployment who have interest in deploying Windows 10. As of yesterday August 17, MDT 2013 Update 1 has officially been released.

Read all about it on Michael Niehaus’ technet blog: here


Find the download links of MDT 2013 update 1 and Windows ADK for Windows 10 here:

Find a list with changes and improvements, here: MDT 2013 Update 1 Now Available

Cheers! Rens