Microsoft Autoupdate An Update Is Already In Progress

admin

Open an Office app such as Word, then on the top menu, click Help Check for Updates. If you don't see Check for Updates, run the latest version of Microsoft AutoUpdate tool, then check for updates again.

Microsoft Autoupdate An Update Is Already In Progress
  • Here you need to right-click 'Windows Update', and from the context menu, select 'Stop'. Alternatively, you can click on the 'Stop' link available under the Windows Update option on the top left side of the window. A small dialogue box will appear, showing you the process to stop the progress.
  • Microsoft AutoUpdate (MAU) version 3.18 and later includes the msupdate command-line tool. The msupdate tool can be used to start the update process for Microsoft applications produced for Mac, such as Office. The tool is primarily designed to give IT administrators more precise control over when updates are applied.

Microsoft AutoUpdate (MAU) version 4.13, released in mid-July, adds the ability to force update deadlines for Office applications. I was one of the MacAdmins who provided Microsoft developers with feedback starting last October and am happy to see the feature come to fruition.

This new functionality will definitely change how I handle updates as described in my post “A hybrid approach to managing Microsoft Office updates.”

The documentation Microsoft provided around the new feature is pretty good. But there has definitely been a lot of confusion in the MacAdmins Slack around getting it to work and there are some quirks to be aware of. If you are interested in the intricacies please read on.

The following information is based off version 4.13 of MAU, my hope is that some of these quirks and oddities will be corrected or added to the official documentation in a future release and might not apply at a later date.

Make sure you have read the Microsoft article “Set a deadline for updates from Microsoft AutoUpdate” (last updated 7/22/19 as of this posting) before continuing here. I’m going to try to avoid repeating a lot of the details.

Options

There are two different types of deadlines which can be set and each type can be set suite-wide and/or for individual applications.

• A certain number of days after the update is detected
• A specific date and time (for a specific update version)

The main consideration between the two methods is that the “number of days” option can be set once and never adjusted again, it will apply to all future updates. The “specific date, time and version” method will need to be adjusted every month and redeployed to client computers as new updates are released.

Microsoft Autoupdate An Update Is Already In Progress In Excel

However using “specific date, time and version” also allows you to more tightly control updates across your fleet. For example, picture a user who has been on a two week vacation when the update deadline arrives.

If a deadline is set using “specific date, time and version” this user’s computer will be updated within 60 minutes of the user logging in after returning from vacation. If the “number of days” option is used it will be an additional X number of days after the user returns from vacation before their computer is updated.

I’ll be utilizing the “number of days” method here at the newspaper combined with an MAU Manifest/Caching Server to control when the updates first appear to groups of computers. This will give me the simplicity of not changing the configuration profile every month with the control of deciding when updates are first made available.

All of my references below assume you are using a configuration profile to set the options, not a defaults write command.

Configuring the Options Suite-wide

By far the easiest option to set is if you want all applications to have the same “number of days” deadline after an update is detected.

This option can be set at the same higher level of the configuration profile, in the mcx_preference_settings key’s dictionary, as HowToCheck, UpdateCheckFrequency, ChannelName, etc. Using this option still allows for different deadlines to be set individually for specific applications lower in the profile.

Configuring the Options for Individual Applications

Pay close attention to the examples under “Preference settings for deadlines” in the documentation when setting these new options for individual applications.

While UpdateDeadline.DaysBeforeForcedQuit can be included in the existing dictionary under the Applications key used to register applications with MAU, specifying a “date, time and version” requires an entirely new dictionary under the UpdateDeadline.ApplicationsForcedUpdateSchedule key.

Both dictionaries include the Application ID key making them look very similar at first glance.

Storing the Deadline

No matter which option you use, internally MAU keeps track of the deadline(s) for applications separately for each user in: ~/Library/Preferences/com.microsoft.autoupdate2.plist

This means that on shared computers, when using the “number of days” method each user will have a separate deadline since the counter only begins when MAU sees the update while logged into that user account.

If the “specific date, time and version” method is utilized then an update will be forced 60 minutes after any user logs in to the computer once the deadline has passed.

The New Dialog

This update brings with it a new deadline dialog designed to inform users about the pending update and give them advance notice of the deadline. While it is effective in its initial form, it is not without its quirks that MacAdmins should be aware of.

• Unlike the Notification Center alert it replaces (see below) that remains on screen until acknowledged, the new deadline dialog disappears after 60 seconds wether the user has acknowledged it or not. After automatically closing it will not reappear for 12 hours.

• On the day of the deadline, the dialog will reference it in 24 hour time notation. This could be confusing to users who are not accustomed to reading a clock in that manner.

• Only the icons for applications that were not able to be automatically updated will appear in the dialog. This means different users will see slightly different dialogs depending on which applications are installed and running when MAU tries to execute automatic updates. (I used Word exclusively for the example images in this post.)

• 60 minutes from the deadline a timer dialog will appear counting down until the applications will be forcibly closed and updated. This dialog cannot be closed or hidden by the user until after the updates are completed.

• All users will see the 60 minute countdown timer no matter how far past the deadline they actually are. This gives users time to save their work.

Microsoft Autoupdate An Update Is Already In Progress Without

• The countdown timer and the progress circle around it can get out of sync. One easy way for this to happen is if the computer is put to sleep during the countdown. Once awoken, the progress circle will pick up where it left off however the timer will display as if it had been running the entire time, easily moving into the negative range. When this happens the progress circle is what actually controls the force quit deadline, not the timer.

When the New Dialog Appears

Another new preference that might get overlooked is UpdateDeadline.StartAutomaticUpdates. It is described in the section of documentation titled “Configure Automatic Download and Install mode.” This option sets how many days before a deadline that the HowToCheck option is automatically switched to AutomaticDownload. The default is 3 days.

While this is handy for admins who normally have HowToCheck configured for Manual or AutomaticCheck, because the option reverts after the deadline, it isn’t immediately obvious what purpose it might serve for admins already using AutomaticDownload.

Importantly this setting is what controls when MAU will switch from using the existing Notification Center alert, that stays on screen until acknowledged, to the new MAU notification that disappears after 60 seconds (and doesn’t reappear for 12 hours). This function of the key is not documented and was not obvious until testing.

If you already have HowToCheck set to AutomaticDownload, you’ll need to decide how many days you want your users to see the persistent Notification Center alert before switching to the new deadline dialog. Otherwise they may not see the notifications at all before the 60 minute countdown begins.

Internally MAU sets the next time this dialog will appear for a user in: ~/Library/Preferences/com.microsoft.autoupdate2.plist

<key>DisplayForcedUpdateDialogOn</key>
<date>2019-07-23T06:08:52Z</date>

User Experience

The user experience is mostly the same no matter which of the new options you choose. However there will be some variation depending on which HowToCheck option is configured. Since I use AutomaticDownload most of my testing centered around that option. (I did not test staggered deadlines and how the dialogs might behave when one application has a deadline days before another.)

• HowToCheck = Manual

Only the new deadline dialog will be displayed once the UpdateDeadline.StartAutomaticUpdates threshold is reached (3 days by default if un-configured).

• HowToCheck = AutomaticCheck

The MAU application will launch and the full dialog will display (as in the past) until the UpdateDeadline.StartAutomaticUpdates threshold is reached at which point the new deadline dialog will begin displaying.

Microsoft Autoupdate An Update Is Already In Progress Online

• HowToCheck = AutomaticDownload

With AutomaticDownload enabled MAU will begin silently upgrading any applications it can as soon as they are detected. For any open applications MAU will display the same Notification Center alert it always has allowing users to delay or update immediately.

While this alert remains on screen until acknowledged, it can be deferred indefinitely by the end user. The new deadline functionality is designed to address that behavior and limit how long a user can delay the update.

If a user selects Update Later the Notification Center alert will display again every 12 hours by default or at the frequency configured using the existing UpdateCheckFrequency key. This alert will be used between the time an update is detected by MAU until the UpdateDeadline.StartAutomaticUpdates threshold is reached (3 days by default if un-configured).

Once the UpdateDeadline.StartAutomaticUpdates threshold is reached MAU will stop using the macOS Notification Center for alerts and switch to using the new deadline dialog. As noted above this dialog will only remain on screen for 60 seconds before disappearing and will not reappear for 12 hours.

If a user does acknowledge the deadline dialog they will have the option to Snooze the alert for various periods of time depending on how far away they are from the deadline. The selected option will override the default of 12 hours.

Once the deadline arrives, or is passed, users will be presented with the countdown timer that cannot be closed. When the timer expires any open Office applications will be closed and updated. The dialog will remain on screen during this process as seen below.

Example Configuration Profiles

Since examples are frequently requested in Slack, I plan to make several different variations of the configuration profile for controlling Microsoft AutoUpdate, including these new options, available on Github shortly.

Further Discussion

If you have any thoughts, feedback or questions about this new behavior please join us in the #microsoft-autoupdate channel of the MacAdmins Slack where Microsoft developers have graciously joined us and other admins are happy to help out.

UPDATE 8/22/19: I have added these new preferences into ProfileCreator.

UPDATE 9/12/19: Microsoft has updated to documentation to include information about how to turn off a deadline.

Based on your feedback, we’ve changed how we roll out upgrades to PowerApps in order to minimize the impact on apps you’ve already published.

Until recently, new releases of the PowerApps automatically applied product updates to published apps. This was so your end users could immediately benefit from improvements to controls and the platform. Unfortunately, in some cases, this caused some side effects that changed the behavior of your published apps, without providing app authors a chance to test these updates. We’ve reworked our release process so that apps will continue to run as published, no matter how often we update PowerApps. The only time published apps will get updated is when you edit them in PowerApps Studio, and then save and publish a new version to your users.

Users build apps with PowerApps as a platform. We deploy a new version of PowerApps every few weeks to provide the latest functionality and experiences. Similarly, we release PowerApps clients for creating and playing apps in Windows, Apple and Google stores every few weeks as well. Both PowerApps service (platform) and PowerApps clients have a release version associated with them, for example, the release version on May 30, 2017 was 2.0.640. We publish details about what’s new in each PowerApps release in our documentation.

What was happening before these changes?

Whenever you created or modified an app, it was done with a specific PowerApps release. Let’s say you created an app with PowerApps release 2.0.570, and published it to many users in your organization. Time passed, and PowerApps was upgraded to a newer version 2.0.642. Users in your organization started playing the app with the latest PowerApps service and clients 2.0.642. PowerApps automatically upgraded your app to work with PowerApps release 2.0.642, which at times changed the app experience. These changes were not visible in the Versions tab in app management experience.

We have stopped doing the auto-upgrade for your apps with every PowerApps release.

Here’s how upgrades will work now:

1. Say you modify and publish an app using PowerApps release 2.0.570. You’ll see that noted in the new column we created in the Versions tab called PowerApps release. This number indicates the PowerApps release with which your app was modified with.

2. PowerApps then releases a new version, 2.0.642. Even if users in your organization download the latest PowerApps client and use the 2.0.570 version your app, the app will be compatible with the newer PowerApps clients and will play normally.

3. If you (the app creator) downloaded the latest client 2.0.640, modified and published the app with it. A new version for the app gets created and will appear in Versions tab.

Our goal is to continue providing you a stable experience for your apps and app users. We will keep you informed about future updates on this topic. Please let us know if you have any questions.

FAQs:

1. Ques: What is the difference between VERSION and POWERAPPS RELEASE column?

Microsoft Autoupdate An Update Is Already In Progress In Chrome

Ans: VERSION column represents the app version. Every change which happens with your app creates a new version. Even if it’s a small change you make to your app e.g. changing the color to the text box and saving the app, will create a new version of the app. Whereas POWERAPPS RELEASE represents the version of PowerApps service with which you are building the app with. So, there can be various app VERSIONS with the same POWERAPPS RELEASE but vice-versa will not be true.

2. Ques: Why do I have no value for POWERAPPS RELEASE for some of VERSIONS of the app?

Ans: We started tracking the POWERAPPS RELEASE for apps recently. Hence, some of the app VERSIONS which were created earlier, will have this field as empty. It doesn’t mean that there is any problem with these apps, but just the POWERAPPS VERSION is not tracked for them. These apps will work just fine!