Managing Updates for Office 365 ProPlus

Automatic Updates streamlines the way administrators deploy updates to Office 365 ProPlus. This post is a joint effort from our global Office compatibility and deployment experts, Curtis Sawin and Martin Nothnagel.

Overview

Part 1 of this blog post discussed how automatic updates worked and addressed some common concerns that we’ve heard regarding the new update process in Office 365 ProPlus. Throughout the article, we talked about the value of having a consistent process for testing and deploying updates.

Specifically, since monthly builds can contain security updates, non-security updates, and functionality improvements, implementing a single process for testing and deploying an updated build reduces your risk as it eliminates variance and provides you better ability to automate. Further, it positions you to rapidly adopt changes like Service Pack 1 or major updates for Office 365 ProPlus, while making sure that the risk of implementing such changes are mitigated.

So what might such a process look like? What type of testing needs to be done? How can I automate this?

This article provides an example how to implement a fully automated testing and deployment process and still have full control about what happens when needed. Hopefully, this will help you determine how automatic updates might fit in your environment

Testing and Update Process Overview

Here are the high-level steps for a fully automated testing and deployment process:

Identify a “testing” group
Configure testing group to get their updates from an internal source
Configure all others to get their updates from a different internal source
Update the testing source after every Patch Tuesday
Have your testing group use Office
Update the production testing source 2-3 weeks later
Enable a back out strategy

We’ll take a look at each of these steps in more detail.

Testing and Update Process Details

Step 1: Identify a testing group

This may be the hardest part…figuring out who will be in your testing group This could be your IT staff, internal application owners, developers, a cross-section of each business function, or however you’d like to slice it. The goal is that these testers will receive updated builds in advance of everyone else, and use Office applications as they normally would during the testing period. So choose your testing group so that you are confident that after a few weeks of using an updated Office build you’re comfortable releasing this build to the rest of your organization.

Step 2: Configure the testing group to get their updates from an internal source

The only difference between the configuring of Office 365 ProPlus for the testing group and the rest of your organization is the location where they get their updates. During setup, you configure the Updates element in the configuration.xml file so that updates are enabled and the UpdatePath attribute points to an internal source. Since the update location is configured during setup, the below sample XML file – “TestingGroup.xml” – shows such a configuration:

Contents of TestingGroup.xml

</Product>

</Add>
<Updates Enabled="TRUE" UpdatePath="\\MyServer\Updates\TestingGroup" />

</Configuration>

The command line to install Office 365 ProPlus for the testing group would look like this:

Setup.exe /configure TestingGroup.xml

Where setup.exe is the Office Deployment Tool for Click-to-Run.

Step 3: Configure all others to get their updates from a different internal source

Next, we’ll need to identify a different source location that will be used for the remainder of the organization, and configure Office 365 ProPlus to look for updates in that source. The below sample XML file – “Production.xml” – demonstrates this:

Contents of Production.xml

</Product>

</Add>
<Updates Enabled="TRUE" UpdatePath="\\MyServer\Updates\Production" />

</Configuration>

The command line to install Office 365 ProPlus for the testing group would look like this:

Setup.exe /configure Production.xml

Step 4: Update the testing source every patch Tuesday

As new builds are released on the 2^nd Tuesday of every month (ie, “Patch Tuesday”), we’ll need to update our internal source after a new build is released to the Microsoft Content Delivery Network (CDN). Since the CDN is globally available, typically a build is available at all locations in the CDN within a day of Patch Tuesday. So, updating your source a day or so after Patch Tuesday will make sure that you have the latest build.

Here’s where we can automate this process to reduce your administrative effort. Using a scheduled task on a single workstation, create a recurring task that runs the Office Deployment Tool using the “/download” switch. For example, below are a sample XML file and command line that will update the testing source (identified in step 2) with the latest build.

Contents of UpdateTestingSource.xml

</Product>

</Add>

</Configuration>

The command line to download the Office 365 ProPlus source files into the testing source would look like this:

Setup.exe /download UpdateTestingSource.xml

Since there is no Version attribute specified in our XML file, when we run the above command line, it will always download the latest available version.

Below is a screen shot of Task Scheduler that shows running the above command line on the second Thursday of each month:

The result is that your testing source will be automatically updated with the latest build on the 2^nd Thursday of each month.

With automatic updates enabled, the next time the Office Automatic Updates scheduled task runs (which runs 3 nights a week and after every logon) on the client computer with Office 365 ProPlus installed, the testing group will get the updated build.

Step 5: Have your testing group use Office

Since this is a step to be performed by those outside of the IT org (ideally), we’ll cover this at the end.

Step 6: Update the production testing source 2-3 weeks later

After the user acceptance testing of the updated build is done, the last step is to copy the files from the testing source to the production source. For this example, we’re going to perform this task on the last Friday of every month. The exact point-in-time should be a balance of “time to test the new build” and “leave the majority of clients at risk” and depends on your specific needs, risks and regulations. Instead of downloading the Office 365 ProPlus source files from the CDN into our production source location, we’re going to copy the files from our testing source.

Why? Since we’re not specifying a version attribute, if we download the files from the CDN we will always get the latest version. If Microsoft releases an out-of-band build – which they’ve done only once so far – there is a chance that the build we download on the last Friday of every month will be different than the build we downloaded on the 2^nd Thursday of every month. While it’s an extremely rare occurrence, copying the files from your testing source into your production source will be always equate to “we are 100% sure that providing the same source files that were tested.”

Copying the source files from one location to another can be done by a scheduled task, using any scripting or commands that you currently use.

Note: Make sure to delete the existing source files before you download or copy the newer source files to your source locations. Each released Office 365 ProPlus build creates a new folder (named by the build number) and will not overwrite existing files. If you don’t remove the previous source folder, you’ll end up with multiple Office builds in your source location, similar to the image below.

Since each Office build is over 900 MB in size, having multiple sources in the same folder can quickly eat up storage. Alternatively you move the files to your own “Office 365 ProPlus archive” if you need quick access to older builds in the future.

Step 7: Enable a back out strategy

The above steps provide an example that will automate the entire process of providing testers a 2-3 week window for testing, and then provide the tested build to the rest of your organization. Meaning, once you set it up, you’ll be on a low-risk, low-maintenance, fully automated path to enable change in Office 365 ProPlus.

But what if your testing group finds a problem? What steps need to occur to back out or revert to the older build?

First, if your testing group deems that the updated build is not suitable for production release, you should disable the scheduled task that copies the source files from the testing source to the production source. Since the source files won’t be updated, the Office Automatic Updates scheduled task won’t take any action. As a result, your production end users won’t receive the newer build.

Depending on the severity or impact of the issue found by your testing group, you have a choice of reverting back to the previous version, or keep the testing group with the newer build. If you want to revert back, you’ll need to rerun “setup.exe /configure” and use an XML file that specifies the version to which you want to revert. Below is an example of such an XML file – downgrade.xml:

Contents of Downgrade.xml

</Product>

</Add>

<Property Name="FORCEAPPSHUTDOWN" Value="TRUE"/>

</Configuration>

Three things to note in the above XML. The Version attribute must be specified that defines which version to install. If the version to install is lower than the currently installed version, you must also specify the ForceDowngrade attribute in the Add element.

Finally, make sure to add the FORCEAPPSHUTDOWN property. If any Office processes are running when setup.exe executes, an upgrade or downgrade will fail. Adding this property will ensure that the downgrade is successful.

That's it? How should I test?

That’s it. After implementing the steps described above you can lean back, listen to music or play a game on your new Xbox and let your users test the newest build for you. Meaning, a single person in your company won’t be in the position to unequivocally state “I’ve tested all the functions in Office, and I give my stamp of approval.” There’s just too many things to test. Any software compatibility testing is best done by the people who use the software. Further, the goal of compatibility testing should be for the testers to positively answer the question, “Can I get my job done?” Having testers that represent many different parts of your organization is a great way to determine if introducing updated software impacts the ability to do business. And saves effort at the IT department.

This means that your testers won’t need to take any extraordinary actions during the testing period. They simply do their normal work and communicate any issues as they normally would.

Results

The above sample testing and update process provides the outcomes:

A zero-touch approach which leverages automation
Reduced administrative and manual testing effort
A consistent process which can lead to higher quality of the process’s result
A 2-3 week window for testing
Automatic deployment into production if no issues arise
An “Opt-out” mechanism

The benefit of this approach is that regardless of what changes are implemented in an Office build, the steps you are taking to mitigate the risk of introducing those changes are consistent. This will enable your organization to quickly (and cheaply!) adopt changes including typical monthly builds, newer Service Packs, or even major versions of Office 365 ProPlus. This positions you to adopt change at a faster pace, increasing your company’s agility while ensuring your cost and risk are minimized and process quality is consistent.

References

Reference: Click-to-Run configuration.xml file

Overview of Click-to-Run for Office 365 setup architecture (Updates)

The new Office Garage Series: Anatomy of Office Software Updates in Click-to-Run

The new Office Garage Series: Click-to-Run Customization and Deployment Deep Dive Part 3 - Integration and Automation with Software Distribution Tools

Microsoft Office 2013 Click-to-Run virtualization