MSI To C2R O365 In One Easy Step!!

TLDR: Here is the link to the github repo that has a short readme.

https://github.com/CodyMathis123/CM-Ramblings/tree/master/Office365 


Recently my organization has had some motivators to move to Office 365. That seems to be a trend, yeah? We all know how much IT loves trends. This one does seem to be sticking around. With that, my job is to ensure we can GET to Office 365 efficiently, and effectively. It is good to keep in mind that a move to Office 365 does have other implications such as reinstalling Visio, and Project under some conditions. From what I am told, some people do indeed use this software at my organization.

Now with this nugget of office suite eradication in mind we need to find a good way to not get fired. Specifically, we need to ensure that if a user has Microsoft Visio/Project Pro/Standard before the Office 365 deployment, they should have an appropriate equivalent after the Office 365 deployment as well. First… let’s chat about how NOT to do this migration.

It worked but it didn’t

I will try to keep this bit short and sweet. For a first attempt at this migration I hoped to take advantage of our existing deployments of these various products. Currently many of our licensed applications are deployed to  collections as required. For a quick solution to our problem these existing applications need a bit of jazzing up. Nothing too crazy though, just a deployment type for MSI, and one for C2R.

The above theme continued for Project Professional, Visio Standard, and Visio Professional. Four applications, two deployment types each. The deployment types had a simple requirement set to determine if Office 365 was installed. In the case of Office 365 being installed, the C2R deployment type is used, otherwise the MSI version is used.

Awesome!

  1. Deploy Office 365
  2. Visio/Project removed (and Office of course)
  3. Office 365 Installed
  4. Wait a while for the required deployments of Visio/Project to evaluate
  5. ???
  6. Finally, they reinstalled based on old deployments and collections

That user experience is not great. Some light at the end of the tunnel was found though. Previously I posted about some fun scheduled task stuff, specifically Post OSD Scheduled Task. This turned out to be very handy for the above Office 365 deployment scenario. By creating a scheduled task to kick off some machine policy, and application evaluations quickly after the Office 365 install the user experience got a little better.

  1. Deploy Office 365
  2. Visio/Project removed (and Office of course)
  3. Office 365 Installed
  4. Scheduled task for policy refresh created and set to run in 1 minute
  5. F5 F5 F5 F5 F5 F5 F5
  6. Visio/Project reinstalled almost immediately after Office 365 based on old deployments and collections

The above method was tested a fair bit with VMs, and some kind testers in the organization. It went well enough for us to roll it out to approximately 400 machines in a pilot wave. We had some oddities happen of course. Office 365 doesn’t seem to like running 2-3 C2R setups back to back on occasion. It was common enough for the Project or Visio installs to hang with no solution or consistency that I had to go back to the drawing board… or Twitter.

Hey, that looks cool!

Mr. @RowdyChildren made a tweet that showed a very crafty way of achieving my goal of not getting fired.

In the thread I mention my current approach that, in the end, didn’t pan out. But that picture got me thinking a bit. The idea seemed simple enough, set requirements per deployment type so we can dynamically select an appropriate XML.

Simple concept, tedious to execute. What if we can just magically generate an application with a deployment type per office suite combination, and assign requirements scriptomatically!

Scriptomatically

I believe the old adage of ‘a picture is worth a thousand words’ is relevant here.

But… some words should still be said. I was able to take the example @RowdyChildren gave, and provide a simple, repeatable method of generating the application.

The main contributor to all of this ‘working’ is a set of global conditions. These global conditions detect if Visio/Project Pro/Standard are installed. They are added as requirements to the various deployment types to guide your ConfigMgr client on it’s spiritual journey to Office 365.

A splash of regex, some querying of the registry, and bam! Global conditions.

Also, towards the end of the below snippet I am using some newer ConfigMgr cmdlets which I did not know existed and had created my own function. But, they are some awesome new cmdlets that make this whole thing possible, and easy to do.

With our rules created, we will also need to add them to the deployment types as needed. There is a second snippet of code below in this section that handles this. We have an array of Product IDs from the XML files (we can talk XML later). That array of IDs is passed into a switch statement for each deployment type, and some regex does the rest. Each match that occurs will add the appropriate requirement.

Use the XML Luke

Even with requirements made, we do still need to make the application, and more importantly the deployment types. Previously we had our trusty setup.exe /admin option for MSI based office customization. Now we are fortunate to have some incredibly useful XML configuration files. These are incredibly useful because we can edit them on the fly very easily.

This script will take some input parameters such as your company name, the channel of office you intend to deploy, the bitness of the installer, license type for Visio and Project, and optionally the software version. With this info we manipulate the XML files to ensure a consistent build.

Outside of editing the XML, you’ll notice I’m sorting my $DeploymentTypes object. This is an important step to guarantee proper deployment type selection based on requirements. If a base install of Office 365 with no requirements were priority 1, or any priority but the lowest for that matter, then this wouldn’t work as intended. A base install has no requirements, so any computer will see this and use that deployment type if it gets that far down the chain. Instead, we sort by $AppName.Length, then $AppName. Really you could sort by the count of ProductIDs in the XML, but name length makes the end result look pretty, and function the same.

License Variations

There are a couple of licensing options available when it comes to Microsoft Visio, and Project. Specifically, volume license, and online licensing. The script has four parameters to let you select which license type you have in your organization. It is possible to specify ‘volume’ or ‘online’ for Visio, and Project Pro and Standard. Below is a set of snapshots for 4 of the application combination possibilities.