Windows Enterprise Desktop


October 9, 2008  9:10 PM

The Application Compatibility Check Process a la Microsoft

Ed Tittel Ed Tittel Profile: Ed Tittel

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:

  1. Collect information about current applications in use.
  2. Prioritize and rationalize applications worth testing for compatibility, and supporting after Vista deployment.
  3. Test a finalized list of applications in priority order as need dictates, and resources permit.
  4. 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

October 8, 2008  6:46 PM

Managing Application Compatibility for Windows Vista

Ed Tittel Ed Tittel Profile: Ed Tittel
HTTP

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:

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
%systemroot%\System32\mshta.exe res://acprgwiz.dll/compatmode.hta
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.


October 6, 2008  3:23 PM

Dealing with Failed Windows Updates

Ed Tittel Ed Tittel Profile: Ed Tittel
HTTP

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:

  • http://*.update.microsoft.com
  • https://*.update.microsoft.com
  • http://download.windowsupdate.com

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).

Stay tuned!

–Ed–


October 3, 2008  6:45 PM

Windows Vista Upgrade Advisor Provides Basic HW Assessments

Ed Tittel Ed Tittel Profile: Ed Tittel

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.

Successful Windows Vista Upgrade Advisor Scan

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

Report Details on System Issues

2. Potential Device Issues

Device warnings

3. Potential Software Issues

Warnings about installed software

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.


October 1, 2008  9:53 PM

Mighty Mark’s Vista Troubleshooting Tour

Ed Tittel Ed Tittel Profile: Ed Tittel
HTTP

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.


September 29, 2008  7:32 PM

Welcome to Vista Enterprise Desktop

Ed Tittel Ed Tittel Profile: Ed Tittel
HTTP

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 edtittel@techtarget.com.

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.

–Ed–


Forgot Password

No problem! Submit your e-mail address below. We'll send you an e-mail containing your password.

Your password has been sent to: