Like a boy named Sue, a product named WUS had better know how to defend itself—or else change its name at the earliest opportunity. In the case of Windows Update Services (WUS), Microsoft saw the wisdom in changing the name to Windows Server Update Services. WSUS isn't a creative leap as far as names go, but at least you can get beyond the name and consider the functionality without giggling.
According to our survey for this month's Hey Microsoft! column, whatever the name, WSUS is highly anticipated and will be adopted quickly. However, readers want clarification about the role of WSUS in relation to Microsoft Update and Systems Management Server (SMS) and want to know where support for patching third-party applications fits and how WSUS improves on Software Update Services' (SUS's) reporting capabilities and distribution and management options.
Survey Findings
Of the 578 respondents to this month's survey, 51.2 percent use SUS and 48.8 percent don't. Reasons for not using SUS include
|
Many readers don't use SUS simply because they're waiting for WSUS. Nearly two-thirds of respondents (62.1 percent) plan to implement WSUS. Only 12.4 percent said they don't plan to implement it, and 25.5 percent aren't sure. When asked "What would prevent you from implementing WSUS," many readers say they wouldn't deploy it if Microsoft starts charging for the product. Those who do plan to deploy it want to do so quickly: about 62 percent within 3 months of its release, 27 percent within 6 months, 3 percent within 9 months, and 8 percent within a year.
These findings, and the numerous comments and questions the survey generated, speak to the pressing need for patch management solutions. Many readers just want Microsoft to hurry up and release WSUS—one reader commented that the most important aspect of WSUS is "its release—only 2.5 years late." Now that WSUS is finally here, I took readers' questions and concerns to Microsoft's Joseph Dadzie (group program manager, Software Distribution Technologies) and Jason Leznek (senior product manager, Windows and Enterprise Management Division).
WSUS, Windows Update, Microsoft Update, SMS
With WSUS, Microsoft also released Microsoft Update. Previously, Jason explained, Microsoft had "Windows Update (which updates only Windows), Office Update, and the Download Center. Microsoft Update is now the centralized information source that WSUS will pull from. Microsoft Update and WSUS support updates for Windows Server, Exchange, SQL Server, Office, client SKUs (i.e., Windows XP, Windows 2000, 64-bit versions), and MSDE. Additional Microsoft products will be supported over time."
Joseph added, "There will still be Windows Update and Office Update, but if you get updates from Microsoft Update, you don't need to go to the individual update sites. Microsoft Update is a sum of those other services, not necessarily a replacement."
Microsoft's patch management strategy has several layers, roughly corresponding to business size. Some readers asked questions such as, "How does Microsoft position WSUS vs. SMS—as complementary or competitive?" I asked Joseph and Jason to explain how the patch technologies fit together.
"The sweet spot for WSUS is the mid-market to the enterprise space," Jason said. "SMS is for the large enterprise. If you're just looking for update components, WSUS is right. If you need remote control and software distribution, SMS is for you."
Joseph agreed. "SMS does update management, but it also does complete software distribution of just about any type of application—OS distribution, imaging, inventory, etc."
Jason continued, "We need to clarify when to use which. I've been working on the messaging between WSUS and SMS, so we have some content on the Web that describes the feature sets."
Joseph added, "There's another dimension. Namely, WSUS doesn't support distribution of patches of third-party products. So if you have that need, SMS is what you want."
When I asked for details about how Microsoft secures the information transfer for patching, Joseph replied, "We document our security precautions in the Windows Server Update Services Deployment Guide's 'Secure Your WSUS Deployment' section."
Reporting
Readers' biggest complaint about SUS was that it provides no reporting, so you don't know whether the update was successful. Joseph is aware of this concern. Reporting "was probably our number one piece of feedback. Customers wanted easy-to-digest reports. So we focused on reports such as how many computers have installed the patch. Also, APIs on the server let you export data into XML or a comma-delimited file or whatever you want. We also have an update status report. You can look at reports based on a computer or aggregate of computers, or by update or aggregate of updates. You can get a global view, dig into a particular update, or see how well a patch is doing. One report provides a high-level view of your environment. In addition, the home page of the console gives basic information around how many machines or patches have errors, so you don't have to dig through a lot of data."
Distribution and Management
One typical respondent asked, "How granular will updates be? I'd like to pick specific updates to apply to different machines."
Joseph replied, "We added classifications: security updates, critical updates, service packs, regular updates, drivers, etc. The default configuration delivers the security and critical classifications. If you don't want to download a service pack, for example, you can choose not to bring that classification down to your server."
He continued, "To determine which machines need a patch before you deploy it, we added Auto Approval Options, which let administrators automatically approve updates for detection. By default, when critical and security patches come in, they are automatically approved for detection. The client PCs don't download the patches; they just do a scan against the patch information and report up to the server. This way, you can quickly see how many machines need this patch and decide whether to act. It's reporting to help guide decisions."
Another question was "How can we limit the patches/updates WSUS downloads from Microsoft? For example, we certainly don't need all the language packs."
Joseph replied, "We've separated the metadata from the binary, or compressed cabinet format (CAB), files downloaded for a patch. Metadata includes conditions under which the patch applies, the patch's title, and so on. The default configuration only brings metadata down to the server. We can use the metadata to detect where the patch is needed, and only when you approve the patch do we bring the files down from Microsoft. If you don't need the Chinese language pack, don't approve it, and it never gets downloaded."
Other readers wondered whether they could uninstall a patch that WSUS has distributed. Joseph admitted, "That's tricky. If a patch supports 'uninstall remotely,' WSUS will support it. Unfortunately, several Windows patches today do not support 'uninstall remotely' because there's an issue with order of installation of the patches. Even on the local machine, if you try to uninstall the patch, it says, 'Hey, these 10 things that you've installed since that patch may have a problem.' Some patches that are .msi-based will be uninstallable (and even the Windows ones, moving forward) as we improve the installation technology."
An important point came up in response to questions such as, "Why didn't you make client-side setup easier? I have implemented the proper Group Policy Objects (GPOs), and the clients still don't poll the WSUS server."
Joseph revealed, "We got feedback on that during the beta. Most cases involved misconfiguration. If you had a SUS server or some other application on the same box using port 80, we tried to put it on a different port (port 8530) to eliminate conflict. When people configured Group Policy to talk to the server, they sometimes forgot the port number. Also, in the beta, we required a manual step to enable self-update on port 80, and people missed that step. In the release candidate, we automatically enable self-update on port 80 so clients automatically update the next time they check with the server. And we now have a client troubleshooting tool that checks the configuration of your ports."
Joseph has some tips for this problem: "First, run Resultant Set of Policy (RSoP) on the client to see what policies are getting down to it. Is your server configured to run on port 80 or port 8530? SUS had different policy entries for the reporting server and the update server. Sometimes people misconfigured them. So WSUS configures only the update server, and when you run the client troubleshooting tool it tells you your configuration, policy settings for reporting, and whether resources match your client version."
A SUS of a Different Color?
Does WSUS live up to your hopes? In my conversations with product teams, I've found that some really care about customer feedback and some just go through the motions. I felt that Joseph and the WSUS team really care and try hard to address user concerns. Do you agree?
