Doing Microsoft Office 365 migrations is becoming more and more common for MSPs. There are a few good reasons for this: Office365 is typically cheaper than purchasing individual licenses for each user every few years, it offers constant updates, cloud storage, scalability, and (mostly) low, predictable cost to the end customer.
In my last article, I talked about deploying files via cloud services, primarily AWS. But I’m hearing from more and more partners who tell me they use it to deploy Office 365 to their customers easily, reliably, and cheaply.
So, let’s start by talking about the high-level steps. Deploying Office 365 is simple, but requires you to do a few things properly. For instance, you should:
- Make sure you have a copy of the latest installer
- Generate an install configuration file for the desired customer
- Use or create an automation policy
- Test it on a small set of devices, tweak, and ensure it’s production ready
- Push the upgrade to all devices based on your schedule via your RMM platform
Now let’s dig into each step.
Step 1: Getting the installer
Getting the installer is simple. If you go to the Microsoft website, you can get a copy of the installer from the Microsoft portal (https://www.office.com/). In this case, get the offline installer. Once you get it, you can upload the 32- and 64-bit versions (if you need both) to the AWS S3 bucket and get your personal URL.
Step 2: Generating the install config file
The install config file is fairly simple and is in XML format. Below is a sample config file. I won’t go into the details of the config. It’s available online and—in most cases—the sample below will work fine. So you can copy and paste it into notepad and save it into XML format.
<Configuration> <Add OfficeClientEdition="64" Channel="Monthly" SourcePath="C:\Temp" AllowCdnFallback="TRUE" ForceUpgrade="TRUE" MigrateArch="TRUE"> <Product ID="O365BusinessRetail"> <Language ID="en-us"/> <ExcludeApp ID="Lync"/> </Product> </Add> <Property Name="SharedComputerLicensing" Value="0"/> <Property Name="PinIconsToTaskbar" Value="TRUE"/> <Property Name="SCLCacheOverride" Value="0"/> <Property Name="AUTOACTIVATE" Value="FALSE"/> <Property Name="FORCEAPPSHUTDOWN" Value="TRUE"/> <Updates Enabled="TRUE"/> <RemoveMSI All="TRUE"/> <Display Level="None" AcceptEULA="TRUE"/> <Logging Level="Off"/> </Configuration>
Step 3: Use or create a policy
The easiest thing to do for this step is use an existing policy. The link below has details to a policy built by Brett Dawson from NetEffect. This policy was submitted as part of the 2019 North American Hackathon. He was one of the winners so it’s a good example. You can download the policy at:
Step 4: Testing
This step is self-explanatory. We recommend you test it locally and/or via your RMM on a few devices first. Ensure it works as you expect and that the customer isn’t having to do steps manually, other than perhaps enter their email address and Office 365 password to log in.
You should complete testing from the automation manager designer, as well as from within your RMM.
Step 5: Deployment
In this last step, we recommend you deploy large sites on a schedule (run a certain number of upgrades per day until completed) to reduce the number of support cases during the upgrade process.
Automation of the week
Following on from above, this week’s automation is the Office 365 deployment AMP. Brett Dawson from NetEffect also created two policies to deploy Visio and Project, so all three are linked below:
If you’ve created an automation policy and would like to share it with the community, please feel free to email me at [email protected]
As always, don’t forget to go look in the Automation Cookbook at www.solarwindsmsp.com/cookbook if you’re interested in other automation policies, script checks, and custom services.
Marc-Andre Tanguay is Head Automation Nerd. You can follow him on Twitter at @automation_nerd