Microsoft Update failure

I’ve been building a Windows XP virtual machine for test purposes and needed to apply the latest updates (even with Windows XP service pack 3 it required over 20 updates to be applied). Unfortunately, Microsoft Update hit a problem and refused to install some of the updates, telling me that “a problem on your computer is preventing updates from being downloaded or installed“. I tried disabling my anti-virus software (AVG Free) but that made no difference.

Microsoft Update: Failed Updates

Microsoft’s advice is to re-register a number of DLLs using the following commands:

regsvr32 wuapi.dll
regsvr32 wuaueng.dll
regsvr32 wuaueng1.dll
regsvr32 wucltui.dll
regsvr32 wups.dll
regsvr32 wups2.dll
regsvr32 wuweb.dll

For each successful registration, Windows should return “DllRegisterServer in filename.dll succeeded” but wucltui.dll didn’t seem to exist on my system. Even so, after re-registering the remaining DLLs, Microsoft Update successfully installed the problem updates.

I hate long goodbyes

Before I go any further, let me set one thing straight… for the majority of Microsoft’s enterprise customers, there are very few reasons why Windows XP should be deployed on new PCs in preference to Windows Vista.

Vista has now been available to enterprises for over a year and a half, has long since passed the first service pack release, and many of the initial difficulties are now resolved. It’s not perfect, but very few software products are. For that matter, neither is Windows XP (nor for that matter are Mac OS X or the various Linux distributions).

Sadly, for Microsoft, the general perception of Windows Vista is not a good one. Ask anybody who ran Vista from day 1 and they will have stories of the problems that they have had because ISVs and IHVs were too slow to update their applications and device drivers (hey, they only had 5 years notice…). But ask the same question from anybody who waited a few months and it’s a different story – Vista runs perfectly well on most modern PCs (and I don’t mean an exotic machine with a fantastic custom hardware specification – I mean pretty much any business PC purchased in the last few years, as long as it has enough memory). Unfortunately there is a saying that perception is reality.

So today is the last day that you can buy Windows XP. Except that it’s not really. In an open letter to Windows Customers entitled “An Update on the Windows Roadmap”, Bill Veghte (Senior Vice President for Online Services and Windows Business Group at Microsoft) explains that:

“It’s true that we will stop selling Windows XP as a retail packaged product and stop licensing it directly to major PC manufacturers. But customers who still need Windows XP will be able to get it.”

So you can get XP. But why would you? The simple fact is, that if you are looking to deploy a new Windows desktop in the next few months, then basing your plans on XP is building a problem for later.

In terms of the product cycle and future roadmap for Windows XP (Professional, 32-bit):

  • Support for Windows XP RTM and SP1/1A has already ended.
  • Support for Windows XP SP2 will end on 13 July 2010.
  • Although no official announcement has been made by Microsoft, it seems unlikely that there will be a fourth service pack for Windows XP. On that basic, mainstream support for Windows XP SP3 will end on 14 April 2009 and extended support (i.e. security patches only) will be available until 8 April 2014.

Some of my recent customers are just starting rollouts based on Windows XP SP2. By the time they have completed their rollouts, XP will be on extended support. And if they don’t move to SP3 soon, then they will be unsupported. In most cases the reason they are not considering Vista is application compatibility – in which case they should really be looking at application upgrades, or possibly using desktop/application/presentation virtualisation technologies – but why does a move to Vista have to be wholesale? A co-existence strategy involving managed diversity on the desktop is the way forward for many organisations.

So, I’ll finish up by repeating what I said at the head of this post:

“For the majority of Microsoft’s enterprise customers, there are very few reasons why Windows XP should be deployed on new PCs in preference to Windows Vista.”

Additional reading

At last, a new service pack for Windows XP

It’s been a long time coming – almost 4 years – but Microsoft has just announced that Windows XP service pack 3 has been released to manufacturing.

In the announcement, Release Manager, Chris Keroack, said:

“Today we are happy to announce that Windows XP Service Pack 3 (SP3) has released to manufacturing (RTM). Windows XP SP3 bits are now working their way through our manufacturing channels to be available to OEM and Enterprise customers.

We are also in the final stages of preparing for release to the web […] on April 29th, via Windows Update and the Microsoft Download Center. Online documentation for Windows XP SP3, such as Microsoft Knowledge Base articles and the Microsoft TechNet Windows XP TechCenter, will be updated then. For customers who use Windows XP at home, Windows XP SP3 Automatic Update distribution for users at home will begin in early summer.”

Microsoft released a white paper a few months back, detailing the improvements that Windows XP service pack 3 will bring – XP SP3 is basically a rollup of updates and some of the networking technologies from Windows Vista – for example NAP client support.

Why Windows Vista should not be viewed as a failure

Many people expect Windows Vista SP1 to be a turning point for deployment of Microsoft’s latest desktop operating system. Critics have derided Vista, citing it as a disaster for Microsoft, suggesting that it has suffered from adoption rates. Others say that the desktop operating system model is a thing of the past – to be replaced by a “webtop” of cloud-based services. I don’t think that day is here yet – and anyway, we’ve been here before – weren’t thin clients supposed to have taken over by now?

But has Vista really done that badly?

Journalist Paul Thurrott used an interesting comparison in a recent podcast (Windows Weekly episode 48). In a market where 260 million PCs were sold worldwide, Microsoft sold 100 million copies of Vista. Some of those would have been downgraded to Windows XP but what about the 160 million PCs sold without Vista? What were these running? A few Linux machines, some Mac OS X, but mostly Windows XP – and this is what some people are highlighting as a failure to sell Vista.

Thurrott was unable to locate global PC shipment figures for the same period after the Windows XP launch, but he used another method to compare the adoption rates of the two operating systems:

  • At the time of the Windows XP launch, the global installed base of PCs was around 250 million and Microsoft sold 23 million copies of XP in the first year. That equates to an adoption rate of around 9.2%.
  • Looking at the figures for Vista, on an installed base of around a billion PCs, Microsoft shipped 100 million copies – an adoption rate of around 10%.

So, Vista has had a greater adoption rate than XP in its first year and, however you look at it, Microsoft sold 100 million copies. To my mind, that’s not stunning – but not bad either – and it seems that Windows Vista adoption is on the increase. CDW’s Windows Vista Tracking Poll (January 2008) suggests that:

  • The number of organizations evaluating and testing Windows Vista has increased to 48% in January 2008 (up from 29% in February 2007 and 21% in October 2006).
  • 30% of organizations are currently implementing or have implemented Windows Vista.
  • Windows Vista is delivering on expected benefits, with nearly 50% of evaluators/implementers reporting performance above expectation on key features.
  • And, although not part of Windows Vista, but of equal significance whilst examining adoption of Microsoft’s core technologies, 24% of organizations have implemented the Office 2007 System, up from 6% in February 2007.

All of this suggests that Vista (and Office 2007) are already pretty successful. So why the perception that Vista is not ready for the enterprise?

The first barrier is the “wait for the first service pack” mentality. Regardless of its validity, this view certainly exists and the release of SP1 may allow some organisations to start their preparations.

Other perceived barriers are the hardware and software requirements for the operating system but the reality is that any system purchased in the last few years should be capable of running Vista. And, when it comes to device drivers and application support, Microsoft is caught up in a vicious circle where vendors are reluctant to invest in updating their product to work with Windows Vista and customers will not deploy the new operating system unless their hardware and application software requirements can be met. This is the reason that, according to Paul Thurrott, Microsoft worked to ensure that SP1 will resolve issues for 150 enterprise applications that were blocking large-scale customer deployments.

The third issue that I see is that of cost. In the late-1990s, we saw organisations perform technical refreshes every three years or so, fuelled by a combination of technology advances and preparations for avoidance of the “millennium bug”. In recent years, however, the need to roll out the latest and greatest has been tempered somewhat. Rolling out separate hardware and operating system upgrades is often seen as double the trouble, and, unless there is a business benefit that exceeds the disruption and cost of a new desktop environment, organisations are slow to make changes.

Instead, many organisations are considering a system of managed diversity – running Windows Vista on new (and recently purchased) systems but sticking with XP on older machines that do not yet warrant replacement, or where applications do not yet support Vista. This was what Gartner recommended back at the time of the Vista launch and it’s for exactly this reason that I have been critical of Microsoft for taking so long to develop a third service pack for XP – by the time SP3 arrives it will have been almost four years since the last one.

Finally, there is the issue of new features. Windows, like Mac OS X, and any other mature operating system has reached a point where some think it has too many features and others say it needs more. Microsoft has a particularly difficult battle, whereby if it bundles software with the operating system it falls foul of competition laws. It seems to me that many of the Windows Vista improvements are incremental – and that makes a wholesale migration difficult to justify. Perhaps the strongest argument to date has been productivity improvements but these may be offset by people needing to learn new methods of working. With the release of Windows Server 2008 this will start to change – new technologies like network access protection and some of the networking enhancements require a new server infrastructure and that’s when we will start to see a stronger case for adoption of new technology.

Microsoft’s problem is persuading customers to make the move from its own legacy and even when Windows XP is withdrawn from sale in June 2008 (although system builders will still be able to provide XP pre-installed until January 2009), extended support will continue until 2014. Interestingly, Gartner, the same organisation that advised customers to wait before moving to Vista is reported in IT Week as warning firms to start the introduction of Vista no later than 2009 because software vendors are likely to start phasing out Windows XP support after this.

Service pack 1 for Windows Vista is now available for customer download (with some restrictions). It won’t be released on Windows Update for a few months, due to issues with certain hardware devices for which new device drivers will need to be released first, but for those 48% of organisations that are evaluating Vista, SP1 will play a major part. Further details of Vista SP1 and its release schedule may be found in Paul Thurrott’s Vista SP1 FAQ.

Windows Vista may not be perfect (no desktop operating system that I am aware of is) but it does offer improvements over its predecessor and is reaching the mainstream business market. SP1 will accelerate the adoption rate but the main change is that, for many organisations, the move to Vista may be a gradual one and strategies for managing co-existence with legacy operating systems will be crucial.

Windows Server 2008 moves a step closer to release

I don’t normally cover new product releases here but there are one or two products on the horizon that are what might be considered "significant releases".

The first of these is Windows Server 2008 and around about now, Microsoft is due to announce release candidate 1 (RC1), marking another step forward towards product release (and launch in February 2008).

Windows Server 2008 RC1 doesn’t include any major build updates (compared to RC0) but it also coincides with Windows Vista service pack 1 (SP1) RC1, effectively bringing Windows Vista onto the same codebase as Windows Server 2008.

Also on track for launch in the same timeframe as Vista SP1 is Windows XP SP3 (whilst I’ve not seen any details yet on the ship date for this, I expect it to be made available at around about the same time as Windows Vista SP1 and Windows Server 2008).

BDD 2007 overview

It’s been almost three years since I wrote a post about the Microsoft Solution Accelerator for Business Desktop Deployment (BDD) and since then it’s been updated twice – first with BDD v2.5 and now with BDD 2007 (the latest version of which is now known simply as Microsoft Deployment).

According to Microsoft:

The Solution Accelerator for Business Desktop Deployment (BDD) is best-practice guidance for desktop deployment. BDD is targeted at companies that want to reduce deployment time, effort, and cost by increasing the level of automation. It allows administrators to deploy desktops with Zero Touch and Lite Touch interaction at the target PCs. This solution also helps organizations move to a managed environment with standardized desktop images.

Effectively, BDD is a framework that brings together a variety of deployment tools with business logic in order to implement best practices.  In it’s simplest form, known as Lite Touch Installation (LTI), BDD allows administrators to create/capture operating system images, customise these and deploy them to other workstations.  This requires very little infrastructure and as such is suitable for small and mid-size business; however there is also a Zero Touch Installation (ZTI) option that integrates with Microsoft Systems Management Server (SMS) 2003 or System Center Configuration Manager (SCCM) 2007 for enterprises that have the required infrastructure in place.

Supported on Windows X, Server 2003, Server 2003 R2 and Vista, BDD can be used to deploy Windows clients, together with applications (e.g. Office 2007) and customisations.  Available in both x86 and x64 editions (with both versions supporting installation of clients on either architecture), BDD 2007 is finally looking like a product, rather than a collection of tools glued together with scripts and HTML applications.  There’s still a few strange interfaces, but the hub of BDD 2007 is the BDD Workbench – an MMC 3.0 snap-in.  Other requirements for BDD are Windows Script Host (WSH) 5.6 and it also makes use various other tools that may be downloaded from within the BDD Workbench:

  • Windows Automated Installation Kit (WAIK).
  • Application Compatibility Toolkit (ACT) 5.0.
  • User State Migration Tool (USMT) 3.0.
  • MSXML 6.0.
  • Key Management Server (KMS) (and associated management pack).
  • Volume Activation Management Tool.
  • Office Migration Planning Manager.
  • Windows Vista Hardware Assessment

Screenshot of the BDD 2007 Workbench

After installation of BDD (supplied as Windows Installer .MSI file, together with a quick start guide and deployment tools overview – both of which are worth reading), the primary folders are held in %programfiles%\BDD 2007\ and consist of:

  • \BIN – BDD Workbench console and supporting files.
  • \Documentation – documentation.
  • \Downloads – storage for components downloaded by BDD 2007.
  • \ManagementPack – BDD management pack files.
  • \Samples – sample task sequence scripts.
  • \Scripts – scripts used by the BDD Workbench.
  • \Templates – master template files used for defaults in unattended Windows installations.
  • \Temporary – temporary storage space.

Other tools (e.g. the WAIK and ACT) add their own folders to the BDD file structure.

The installation also creates a \Distribution folder on the drive with the largest amount of free space (or at a custom location supplied during installation).  This contains the following subfolders and except \Scripts and \Tools are empty at installation time:

  • \$OEM$ – files and folders to be copied to the destination computer during Windows Vista setup.
  • \Applications – any application files that are installed as part of deployment.
  • \Captures – images captured using ImageX.
  • \Control – storage of files used by the BDD execution engine.
  • \Operating Systems – any operating system files that are installed as part of deployment.
  • \Out-of-Box Drivers – driver files not delivered by default with Windows Vista.
  • \Packages – Windows Vista-compatible packages for installation with the operating system (security updates, language packs, service packs, etc.) in cabinet file (.CAB) or Windows Update (.MSU) format.
  • \Scripts – scripts used by the Lite Touch deployment engine.
  • \Tools – tools used by the deployment engine and the location of USMT source files.

Configuring BDD to deploy an operating system and applications consists of:

  1. Install BDD.
  2. Update/install additional components (e.g. WAIK, USMT) from within the BDD Workbench.
  3. Add one or more operating systems to the distribution share from within the BDD Workbench.  This could be a full set of source files, a custom image (.WIM) file (i.e. an image captured from a reference computer) or an image from a Windows Deployment Services server.  This operation can either copy the installation or move it from another location.
  4. Add any applications to the master image from within the BDD Workbench – applications can be moved/copied to the distribution share or existing locations may be referenced via a UNC path.  Specify any application settings (e.g. command line switches for a silent installation, or a working directory).
  5. Add any additional device drivers that are required within the master image, using the BDD Workbench.  The BDD tools will look for .INF files in the process of scans all subfolders in the specified directory.
  6. Add any additional packages, such as operating system updates and language packs, using the BDD Workbench.

Once the master image is established, it’s necessary to define one or more builds.  Each build has an identifier (which must not contain spaces) as well as a name and a number of associated comments.  The build defines an operating system, along with key details such as product keys and the Administrator password and, once created, the build properties can be amended to customise settings, optionally launching the Windows System Image Manager to edit the unattend.xml file that controls the Vista installation.

Finally, the deployment point must be configured:

  • Builds may be deployed using the local BDD distribution point (shared as \\%computername%\Distribution$), a separate share on the local or a remote computer, as a .ISO image for use on removable media (DVD, USB flash drive, etc.), or via SMS 2003/SCCM 2007 (which facilitates ZTI installations).  Note that SMS 2003 requires the SMS 2003 Operating System Deployment (OSD) Feature Pack whereas SCCM has OSD functionality built into the product.
  • Various options exist to control the user experience during deployment (e.g. the selection of other applications during installation).
  • It may be necessary to create/update the Windows pre-installation environment (WinPE) images that are used to connect to a deployment point.  The resulting .WIM files (found on the distribution point in a \Boot folder) can be added to a Windows Deployment Services (WDS) server as a bootable PXE image for bare-metal deployment whereas the .ISO file equivalents can be mounted in a virtual machine or booted from removable media.  During the creation of these images, tasks are logged in %temp%\DeployUpdates_x86.log.  Generic images are generic_x86.wim and generic_x86.iso.

At this stage, BDD is ready to deploy builds to workstations; however there are some additional capabilities:

  • It is possible to define a SQL Server database to store details of deployed computers.
  • Images may be captured using BDD deployment points such that there is no requirement to separately run SysPrep or ImageX.  The Windows Deployment Wizard (invoked from the Windows PE images created earlier) automatically runs both of these utilities in order to prepare and capture an image.

How Windows PowerShell exposes passwords in clear text

I’m attending a two-day Windows PowerShell course, delivered by my colleague Dave – who I know reads this blog and should really think about starting his own…

I’ve written before about Windows PowerShell (twice) and I think it’s a great product, but it is a version 1.0 product and as such it has some faults. One (which I was horrified to discover today) is that this product, which is intended to be secure by default (for a number of good reasons) has the ability to store user credentials in clear text!

All it takes is two lines of PowerShell script:

$cred=get-credential username

(the user wil then be prompted for their password using a standard Windows authentication dialog)


(the username, password and domain will be displayed in clear text)

Some people ask what’s wrong with this? After all there are legitimate reasons for needing to use credentials in this manner. That may be so but one of the fundamental principles of Windows security is that passwords are never stored in clear-text – only as a hashed value – clearly this breaks that model. Those who think there is nothing wrong with this argue that the credentials are then only used by the user that entered them in the first place. Even so, I’m sure this method could easily be used as part of a phishing attempt using a fake (or altered) script (digitally signing scripts may be the default configuration but many organisations will disable this, just as they do with signed device drivers and many othe security features).

After searching Microsoft Connect and being surprised that I couldn’t find any previous feedback on this I’ve raised the issue as a bug but expect to see it closed as “Resolved – by design” within a few days. If it really is by design, then I don’t feel that it’s a particularly smart design decision – especially as security is tauted as one of the key reasons to move from VBscript to PowerShell.

Tab completion in Windows

Many people will be familiar with the command line tab completion functionality that can be used to complete folder and filenames in recent versions of Windows, but what I wasn’t aware of (until I just used it, following some instructions from Microsoft in a hands-on lab training manual) was that wildcards like *.reg <tab> can be used to tab-complete filenames. This technique can even be used as arguments to a longer command, e.g. notepad *.reg <tab>.

Dustin L makes a good point in his comment on the Lifehacker article that discusses command line tab completion – Unix admins will already be familiar with the concept but there are a couple of differences between the Windows and Unix/Linux CLI tab completion implementations:

  • “In the Windows command line, if there is more than one match for what you’ve typed, successive presses will cycle through all of the matches rather than just display a list of the matches.
  • Windows will not complete commands, only files and directories.”

How Windows XP’s System Restore feature gave me back part of my weekend

My father-in-law’s PC has gone screwy again. Sometimes it just happens.  He doesn’t deliberately make configuration changes, although he did recently buy a new digital camera and the installation CD added a lot of third party software that I would have managed without.  I would consider him to be a “normal” Windows user: he uses the PC for Internet (web) access, e-mail, the odd letter, home finances, some family history research and digital photography; he also pays for a McAfee subscription which should keep him safe from some of the badness out there on the ‘net – except that, a couple of nights back, McAfee updated itself and since then something has been “wrong” with the PC.

Actually, I don’t think I’ve ever seen a PC with a networking stack that was so badly “wrong”. Not having been there when the McAfee update took place, I don’t know what messages it displayed but from looking at the event log after a very slow boot, the DHCP client service shut down because “a system call that should never fail has failed”. Then, after a few minutes of waiting, various services failed because of missing dependencies (including, critically for Internet access using his ADSL modem, the Remote Access Connection Manager service). Removing all McAfee software didn’t help. Neither did restoring the IP stack to its default state with netsh int ip reset (see Microsoft knowledge base article 299357).

It was one of his friends that suggested the answer – what about System Restore?  I’d never previously used this feature in Windows XP but it was a godsend.  I restored the system to the state it had been in before the McAfee update and rebooted (see Microsoft knowledge base article 306084).  The boot up sequence was back to normal, the Internet connection was working again and all I needed to do was remove and reinstall the McAfee software.  Which meant that I did get to spend at least part of my Sunday afternoon in the park with my wife and kids.  Result.