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:

O365update

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

mdt2013u1

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

This blog isn’t dead, just looking for new content…

 

Returning visitors may think: “Where’s the new stuff dude!?!” -Well.. last couple of months have been very quiet on this website, I agree! This is mostly due to two things:

  1. We moved into our new house, which needed decorating and numerous DIY chores
  2. I’m currently not involved in any automation project…

For some time now I’m employed at a customer as a packaging engineer at a local hospital, where my job activities currently do not involve automation in relation to Microsoft Deployment Toolkit, System Center Configuration Manager and / or RES Automation Manager. I actually work more with RES Workspace Manager and VMware ThinApp at the moment.

As a result this causes lack of input for my blog to generate content. I don’t want to use this as an excuse, since content can be generated in many ways. But on the topic of MDT in particular a lot has been written by fellow colleagues and myself and I currently do not experience any incentives that trigger me into writing new stuff in relation to MDT.

Nevertheless I remain active on Microsoft’s social.technet forum in the MDT, SCCM, Windows 7 and Windows 8.1 section to assist users with topic related problems and questions. And besides this I answer questions which I receive frequently on my own website, something I greatly appreciate!

If you have any news to share, want me to explain anything related to mentioned topics above or simply have a question!? Please don’t hold back and let me know through my twitter handle @renshollanders, a reaction on my website, or if you dig some further you will find my e-mail address too!

I just felt the need to explain, so you all understand this is just a phase and not a definitive state! :)

Cheers! Rens

 

MDT – Monitoring creates event viewer entries

 

This quick post is about admitting that sometimes even I learn new stuff about MDT.

Since I usually do not setup MDT monitoring (I use dynamic logging most of the time), at a particular customer I did, since they wanted to track progress of their deployments.

Setting up monitoring is quite easy, enable the checkbox on your deployment share properties and add an additional property into your customsettings.ini:

figure 1.1: Enabling MDT Monitoring

mdtmonitor001

figure 1.2: Monitoring property customsettings.inimdtmonitor002

EventService=http://WIN81-LAPTOP:9800

When this is done, for each machine that will be deployed through MDT, the MDT Monitoring service will create an event in your Application log, with information regarding when the deployment was started for a particular machine, when it has ended and if any error’s did occur.

figure 1.3: Eventviewer Application Log MDT entriesmdtmonitor003

Cheers! Rens

MDT – Put the domain join where it belongs..

 

Hi Guys and Gals,

Long time no see. Took me some time to move into our new house which had to be decorated with wallpaper, flooring, additional electric and internet wiring etc. So March 2015 will leave a gap in my blog archive, but I’m hoping to compensate this with writing some new articles.

One of them is this one: Put the domain join where it belongs. If you are like me, I like to work with one MDT deploymentshare to rule them all. When looking on social.technet in the MDT forum’s I see many people struggling to combine build and deployment shares together, or shares that have separate settings regarding computer deployment or domain membership.

Now MDT offers four options to create a deploymentshare so flexible you’ll only need one share to truly rule them all:

  1. The customsettings.ini
  2. Multiple customsettings.ini
  3. The MDT Database
  4. Task Sequence Variables

Allow me to explain each option and the pro’s and con’s:

Customsettings.ini: hey If you can manage it per model, macaddress, tasksequenceid etc. thats fine! But usually you are going to end up with a conflict that either strikes your build deployment or your deploy deployment. Most issues I see here are domainjoin and capture related.

figure 1.1: CustomSettings.ini

customset000

Multiple customsettings.ini, you can specify which ini file to process right into your task sequence “gather” step; this makes your deploymentshare more flexible and forces a specific task sequence to use a different ini file for processing then let’s say the default task sequence. Editing the Gather step is an option, but since you’ll have to edit it multiple times in one task sequence, it’s easy overlooked and prone to error when making typo’s

figure 1.2: Multiple customsetttings.ini

customset002

If you are planning on changing the gather step’s, then please take into consideration there are four of them in every deployment task sequence:

The first is during Initialization, the second during Preïnstall the third during State Restore and the last one can be found during Imaging

figure 1.3: Configuring different CustomSetting.ini

customset001

Then there is the MDT Database, store settings that would otherwise end-up in your customsettings.ini individually based per machine, make and/or model, roles or location, a very good alternative to use but a little bit overpowered when just wanting to make the difference between machines joining a domain or getting captured.

figure 1.4: Using the MDT database integration

mdtdb001

figure 1.5: Properties of a MDT database object (A customsetting.ini of your own)mdtdb002

Task Sequence variables, this to me is the most powerful option of all. Let’s say I want to specify a property which may not occur anywhere else, simply put a task sequence variable at the front of your task sequence.

figure 1.6: Using task sequence variables in your task sequence

tsvars001

Just as you would post information about capturing your reference build in the build task sequence, you could do exactly the same for the following values regarding domain joins:

  • JoinDomain=contoso
  • DomainAdmin=mdt-domainjoin
  • DomainAdminDomain=contoso
  • DomainAdminPassword=P@$$w0rd
  • MachineObjectOU=OU=Computers,OU=Laptops,DC=contoso,DC=local

This prevents machines that are intended to be captured, end up domain joined and machines that are deployed and are domain joined to be captured (which will result in error, since sysprep will not allow a domain joined machine to be generalized for capture).

Hope this helps in gaining insight in how to achieve a more flexible MDT deployment.

Cheers! Rens