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:

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:

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 2nd 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.

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 2nd 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 2nd 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:

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.

The issues are with Microsoft not testing their own software with their own software. Business Contact Manager has an incompatibility with 2 Hotfixes that cannot be controlled by the user. Not having the ability to roll back hotfixes is a HUGE downside
to OPP. How do we roll back specific updates if we cannot see them? Why doesn’t Microsoft address issues with their software?

I wonder what happened to the good old times when Microsoft was promoting single sign-on and managing all your updates from one central point and so on. Now we have Microsoft Live Passport accounts that are not compatible with Office 365 account and Office updates for Office 2013 can be done through WSUS but the Office 365 ProPlus ones must be done manually separately if you want any control over their deployment. this just makes lots of extra work for Admins. To me it just seems that MS has different departments or sections that do not want to comply with other services and they just do their own thing and cause extra work for Administrators and MS does not care. For home users automatic updates like this make sense but for corporate environments they are just extra work for the admins, because downloading separate copy of update cause lots of extra internet usage costs as the data is limited/metered and the update testing will have separate overhead work for administrators over testing all other updates.

It mentions that the ForceDowngrade is no longer a supported attribute. Was the eliminated as part of the 15.0.4569.1507 release? And if so, what will be the recommended method of rolling back to an earlier version now (assuming any future releases beyond 15.0.4569.1507).

So, in the above scenario, the task scheduler forced the test group to look for updates in the testing group repository? If so, when you copy to the production share, is there a matching task schedule to force the production clients to look for the updates?

Echoing PriitVosu above, I'm very confused and disturbed that I'm unable to update Office 365 through our traditional WSUS setup. Why? The update packages could just as easily be issued through WSUS like any other package. Scheduled tasks? really?

After many cvompanies bought the Hardware and very cheap *cough* licenses for WSUS & SCCM you just explain to them we dont need them any more because we make a step – no a jump! – 10 years back and work with cmd scripts and scheduled tasks?

Really? You can only set the update at install? What if you need to update it at some point in the future? Has no one at Microsoft ever heard of Group Policy? Setting the update path seems like a GPO no-brainer. Then you only need one install, and can
target your test systems by OU.

When I was looking at the Office 2013 and Office 365 Group Policy templates fromhttp://www.microsoft.com/en-us/download/details.aspx?id=35554, I found the following:
Microsoft Office 2013 (Machine)Updates Update Path
This policy setting allows you to specify the location where Office will get updates from.If you enable this policy setting, you can specify one of the following for the update location: a network share, a folder on the local computer where Office is installed,
or an HTTP address. Mapped network drives arenÆt supported. If you enable this policy setting, but you leave the update location blank, Office will get updates from the Internet.If you disable or donÆt configure this policy setting, Office will get updates
from the Internet, unless you specify a different location by using the Office Deployment Tool.Important: This policy setting only applies to Office products that are installed by using Click-to-Run. It doesn't apply to Office products that use Windows Installer
(MSI).

Roaming uses (VPN) and interrupted updates. We have a fleet of very mobile users that access the network via VPN over any kind of connections. If they try to update over a hotel's slow WAN and they don't see the update running, they might as well get disconnected
or turn their computers off in the middle of the update!

Then, they will have a broken Office installation.

How can we handle this occurrence? At least with WSUS patches, they were pre-staged and only after they were downloaded they were applied.

Is it possible to configure the configuration.xml so that you can update some of the office components to the latest version, i.e. Word, Excel, Outlook, Access, etc but keep, for example, Lync on an older version? The exclude option just removes Lync when
performing the update.

Situation: Click to run,and updates on file share. Updates are tested by test group before copying the content to fileshare for updates to all other users in the organisation.

After the testing the updates by a testing group some incompatibilities are found. How do an administrator leave out the single part of an update that causes the problem?

Will the update process completely stop as future updates most likely will contain same part that caused the problem ? Is there some way of doing selective updates like rolling out only security updates?

Is there a way to get updates to office pro plus(2013) if for example MS choose to deploy office Pro Plus 2016?.

Absolutely frustating! The client network collapses two or three days each month due to the O365 updates system. Now we have to change all the O365 client installations in order to redirect the Updates to internal servers and to use a different system
to manage these updates.
Absolutely agree with PriitVosu and other comments. How is possible that MS does not allow to use the WSUS/SMCC for O365 updates?