Freigeben über


Managing Updates for Office 365 ProPlus – Part 2

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:

  1. Identify a “testing” group
  2. Configure testing group to get their updates from an internal source
  3. Configure all others to get their updates from a different internal source
  4. Update the testing source after every Patch Tuesday
  5. Have your testing group use Office
  6. Update the production testing source 2-3 weeks later
  7. 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

<Configuration>

  <Add OfficeClientEdition="32" >

      <Product ID="O365ProPlusRetail">

         <Language ID="en-us" />

      </Product>

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

<Display Level="None" AcceptEULA="TRUE" />

<Logging Name="OfficeSetup.txt" Path="%temp%" />

</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

<Configuration>

  <Add OfficeClientEdition="32" >

      <Product ID="O365ProPlusRetail">

        <Language ID="en-us" />

      </Product>

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

<Display Level="None" AcceptEULA="TRUE" />

<Logging Name="OfficeSetup.txt" Path="%temp%" />

</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 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.

Contents of UpdateTestingSource.xml

<Configuration>

<Add SourcePath="\\MyServer\Updates\TestingGroup" OfficeClientEdition="32">

      <Product ID="O365ProPlusRetail">

        <Language ID="en-us" />

      </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 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:

Contents of Downgrade.xml

<Configuration>

  <Add OfficeClientEdition="32" Version="15.1.2.3" ForceDowngrade="TRUE" >

      <Product ID="O365ProPlusRetail">

        <Language ID="en-us" />

      </Product>

  </Add>

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

 <Display Level="None" AcceptEULA="TRUE" />

 <Logging Name="OfficeSetup.txt" Path="%temp%" />

  <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

Comments

  • Anonymous
    January 01, 2003
    Managing Updates for Office 365 ProPlus – Part 2
    thank you for this information
  • Anonymous
    January 01, 2003
    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?
  • Anonymous
    January 01, 2003
    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.
  • Anonymous
    January 28, 2014
    Automatic Updates streamlines the way administrators deploy updates to Office 365 ProPlus. This post
  • Anonymous
    February 07, 2014
    226 Microsoft Team blogs searched, 30 blogs have new articles. 102 new articles found searching from
  • Anonymous
    February 21, 2014
    Recent Releases :

    Updates: Process Explorer v16.0, PsPing v2.01 - 29-Jan-2014
    Released: Management
  • Anonymous
    February 26, 2014
    Now that Office 2013 is generally available, it is time for many organizations who are currently using
  • Anonymous
    March 13, 2014
    According to the latest reference for the click-to-run:

    http://technet.microsoft.com/en-us/library/jj219426%28v=office.15%29.aspx

    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).
  • Anonymous
    March 29, 2014
    The comment has been removed
  • Anonymous
    May 08, 2014
    My WSUS server is feeling neglected and upset at being replaced by a newer, shinier process
    (nice clear article by the way)
  • Anonymous
    May 09, 2014
    p.s. would the downgrade.xml file not need a SourcePath specified in the Add element?
  • Anonymous
    June 17, 2014
    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?
  • Anonymous
    July 09, 2014
    How do we manage bandwidth to sites with slow links? Can we control the times the updates happen?
  • Anonymous
    July 31, 2014
    I've implemented the above in our organisation adapted to be administered by Altiris and pushing the updates to the C: of our production computers.

    The Production XML file puts entries in the Registry to tell Office where to look for it's updates:

    HKLMSOFTWAREMicrosoftOffice15.0ClickToRunScenarioINSTALLUpdateUrl

    HKLMSOFTWAREMicrosoftOffice15.0ClickToRunConfigurationUpdateUrl

    However, I performed an online repair for one of our end-users and it wiped out these two Reg Keys.

    It's not a problem to put hem back, now I know about it, but is there a way to stop this from happening?

    Kind regards, Mark
  • Anonymous
    October 27, 2014
    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?
  • Anonymous
    November 27, 2014
    Scheduled Tasks? Really?

    i mean 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?

    Hahaha nice
  • Anonymous
    December 18, 2014
    @Markus - lol agreed!
  • Anonymous
    January 12, 2015
    What's the difference between ForceDowngrade and using the OfficeC2R.exe command?
  • Anonymous
    January 19, 2015
    Background:
    The SP1 release of Microsoft Office 2013 Click-to-Run for Office365 offers a new Update
  • Anonymous
    February 12, 2015
    This is not ent level stuff, how do you report patch compliance! uninstalls, "scheduled tasks"!!!, global coverage, etc.!

  • Anonymous
    February 12, 2015
    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.
  • Anonymous
    February 24, 2015
    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).
  • Anonymous
    February 25, 2015
    Jack - you can use GPOs to set the update path too.
  • Anonymous
    April 15, 2015
    Watcher Interval = what is the time period mentioned that a workstations will query Microsoft environment to get auto updates? where do I check.
  • Anonymous
    April 27, 2015
    The first step in configuring local Office 365 updating is to download the Office media using the Office
  • Anonymous
    June 02, 2015
    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.

    I don't consider the installation mechanism current.

    I would be grateful for an answer to this.
  • Anonymous
    July 09, 2015
    Someone knows how configure WMI Queries to identify x64 or x86 version of Office 365 Pro Plus?
    It could be helpful to manage GPOs that contain different path for update/upgrade
    Thanks
  • Anonymous
    August 21, 2015
    The comment has been removed
  • Anonymous
    September 08, 2015
    The comment has been removed
  • Anonymous
    September 16, 2015
    Question regarding updates for Office Pro Plus ;

    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?.

    Kind regards

    Asger
  • Anonymous
    October 08, 2015
    Is there ANY way to make these updates work in SCCM? We use that enterprise-wide to do all our updates and our processes are built around it.
  • Anonymous
    October 30, 2015
    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?