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:
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.
<Add OfficeClientEdition="64" Channel="Monthly" SourcePath="C:\Temp" AllowCdnFallback="TRUE" ForceUpgrade="TRUE" MigrateArch="TRUE">
<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"/>
<Display Level="None" AcceptEULA="TRUE"/>
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.
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
Get the latest MSP tips, tricks, and ideas sent to your inbox each week.