Home » Clients » Office 365 ProPlus » Setting Up a Simple Office 365 Deployment From a Network Share

Setting Up a Simple Office 365 Deployment From a Network Share

When a customer on-boards to Office 365 they usually already have local installations of Office, either volume licensed or perhaps even OEM licenses that came with their computers. Sometimes there’s an immediate need to install new Office client applications due to compatibility issues with the older versions already running on the PCs, and other times the business is willing to take a slower approach, either performing the deployment in smaller groups, or by installing it as new PCs are purchased to replace older hardware.

In mid-size organizations the deployment of Office 365 clients to computers is a larger task than can be reasonably performed with manual installs. And manual installation is also tedious and repetitive. But often the same organizations don’t have a software deployment platform such as Config Manager available to use.

For simple deployment scenarios it’s fairly easy to just set up a file share on the network and automate the deployment from there using a script. In this article I’ll break down the process and show you how it’s done.

For more complex scenarios, you might be interested in the Office Deployment Scripts for IT Pros. In fact, you might even be wondering why I’m about to show you a different method, instead of just making use of those deployment scripts. The reason is that the Office deployment scripts, while certainly very powerful and flexible, can take you quite a bit of time just to learn how to use them. Using those scripts will be the subject of a future blog post here. In the mean time, if you’re just looking for a quick path to victory, read on below.

This tutorial assumes that you’ll be deploying an Office 2016 build of Office 365 (either ProPlus or Business).

Preparing a Network Share

To begin with, create a shared folder on your network that will be used to distribute the Office 365 client software. For this example the server MGMT is hosting a share named “Installs”. Within the shared folder a sub-folder of OfficeCTR has been created, and then sub-folders for each update channel. If you only plan to use one specific channel, such as Deferred, then you don’t need to create the others. Users or computers will need read access to the share and the folders within. The Authenticated Users group is usually sufficient, or you can setup a specific group if you prefer.

network-share-01

Creating a Configuration XML File

Download the Office Deployment Tool (ODT) for Office 2016. When it has downloaded, launch the file and extract the ODT to a folder on a computer that you will use to download the Office 365 client setup files from Microsoft’s content delivery network (CDN). I usually just place it in the folder where the Office applications will be deployed from.

office-deployment-tool-2016-01

Next, use the Office configuration XML editor to create an XML file that contains the configuration you want to deploy. Build the XML file by starting with the version of Office you’ll be deploying (in this tutorial it is 2016), selecting ProPlus or Business, the “bitness” (32 or 64), channel, and language. Click Add Product to add your selection to the XML file.

office-deployment-tool-2016-02

Continue on to the Updates section, and configure how you would like your Office 365 clients to update. You can simply enable updates and choose the channel, and leave the other fields blank if you want your clients to download updates from Microsoft’s CDN. If you’d prefer to set up a local network share for hosting update files, you can configure those options now, or you can set or modify the update settings later using Group Policy if you change your mind. Keep in mind that if you choose to self-manage the update files on your network, that’s going to create additional work for you in the long term, and you do need to keep your clients updated because Microsoft doesn’t provide security updates or support for builds that are too far out of date. The Deferred channel with automatic updates is a good choice if you want to reduce your workload but also keep your users away from the very latest builds.

office-deployment-tool-2016-03

One option I do recommend you look at is excluding Groove (the legacy OneDrive for Business sync client, also known as groove.exe) from your deployment. The new OneDrive client has replaced it and is far more reliable.

For the rest of the sections in the XML editor there’s nothing required, but you might like to explore the logging options or compare your XML file to the templates that Microsoft provides. You may notice the Display options such as Accept EULA. For a GPO-drive deployment using a startup script, which is what I’ll be demonstrating here, that option has no effect. If you plan to run the install using the credentials of a logged on user, you could look at enabling that option so they don’t need to accept the EULA.

When you’re ready, copy the XML code and save it as Configuration.xml along with the ODT setup file on your deployment share.

office-deployment-tool-2016-04

Download the Office 365 Client Setup Files

Now it’s time to download the Office setup files. Open a command prompt and navigate to the folder containing the setup and configuration files. Run the following command to begin the download. Because no source path was configured in the XML file, the Office files will be downloaded to the same folder where setup.exe is being run.

ODT will begin download the Office setup files, which add up to about 1.3GB for this demonstration.

office-deployment-tool-2016-05

Configure the Deployment Script

For this demonstration I’m using a computer startup script in a Group Policy to install the Office 365 client applications. But before I get into that, here’s what the installation command line looks like if you just wanted to write a quick batch file.

That will basically do the job, but if you were to assign that as a startup script it would run at every startup and try to reinstall Office each time. Checking for existing Office installs first would be ideal. Microsoft’s Office deployment scripts have a solution for that, as well as for removal of existing Office versions if they’re detected. But for this simple scenario, some script logic to install Office to a new computer at startup, and then not try to install again after that, should be enough.

So for this demonstration I’ll use Install-OfficeCTR.ps1, a PowerShell script that I’ve used for small to mid-size customer projects in the past.

Install-OfficeCTR.ps1 uses the following parameters:

  • InstallRoot – Specify the UNC path to the network share that hosts the Office 365 setup and configuration files.
  • SKU – Specify the the Office CTR SKU to deploy (e.g. ProPlus, Business)
  • Channel – Specify the build channel to deploy (e.g. Current, Deferred)

The three parameters are used by the install script to locate the appropriate setup and configuration files in your install share on the network. For example:

The example above will look for setup and configuration files in \\mgmt\Installs\OfficeCTR\ProPlus\Deferred.

The script and parameters can be configured in a Group Policy as a startup script.

office-deployment-script-gpo

You can control which computers run the startup script by using the security filtering options for the GPO.

office-deployment-script-gpo-02

After assigning the GPO the computers should install Office 365 on their next restart, which (depending on how you do the security filtering) makes it easy to get it installed after a standard automated build process has joined the computer to the domain.

Summary

Automating Office 365 client application installs saves a lot of time when on-boarding a customer to Office 365. Although the Office deployment scripts from Microsoft provide a lot of flexibility for this task, there’s also a learning curve required to start using them effectively. For simple scenarios, creating your own configuration XML file and using the Office Deployment Tool to deploy from a network share via a basic scripted installation is often more efficient.

Paul is a Microsoft MVP for Office Servers and Services. He works as a consultant, writer, and trainer specializing in Office 365 and Exchange Server. Paul is a co-author of Office 365 for IT Pros and several other books, and is also a Pluralsight author.
Category: Office 365 ProPlus

7 comments

  1. Joshua Bines says:

    Adding  to the xml also seems worthwhile as well to make it completely seamless not sure if anyone has had any success with that value? I was wondering if ADFS was a requirement for this to work?

  2. Mikael says:

    I´m trying to add this script to a GPO startup script but it wont run. I´m pointing to a network share where the script is. I´ve tried to set up the GPO with a dummy powershell script that creates a file in that network share and that works fine. Is there any permissions on the network share that your scripts need? Or what am I doing wrong? I´ve set the execution policy to allow all in that GPO.

    Thanks,

    Mikael

    • Mikael says:

      EDIT: I had forgot to give ‘domain computers’ permission on the folder where the xml was. I had only given that to the folder where the scripts was. It looks to be working now.

Leave a Reply

Your email address will not be published. Required fields are marked *