Skip navigation

Mobile users have long presented a special challenge to IT professionals when it comes to the task of patch management. The problem is that under normal circumstances centralized patch management only works when the end user is logged into the corporate network. This can be a problem since mobile users might only rarely bring their laptops into the corporate office.

 

In the past, IT pros have used two main techniques to deal with this challenge. One of those techniques involves decentralizing the patch management process. The Windows operating system can be configured to download patches directly from Microsoft and to install them automatically. Many third party applications offer similar functionality.

 

Decentralized patch managment

Decentralizing patch management for mobile users can be very effective because patches are automatically downloaded from the Internet, even if the end user is not connected to the corporate network. The disadvantage to using this technique, however, is that it leaves a lot to chance. Most larger organizations like to test patches before they allow them to be applied to production systems. When you decentralize patch management for mobile users, patches are automatically applied to the user’s laptops whether the organization has tested them or not.

 

Furthermore, this technique makes it difficult for administrators to determine which patches have been applied to mobile user’s laptops. When you decentralized patch management you also forfeit centralized patch deployment reporting.

 

VPN Connections

The other technique that has been traditionally used to handle patch management for mobile users is to deploy patches over VPN connections. In this scenario, the organization maintains centralized control of the patch management process. This allows the administrator to perform patch testing before any patches are authorized for deployment to production systems. When a mobile user logs into the corporate VPN, their computer checks in with the patch management server and downloads any missing patches.

 

On the surface this technique seems ideal, but it has one fatal flaw. The problem is that patch management can only occur when the end user is logged into the corporate VPN. If the end-user only connects long enough to check their email, then it is unlikely that the session will last long enough for the patch management process to complete.

 

Either of these techniques can be used to facilitate patch management for mobile user’s laptops. As you have seen however, neither of these methods is perfect. Even so, there is a third method that directly addresses the shortcomings of the previous two methods.

 

DirectAccess

This method involves using Microsoft’s DirectAccess feature to facilitate patch management. If DirectAccess sounds familiar, it may be because Microsoft introduced it with Windows 7 and Windows Server 2008 R2 as a next generation alternative to traditional VPNs. However, DirectAccess didn’t catch on because it was extremely difficult to configure.

 

Even though the first incarnation of DirectAccess was a flop, the story isn’t over. Microsoft revisited the DirectAccess feature in Windows Server 2012 and Windows 8 and made it much easier to configure. In fact, you can now deploy DirectAccess with only a few mouse clicks.

 

The reason why DirectAccess can be beneficial to mobile patch management is because it eliminates the need for a user to log into a corporate VPN. When a user’s connects to the Internet, Windows automatically establishes a DirectAccess session to the corporate network. This connection is established from behind the scenes with no end user involvement.

 

DirectAccess can be thought of as an always on connection to the corporate network. If the laptop has Internet connectivity, it also has connectivity to the corporate network. This makes it a lot easier to perform centralized patch management because administrators no longer have to worry that end users will only log on for a few short minutes to check their E-mail. Mobile users often remain connected to the Internet for several hours at a time, which is perfect for deploying patches.

 

Requirements to use DirectAccess

In case you are wondering, there are some client side requirements that must be met in order for an end user to establish DirectAccess connectivity. The only client operating system that natively supports DirectAccess is Windows 8; however, there is an update available for Windows 7 that allows it to work with the Windows Server 2012 version of DirectAccess. The client computer will also have to have a TPM chip in order to work with DirectAccess.

 

The Feather in the Cap

When all is said and done, DirectAccess might be the perfect mechanism for facilitating patch management for mobile users. It allows the organization to maintain centralized control of the patch management process, it doesn’t require the end user to do anything special, and the amount of time that users tend to spend online should help the patch deployment process to complete.

 

And because the DirectAccess connection is bi-directional, when combined with SolarWinds Patch Manager it gives you the ability to deploy updates on-demand, as well as perform other systems management tasks.

Today Microsoft announced the forthcoming content for Patch Tuesday -- Nov 13, 2012.

 

You can have Microsoft's security bulletins sent directly to you:

To receive automatic notifications whenever Microsoft Security Bulletins are issued, subscribe to Microsoft Technical Security Notifications.


Microsoft also hosts a webcast where they discuss the releases, typically the Wednesday after Patch Tuesday:

Microsoft will host a webcast to address customer questions on the security bulletins on November 14, 2012, at 11:00 AM Pacific Time (US & Canada). Register now for the November Security Bulletin Webcast. After this date, this webcast is available on-demand.

You can also follow the MSRC team at @MSFTSecResponse.


Number of Releases: 6

Number of CVEs addressed: 19


Critical Security Updates: 4 addressing 13 vulnerabilities in Windows, IE, and the .NET Framework

Important Security Updates: 1 addressing 4 vulnerabilities in Office

Moderate Security Updates: 1 addressing 2 vulnerabilities in Windows


Updates are typically released by Microsoft at 10am PT (6pm UTC).

Configuring WSUS servers to synchronize relative to that time can be helpful in expediting availability of these security updates.



From Doug Neal at Microsoft Update:

 

I want to [...] distinguish between two issues to help experts and admins understand the potential impact of two changes you may be seeing in your environments.

 

The first issue regards digital certificates (as described in KB2749655); the second is related to improvements in the Microsoft Update service used by WSUS Server, SCCM and Intune (as described in KB 2718704).

 

ISSUE  1 - DIGITAL CERTIFICATES

The digital certificates issue is described in the MSRC advisory http://technet.microsoft.com/en-us/security/advisory/2749655 and the associated KB article http://support.microsoft.com/kb/2749655

 

These updates released on October 9 (2nd Tuesday in October) and resulted in between 50 and 250 updates being changed depending on how many of these were in your servers. Some of these were revisions (metadata only changes).  Some were re-releases (due to the code-signing elements being integrated into Windows CBS-based binaries).  While the payload changed for some of these updates, none of them had functional or targeting changes beyond the signing corrections.  Any additional updates for this same issue will likely be released on future 2nd Tuesdays and will appear as a similar set of 50 - 250 updates that are either revised, re-released or both.

 

While I can't discuss future releases, you should expect a few more of these in the coming month or so. The impact on WSUS, SCCM servers should be the same as they were on October 9.  Intune is not affected since it maintains the datastore in the cloud, not in a local database like WSUS and SCCM servers.

 

ISSUE 2 - ADDITIONAL IMPROVEMENTS

As part of a strategy to improve the security of Windows/Microsoft Update, many updates were revised in other ways as mentioned in the MSRC blog http://blogs.technet.com/b/msrc/archive/2012/06/04/security-advisory-2718704-update-to-phased-mitigation-strategy.aspx, in the MSRC advisory http://technet.microsoft.com/en-us/security/advisory/2718704 and in the associated KB article http://support.microsoft.com/kb/2718704.

 

The WSUS team posted this related post Wednesday October 31: http://blogs.technet.com/b/sus/archive/2012/10/31/support-tip-many-new-revisions-of-updates-may-be-downloaded-by-the-wsus-server.aspx

 

Within the MU service, a very large number of updates were improved in additional ways to secure and harden the service (I'm not able to provide more details).

 

The large number of improved updates became visible to WSUS servers on a rolling, one-time basis beginning the first week of October.  This means that one WSUS admin may have received the improved revisions all at once one day after a sync, while another WSUS server may have received the same large batch of updates 1, 2, 5, 7 or even 14 days later than the earlier admin.  And once these improvements come down to your WSUS/SCCM server, you will not incur another experience like this again.  This is a one-time sync of the large number of updates we've already made in our service - separate and different from those described in ISSUE 1 above.

 

Depending on how many of these improved updates were present in your WSUS server, you may have observed anywhere from 1000 or more revisions.  As a result, your managed clients may have briefly indicated they weren't compliant (due to the new revisions).  But after the clients obtained the revision and rescanned, they would report back that they were again compliant.

 

For SCCM admins, the latter issue will incur a one-time cost to re-download any active deployments to both sync and redistribute these to ConfigMgr distribution points.  While there's a wizard that helps, the effort increases with the number of active deployments that were changed.

 

TECHNICAL IMPACT

In both cases - whether for digital certificates or the additional improvements - neither the targeting (metadata) nor payloads were changed in any functional way.

 

The impact to WSUS servers is more likely worrying than troublesome.  SCCM admins had a much greater impact that required manual effort to ensure all clients and their active deployments returned to a compliant state.

 

While both changes we made were to improve the service for enterprises and consumers, the impact wasn't sufficiently understood beforehand and communicated proactively. I hope this explanation helps describe the situation and helps you plan for and accommodate these changes.  We strive to provide a powerful service you can trust without interruption.  And we're already making improvements based on your feedback.

 

For reporting issues with SCCM or WSUS Server, please take the time to review and post on the forums below where we watch for issues affecting our customers:

 

 

 

doug neal

Microsoft Update (MU)