People, Process and Technology sometimes collide

re: People, Process and Technology sometimes collide

Trevor Kellaway — Mon, 09 Apr 2007 23:42:39 GMT

Keith,

WSUS fail-over to a public server assumes that the same patches are released on both.

Many organizations might not want all MS releases available to end users (e.g. internal testing finds a patch kills an application), therefore letting them lose on the public server via fail-over defeats this.

Of course, working for MS you don't have this problem ;)

re: People, Process and Technology sometimes collide

Keith Combs — Mon, 09 Apr 2007 23:52:56 GMT

Yea, I know. That's the dilemma. WSUS is great for patch testing and approval. Where I got caught was the VPN quarantine check and the GPO update.

Since I was behind on updates, VPN quarantine said I could not pass go and connect to corpnet. And the GPO said I could only connect to a corpnet update server.

Of course, this would not have happened if Windows Server "Longhorn" Network Access Protection (NAP) was fully deployed. If NAP was controlling the network policies, then it would have spotted my machine was not compliant then send me over to a group of remediation servers. Since NAP isn't fully rolled out yet, I didn't get that benefit.

re: People, Process and Technology sometimes collide

Gerard van der Land — Tue, 10 Apr 2007 18:53:10 GMT

We ran in to the similar problem with people using company Windows Vista notebooks while working at customers for longer periods of time with no possibility to use VPN: they would always get this error for not being able to contact our internal WSUS server. For this reason we are considering publishing our WSUS server through ISA Server on a public URL and specifying that URL in the Group Policy (internally redirecting it to the internal server using split DNS), so that we can still push updates to those users.

Another problem was that until recently the Windows Vista Ultimate Extra's were not published on WSUS, which meant that some users running this OS edition would remove our internal server from the registry keys so they could get them from the Microsoft Update Service.

This upcoming change in the Windows Vista sort of brings us back to the situation in Windows XP where users could use IE to browse to Windows Update or Microsoft Update and download and install updates that we had not approved in WSUS (yet). Afterall, part of the point of using WSUS is that the company IT department can control what gets installed on our notebooks. I sure do hope that there will be a Group Policy setting to disable the "Check online for updates for Microsoft Update Service" option, or that we can configure that it should only allow this when the user is not on the domain, and that we can configure what kind of updates can be installed this way (so similar to how we have configured WSUS to auto-approve Security and Definition Updates, we may want users to only be able to those two specific types of updates from Microsoft Update Service, and not for instance, drivers and service packs).

re: People, Process and Technology sometimes collide

Keith Combs — Tue, 10 Apr 2007 19:24:28 GMT

Control is key in many environments. I agree it's prudent to test new updates and verify they don't break other mission critical apps.

Remediation is key. Publishing part of your WSUS server environment is one solution. NAP will be another.

I'll check to see what GPO blocks are available in WinxP and Windows Vista to prevent getting updates from the public download catalogs and update.microsoft.com servers.

How do you notify users of updates?

Keith Combs' Blahg — Thu, 19 Apr 2007 23:42:31 GMT

As you'll recall, I posted some information about the Microsoft IT organizations implementation of WSUS