Demistifying Office 365 ProPlus Deployments with PowerShell

Greg BessoLead Systems Engineer
CERTIFIED EXPERT
Continually learning and practicing with Microsoft technology solutions to make positive impacts in user productivity.
Published:
My attempt to use PowerShell and other great resources found online to simplify the deployment of Office 365 ProPlus client components to any workstation that needs it, regardless of existing Office components that may be needing attention.

I've been spending quite a bit of time working with Microsoft's Office 365 offerings, this month going from solely using the cloud hosted server components to adding the ProPlus client components. A major task in this type of implementation is planning how best to migrate all of your existing users of Office software to using the new "Click to Run" build of Office 2016.


Over the past few weeks I've been compiling as many of the best practices and scripts to help simplify this task, and also to help automate as much of it as possible, and wanted to share my notes with anyone that may find them useful. If you're also considering an implementation of Office 365 ProPlus components, continue reading...



First, the short version, aka TL;DR;...

  • I've attempted to make a very painless, time-saving, and scenario-encompassing set of scripts that will let you migrate all your existing users from "traditional MSI" installs of Office / Project / Visio to the new "Click to Run" 2016 versions of those same software components, regardless of the architecture or version being used currently.
  • I'm accomplishing this in the simplest scenario using only three text files and nothing else (aside from the network share to store them on). One is a batch file, another is a PowerShell file, and the last is the Config.xml file.



Second, the long version...


This is my full drawn out post as I tend to ramble a bit and really like to try to visualize the challenges and my thought process around them...


First, let’s talk a little about the current technology landscape that an administrator is surrounded by when attempting to reign in all the available methods to install Microsoft Office software…




There’s many moving parts. One has to consider, and become expert with, the following:

  • Retail builds of Office 2003-2016 software, and their media.
  • Volume licensing of Office 2003-2016 software, and the volume license versions of the media (they are not compatible or interchangeable).
  • Installations and updates for core Office components.
  • Installations and updates for companion products such as Project, Visio, SharePoint Designer, etc.
  • Cross-version compatibility and cross-architecture compatibility concerns (32-bit versus 64-bit, and co-existence of 2007, 2010, etc where supported)
  • Knowing how to install software silently using MSIExec, Config.xml files, Office Customization Tools, etc.
  • Knowing about this new “Click to Run” installation option and the configuration and tools related to it.
  • Then trying to apply this gathered knowledge when a Citrix or Terminal Services box comes online 


Do you need a coffee break yet?


To reiterate, the “old way” of installing and managing Microsoft Office instances was quite complicated. Once you got it running the way you wanted, you still had other issues such as…

  • Managing consumed licenses when re-imaging workstations or transferring software to other users. How many times have you had to reach out to the Microsoft folks to get your license count adjusted?
  • Upgrading to new versions. Every version had a new media, new considerations, and new lack of backwards compatibility to contend with.

 

Switching gears for a moment, let’s see what this new “Click to Run” technology is all about. What does it do, and what do you need to know?

Here’s a few useful details:

  • Click to Run uses a virtual file system on the workstation, meaning you can have it co-exist with older (or newer) versions without compatibility concerns.
  • The installation media uses a much simplified configuration file strategy, where you have a single EXE file, a single XML file, and then all the rest “just happens” based on your preferences.
  • The licensing model is now “per user” instead of worrying about user CALs, device CALs, etc. Also the licensing is based on a monthly subscription, so no significant investment (or commitment) is needed upfront.
  • Updates are ongoing, opt-in/opt-out capable, and perpetually accessible. You can download them and install them even if you don’t have a license configured yet.
  • Updates are seeded / intelligent, meaning when you apply a 1.5 GB update to a workstation, only the actual files that have changed between v.current and v.new are applied. It’s very fast to apply updates.
  • The installation media for one product is also used for all other products. So, if you have some users that only use “core Office” and then some other users that also use Project and/or Visio, you can use the same installation media for all of them regardless of what they have installed.

 

When it comes time for you to go through the process of migrating the existing workstations in your environment, you can do what I am doing and put in place an “all-in-one, one-for-all” type of installation script in place.

The goals I have for this project are the following:

  • Upgrade everyone to Office 365 ProPlus, regardless of current install status…
  • Including users that don’t currently have Office.
  • Including all users of “core Office”, meaning Outlook, Word, Excel, PowerPoint.
  • Including all users of Lync 2013 and/or Skype for Business 2015/2016.
  • Including all users of Microsoft Project.
  • Including all users of Microsoft Visio.
  • Including anyone regardless of current version (2003, 2007, 2010, 2013, 2016).
  • Maintaining current chosen architecture of each person’s Office build, keeping folks that use 32-bit Office 2007 for example to use 32-bit ProPlus while enabling folks that are on 64-bit Office 2013 to be given 64-bit ProPlus, etc.

 

Here is a list of how I’m going about accomplishing my goals:

  • Setting up a DFS share that is accessible from all the workstations.
  • Downloading and installing the Office Deployment Tool files into a sub-folder in this new share.
  • Having a handful of batch files for different installation scenarios, although they are no longer needed. These files are one-liners that call PowerShell.exe with a UNC path to a PS1 file, with Execution Policy being bypassed. Examples, InstallO365All.bat, InstallProject.bat and InstallVisio.bat.
  • Having a single PowerShell PS1 file that handles requests from each of the above-mentioned batch files. This one file will do the heavy lifting, taking care of any special tasks I want to bake into my install process. Examples: gathering existing workstation versions, OS architecture and other details; uninstalling existing builds of Office 2003-2016; installing the new C2R versions of the desired applications; logging the results in email or SharePoint. It’s a pretty useful file for sure!
  • Then the actual Config.xml files that are tweaked to meet the needs of each of my various install scenarios, one for each of the scenarios (Although, you really only need one if you don’t mind installing all the components for all computers). Examples: ConfigureOfficeOnly64.bat, ConfigureOfficeOnly32.bat, ConfigureOfficeAll64.bat, etc.

 

It sounds like a lot but in really it’s so much less than before. You can start with literally 3 text files and then copy/paste/edit them to quickly prepare for different scenarios, all the while never having to think twice about having actual “installation media” ready.


In my repository I have a lot of files to handle a variety of desired install scenarios, but the simplest one is to have the o365.batfile call the o365.ps1 file, and set that to call the configuration32OfficeAll.xmlfile (or the 64-bit one if existing 64-bit components are found). If you take the time to see what I’m doing, you’ll see I kind of over-complicated it to allow some flexibility but you can comment out most of that stuff if you don’t need it.


Check it out and let me know if you notice anything that could use some improvement…


My original post of this content, with useful reference links, is available at:

https://gregbesso.wordpress.com/office-365/deployment/


The scripts I've shared on GitHub are available at:

https://github.com/gregbesso/Office-365-ProPlus-Deployment

2
1,279 Views
Greg BessoLead Systems Engineer
CERTIFIED EXPERT
Continually learning and practicing with Microsoft technology solutions to make positive impacts in user productivity.

Comments (5)

Albert WidjajaIT Professional
CERTIFIED EXPERT

Commented:
Thanks for the sharing.
So based on your experience, can I deploy Office 365 Pro Plus with just Powershell script and Group Policy Preference with no SCCM ?
Greg BessoLead Systems Engineer
CERTIFIED EXPERT

Author

Commented:
Hi there, TOTALLY. I don't currently use SCCM. SCCM is great if you want to not have to "roll your own" tools, but mostly everything it does you can also do on your own with PowerShell (and a little elbow grease).
Albert WidjajaIT Professional
CERTIFIED EXPERT

Commented:
Great, so do you know what are the steps or link for that Greg ?
Greg BessoLead Systems Engineer
CERTIFIED EXPERT

Author

Commented:
So IMO this is a great example of a project where you can "divide and conquer". You have a few different parts...

First, you have your method of deploying Office 365 ProPlus. This article shows my method of getting that done. Just download the scripts, tweak them to meet your needs/environment, and then it's all set.

Second, you have the "how will I install this remotely on many computers" step. For me, I rolled my own SCCM type of solution which is a set of scripts that I also have up on my blog that I called "PSMANAGE" scripts. It's an evolving project of mine, but check it out if you like.

Another tool I used to push out software remotely was this PS Tools PsExec.exe. You could remotely push a command to any workstation that was online, such as telling it to run your silentInstall.bat file. Check that out also:

https://technet.microsoft.com/en-us/sysinternals/pstools.aspx
Albert WidjajaIT Professional
CERTIFIED EXPERT

Commented:
Thanks, Greg, you are amazing :-)
let us know once you've shared the new script of yours.

Have a question about something in this article? You can receive help directly from the article author. Sign up for a free trial to get started.