Microsoft is developing a long-term plan to unify the process of installing various software updates across its product groups.
The initiative, which one Microsoft executive said will be unveiled later this year, will undoubtedly please IT administrators who struggle to evaluate the multitudes of missives they receive from the different Redmond engineering groups responsible for preparing patches for customers.
In addition, William Anderson, lead product manager for the company's Management Business Group, said Microsoft is working to name classifications in order to make its terms more clear. That way customers will have a better idea of what content they are getting.
Microsoft declined to provide additional details about the initiative.
Today customers receive hot fixes, service packs, service releases, critical updates and patches, and there is no way to know exactly what is included in each release because they come from different engineering groups across Microsoft, which does not use a standard method for identifying the content.
"We throw these terms around -- we live in them every day," Anderson said. "It's a good process to go through. How can we better make it clear? What is a critical update versus an update, versus a new feature?"
Sometimes customers find that even installing a fix can be a chore because of the differences across the product groups.
"From the Windows group to SMS and Exchange, a fix is not a fix," said Michael Niehous, an IT consultant at Marathon Oil. "They all don't register themselves to the system."
Anderson said that Microsoft's approach -- letting each division update its products independently -- has enabled the company to provide the best updating model for the unique needs of each product and customer.
However, the company recognizes that these differences also cause confusion for customers who must routinely apply updates across their enterprises, Anderson said. By unifying the installation process across all product lines, customers will have a more predictable and consistent experience in managing all of their Microsoft products.
Today each Microsoft engineering group independently runs patches through their paces -- checking for reliability and stability -- before posting for customers. Microsoft tests its patches against the various permutations of Windows, but it's the customer's job to test each update in the enterprise.
IT administrators, who have enough to do without worrying about fixes, must decide quickly whether they need a patch, whether it's something they can set aside because it's not important, or whether it's something that could crash a legacy application.
Even using some of the new tools to check updates can be problematic. Microsoft has some excellent tools: Software Update Services (SUS) dispenses updates to the Windows platform, and the Baseline Security Analyzer and HFNetChk identify misconfigurations and scan for missing hot fixes.
But these tools often provide conflicting answers, because there is no consistent metabase among tools, said Peter Pawlak, an analyst at Directions on Microsoft, a Kirkland, Wash., consulting firm. So even if tools are looking for the same or similar things, they won't necessarily be able to find them because they don't share the same directories of information.
"So people are complaining that they don't know what they have or why they would need something," Pawlak said.
Today Microsoft has a recommended patch-management strategy for its customers. For basic security patch management, the company recommends that most mid-sized enterprises (with a workgroup consisting of a couple hundred nodes or so) use SUS. But it works best only where there are neither many business processes nor much workflow.
And there's a hitch. SUS can be used only on Windows 2000 and XP, and it only handles Windows content.
Any enterprise with a more complex environment must move up to full-blown system management software such as Systems Management Server (SMS), which supports all platforms and dispenses all forms of content. The public beta trial of SMS 3.0 should begin within weeks, Anderson said.
There is another way to ship updates across the enterprise -- by using the Group Policy feature in Active Directory. This method is limited in the same way as SUS in that platforms need to be 100% Windows 2000 or XP. The IT shop needs Active Directory, of course, and content must be in Microsoft Software Installation (MSI) format.