I’m Aaron Czechowski, a senior program manager on the Windows Intune engineering team. This is the first in a three-part series on topics surrounding Windows Intune client behavior when the Windows Intune team publishes a client update. We’ve recently heard a lot of feedback from customers on client update behavior so wanted to provide more information. This first post details why we publish client updates and then what happens underneath the hood.
First Some Background…
Windows Intune is a cloud-based PC and Mobile Device management service, one of the features of which is deploying software applications and software updates. When a computer is first enrolled to the Windows Intune service the client software is installed so that it can be managed. Windows Intune can then be used to deploy applications and updates (for example, security updates for Windows or Office), leveraging the Windows Intune client to deliver the software to Windows for installation. We currently also define a category for Mandatory Updates which mostly includes updates for the Windows Intune client software itself. These mandatory updates are processed similarly as other software updates, with some exceptions, but more on this later.
When Are Mandatory Updates Published?
One of the goals of the Windows Intune team is to reduce the frequency with which we publish mandatory updates for our client software. The two primary reasons why these updates are released are for functionality and security. General functionality releases typically coincide and align with a major upgrade of the service, such as the recent upgrade in September to the June 2012 release. If we identify a critical service-impacting or security bug in our client software we will fix it in a timely manner, which may require publishing a mandatory update for our client software. Such an update was released in October.
Under The Hood
So what’s actually happening when one of these mandatory updates is released?
- Separate from the Automatic Updates cycle, a client process called Agent Sync automatically runs every day on a randomized timeframe to spread the load on our servers and your networks.
- When Agent Sync sees that a new mandatory update is available it downloads the update and immediately installs it.
- If the updated agent is currently in use and cannot be cycled before it is updated the primary client agent, Windows Intune Software Distribution Manager (WISDM), will signal the Windows Intune Automatic Updates (WI-AU) agent requesting a restart. Today, if the mandatory update is for WISDM itself a restart is almost always requested.
- Once WI-AU is signaled the client behavior and notification follows the current Updates policy settings in the Windows Intune Agent Settings template. (I’ll go into much more detail on these policy settings in the next post in the series.)
The next Windows Intune release will include an additional policy setting to control end user notifications when a mandatory update requests a restart, and we are making improvements to the underlying functionality of the client software itself to reduce the need for restarts when updates occur. In future Windows Intune releases the engineering team is looking at ways to improve this behavior and provide our customers with greater control over these mandatory updates for our client software. At the same time we still need to balance this with centralized enforcement to ensure the end-to-end functionality, stability and security of the Windows Intune service.
It is important to note that these new features will not be available until all agents are running the new version, so the next upgrade will still behave similar to the previous upgrade. Another related note is that the Common Anti-Malware Platform (CAMP), used by Windows Intune Endpoint Protection, is currently updated via a separate channel that does not always follow the same update schedule or behavior. The Windows Intune and Endpoint Protection product teams are looking into alignment of the update behavior for a better integrated experience.
Now that you have more context on client updates, stay tuned for the next post which will go into more detail on the applicable policy settings and end-user notifications. The third post will detail our current notification mechanisms so that you can adequately prepare for service upgrades and maintenance.