Office 365 – Automatic deployment of Office 365 with MDT

Published / by Rens Hollanders / 77 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

o365plans

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

O365setup

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

o365cmd

  • 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++

o365np++

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

o365mdt_app

First an application, which calls the install.cmd

figure 1.6: MDT Task Sequence

o365mdt_ts

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.

Concluding:

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

zip
O365_BlogContent.zip

Thanks for reading 🙂

 

Windows Intune – Automatic client installation on Windows 8 / 8.1

Published / by Rens Hollanders / 1 Comment on Windows Intune – Automatic client installation on Windows 8 / 8.1

When writing this blog, the initial purpose was to gather information and proof that the current Microsof Windows Intune client installation does not work on Windows 8.1. However before I went home today, I’ve deployed another Windows 8.1 machine with the Intune client with the intention to gather information, screenshots and logfiles to endorse this blog. However, 3 hours later, the results where entirely different.

This week I was busy with creating and testing a new deployment solution, which I’m building for one of our customers.

Since Microsoft Windows Intune was in play, and Intune provides Software Assurance, and this means we can use the latest available software. I created a Windows 8.1 and Office 2013 deployment task sequence, with the automatic installation of the Windows Intune Client (x64)

First of all the people new to Intune, need to know, that when you are going to deploy Windows Intune, firstly the client (which holds the Intune Agent) is being deployed, and when all goes well, the other Intune components are retrieved by the agent and automatically installed. Not only will this take some time, but this is also an indication, that Windows Intune will not appear directly on your new enrolled client in the start menu and or taskbar.

Based on Microsoft’s documentation about deploying Windows Intune on clients automatically, this can be done in 3 ways:

  1. Windows Intune Administrator Deployment
  2. User-initiated Enrollment for Computers in Windows Intune
  3. Installing the Windows Intune Client Software as Part of an Image

I chose another option, namely to deploy the client in my deployment task sequence. Separately from my image, so I’ve created the following step:

figure 1.1: task sequence properties

task_sequence_1

Which executes the installation of the application with the following command line: “msiexec.exe /qn REBOOT=ReallySuppress /i Windows_Intune_x64.msi

figure 1.2: Microsoft Windows Intune application properties

applications_1

After the deployment was finished, I saw the client reported itself in the Intune management console, but I also saw that some errors where reported stating that the installation of the “Intune Client (x64)” could not be completed.

figure 1.3: Intune portal error

intune_console1

figure 1.4: Intune portal, detailed error pt. 1

intune_console2

figure 1.5: Intune portal, detailed error pt. 2

intune_console5

After checking my bdd.log (since I use MDT for deployment) and the MSI log’s that can be found in the %Windir%\%temp% directory, I saw all kinds of strange errors in the MSI logs which I could not interpret (The BDD.log was clean).

figure 1.6: bdd.log nothing to see here

intune_bdd.log

figure 1.7: MSI{random_number}.log

trace_error

After this I started to do some debugging, and try to take different approaches on installing the Intune client. First of all, I’ve started reading the “Troubleshooting Windows Intune Client Software Deployment and Enrollment” and “Validating Windows Intune Client Software Deployment

Next I performed a local copy action (from within the task sequence) of the client to the machine, and performed a local installation, instead of a network installation directly from the deployment share. I tried another installation switch. I extracted the .exe file and used the .msi instead. All did not lead to a solution. However I was able to install the client manually, without any problem. Which is very strange to my opinion since nothing has changed, the privileges used for installation where the same (administrator) and the only difference I could detect was using a task sequence versus manually installation.

Finally I tried a Windows 7 x64 deployment, with the Microsoft Windows Intune client incorporated in the deployment task sequence, which lead to the following result:

figure 1.8: Intune on Windows 7, everything green (except missing some updates)

intune_console3

So deploying Microsoft Windows Intune on a Windows 7 machine, works right away without any noticeable delays. Although Microsoft itself states that delays up to 30 minutes are ‘normal’:

After the Windows Intune client software is installed on client computers, the Windows Intune agents communicate with the Windows Intune service to provide the service with data about the clients. The frequencies with which the different agents communicate with the Windows Intune service depend on the workspace (for example, for the Updates workspace, the agent communicates with the Windows Intune service once a day; for the Software workspace, the agent communicates with the service once a week). In a few minutes to 30 minutes after the client software is installed, the names of the client computers appear in the Windows Intune administrator console. To locate the computers, in the Windows Intune administrator console, in the workspace shortcuts pane, click Devices, and then click All Devices. For more information, see Validating Windows Intune Client Software Deployment.”

source: http://technet.microsoft.com/en-us/library/jj676583.aspx

So it is very strange to see, that after 3 hours the Intune client finally did come through on the Windows 8.1 machine. There where no interruptions, no reboots and no loss of internet connectivity. Just by looking at the timestamp of the logs, it just showed that for the past 2 hours and 35 minutes, nothing had happened, untill I checked back on the machine again:

figure 1.9: timestamp of logfiles

timestamp

Very strange right? And I have performed over 5 deployments with no effect, the Windows Intune Client remained in a state. So when I noticed this, I decided to do a new deployment again, and leave the machine unattended for longer then a day. When I checked it the next day, again the Intune client was installed correctly, however, again by looking at the timestamp of the logs. It again took longer then the projected 30 minutes. This time it took over an hour for the client to be succesfully installed.

figure 2.0: Intune on Windows 8.1

intune_windows81

Conclusion

My conclusion thus far is that the Intune client is not entirely self-reliant at this moment to be automatically deployed on Windows 8.1. Yes it will install eventually, but it takes more time then I’m used to. Certainly, when we see that on Windows 7, the installation goes without a problem. So if time is not of the essence, you can go ahead and automatically enroll your Intune client, but if time is against you, you may want to enroll the Intune client manually at this moment, which goes without any errors, and it starts syncing the other components right away.

Just by looking at the log files, and the error’s that can be found in the log’s surely indicate that automatic deployment of the Intune client on Windows 8 /8.1 struggles to get installed correctly. However I can’t see anything specific in the log’s since the error’s don’t make sense to me (see figure 1.7).

Another thing that still needs to be resolved is the ‘remote desktop’ or ‘remote assistance’ functionality which appears to be disabled for Windows 8 / 8.1 machines on the Intune management console due to unsatisfying performance.

Hope this blog may be of some assistance for people that are trying to achieve the same, and -or perhaps you have managed to pull this one off without any problems. If so, feel free to contribute in the comments or to send me a message directly or via twitter

ps. forgive me for the Dutch screenshots, the Intune Portal belongs to a Dutch customer, and I have not find a way to set the interface to English.

Find attached the screenshots used in this blog, and the logfiles:
zip
Intune_BlogContent.zip