WSUS Product Team Blog

Hello folks,

I am finally back from a long vacation, hopefully everyone is doing alright. Since there has been a lot of movement in the blog, I also wanted to bring to your attention the post that the MU folks have just added to their blog which relates to the availability of Windows Search 4. As a reminder, this update will not automatically install on WSUS clients. Windows users will either see it as an "Optional" or "Recommended" update depending on the version you are running.

Thank you.

Cecilia Cole | WSUS Program Manager

Hi all,

Anyone who added "Drivers" to their WSUS synchronization options may have noticed a large number of driver updates showing up in their WSUS server recently, and the majority of them have the same title. We wanted to let you know what's going on and what we are doing about it.

First lets talk about the root cause. Drivers can target one or more hardware IDs, and we have a limitation in our data-model so that each "update" can only support a single hardware ID. What that means is that a single driver is often implemented as multiple updates, all with the same title. What happened recently is a few drivers were released to WSUS that supported a very large number of hardware IDs.

It turns out the proper fix for this is not simple; it involves changes to WSUS, WUA, WU, and our driver publishing pipeline to allow a single driver update to support multiple hardware IDs. We have made a number of these changes already, but all this won't come online until some time after the next WSUS release. A number of folks have asked "can't you just do some quick change to the WSUS UI to group them together" and unfortunately that is an even more complex change to make (although in the WSUS 3 UI update view, we do have a "group by" feature that allows one to at least group the updates by title - but that's only a small part of update handling).

In the short term, we will be making some publishing policy changes to ensure that drivers with a large number of hardware IDs don't flow to WSUS through WSUS/MU server synch. This doesn't mean the drivers won't be available to WSUS - they can still be imported from the MU catalog site (from the WSUS 3 UI, go to the "Updates" node and select "import..."). It's just that they won't flow automatically and surprise those who have added drivers to their synch options.

-Marc Shepard

WSUS Lead Program Manager

Hi all,

We have released a fix for the synchronization issues that Cecilia described in http://blogs.technet.com/wsus/archive/2008/06/18/client-server-synchronization-issues.aspx. For details on how to obtain the update, please refer to http://support.microsoft.com/kb/954960.

If you are installing the update on Server 2008, you need to install the update with elevated privileges or else install will fail. E.g., you can run it from a command prompt that was launched with "Run as administrator”.

The update does not support uninstall or have an entry in ARP. But one can verify the update has been installed by checking that the version of  Microsoft.UpdateServices.WebServices.Client.Dll (in %Program Files%\Update Services\WebServices\ClientWebService\bin\) is 3.1.6001.66 (it will be 65 if the update has not been applied).

While this update is only available on download center today, we are working on making it available through the WU/WSUS pipeline and hope to have that done as soon as possible. When released through WU/WSUS, it will be marked as a mandatory update, which means it will appear in the Updates/WSUS Updates node of the Admin console, and will be auto-approved by default (since the “Advanced/WSUS Updates” checkbox is checked by default in Options/Automatic Approvals).

Thanks,

Marc Shepard

WSUS Lead Program Manager

Hi all,

We wanted to let you know that a new version of the Windows Update Agent is being released on Windows Update over the next couple of months. Because WSUS and Windows Update both use the same Windows Update Agent, this means that WSUS-managed end-user who navigates to WU to perform an interactive sync will receive an updated version of WUA as this new agent is rolled out over the next few months. Machines who's end-users don't explicitly navigate to WUA to perform an interactive scan will continue to use the existing version of WUA. This will result in a mixture of WUA versions in most corporate environments. Because WUA is backwards compatible, machines that recieve the newer agent will continue to work just fine with WSUS.

You can read more about this change in the Windows Update blog at http://blogs.technet.com/mu/archive/2008/07/03/upcoming-update-to-windows-update.aspx.

-Marc Shepard

WSUS Program Manager Lead

I read Marc’s post about Compliance Reporting and it was similar to a problem I deal with in my job.  Part of my job is to run Update Management on one of the domains consisting of around 12,000 managed computers at Microsoft using WSUS.  We do this in order to validate WSUS (and similar products) in an environment with real users.  Another group at Microsoft audits my compliance, and often request a list of non-compliant machines for specific security bulletins.  I have adapted Marc’s SQL script to do just that.

I ran into one issue, Marc’s SQL script will blocks clients from scanning while it runs.  Since the script can take a long time to execute on larger data sets, I decided to allow SQL to read dirty data and unblock my clients (SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED.).

I hope you find this useful.

Travis Plunk

Software Design Engineer in Test II, WSUS

-- Find computers within a target group that need a security bulletin

USE

SUSDB

go

SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

GO

DECLARE

@TargetGroup nvarchar(30)

DECLARE

@Bulletin nvarchar(9)

SELECT

@TargetGroup = 'All Computers'

SELECT

@Bulletin = 'MS08-030'

-- Find the computers not compliant for each security bulletin in the given @TargetGroup

-- where the approved occured between @Days and @DaysEnd days ago

SELECT              ct.Name,@Bulletin as Bulletin,ct.LastReportedStatusTime

FROM         PUBLIC_VIEWS.vComputerGroupMembership as cgm INNER JOIN

                      PUBLIC_VIEWS.vComputerTarget as ct ON

                      cgm.ComputerTargetId = ct.ComputerTargetId INNER JOIN

                      PUBLIC_VIEWS.vComputerTargetGroup as ctg ON

                      cgm.ComputerTargetGroupId = ctg.ComputerTargetGroupId

WHERE     (ctg.Name = @TargetGroup)

-- And only select those for which an update is approved for install, the

-- computer status for that update is either 2 (not installed), 3 (downloaded),

-- 5 (failed), or 6 (installed pending reboot), and

-- the update bulletin is the one provided.

                              AND EXISTS

                          (SELECT     1

                            FROM          PUBLIC_VIEWS.vUpdateEffectiveApprovalPerComputer as ueapc INNER JOIN

                                                   PUBLIC_VIEWS.vUpdateApproval as ua ON

                                                   ua.UpdateApprovalId = ueapc.UpdateApprovalId INNER JOIN

                                                   PUBLIC_VIEWS.vUpdateInstallationInfoBasic uiib ON

                                                   uiib.ComputerTargetId = ct.ComputerTargetId AND

                                                   ua.UpdateId = uiib.UpdateId

                                                   inner join PUBLIC_VIEWS.vUpdate as u on ua.updateid=u.updateId 

                            WHERE      (ueapc.ComputerTargetId = ct.ComputerTargetId) AND

                                                   (ua.Action = 'Install') AND (uiib.State IN (2, 3, 5, 6)) AND u.securityBulletin is not null and u.securityBulletin=@Bulletin )

Customers at TechEd asked how to generate a compliance report that shows computers that are out of compliance against updates that have been approved for install to them for N days. This can't be done in the public UI because it has no ability to specify the length of time an update has been approved, or to scope to just updates approved-for-install to that computer. However it can be done in WSUS 3 and later via our public SQL views.

Information on how to use our public DB views can be found here: http://msdn.microsoft.com/en-us/library/bb410149(VS.85).aspx. As described in the article, to do this with the Windows Internal Database with WSUS, one first downloads SQL Studio Express Edition, and then connects to the DB using Windows Auth and the connection string "\\.\pipe\MSSQL$MICROSOFT##SSEE\sql\query".

Anyways, here's a query that accomplishes this. This query has not been tried on large DBs yet and may have  performance challenges on such DBs. We will probably update this blog next week with a tweaked version of this query that performs better on large systems, and that lists the particular updates that are needed by the computer (and also says if they are needed just because a reboot is needed). But so many folks asked about how to use the public views to do this type of query last week that we wanted to show how it is done.

-Marc Shepard

Lead Program Manager, WSUS

USE SUSDB

DECLARE @TargetGroup nvarchar(30)

DECLARE @Days int

SELECT @TargetGroup = 'Test Machines'

SELECT @Days = 7

SELECT vComputerTarget.Name

FROM PUBLIC_VIEWS.vComputerGroupMembership

INNER JOIN PUBLIC_VIEWS.vComputerTarget on vComputerGroupMembership.ComputerTargetId = vComputerTarget.ComputerTargetId

INNER JOIN PUBLIC_VIEWS.vComputerTargetGroup on vComputerGroupMembership.ComputerTargetGroupId = vComputerTargetGroup.ComputerTargetGroupId

vComputerTargetGroup.Name = @TargetGroup

AND EXISTS

select * from

PUBLIC_VIEWS.vUpdateEffectiveApprovalPerComputer

INNER JOIN PUBLIC_VIEWS.vUpdateApproval on vUpdateApproval.UpdateApprovalId = vUpdateEffectiveApprovalPerComputer.UpdateApprovalId

INNER JOIN PUBLIC_VIEWS.vUpdateInstallationInfoBasic on vUpdateInstallationInfoBasic.ComputerTargetId = vComputerTarget.ComputerTargetId

vUpdateEffectiveApprovalPerComputer.ComputerTargetId = vComputerTarget.ComputerTargetId

AND vUpdateApproval.Action = 'Install'

AND vUpdateInstallationInfoBasic.UpdateId = vUpdateApproval.UpdateId

AND vUpdateInstallationInfoBasic.State in (2, 3, 5, 6)

AND DATEDIFF (day, vUpdateApproval.CreationDate, CURRENT_TIMESTAMP) > @Days

Good morning folks,

A couple of weeks ago, I posted about Windows Vista Service Pack 1’s availability to WSUS. In that post, we mentioned that you should install the WinVerifyTrust update (KB 938759) if you are running your WSUS server on a Windows 2003 server to prevent Windows Vista SP1 from being continually re-downloaded to the server once the service pack is released to WSUS. 

Today, we’d like to let you know that, in order to make sure all customers are well protected, we will be marking this particular update as mandatory, which means it will appear in the Updates/WSUS Updates node of the Admin console, and will be auto-approved by default (since the “Advanced/WSUS Updates” checkbox is checked by default in Options/Automatic Approvals).

After this update has been marked as mandatory to WSUS for a short period of time, we will release Windows Vista Service Pack 1 to WSUS. We believe that this change will help make sure all customers have a good experience once SP1 is released to WSUS, and will also ensure that WSUS can be used to deploy other large updates we may release in the future.

Thank you for your support.

Cecilia Cole

WSUS Program Manager

Good morning!

Now that you are all back from TechEd, I wanted to address an issue that a couple of folks contacted us about regarding some client/server synchronization issues they were experiencing in their WSUS environment.

Issue:

Computers that have Office 2003 or components of Office 2003 installed fail to run a detection against a WSUS server that has the latest Office updates. This prevents the computers from receiving any updates from the WSUS server.

Affected products:

·         WSUS 3.0 Server (RTM or SP1)

·         Computers with Office 2003 or components of Office 2003 installed.

Symptoms:

Automatic updates fails detection against the WSUS server.

1.       On the client side, the automatic updates log file (%windir%\WindowsUpdate.log) has an entry similar to below during the detection phase:

2008-06-13    19:59:53:383  788   ee4    PT     +++++++++++  PT: Synchronizing server updates  +++++++++++

2008-06-13    19:59:53:383  788   ee4    PT       + ServiceId = {3DA21691-E39D-4DA6-8A4B-B43877BCB1B7}, Server URL = http://<WSUS Server>/ClientWebService/client.asmx

2008-06-13    19:59:56:617  788   ee4    PT     WARNING: SyncUpdates failure, error = 0x8024400E, soap client error = 7, soap error code = 400, HTTP status code = 200

2008-06-13    19:59:56:617  788   ee4    PT     WARNING: SOAP Fault: 0x000190

2008-06-13    19:59:56:617  788   ee4    PT     WARNING:     faultstring:Fault occurred

2008-06-13    19:59:56:617  788   ee4    PT     WARNING:     ErrorCode:InternalServerError(5)

2008-06-13    19:59:56:617  788   ee4    PT     WARNING:     Message:(null)

2008-06-13    19:59:56:617  788   ee4    PT     WARNING:     Method:"http://www.microsoft.com/SoftwareDistribution/Server/ClientWebService/SyncUpdates"

2008-06-13    19:59:56:617  788   ee4    PT     WARNING:     ID:c0a7445f-b989-43fa-ac20-11f8ca65fa8c

2.       On the WSUS server, the WSUS log file (%Program Files%\Update Services\Log Files\SoftwareDistribution.log) has an entry similar to below, which one can find by searching on the ID obtained from the client log:

2008-06-14 02:59:57.642 UTC Error  w3wp.12       ClientImplementation.SyncUpdates       System.ArgumentException: Item has already been added. Key in dictionary: '8862'  Key being added: '8862'

   at System.Collections.Hashtable.Insert(Object key, Object nvalue, Boolean add)

   at System.Collections.Hashtable.Add(Object key, Object value)

   at Microsoft.UpdateServices.Internal.ClientImplementation.GetSyncInfo(DataAccess dataAccess, Hashtable stateTable, Hashtable deploymentTable, Boolean haveGroupsChanged, Boolean doChunking)

   at Microsoft.UpdateServices.Internal.ClientImplementation.SoftwareSync(DataAccess dataAccess, UnencryptedCookieData cookieData, Int32[] installedNonLeafUpdateIds, Int32[] leafUpdateIds, Boolean haveGroupsChanged, Boolean expressQuery)

   at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cookie cookie, SyncUpdateParameters parameters)

   at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cookie cookie, SyncUpdateParameters parameters)

   at Microsoft.UpdateServices.Internal.Client.SyncUpdates(Cookie cookie, SyncUpdateParameters parameters)

       <lines removed>

2008-06-14 02:59:57.642 UTC Warning       w3wp.12       SoapUtilities.CreateException     ThrowException: actor = http://wsusebc/ClientWebService/client.asmx, ID=c0a7445f-b989-43fa-ac20-11f8ca65fa8c, ErrorCode=InternalServerError, Message=, Client=?

Root Cause:

A recent revision to the ‘Office 2003 Service Pack 1’ update has resulted in some WSUS 3.0 servers syncing

Workaround:

In order to reset the approvals to a consistent state on the WSUS server, follow these steps from the WSUS Administration Console:

1.       Find the Office 2003 Service Pack 1 update in the updates list, UpdateID: D359F493-0AAD-43FA-AF5C-6763326CD98F. This may involve changing the Status and Approval filters. Set Status to Any and Approval to Declined; if you still do not see the update, set Approval to Any Except Declined.

2.       Perform the following steps:

a.        Ensure the update is already declined.

                                                                                       i.      If the update is not already declined, right-click on the update and then click Decline in the shortcuts menu.

b.       Cause the update not to be declined.

                                                                                       i.            Right-click the update and then click Approve in the shortcuts menu.

                                                                                     ii.            In the Approve Updates dialog that opens, just click OK without making any changes to the approval settings.

c.        Decline the update.

                                                                                       i.       Right-click the update and then click Approve in the shortcuts menu.

                                                                                     ii.       In the Approve Updates dialog that opens, just click OK. Dismiss the Approval Progress dialog that appears.

The computers that were failing detection will now successfully complete detection against the server and receive any applicable updates.

Note: If you have a hierarchy of WSUS servers, these steps must be performed on each server, starting with the top-level server. If one of the servers is a replica child, one must first change it to be autonomous, then perform the steps above, then change it back to being a replica. This can be done from the Options/Update Source and Proxy Server dialog box.

Thank you.

Cecilia Cole

WSUS Program Manager 

Hi all,

If you use Microsoft Office, a great new resource has recently come online to help you understand how Office updates work. The Office Sustained Engineering blog features release announcements, known issues, explanations of update behavior, and other information about Office updates. If you work with Office updates, it’s worth monitoring this page for the latest info, such as the recent announcement that Office 2007 SP1 will be delivered through Automatic Updates starting in mid-June. Check it out!

Cecilia Cole

WSUS Program Manager

Hi everyone,

Windows XP Service Pack 3 (SP3) was made available to Windows Server Update Services this morning, classified as a service pack.  It includes previously released updates and hotfixes to Windows XP and creates a new baseline for servicing.  For more information about what's changed and how to deploy, see the Windows XP Service Pack 3 Overview.

One thing you may be aware of, if you happen to be managing any clients running Microsoft Dynamics Retail Management System, is an incompatibility Microsoft Dynamics RMS has with Windows XP SP3.  To address the problem, we’ve added a filter to help prevent Windows XP SP3 from being installed on clients managed by WSUS and will make a fix available soon (more info here).

-Cecilia Cole

WSUS Program Manager

WSUS Admins;

We’ve seen a little bit of confusion around the specific WSUS behavior with the OGA update.  As most of you know the package is expired, so it’s no longer available to your WSUS servers. Also, not to bore the experts who know this, auto-approval rules don’t apply to updates that require explicit EULA acceptance, which this one does.  Only manual approval and EULA acceptance will have made this update available to your clients, even if you had auto-approval rules applied.

The WSUS team

WSUS Admins:

On April 15^th the Office Genuine Advantage (OGA) notifications update (KB949810) was inadvertently published to WSUS servers for approximately twenty-four hours. This update was intended for Microsoft Office users in the pilot countries of Italy, Spain, Turkey and Chile, but because of WSUS publication, it became available to WSUS managed clients inside and outside of these intended countries.  This update has since been removed from WSUS.  For servers which synchronized the OGA update package, the package required a EULA acceptance before it could be made available to WSUS managed clients, via either manual approval, or auto-approval rules.   OGA notifications are designed to alert customers who are using non-genuine software, and are thus more vulnerable to activation exploits and the risks of counterfeit. As such, this update was marked critical for WSUS.

We are available to offer full assistance if you have problems or questions related to this issue, via your regular support channels.  Customers who want to learn more about OGA notifications can reference the online KB Article.  Customers who require support should submit  a Technical Support Request for Microsoft Genuine Advantage Issues.