With the continual evolution of the Office 365 offerings from Microsoft, there have been vast improvements both on the “server side” and the “client side”. Monthly, there are changes that are making it easier to deploy and more compelling to use these cloud hosted services from Microsoft. Anyone that chooses to leverage the E3 or higher license model (or the Office 365 ProPlus a la carte menu item) will need to determine how to begin using the new “Click to Run” components.
This post is my attempt to document and share my experiences planning a migration from existing “traditional MSI installed clients” to this new technology, and it involves my favorite tool: PowerShell!
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.bat file call the o365.ps1 file and set it to call the configuration32OfficeAll.xml file (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…
https://github.com/gregbesso/Office-365-ProPlus-Deployment
Useful Reference Links…
Office 2016 Deployment Tool (to download and setup the actual software installation media):
https://www.microsoft.com/en-us/download/details.aspx?id=49117
Office Deployment Tool Reference:
https://technet.microsoft.com/en-us/library/jj219426.aspx
GitHub: Office IT Pro Deployment Scripts:
https://github.com/OfficeDev/Office-IT-Pro-Deployment-Scripts
Office Click-To-Run Configuration XML Editor (to avoid using Notepad for everything):
https://officedev.github.io/Office-IT-Pro-Deployment-Scripts/XmlEditor.html
greg's wordpress... 