and other brilliant error messages

Tag Archives: VBScript

Since my Windows 7 deployment I get an error every time a new user logs in (or logs in following a profile reset).

Windows Mail could not be started because MSOE.DLL could not be loaded

Since you can click past it I wasn’t initially too concerned but I soon came to realize that there’s pretty much no information on the Web about this problem. Anything the search engines turn up is invariably about Outlook Express on Windows 98/Me.

It seems to be caused when some kind of IE First Run process opens Internet Explorer with an MSN page and presumably tries to register the default email client (which is not yet set to Outlook, despite it being installed). The strange thing is that Windows Mail is not even available on Windows 7. Microsoft discontinued it after Vista in favour of Windows Live Mail. WinMail.exe is present on the system but it’s hidden, and that MSOE.DLL has been purposely omitted. Apparently you can get it working again by supplying a copy from a Vista PC.

The problem is that this error looks important enough for a new user to contact the helpdesk about. The other issue is that it significantly delays that first logon, sometimes by several entire minutes. The error occurs immediately after you enter your credentials (you can hear the alert sound) but it happens while the desktop is still hidden from view by the Windows 7 splash screen. Eventually the Preparing your desktop splash screen times out and you can click OK:

Notice the label in that floating window – it’s setting up a component which is titled as Microsoft Windows.

Having consulted that document I viewed HKLM\SOFTWARE\Microsoft\ActiveSetup\InstalledComponents in Regedit and saw that there is indeed a component with the name “Microsoft Windows” which is invoking WinMail.exe, intending to register it as a mail and news (nntp) client:

I have no idea why it’s doing this since WinMail.exe is intentionally disabled in Windows 7. It would seem logical that deleting this whole key should fix the problem (I backed it up first of course). In testing this didn’t seem to work though.

However I did notice that sometimes I got the error on screen twice and other times only once. Exasperated I searched the registry for instances of WinMail.exe until I discovered the reason: the entire ActiveSetup branch of the registry also exists under HKLM\Software\WOW6432Node\Microsoft, for the 32bit version of Internet Explorer on 64bit systems. Once both keys had been deleted the error disappeared.

I was then able to refine this – instead of deleting the whole key you only need to set to the single DWORD value IsInstalled to zero. Do this to both instances and the problem is fixed! In my environment I used my existing VBScript startup script which worktations inherit by Group Policy. Excerpt below:

Migrating to Windows 7 has thrown up another problem – users wanting to connect from home computers running XP cannot use the Remote Desktop Client to connect to their newly upgraded office PCs. The Network Level Authentication change to the Remote Desktop Client was made because the original RDP is susceptible to Man-in-the-middle attacks.

Rather than leaving the new systems vulnerable by allowing connections from all clients in Computer Propertes > Remote settings, I discovered that Windows XP SP3 does in fact offer NLA support however it’s disabled by default. Somewhat frustratingly, the steps outlined in Microsoft KB 951608 require Registry edits which I would not want to encourage non-IT-savvy people to try. Giving out a .reg file is not really a good idea here either since these are additions to existing values, so forced replacements could interfere with certain vendors’ VPN clients etc.

Here’s a VBScript for the task which will only install on XP SP3 and will detect if the modifications have already been made. You could easily target it at a whole group of PCs by iterating through an array of hostnames.

Windows 7, like Vista, uses an XML answer file to configure the OS install. What’s neat about this is that even though you use the WAIK‘s WSIM tool to edit and validate it, you can customize it and add your own sections for software packages etc. as you can see from the example below, though these custom sections will need to be inserted after the sections that WSIM validates. This answer file can easily be parsed with VBScript using MSXML DOM, allowing for variables like passwords, driver sets, product keys and so on to be inserted at build time.

Why use an unattended install?

If you’ve always used an unattended install to build your workstations, you’ll know that they can be extremely versatile. If you already have a scripted build for XP with applications then chances are you’ll want to tweak those scripts to work with Windows 7. Sure, Sysprep images are handy too, but unless all your machines are the same, or all your packaged app requirements are identical, then you’ll need to add a load of scripted customization to them anyway. Which begs the question: why not just use an unattended install? That way you eliminate application problems that sometimes surface after image-based deployment. In a previous job I remember Roxio deployment in particular was a nightmare for this reason.

Microsoft have certainly made things considerably easier with the release of the Microsoft Deployment Toolkit 2010 but, though it offers a great introduction into the process of automated system building, it lacks the flexibility of rolling your own build process – in particular if you already have a host database. When I decide to rebuild a machine, it boots Windows PE from WDS, looks up its MAC address in the host database and reads the model type from WMI and will offer default choices in my build script menus based on that. It also works out which is the nearest site file server to use for the install.

The problem with Sysprep deployment if you have a very mixed hardware environment is that you either have to:

Create a WIM image for each different hardware type (lots of boring maintenance when changes are required)

Add a huge bulk of drivers to a single WIM image with DISM

Use the AuditSystem phase to connect to a driver share and re-detect all the hardware

Since Windows Vista and later versions effectively just install a WIM and run a hardware detection phase during their normal install process, Sysprep no longer offers much of a speed improvement over an unattended build.

Device drivers

Additional mass storage and networking drivers that will be essential during setup are detected in the Windows PE instance (which we booted from WDS) Driver Store and ‘reflected’ into the installed OS. As you build your custom Windows PE boot image, add these using DSIM as described in my post on the subject.

Since we can read the PC model name from the BIOS via WMI, we can add a tailored device path to the offlineServicing phase of setup. This allows for easy maintenance of driver bundles, since we can arrange them by model type (which certainly beats having dozens of SoundMAX audio drivers lumped together), and we can limit which drivers are offered to each model – particularly useful when a driver causes problems for some models, as with the GMA950 driver and Adobe Flash on Intel 945G motherboards.

I noticed that this is in fact considerably neater that the method used in MDT2010’s ZTIDrivers.wsf script, which copies drivers to the local system then invokes the AuditSystem phase, running the PnP detection routines a second time, slowing down the install. Useful for an OEM like Dell I suppose, whose PCs are often started from their factory image with no connectivity, but not ideal for corporate LANs.

Sample autounattend.xml with custom sections at the end

Note 1 – I couldn’t find any examples of this online, but I discovered that the values for pre-populating the Internet Explorer 8 Search Providers can be obtained by configuring a workstation, then harvesting the registry settings from HKCU\Software\Microsoft\Internet Explorer\SearchScopes. I have highlighted the relevant lines in the XML below.

Note 2 – Somewhat confusingly, in the offlineServicing phase Microsoft-Windows-PnpCustomizationsNonWinPE will fail to connect to your file server for drivers unless you connect to its FQDN (assuming the unattended launched the OS build from a share referencing just the NetBIOS name). Fail to do this and %systemroot%\panther\setupact.log will reveal that it fails to connect with error 0x4C3 (multiple credentials on connection to the same server). What’s bizarre is that there certainly aren’t multiple credentials in use – I use the same ones throughout. I wrote up this problem and solution in this thread on the MSFN Forums. I suspect this might be caused because I launch setup.exe from a network drive rather than mounting the OS WIM image from a WDS server (I wanted to maintain consistency with my other legacy OS builds). I have highlighted this on line 57.

Many organizations decide to use a house style for email, and being able to force a default font is the only reliable way to get this consistent. I do this with the login script.

What’s difficult about it is that it’s not just a minor registry edit – the font styles are actually written in HTML and then stored in binary in the registry. The best way to get them modified is to use an Outlook client to make the changes, then grab them from the registry. They’re stored at:

HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Common\MailSettings

In Outlook you need to edit the stationery in Tools > Options > Mail Format tab > Stationery and Fonts, making sure to change the font for both new messages and replies.

The cleanest way to script this is to export the values from regedit (they will be in hex) and insert them into the script unmodified with the line breaks intact. Then you just quote and line-wrap them, split them into an array on the ”,” character and use a hex-to-binary function before inserting them into the user registry. Here is my example OutlookStationery subroutine for reference (note that it’s not a working script – some objects are defined elsewhere, e.g. objReg, the Active Directory job title, name, surname etc.):

Most Windows sysadmins use a Group Policy object to launch their login script. You may have noticed that Windows 7 and Vista fail to connect network drives defined in the login script if the user is a local admin and UAC is enabled. The script completes successfully and no error condition is encountered, but no drive mappings. Run it again manually and everything’s fine.

This is in fact by design, and it’s caused by the way UAC works. When you’re a member of the Administrators group and you log in, your account is busted down to a non-privileged user by UAC. This running context is completely separate from the context you get when you right-click Command Prompt and launch as an administrator. As you’ll probably have noticed, network drives connected in one context are not visible in the other. The problem is that GPO-based login scripts are being executed in the Administrator context – not the ordinary user context.

So, how do we get it working? Microsoft offer an unsupported kludge in KB937624 – getting around the issue by weakening Windows security and forcing network connections to be common to both user contexts. They carefully designed this not to be the case, so modifying the behaviour does seem like a bad idea.

However, Microsoft’s preferred solution (example launchapp.wsf script in the appendix of that page) is to use the GPO-triggered script to set a Scheduled Task to run immediately in the other (non-admin) context, and run your login script from there – much better.
The reasons I’m writing all this up are that:

Microsoft’s example script has some illegal character/line-wrap in there – copying and pasting it won’t work!

This method doesn’t work with XP so some forking logic is needed if you have mixed clients.

They make no allowances for multiple admin/non-admin users sharing the same PC.

This appears to be Microsoft’s sole example document of how to program using the Task Scheduler 2.0 API, and it neglects to define several absolutely essential object properties if you want to do something more useful than simply open Notepad.

My particular problem was that I needed to launch a script with a space character in the path, e.g.:

For me changing this path name was not an option as there were many other dependencies. I spent a long time wondering why the API was eating my quotes as I fed it the above string and I tried various ways to escape them. Eventually I launched the Scheduled Tasks MMC tool (click on the root of Task Scheduler Library to see the job). Looking in the Action properties I realised that there are separate fields for the starting directory and for the arguments. Manually editing the job to use these got it working:
Frustratingly, there don’t seem to be any examples on the Web showing you how to populate these fields programmatically. Guessing the Arguments property was straighforward but StartIn is not a valid propery name. I read on Wikipedia that Task Scheduler 2.0 uses XML to store its jobs so I exported the job and viewed it. Luckily they used consistent property names in the XML (Arguments and WorkingDirectory) and I was able to set them in VBScript (see highlighted lines below).

There was an additional complication though. Once a user has run the Scheduled Task, it’s left behind on the system. In my initial testing this wasn’t a problem because I was testing admin users, but I soon discovered that a non-privileged user cannot delete and recreate the task if one created by another user already exists. So we need only schedule the task if the current user is running in an elevated security context. By far the simplest method is to parse the output of the whoami /groups command, as explained in this post:http://blogs.technet.com/b/jhoward/archive/2008/11/19/how-to-detect-uac-elevation-from-vbscript.aspx

UPDATE – added some logic to prevent the login script from launching for RemoteApp sessions to Terminal Servers.