One of the most common requests that we’ve received over the years is for instruction on how to properly deploy Office 365. Some time ago, High Overlord Brigg was kind enough to compile an article that many of you have used to build your own Deploy package for this task. Unfortunately, as his power has waned and Office 365 has been updated, that article is now out of date.
Here’s a high-level overview of the steps we need to complete:
Generate a configuration file using the Office Customization Tool.
Use that configuration file to download the install files for Office 365.
Build a package in PDQ Deploy.
Deploy and test your newly-built package!
Let’s get started, shall we?
Generating the O365 Config File
The Office Customization Tool (we’ll refer to it as OCT for short) is a website that can be used to generate configuration XML files for the Office 365 suite of products. It’s an extremely flexible, well-designed tool, but there are options that are easy to miss. Some of these options are necessary for a successful silent installation, and not all of the settings you can edit are well-documented. This process used to be additionally complicated by having to create separate XML files for the download portion and the installation itself, but has now been simplified to use only one!
Fortunately, we’ve tested plenty and have quick lists of both required and recommended settings, along with explanations for each.
The list of required settings is fairly short:
1) Products and releases > Products: You must select a product/application you want to Deploy. Duh. In this example, we’re going to select Office 365 ProPlus, but pick the application you actually intend to install.
2) Language > Languages: You must select a language for the installation. You can either specify one or more fixed languages, or you can select “Match Operating System”, which will default to the locale on the target machine.
If you run the download on a machine with a different locale than the target machine, the installer will fall back to the Office CDN for the missing language files.
3) Installation > Installation Options > Show installation to user: You’re never gonna guess what this does. Change it to “Off”. People miss this. Like, a lot.
4) Licensing and activation > Automatically accept the EULA: This is the other setting that is required specifically for a silent install. We don’t want to have to click through a prompt to accept a EULA. Simply change this to “On”.
While these are the only settings that are 100% required for a silent installation, I implore you read on to our recommended settings, or you’re likely in for a world of hurt.
Our recommendations are as follows:
1) Installation > Installation Options > Source: By default, the configuration file generated by OCT will tell the installer to pull down a copy of the Office installation files from the Office CDN. This is a waste of bandwidth and will murder your office’s internet connection should you push it to any sizeable number of computers. Select “Local Source” and enter a fixed UNC path.
In our particular example, we’re actually going to set it to a folder in our Deploy repository. This provides a consistent, reliable location from which the installer can pull the source files, as both the download and installation processes use the same path setting.
This needs be an absolute path. Relative paths and environment variables will not work and your deployment will fail if you try to use them. I highly recommend using the UNC path to your Deploy repository. You will need to ensure your Deploy User can access this location, as the installer runs in the context of that account.
2) Installation > Installation Options > Logs: Logging is good! Logging gives us visibility into processes, successes, and (most importantly) failures! And ooh boy, Office 365 loves to write exceptionally verbose logs. Set “Save log file to” to somewhere convenient.
In this example, we’ll set it to a folder called “Logs” in the source folder in our Deploy repository. You don’t actually need to create this folder yourself, as the installer will automagically create it if it does not exist.
3) Products and releases > Architecture: For some reason, this is set to 64-bit by default. If you’ve dealt with Office at all in the past, you’ll know this is a poor choice for the vast majority of use cases, and you’ll want to do some research to determine what is needed for your environment. In most cases, however, you’ll want to switch it to 32-bit.
4) Products and releases > Update channel: This determines how frequently Office is updated. This has different default settings based on the version of Office 365 you’re deploying; for ProPlus, it’s the Semi-Annual Channel. For Business, it’s the Monthly Channel. Monthly updates will keep Office closer to the bleeding edge, but if you strive for stability and well-tested software, the semi-annual option may be better for you. Pick an update channel that fits the needs of your business.
Once you’ve set all the settings you want to set, hit the Export button in the top-right corner and save the resulting XML file somewhere safe. For the purposes of this demonstration, we’ll just call it “configuration.xml”.
Before we move onto the next step, let’s set up a few folders in your repository for organizational purposes: a folder called Microsoft, and a subfolder called Office 365. Next, you’ll want to move the setup.exe and configuration.xml files into that folder.
Obtaining Office 365 Source Files
With recent releases of Office 365, the process of downloading source files has been simplified. Open an elevated PowerShell window and navigate to the UNC path where you placed the installer and XML file earlier. Run the following command:
And wait. This will initiate a download of the source files to the SourcePath specified in the XML file. If you’ve done this correctly, you should magically see a subfolder called “Office” created in the aforementioned Office 365 folder! This contains all the source files needed for your installation. Easy peasy.
Building the Deploy Package
Due to the results of extensive deployment testing and some inconsistent behavior from the installer, the prior incarnation of this article used a Command Step to initiate the installation of Office 365. Based on my research, however, those issues appear to have been resolved, so we’ll use an Install Step instead.
This is also nice and straightforward:
Set the install file to setup.exe.
Add the parameter “/configure configuration.xml”.
Add the configuration.xml file as an Additional File.
Under the step’s Options tab, change the Run As setting to “Deploy User (Interactive).”
(Your package should look something like this when you’re done!)
You can now test this deployment against your machines. Some things to note before doing so:
Regardless of the pull/push setting you have configured, this will effectively function as a pull deployment. The Deploy runner service will only push/pull the setup.exe and configuration.xml files on its own. Once the installer is started, it uses the SourcePath in the XML file to pull the files from your repository. As such, it will not respect any Deploy bandwidth-related settings, so be cognizant of how many machines you’re deploying to simultaneously!
This behavior can be changed by making some changes to the process:
Change the SourcePath to a fixed local path (e.g., C:\foo\bar)
Create a File Copy Step to copy the source files to a fixed path on the target machine before the installation
Create a PowerShell/Command Step to perform cleanup of those files after installation
On principle, I generally prefer to let the installer manage obtaining its own files. I understand that this may not work for everyone’s individual use cases, but it’s simple, clean, and very, very fast. For reference, using the test machines on our internal network, I successfully deployed Office 365 in under 5 minutes.
Allison was an employee at PDQ.