Tag Archives: mdt 2013

Office 365 – Automatic deployment of Office 365 with MDT

Published / by Rens Hollanders / 79 Comments on Office 365 – Automatic deployment of Office 365 with MDT

This blog has been updated by a new blog:
Office 365 – Updated Deployment Guide

Not every blog needs to be technical, sometimes clustering information, that is shattered over the internet can be useful too!

This time I want to explain how Office 365 can be deployed unattended, automatically, first time right!

On my journey into all the new stuff  (for me at least), I’ve encountered allot of things in the past couple of months. Automatic deployment of bitlocker on Windows 8.1, Intune, Server 2012 (R2) etc.

The challenges that arise by trying to work and automate with these new things really make me enjoy my work, because it is fun to do, it provides insight and experience after you have managed to get things working. So was this, when I was looking into Office 365. For a project that involves Windows 8.1, Office 365 and Windows Intune, I was looking on how to gather the right files to do a unattended deployment of Office 365 and it all came down to this:

1. Know which Office 365 plan you have!

First of all, there is this website: Compare Office 365 for Business Plans this Microsoft website explains the number of Office 365 plans that are available and lets you as a customer, reseller or company choose which plan suits best for your purpose.

figure 1.1: Office 365 Business Plans


Based on the chosen plan, Microsoft has a list of official product id’s, just like the regular office suites, which are used to identify which version of Office we are dealing with here: Product IDs that are supported by the Office Deployment Tool for Click-to-Run

2. Know which Product ID you need!

As you can see, the product IDs differ much from the Business Plans names:

The following Microsoft Office 365 product IDs are supported by the Office Deployment Tool for Click-to-Run in Office 365 deployments:

  • O365ProPlusRetail
  • VisioProRetail
  • ProjectProRetail
  • SPDRetail (SharePoint Designer)

In addition to these product IDs, the following non-Office 365 product IDs are supported by this tool:

  • AccessRetail
  • ExcelRetail
  • HomeBusinessRetail
  • HomeStudentRetail
  • InfoPathRetail
  • LyncRetail
  • ProfessionalRetail
  • O365HomePremRetail
  • O365SmallBusPremRetail
  • OneNoteRetail
  • OutlookRetail
  • PowerPointRetail
  • ProjectStdRetail
  • PublisherRetail
  • VisioStdRetail
  • WordRetail

These product Id’s come in quite handy, when trying to retrieve the Office 365 click-to-run files, which are no ordinary setup.exe and some source files, but rather exist out of several cab files (depending on what you are downloading) and a number of *.dat files containing the source files.

3. Acquire the Office Deployment Tool for Click-to-Run!

It all starts with the setup.exe for Office click-to-run which can be downloaded here: Office Deployment Tool for Click-to-Run

This is no ordinary setup as mentioned earlier, instead it contains the logic to download Office 365 click-to-run based on certain command line switches and a “configure.xml”

figure 1.2: Office 365 click-to-run setup files


4. Know how to use the setup.exe

When downloaded, these files are located in a folder. Open up an elevated command prompt, browse to the folder and type:

setup.exe /?

This will provide the following available information and command line switches:

figure 1.3: command prompt


  • setup.exe /download
  • setup.exe /configure
  • setup.exe /packager

The purpose of each switch is explained in the command prompt.

Based on the configuration of the configure.xml, a Office 365 click-to-run installation will be downloaded to a designated directory. Based on the very brief documentation about the configure.xml, I choose to do the following:

Create one “configure.xml” for downloading and call it “download.xml”, and one “configure.xml” for installation and call it “install.xml”. This way it’s not necessary to change the xml file ever again. Since within the configure xml a download directory is specified, but this directory also functions as a source folder. That’s the reason why I used two xml files, since the download and source directory can be different.

Next I’ve created a command line file (cmd) which does the following when running the Office 365 click-to-run during an automatic deployment:

codeblock 1.1: install.cmd

It copies the source to the local %temp% directory into a seperate folder. It executes the installation of Office 365 click-to-run locally, and unattended, and when done, cleans up the temp folder.

To demonstrate the differences between the xml files, I have provided a screenshot of them opened in Notepad++

figure 1.4: download.xml and install.xml in Notepad++


as you can see I’ve used one of the desired Product ID’s specified by Microsoft’s website, I’ve specified on the download.xml a source path where the files can be stored, and on the install.xml the source path for installation.

5. Incorporate in MDT (or any other tool)

In MDT I’ve created the following:

figure 1.5: MDT Application


First an application, which calls the install.cmd

figure 1.6: MDT Task Sequence


and embedded this step as an “install application” step in my task sequence. Since I use this task sequence to build reference images, I’ve disabled other versions of Office and added the Office 365 click-to-run as an application to be installed.


Deploying Office 365 click-to-run isn’t that hard to do, you just need to know where to look and how to approach the installation. Keep in mind that whatever Office version you download, this software is not branded to one Office 365 account. The software is universally applicable. Since after the deployment you always need to sign into Office with your Office 365 account, thus activating 1 out of 5 available installations for this account.

Anything to report, contribute or have done deploying Office 365 click-to-run in any other (efficient) way. Please feel free to contribute in the comments, or write me an e-mail or contact me at twitter!

Find attached the screenshots and files used for my Office 365 click-to-run deployment


Thanks for reading 🙂

MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Published / by Rens Hollanders / 5 Comments on MDT2013 – Powershell ‘BESERK’ mode, configure everything with Powershell!!!

Very recently, deploymentreseach’ Johan Arwidmark, blogged about configuring your DeploymentShare properties (which are saved in .\Control\Settings.xml) with Powershell.

Some time ago I started working on some Powershell scripts myself, mostly oriented on configuring the bootstrap.ini and customsettings.ini, and creating some folders within the MDT Workbench.

While I never had gotten the time and energy to finish it, Johan’s blog basically pushed me over the edge, and then it happened… I went BESERK /cannot compute 😛


The result you can find in the following script which not only configures your deployment share properties, but also configures:

  • Bootstrap.ini
  • CustomSettings.ini
  • Modifies “.\Scripts\Litetouch.wsf” to use the _SMSTSPackageName variable
  • Configure DeploymentShare Properties
  • Creates a folderstructure within MDT
  • Creates selection profiles within MDT

The script! Updated @ 2014-03-20

Basically this script can be divided into five pieces:

1. Constants

The constants that I have declared are the variables that represent the value that is shown, by modifying these values, you can customize and personalize this script for your own purposes. This script is primarily intended for new to be configured deployment environments, so keep in mind that using this script on existing environments will overwrite all content within the bootstrap.ini and customsettings.ini!

2. Configuring Bootstrap.ini and Customsettings.ini

Basically I use a multiline string for both my Bootstrap.ini and CustomSettings.ini and within that line of code, on certain places I call my variables. This way the variables will be used for input, instead of having to change a server name every single time on every single row of code.

3. Configuring the DeploymentShare properties

This part we already know from Johan / deploymentreseach, however I’ve took the liberty to customize it to my wishes, and fully write out all the available settings in .\Control\Settings.xml

4. Configure a logical folderstructure within the MDT Workbench

This part is quite new, I now know again thanks to Johan and Roger the Young a PSDrive can be browsed from a powershell command prompt, just type: dir ds001: and you can actually see and browse the MDT Workbench ‘folder structure’.

figure 1.1: Browse PSdrive


If you want to browse any further, just type dir DS001:\Applications or “DS001:\Operating Systems” (note that if you use spaces in your folders, you need to use quotes “”)

5. Configure selection profiles for Driver and Packages selection

The last thing I wanted to do is configure pre-configured selection profiles which can be uses for injecting certain drivers, targeting packages, creating media etc.

What has changed since 2014-03-20

The script needed some simplification to avoid having to enter the same values at different places. Also now the script creates an entire deployment share for you. So now there is no need to create an deploymentshare with MDT before executing this script. Lastly the ZTIDiskpart.wsf will be modified to calculate with binary metrics. So a 100 Gb disk partition specified will actually end up as an 100 Gb disk partition instead of 98,7 Gb.


Is this the right way to do it, I have no clue, what I do know is that I never want to configure a deploymentshare manually ever again, so this script definitely helps me. Also, adjusting the values of the constants declared is a fraction of the effort I have to put in vs. going through “Create folder” wizards for the 50th time.

Special thanks go out to scripting wizard Roger the Young a.k.a. “DrillSergeant” and Johan Arwidmark, for giving me renewed inspiration to continue to develop this script in what it has become.

ps I. forgive my powershell language, using words as constants, variables, properties and values, are perhaps not used in the correct way! -im still trying 🙂

ps II. also I can imagine this script can be simplified drastically, and I don’t mind if you do, as long as you share it back with me, like I shared it here with you 😀 Or as the Germans say: “wiedersehen macht freude”

Finally, you can download the script here:


MDT 2013 – Configuring your environment for Bitlocker deployments with TPM, Windows 8.1 and MDT 2013

Published / by Rens Hollanders / 20 Comments on MDT 2013 – Configuring your environment for Bitlocker deployments with TPM, Windows 8.1 and MDT 2013

In a previous post I explained how we could deploy the HP Elitepad 900 with the Microsoft Deployment Toolkit.

For that same project that I have recently worked on, it was a requirement that this tablet would be deployed unattended, securely and reproducible.

I defined the following actions that needed to be done:

  1. Extending the AD Schema
  2. Update policy templates (since we where running Server 2008 R2)
  3. Configure ‘Bitlocker’ Group Policy Settings
  4. Configure CustomSettings.ini
  5. Configure Task Sequence
  6. Configure Unattended.xml
  7. Use a domain account
  8. Perform a test deployment

1. Extending the AD Schema

On the internet there was a lot of information to find on how to achieve this. The information that I found useful was mostly from Microsoft’s own blog sites and was very helpful in configuring this to get it to work first time right.

The blogs that helped me achieve this:

From the link below a complete documentation guide and 4 vbs scripts help you configure the Active Directory Domain Environment to be prepped for storing Bitlocker information into Active Directory.


The basic requirements on how to achieve having bitlocker write information into active directory, can be derived from the document: “Configuring Active Directory to Back up Windows BitLocker Drive Encryption and Trusted Platform Module Recovery Information.doc” which can be downloaded from the link I have provided.

2. Update policy templates

Updating the policy templates makes sure, that the Group Policy Manager can posses over the latest available policy templates out there. When running a Server 2012 R2 domain controller, these templates are already available, but if you’re running an earlier version of Windows Server (from 2003 sp2 up to 2008 R2), it is recommended that the policy templates are updated.

This can be done by:

  1. Downloading the Administrative Templates (.admx) for Windows 8.1 and Windows Server 2012 R2
  2. Updating the current templates with the new templates

Step 2. is actually quite easy, type in your FQDN followed by “\SYSVOL\Policies” which brings you to the folder where the policy templates are located. Just in case before you do anything, creating a back-up of the current policy files might come in handy in case you want to rollback or something goes wrong.

Just paste the new templates in the Policies folder, to find the new Server 2012R2 and Windows 8.1 policies available in the Group Policy Manager straightaway.

3. Configure ‘Bitlocker’ Group Policy Setting

Configuring the required group policy settings for Bitlocker, makes sure all the necessary information about the computer object will be stored in Active Directory that is being deployed. In the zip file at the bottom of this page you will find the desired GPO configuration in HTML, needed to store the information Active Directory. Also these policies are perfectly explained in the referenced document above, and in the provided ‘useful links’  section at the bottom of this page. And to get you started, I have provided a screenshot of those policies right here:

figure 1.1: Bitlocker GPO Configuration


4. Configure CustomSettings.ini

Configuring the CustomSettings.ini. Basically there is enough information to find in the documentation of MDT itself on how to configure the properties for bitlocker, and which properties you can configure and what their values are. However I did some investigation, and came up with the following configuration:

figure 1.2: DeploymentShare properties, Rules (customsettings.ini)


codeblock 1.1: customsettings.ini rules

As you can see I have set my priority on Model 1st and Default 2nd.

So all rules stated under  HP Elitepad 900 overrule the Default section, and only apply for this model.

For clarification I often comment my customsettings.ini, since the people who are going to work with it, may want to understand why a certain setting is set.


5. Configure Task Sequence

When the CustomSettings.ini is configured, the next thing we need to do is make some adjustments in the task sequence on the Bitlocker part:

figure 1.3: Task Sequence properties, configuring bitlocker


In the ‘State Restore’ section, click on the “Enable Bitlocker” step, and check the following:

  • Current Operating System Drive
  • TPM Only
  • Choose where to create the recovery key
  • In Active directory

Alternatively you may check: “Wait for bitlocker to complete the drive encryption process on all drives before continuing the task sequence execiution

This means, that the Task Sequence will wait until the entire drive is encrypted, then perform a reboot, and continue with the task sequence.

6. Configuring Unattended.xml

Configuring the Unattended.xml has little to nothing to do with configuring bitlocker, however, to achieve a fully unattended installation. It is recommended you extend your Windows 8.1 Unattended.xml in the TaskSequenceID folder with the following additions:

codeblock 1.2: Windows 8.1 unattended.xml additions to suppress Windows 8.1 setup wizard

The following strings make sure the Windows 8.1 setup will not interfere with the process.

7. Use a domain account

Since we are configuring deployments to work with Bitlocker and storing the recovery password into Active Directory we at least need some form of authentication. My experiences are, that the domain join account which is used to join the machine to the domain, has enough privileges to first: create the computer object in Active Directory and second: write the bitlocker recovery key and TPM owner information into Active Directory on the same computer object.

A domain account does not need all kind of fancy privileges and certainly not needs to be an Domain Admin. To see which privileges are required, please visit the following two blogs which explain it perfectly:

8. Perform a test deployment

The only thing that remained was performing a deployment test, which of-course I did, and the results were very satisfying 🙂

figure 1.4: trace64.exe – bdd.log


figure 1.5: computer object properties – active directory


figure 1.6 computer object properties – bitlocker-recover


Usefull links

These links helped me on my way achieving this:

Find attached the resultant set of policy that has been configured in Group Policy Manager, a copy of the BDD.log of a successful deployment, the screenshots used in this blog, and a copy of my customsettings.ini rules that I have used.


If there are any questions or improvements you’d like to share, please feel free to contribute in the comment section!

Thanks for reading this blog! 😀

ps. forgive me for the Dutch computer object property screenshots, this is just for the moment until I can retrieve some English looking panes.

WinPE 5.0 will not boot on Hyper-V properly if start-up memory is less then 1024 Mb

Published / by Rens Hollanders / Leave a Comment

Since Windows 8.1 is here, and I’m a deployment enthusiast who likes to work with new things, I needed to upgrade my own system to Windows 8.1.

After this was complete I immediately installed the Hyper-V client role on my machine and created a Windows Server 2012R2 with MDT 2013 and Windows Assessment and Deployment Kit 8.1 for Windows 8.1 and Windows Server 2012R2.

During the installation of the Windows Server 2012R2 in Hyper-V I received the following error: “Error code: 0xE0000100

figure 1.1: Windows Server 2012R2 installation error


Later on it appeared to me that addressing less then 1024 Megabytes of memory, caused this error.

After my server and MDT 2013 where succesfully installed, I wanted to do some deployment testing using one of my VM’s which I have configured as following:

figure 1.2: Hyper-V Machine Configuration – Memory


Since I’m only using Hyper-V for my own lab/test environment and my client machine has 16 Gb of RAM memory, I always check the “Use Dynamic Memory for this virtual machine” checkbox, thinking that if my virtual machine needs more memory then 512 Mb, it will claim it by itself!

By increasing the memory configuration in Hyper-V for this particular virtual machine from 512 Mb to 1024 Mb the installation error of Windows Server 2012R2 was resolved, which got me thinking…

If Windows Server 2012R2, Windows 8.1 (which has been released at the same time with these two operating systems) and WinPE 5.0, all have the same kernel, increasing the memory from 512 Mb to 1024 Mb on a virtual machine which I’m going to to use for MDT deployments should solve my problem that WinPE 5.0 stalls during boot, and shows no MDT wizard screens within WinPE, and my assumption was correct

So, if you encounter this on your own lab environment, or using WinPE 5.0 on Hyper-V, then make sure the virtual machine you are using has at least 1024 Mb of startup memory available!

Almost weekend! Cheers! 😀

MDT 2013 – Deploy HP Elitepad 900 using the HP Expansion Jacket, HP Dockingstation, MDT2013, WinPE 5.0 and ADK 8.1

Published / by Rens Hollanders / 4 Comments on MDT 2013 – Deploy HP Elitepad 900 using the HP Expansion Jacket, HP Dockingstation, MDT2013, WinPE 5.0 and ADK 8.1

Well… that’s a mouth full, but I couldn’t describe it better any other way 🙂 Because that’s what I’m doing right now!

In this ‘tutorial’, I will explain the steps I did to achieve a basic MDT LTI deployment based on:

  • MDT Lite Touch Deployment
  • FAT32 Formatted USB Bootable WinPE 5.0 stick
  • Deploy HP ElitePad 900 with all drivers installed working out-of-the-box

For a new project I’m working for a major health care facility which are going to use approx. 800 HP Elitepad 900 tablets, who will be running not the stock Windows 8, but the recently released Windows 8.1.

Currently I’m in testing phase so I’ve got a nice setup at home, running some VM’s, a connection to my deployment share and of course a HP Elitepad 900 tablet, with HP Expansion Jacket and HP Dockingstation

To get things going I first installed a MDT 2013 dedicated machine, with the newly released Windows ADK 8.1 which brings us support for Windows 8.1 and Server 2012R2.

Then I recovered the HP Elitepad 900 which was already used for some testing, back to factory settings and started the whole operation.

For the following weeks, I will try to keep track of the most important things I encounter and share my experiences with you all.

The first thing I had to do is create a driver folder structure in MDT which makes sense (at least for me it does).

figure 1.1: Deployment Share Driver folder structure


As you can see I created several additional driver folders parenting in the WinPE folder, this is all for driver manageability.

HP offers perfect support when it comes to driver packs for the various WinPE environments, so I have downloaded all available packs and imported them into MDT.

The drivers of the HP ElitePad 900 came from the following sources:

HP Website

Microsoft Windows Update Catalog

Extraction of the following HP executable, which can be downloaded from the HP website listed above: “.\sp64292\x86_Win8.1\Driver – Firmware and Chipset\HP\sp63851

Keep in mind you need to extract the SP64292 file AND the SP63851, when all drivers are extracted, together with all other HP ElitePad 900 drivers, target the “Import Drivers” step to the parenting folder which possesses all drivers.

When all drivers are imported, it should look something like this

figure 1.2: HP ElitePad 900 drivers

ElitePad Drivers List

Because the HP ElitePad 900 also has touchpad (which actually works in WinPE IF you embed this into the boot image) drivers and other specific drivers, I targeted these drivers specifically in a separate folder.

With these folders, I have created selection profiles. These selection profiles target individual (driver) folders and present only the content that is residing in that folder during a certain step in the task sequence. This way I have managed to create a WinPE x64 and x86 folder, and I can target these folders individually when generating the boot images for x64 and x86 deployments.

Figure 1.3: Selection Profile Properties


Makes sense right? Each selection profile targets a different WinPE platform folder

figure 1.4: Overview of Selection Profiles


How this looks on the deployment share properties?

figure 1.5: WinPE x64 Properties


figure 1.6: WinPE x86 Properties


Next we can have a look at targeting the drivers for the HP ElitePad 900 in a decent manner. (Johan Arwidmark has described a new driver management approach for MDT 2013 Lite Touch, read it here).

First I have executed the following ‘query’, on the HP ElitePad 900 in a command prompt:

wmic computersystem get model“, which showed the following result

figure 1.7: Result of query

wmic HP Elitepad 900

Since we have imported the drivers of the HP ElitePad 900 in a earlier stage, the remainder of what we need to do is modify the “Inject Drivers” step in the task sequence to target only the drivers for the HP ElitePad 900. So open up the deployment task sequence, and advance to the step “Preinstall\Inject Drivers”, and select the driver Profile matching the HP ElitePad 900

figure 1.8: Inject Drivers based on Selection Profile


Now to make sure that these drivers are only applied if the model equals the HP ElitePad 900 our little query comes in handy

figure 1.9: WMI Condition on Inject Drivers step


The exact WMI query used is: ” Select * FROM Win32_ComputerSystem WHERE Model like “%HP Elitepad 900%” ” (without the two “” at both ends, that’s just me explaining the query 😉 )

The next thing we need to configure is disk partitioning of the HP ElitePad 900, since it’s a UEFI based machine, it uses GPT, so advance to the step: “Preinstall\New Computer Only\Format and Partition Disk” and change the disk type from: Standard (MBR) to GPT

figure 1.10: Format and Partition Disk GPT


Click Apply and OK.

Basically we are ready to perform a deployment test, and that’s what I have done during the writing of this blog, to see the following results:

Figure 1.11: Device Manager OK! (no unknown devices left) and Deployment Finished successfully!

HP Elitepad 900 Device Manager

Also what we can see is that by selecting the GPT Disk type, during deployment the GPT partitions have been created automatically.

figure 1.12: Disk Management GPT Scheme


This concludes my little tutorial of how to deploy Windows 8.1 to the HP ElitePad 900.

In the upcoming period I’m going to:

  • Configure the Default User Profile
  • Configure the start screen with the Start-Layout PowerShell command
  • Configure Bitlocker
  • Configure Direct Access
  • Configure and tweak Windows 8.1 wherever it is needed
  • Configure the LTI deployment furthermore so that it becomes fully automated just like ZTI 🙂
  • Configure RES Automation Manager and RES Workspace Manager for automation and user workspace management

And of course the test environment will be mitigated to a Windows Server 2012R2 with WDS and PXE Boot enabled to deploy these tablets via PXE, and we will see how that goes!

I’ll leave you all with a little package that might become handy when you are going to approach the same challenge. In the attached zip file you will find:

  • BDD.log_properties which are quite useful to determine al kinds of conditions, queries and variables
  • A Driver list which is an export of my HP ElitePad 900 driver folder, so you can verify if all drivers are present
  • All screenshots used in this tutorial


Keep on automating my young padawans 😀

! Any general reconsideration’s to keep in mind are:

  • Format the bootable USB drive with FAT32, NTFS is not read by the HP ElitePad 900
  • When staging a HP ElitePad 900, make sure a USB keyboard is attached if you are performing an LTI deployment, yes touch works, but that doens’t mean you can type in WinPE!!!