Normally, Microsoft reserves its security patches, fixes, updates, and other software tweaks and maneuvers for the second Tuesday in each month, aka “Patch Tuesday.” Yesterday afternoon I was somewhat surprised to see various sources trumpeting the release of an out-of-schedule security patch through Windows Update on the fourth Thursday in October.
As described in Knowledge Base article 958644 and MS Security Bulletin MS08-067, this update addresses a vulnerability in the Windows Server service. The Server service is a critical portion in any modern Windows OS that responds to incoming network communication requests; it has been part of the Windows kernel since the LAN Manager days. In fact, this service is called the LAN Manager Server in the “Server service configuration and tuning” article (KB 128167). It’s also managed via a Registry key named LanmanServer in the HKLM\SYSTEM\CurrentControlSet\Services sub-tree.
In short, the Server service is so entrenched in Windows operating systems that even Windows Server 2008 installations that lack a GUI–the so-called “Server Core” minimalist version–can fall prey to this vulnerability. That explains why every Windows OS from Server 2008 and Vista, to Windows XP, Windows Server 2003, and Windows 2000, in 64- and 32-bit flavors, and server and workstation versions, where applicable, is included in this security update.
Why all this hoopla? According to Brian Livingston’s Windows Secrets Newsletter, “this is the first time in 1-1/2 years that Microsoft has released an emergency fix outside of its montly Patch Tuesday cycle.” The reason is that Microsoft discovered an RPC (remote procedure call) attack that could propagate around internal networks and the Internet with no user action needed to help it spread. Modern versions of Windows that predate User Account Control (UAC), such as XP, Windows Server 2003, and all flavors of Windows 2000, are especially susceptible to this vulnerability. At the same time, most AV vendors have also released updates to defend against this kind of attack, but Livingston’s newsletter reports “there are already nine different strains of viruses” that seek to exploit this vulnerability.
As with other patches that replace kernel files, Windows will request you to restart your PC after the patch is installed. In writing the story on this RPC vulnerability for the Windows Secrets Newsletter, writer Susan Bradley also urges administrators and users to reboot their PCs before installing the patch, just to make doubly darn sure the machine will reboot properly once the patch has been installed (the update process requires a successful restart/reboot for the patch to be completely and properly applied). Then when you reboot the machine after installation, you can be reasonably sure it will complete the installation process following a second successful restart.
If you haven’t already installed this patch, please do so now. It only replaces a single Windows file–namely Netapi32.dll–and is therefore unlikely to cause any incompatibility problems, either for server or desktop machines.
Like it or not, sometimes applications wind up on Vista desktops that have to go. Either they’ve been replaced with something different, newer, or better, or they never should have been there in the first place. Count yourself lucky if a program’s uninstall utility does a thorough job of removing its traces from the file system, the desktop, and the Windows registry. My own informal testing with hundreds of Vista apps indicates that about every other one does a decent or better job of cleaning up after itself, with no additional clean-up required. That’s not lucky enough to justify buying a lottery ticket, in other words, but it is lucky enough to guess “Heads or tails?” in a friendly coin toss.
What to do when applications leave detritus behind? This can include orphaned icons, orphaned file associations, files and folders in the
%SystemDrive%\Program Files folder, and all kinds of odd and interesting leftovers in the Windows registry. Occasionally, you may even finder helper or support applications left behind (such as various types of viewers, players, or other software the program uses to display certain files, but may not remove from your system even though it cleans up its own code quite nicely), and so forth. The answer to this dilemma depends on which installer the program uses, and what kinds of tools you’ve got at your disposal.
Let me mention two particular items of interest in this context:
- Revo Uninstaller
A free, handy, and quite usable tool that even offers various levels of post-vendor-uninstall-cleanup for you to choose. Basically, you use this tool to launch a program’s built-in uninstaller from inside this program. Revo Uninstaller watches what that program does, then checks the file system and the registry for you to remove additional remaining traces after the built-in program does its job. I’ve been using it for a couple of years now, and it’s a capable and well-maintained tool (they post updates on a regular basis, sometimes as often as once or twice a month). Grab it at www.revouninstaller.com. For a more complete review of this tool see my recent article “Should Software Makers Clean Up After Themselves?“
- Windows Installer Cleanup Utility
This tool comes from Microsoft, the same folks who created the Windows Installer, and the most likely party to use this tool for installing software (though you do find a fair number of third-party utilities that do likewise). It only works with programs that use the Windows Installer to install themselves, but it is able to clean up after incomplete or failed installs that originate with that tool. MS Help and Support provides information about and access to this tool in their “Description of the Windows Installer Cleanup Utility” article (KB290301). Please note that this tool will not clean up mangled Microsoft Office 2007 installs, and if the Windows registry’s Windows Installer configuration management data gets munged, you may be likewise out of luck.
If you run into problems or issues with these tools, there are plenty of commercial uninstaller programs that work on Vista. Fortunately for my own Vista machines, I’ve yet to encounter an uninstall problem that one or the other of these tools can’t handle. That said, if you have any experience or favorites you’d like to share, please post a comment to this blog and let us all know. I’ll keep an eye out, and review such items as attract glowing mention and my own fancy.
I recently stumbled across a hitherto unknown gem inside Windows Vista–to me, anyway. It’s called a “System Health Report” and it provides a pretty comprehensive view of a Vista system’s state, status, and current behavior. To my surprise it comes from the same facilities that support the System Reliability Monitor (see my blog “My Love-Hate Relationship with System Reliability Monitor” for my take on this built-in Vista facility) and generates a report on all major components and subsystems on the Vista PC it targets.
Here’s how to launch this facility:
- Click Start, type Performance into the Vista search box, then select Performance Information and Tools.
- Click Advanced Tools in the left panel.
- Click Generate a system health report.
At first, you’ll see a display that lets you know the program is gathering data
Once the data-gathering phase is complete, you’ll see an overview report appear instead. It offers details in a number of areas, including Diagnostic Results, Software and Hardware Configuration, and details for CPU, Network, Disk, and Memory, as well as Report Statistics. The overview report looks pretty innocuous, but you can click the arrow to the right that’s associated with any item on the left to start digging into the details.
Here, you can see the various warnings that my Vista machine collected as I ran this report. These reflect my having turned User Account Control (UAC) off on this machine, and the interesting failure of Spyware Doctor with Antivirus to register either of those components–antivirus and antispyware, that is–with the Microsoft Security Center on this machine. In this case the former is a deliberate choice, and the latter a known issue (though Spyware Doctor maintains updated signatures and software as it’s supposed to, so there’s no real cause for concern here).
If you manage a large number of Vista desktops, you may be interested to learn that this facility dovetails with products that include System Management Server or System Center Essentials to enable daily health reports to be e-mailed from each machine to a mailbox for subsequent analysis and review.
For some more good information on working with this facility in Vista, see “Scenario 6: View a diagnosis report” in the Windows Vista Performance and Reliability Monitoring Step-by-Step Guide on TechNet.
For the next couple of weeks, I’ll be digging into issues related to application compatibility for organizations and enterprises considering the move to Windows Vista. For such outfits, one of the most important and pressing concerns that surround a migration has to be application compatibility, which should perhaps be pithily restated as “Will my apps work with Vista?”
Microsoft is keenly aware of this potential hurdle, and has devoted considerable time, energy, and resources to creating tools, guides, and processes for assessing application compatibility. In some upcoming blogs, I’ll take a closer look at that company’s Application Compatibility Toolkit 5.0, aka ACT. In this blog, I begin the overall process of assessing application compatibility by describing that process as Microsoft sees it, and pointing to some papers, resources, and how-to’s that the company has put together to help companies and organizations see their way through it. Much of the information you’ll find here, in fact, is summarized from the company’s paper entitled “Getting Started with Application Compatibility in a Windows Deployment” (PDF document, 301KB).
In a nutshell, the process works like this:
- Collect information about current applications in use.
- Prioritize and rationalize applications worth testing for compatibility, and supporting after Vista deployment.
- Test a finalized list of applications in priority order as need dictates, and resources permit.
- Mitigate issues to make applications workable or replace them as necessary (Or as MS puts it: “remediate, upgrade, mitigate, retire”).
Centrally managed environments that have established standard desktop configurations and that control the applications allowed to run on those desktops will have the easiest time of the inventory stage. ACT includes an inventory tool, in fact, for environments that don’t already maintain one (such as Microsoft Desktop Optimization Pack for Software Assurance, Microsoft System Center Configuration Manager 2007, or SMS 2003). The idea is to put together a comprehensive list of every application and version in use on enterprise desktops.
The next step, which MS delicately labels “prioritize and rationalize” is the tricky one. This really means choosing standard versions for apps in use across multiple versions (what MS calls “application relevancy”). It also means choosing a single app when more than one is used to do the same job (such as multiple productivity suites, video editing tools, and so forth; MS calls this “application redundancy”). Finally, it means getting rid of unauthorized applications or those that, as MS puts it, “are irrelevant to the day-to-day work being done in your organization.”
After the winnowing process is done, there will be fewer applications to deal with. This is the point at which prioritization occurs, based on the relative importance of the remaining applications within your organization. Often, this means tossing names into buckets that might be labeled:
- Business Critical: essential to ongoing business operations. SLA response
- High Priority: perform vital roles in some departments or across the organization. SLA response
- Important: used frequently but won’t cause work stoppages if it fails. SLA response
- Optional: Approved applications in limited use not directly related to business functions. Not covered by SLA, and receive “best-effort” IT response.
The categorization process also involves identifying applications essential for business or operations to proceed, and for typical job roles to be enacted. Prioritization within buckets requires management buy-in and means tackling items from the top down, once there’s agreement on what’s on top, and how items are ordered from there.
Next comes application testing, which is where you’ll decide which applications can be made to work, and which ones may need to be retired and replaced. Ultimately, the idea is to work toward a collection of software components that get the necessary work done and that also work properly with Vista. More on this in my next blog!
For more ACT resources, check out
Just Released: Application Compatibility Toolkit (ACT)5.0.3
ACT 5.0 Deployment Guide
ACT 5.0 Step by Step Guides
TechNet Webcast: Making Windows Vista Application Compatibility Testing More Predictable
Webcast: Debugging for Application Compatibility Issues with Chris Jackson (interested readers should also check out Jackson’s Blog)
Windows Vista Application Compatibility Training Recordings
In a perfect world, IT professionals wouldn’t have to worry about application compatibility issues: everybody would already have embraced the latest versions of Visual Studio (2008) and the .NET Framework (3.5), and all code would run on Vista seamlessly and unhindered. Yeah, right! In the real world, however, all kinds of interesting code still runs, and needs to keep running, be it orphaned, legacy, unsupported, or whatever other trouble-making adjectives might apply to same. All of this conspires to make Application Compatibility a real concern for Windows Vista administrators, if not something of a “dirty word” to that doughty community. In my next series of upcoming blogs, I intend to dig into this subject from a number of different points of view, and examine some important tools and resources available to Vista admins to help them tackle and handle the sometimes tricky tasks of assessing, testing, and where possible, forcing applications to work properly on Vista desktops.
To kick off this discussion, I want to point at a Web page in the Microsoft Technet Windows Client TechCenter. It’s entitled “Application Compatibility and User Account Control” and provides all kinds of tools, information, and material to help IT professionals and managers deal with application compatibility issues at all conceivable levels.
The key resources portion of this page itemizes some interesting elements, some of which I’ll cover in more detail in upcoming blogs:
- the Microsoft Application Compatibility Toolkit (ACT)
- the Windows Vista Compatibility Center (covers both hardware and software, in fact)
- the Application Compatibility Factory (ACF)
You’ll also find some fascinating discussions of “software shims” (small bits of custom-crafted software designed to fit between (older) applications and (newer) operating systems) in a paper called Managing Shims in the Enterprise with an accompanying Stock Viewer Shim Demo Application.
As you deal with application compatibilty issues with Windows Vista, don’t forget its own built-in Program Compatibility wizard (you can launch this by typing
at the command line). This lets you select a program target, then choose from a list of other Windows versions that Vista can emulate (Windows 95, Windows NT 4.0 SP5, Windows 98/Me, Windows 2000, Windows XP SP2, and Windows Server 2003 SP1), select a display mode, run with administrator privileges, to see if it works as needed or not. Only if you exhaust the various possibilities that this Wizard offers without solving your compatibility problems, should you dig into the other topics I’ll cover in my upcoming blogs on more advanced applications compatibility topics and tools.
Even in enterprise situations where IT professionals will disable Windows Update on desktop and server machines, in favor of staging updates to test machines in the background, and using their own deployment tools and techniques to roll them out, there will be occasional problems in downloading or installing updates from the Windows Update servers. I’ve learned two valuable techniques to help overcome these problems as and when they occur.
Unable to Access the Windows Update Server
After a clean Vista install, and after installing Service Packs on reference builds, you will occasionally encounter an error message that reads “Windows Update Error 87002EE2: Unable to access Windows Update.” The help link that accompanies this error information includes lots of potentially useful information to help resolve the various possible causes for this error, but I’ve observed that adding the following URLs to the Trusted Sites list in Internet Explorer usually resolves this problem:
Please consult KB836941 for more information and troubleshooting tips for this situation.
When individual updates fail to install automatically, look for standalone installer versions
Discriminating admins will notice that all Windows Updates make reference to related Microsoft Knowledge Base articles, in a form that looks like KB, where is a 6-digit number. Invariably, digging up the relevant article will also include a link to the Microsoft Standalone Installer version of the same update that Windows Update delivers in slightly different binary form. Simply by inserting the six-digit KB article number into this string should take you right to that document: http:/support.microsoft.com/kb//en-us (replace with the actual number).
In most cases, you can package up the self-installing update for deployment to client machines after you’ve tested and approved it for general release. It will need to be embedded inside a script to force the installer to run, but this shouldn’t present too many difficulties (I’ll cover this activity in another upcoming blog).
In enterprise environments, desktop hardware configurations tend to be standardized, and are usually limited to at most a handful of different setups that will be deployed for various job tasks or roles. For companies and organizations considering a move to Windows Vista for those machines it might be wise to download, install, and run the Windows Vista Upgrade Advisor on sample machines that match deployed configurations.
The program comes packaged in a 6.6 MB file named WindowsVistaUpgradeAdvisor.msi, and sets itself up using the standard Windows Installer. Typical installation time is under two minutes, and the program requires Windows XP SP2 or better (it also works with Windows Vista; I checked). Other supporting software elements that must be present include .NET Framework 1.1 or newer, and MSXML 4.0 or better. Installing the program is a snap and simply demands clicking through a handful of screens to accept a EULA, selecting a target directory, then managing startup and desktop icon options.
When you install and run the program on a target machine, it will usually take at least a couple of minutes to complete. In the background the software is enumerating all devices and software on that machine, and comparing them to a database of Vista compatible (and incompatible) items. The best possible outcome for the scan is depicted in the next screenshot.
Of course, this resulted from a put-up job deliberately designed to pass with flying colors. On an older more typical desktop running Windows XP SP3 with 2 GB RAM, Sempron 3200+ CPU, and integrated graphics, the results were a bit less exhilarating: warnings showed up in all three categories that the Upgrade Advisor checks: System (the computer system itself), Device (adapter cards, drives, and other devices inside the PC), and Program (software running on the target machine). The next three screenshots illustrate each of these reports from the Upgrade Advisor.
1. Potential System Issues
2. Potential Device Issues
3. Potential Software Issues
Investigating Potential Issues
When it comes to dealing with the items reported in the Upgrade Advisor’s detail sections, it’s important to formulate a strategy for accommodating or overcoming those results. For example, if users don’t need the Vista Aero theme and its graphics razzle-dazzle, upgraded machines can be configured using Sysprep or some other image construction and deployment tool to turn off that resource-intensive capability. On the other hand, for users that need more capable graphics performance, one could replace an existing graphics adapter or (as would be the case for this test target platform) install a graphics card thereby disabling its older and less capable integrated graphics. The same type of approach generally holds true for both devices and software, with the possible exception of legacy or custom appliications that users simply must run. For such items, if all else fails, remember that you can install older Windows operating systems in Virtual Machines (VMs) running inside Windows Vista, as a next-to-last resort for keeping such items operational (the last resort is to set up a server or target machines elsewhere on the network that Vista users can remote access into).
A Grain of Salt Applies to the Upgrade Advisor’s Advice
The target XP machine on which I chose to run the Upgrade Advisor gets a suprisingly clean bill of health from the software. My own experience has been that Vista runs best on a dual-core processor or better, works best with at least 2 GB of RAM, and requires an Nvidia 7600 or AMD/ATI 2400 graphics card or better, for even minimal and acceptable use. It’s important to bear such observations in mind when pondering how to react to the Upgrade Advisor’s reports and recommendations. Otherwise, end-users may wind up with painfully slow desktop systems. Once you’ve decided on an upgrade strategy, it’s probably wise to upgrade a small group of machines, place them with a hand-picked set of at least moderately knowledgeable users, and let them try out the new gear for two to four weeks, then evaluate those results and react to them, before performing any wholesale upgrades. Otherwise, one wave of effort and expense may simply lead to another, along with a sizable group of end-users in various states of disarray and disaffection.
For today’s blog, I take great delight in referencing a true Windows luminary’s similar efforts at Microsoft. I’m talking about Mark Russinovich, who continues his efforts with Sysinternals tools and utilities, and anything else that catches his considerable fancy, under the Microsoft umbrella. For those not familiar with Mark’s fabulous skills and abilities, let me observe that he’s the author of the best book on Windows Internals ever written (due in a fifth edition in January 2008, with an exclusive focus on Vista and Windows Server 2008), and a former principal in Sysinternals/Winternals, a company devoted to crafting really great Windows tools and utilities. In a rare and perhaps unequaled display of corporate good sense, Microsoft bought Sysinternals/Winternals in 2005, and continues to make the free Sysinternals software available on their Web pages.
In Mark’s latest blog entitled “The Case of the Sloooooow System,” he delivers a tour-de-force demo of the great Sysinternals tool known as Process Explorer. This nifty tool not only shows you what processes are active on your Windows PC, a la Task Manager’s Processes tab, it also shows you which execution threads belong to those processes, and even lets you suspend them temporarily, thanks to a handy right-click menu facility.
In this troubleshooting exercise, Russinovich makes use of Process Explorer to identify a problem that drags his wife’s Vista desktop into the weeds, performance-wise. He immediately sees that two processes are consuming 100% of the CPU resources between them. Because she’s got a dual-core CPU, each one grabs one of those cores for its exclusive use, thereby freezing out all the other processes (and threads) that want to run on the system. A little quick sleuthing shows that some browser helper object (BHO) is sucking up all the cycles on one core within Iexplore.exe (the process name for Internet Explorer), and that a COM services DLL named Dllhost.exe is doing likewise for the other core.
In the course of identifying his troubles and trying to determine what’s at fault, Russinovich not only shows how to make inspired use of Process Explorer, he also provides some really great information about — you guessed it — Windows internals. He takes us on a journey from Internet Explorer, to one of its specific tabs, and then into the Thread Stack to show us that something about Adobe Flash is hogging that CPU core. For this, there proves to be no obvious fix: no patches, updates, or replacements for the version that’s already running on the machine. The other cycle sucker gets traced back to Roxio Creator, and for this one he does find an update (not yet advertised on Windows Update or via the Creator auto-update functions) that appears to fix the problem. He downloads and installs the update, and does away with one out of two of the problems.
His final assessment of the situation is worth the price of admission all by itself: “My wife’s system was now usable again, and though I wasn’t able to close the Flash-related part of the case, at least I knew the cause and could keep an eye out for updates. More importantly, by solving the Dllhost part of the case, even if Flash went crazy again, her system would still be usable and she wouldn’t be filing a critical support incident for it with me – thanks to Process Explorer and Process Monitor.”
Like any great performance it looks obvious, elegant, and effortless. Only those of us who’ve spent hours trying to troubleshoot runtime gotchas know how much and what kind of experience is necessary to develop such mastery. If you aren’t already familiar with the great Sysinternals toolset, type www.microsoft.com/sysinternals/ into your Web browser and do some spelunking. You’ll be sure to find some cool stuff, and possibly some great tools you won’t be able to live without a moment longer. You’ll probably want to grab Process Explorer, but be sure to check out the PSTools grab-bag as well.
Dear Interested Reader
This the first post to a three-times-a-week blog that will tackle Windows Vista desktop issues for the enterprise environment. My primary areas of focus will include topics of interest to IT professionals work with Windows Vista on large networks. Thus, it will address topics related to setup and configuration, release definition, deployment, migration from earlier Windows desktops (primarily XP), virtualization, terminal services, and security. I hope you’ll want to contribute your own ideas, issues, and information needs in the comments you can append to these blogs, or send to me via e-mail at firstname.lastname@example.org.
Here’s a list of topics I already have lined up to tackle. Feel free to help me adjust, add to, or remove elements as you see fit:
Checking upgrade viability with the Vista Upgrade Advisor
Dealing with failed Microsoft Updates
Managing Vista application compatibility (general)
Using the Vista Application Compatibility Toolkit (ACT) 5.0
Choosing compatible security software components (firewall, AV, anti-spyware, …)
Toward a more positive Vista application uninstall experience
Software as a Service (SaaS) on Vista: setup and configuration
Software as a Service (SaaS) on Vista: updates and maintenance
Software as a Service (SaaS) on Vista: uninstalls and changeovers
Vista changeover issues/Ensuring a smooth Vista transition
Working with the User State Migration tool
Vista deployment tools:
Volume Activation 2.0
Volume Activation Management Tool
Key Management Service for Windows Server
Windows Automated Installation Kit (WAIK)
Windows System Image Manager (Windows SIM)
Working with answer files and unattended installs
Working with catalogs and Windows images
Using the Windows Preinstallation Environment (Windows PE)
Working with ImageX
Working with the System Preparation Tool (Sysprep)
About IE8: what’s new, different, and better
About IE8: working with the preview
Desktop virtualization benefits
Understanding desktop virtualization technology: virtual machines
Understanding desktop virtualization technology: virtual networks
Understanding desktop virtualization technology: virtual devices and their interfaces
Desktop virtualization tools: VirtualPC 2007
Desktop virtualization tools: VMWare
More Desktop Virtualization tools
Terminal services and Windows Vista
VPNs and Windows Vista
Enterprise desktop endpoint security
I also plan to share troubleshooting information that my own day-to-day adventures with Vista end up teaching me (often the hard way), and to help others research and address issues they choose to raise through comments here, or e-mails to me. Hopefully, we’ll all learn a few things along the way. At the barest minimum, which I hope to exceed by a wide margin, you’ll get exposure to the wealth of material that Microsoft itself provides about Vista on TechNet and in its Help and Support pages and forums.
Thanks in advance for your interest, support, and participation. Look for my first “real blog” on Wednesday, October 2. Please also check out my Website at www.viztaview.com, where you can get a good sense of the issues and problems I’ve been chasing down with Vista myself lately as well.