Jerry's Incoherent Babbling

Windows Vista x64 imaging in the Enterprise: Trials and Tribulations galore

2006-10-09T16:18:00Z

If your company has pursued the holy grail of the "single workstation image" like mine has (and we got there with Windows XP, woohoo!), you may be wondering if your tools are up to the challenge of doing a single build process with Windows Vista across the x86 and x64 environments. Microsoft likes to say that the new tools in Windows Vista and new HAL technology makes it possible to cut your number of images in half. However, in a well managed shop that used some hacks with Windows XP it was very achievable to be at one image already (and we were!). Now, with Vista though, x64 is going a bit more mainstream. It isn't to the point yet where everyone will or even should get it – but there are going to be some folks that need it. One of the things my team has done over the last several weeks is to go through our tool set and try to make an x64 image work using the same base building scripts and tools as we use for x86 32 bit images. The results surprised me – and this wasn't a good thing. I thought I already understood where x86 and x64 differed in terms of 32 bit software but I definitely learned a bunch during this process. For the results, read on.

So, how did it go?

The first things we hit was just trying to lay the image down on a machine. This testing was with just a generic MS Install.wim with no customizations. What we found was a catch-22:

Our tools (mostly in-house and mostly VB6 since .Net doesn't work on WinPE) are all 32-bit.
The x64 WinPE doesn't support any 32 bit code at all.
The 32 bit setup.exe is incapable of installing the 64 bit Windows

Great! Blocked right out of the starting gate! We can't run our tools in a 64 bit WinPE and can't run the 32 bit setup.exe against a WIM with 64 bit windows. So, we found that although we deploy our 32 bit images using the "Install Based Setup" or IBS (MS: who comes up with these acronyms – Google IBS and see what you hit first) we had to use a down-level look and feel to deploy the x64. That's right: ImageX will deploy a 64 bit image from a 32 bit WinPE. So while the 32 bit installs have the new pretty setup screens, the 64 bit ones are stuck looking like a DOS install in a command window. This at least let us use the same boot.wim – the same tools running in it to check things like whether the hardware is supported or not, etc.

Next Snags

In order to build an image, we use a process that is repeatable and deterministic – nothing new there. In our process we install the base OS (either with an unattend or a sheet showing step 1, step 2, etc.). Then we run a series of installs that are scripted. In our case we are using Wise Installmaster 9.x, but it could be just about any 32 bit tool. We probably have a set of 40 or so scripts (many are run at once by some master scripts) that manage this process. They install software, configure user settings, load up the default user's HKCU hive and make changes to it so that all new users on the machine get the settings, etc. All pretty standard stuff actually. Howewver, we hit several issues in our code:

A few hard-coded references to "C:\Program Files" were causing x86 code to end up in the 64 bit program files location. Easy fix: slap the coder that did it and recompile.
Registry changes that needed to go into the real HKLM\Software were getting sent to the HKLM\Software\Wow64Node. These were things like the Autologon settings that go in the WinLogon area of the registry. It also redirected everything that we tried to put into HKLM\Software\Microsoft\Windows\CurrentVersion\Run. These edits were being made by standard "edit registry" command in Wise scripting. They could as easily have been made by any other 32 bit tool with the same results as all 32 bit code that writes to HKLM\Software gets redirected. Fix: not so easy!

For that last one, we ended up scratching our heads for quite awhile. We could have done several things:

Compiled some VB.Net 2005 code using the "Any CPU" compile option so that the code would run as 32 bit on x86 and as 64 bit on x64. This would be a maintenance problem for us as minor changes would need a recompile of VB code. Not too bad.
Change the script to call the new API function to disable registry virtualization of 32 bit code. Oops, there ISN'T one! What there is, is a new flag to the registry functions like RegCreateKey that allows you to turn off the virtualization. The problem here is that none of the scripting languages (and even VB.Net) will let you control those flags. So you can't use them in scripting at all.
Turn off file system virtualization for 32 bit code. This trick we came up with does work. What we did was call the "Wow64DisableWow64FsRedirection" function from kernel32.dll. How does that help? Well, then we can call reg.exe and pass it the items we want to set. On a 32 bit system, that API call just silently fails and you call the correct 32 bit reg.exe. On an x64 system, the call works and you end up calling the 64 bit reg.exe which does not get virtualized. At the end, you test the result code from Wow64DisableWow64FsRedirection. If it succeeded (you were then on 64 bit), you call Wow64RevertWow64FsRedirection. We found a lot of places in our scripting where we needed to use this clumsy mechanism.

The results of all this:

We have a single set of build scripts that can take a base install of Windows x86 or Windows x64 and get it loaded up and installed with all of the items we put in our single corporate image. We can also use a single boot.wim (a customized 32 bit one) that will determine whether it must run setup.exe for 32 bit OS installs or ImageX for x64.

Hopefully Microsoft will get this right next time and have a way to actually deploy this stuff easily. For now, be prepared to do a lot of work to get a single set of tools working for both x86 and x64.

Enabling the Administrator Account for Logon in Vista Beta2 5384

2006-06-08T21:46:00Z

Those of you who have downloaded and installed Windows Vista Beta 2 (build 5384) may have noticed something annoying: unless you join a domain, it is awfully difficult to logon to the built in Administrator account.

To work around this:

Logon as the account you created during the installation.
From the Start menu, go to "All Programs", "Accessories"
Right-click on "Command Prompt" and choose "Run as Administrator"
Click "Allow" from the ConsentUI prompt
In the resulting Command window, enter "regedit" and press enter
In regedit, browse to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Add a new key at that level called SpecialAccounts
In the SpecialAccounts key, create a sub-key called UserList
At this point the path is: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList
In the UserList key, create a new value of type DWORD (32 bit) called Administrator and set the value to 1.
From the command prompt enter: "net user Administrator /Active:yes"
Reboot, and now you can logon to the Administrator account

For those of you who join your computer to a domain, you can easily logon as the local administrator account using Switch User, as long as you have enabled the account.

Remember to get Connected on WindowsConnected.

Office 2007 PDF support in jeopardy

2006-06-02T16:51:00Z

When is an open standard not open?

It seems that Adobe reserves the right to tell some folks PDF is open, and other folks that it isn't. For years, PDF has been a standard portable (and open) format on the internet. Many ISV's and open source projects have read the statements on Adobe's web site (PDF File here) that seem to say that PDF is open and you just have to meet the standard and have some Adobe info in your copyright (OK, so IANAL, but that's what it looked like to me). I'd guess I wasn't the only one since the OpenOffice people, the GhostScript project, and several ISV's who sell add-ins or printer drivers to produce PDF files seem to have thought the same.

Along comes Microsoft trying to add support for output to PDF into Office 2007. All of a sudden it isn't an open format that anyone can implement anymore. At least it seems Microsoft can't without Adobe's permissions which it seems inclined to withhold. They must have been quoting Captain Barbosa from Pirates of the Carribean, the Curse of the Black Pearl where he said "I'm disinclined to acquiesce to your request. Means no." Argh and all that.

Now obviously there are two sides to this one. Maybe Adobe is worried that some ISV's will go under if MS provides this functionality out of the box for Office 2007. Maybe they are worried that Acrobat Professional sales will fall once people realize there are other ways to produce basic PDF files. Maybe Adobe is worried that MS will kill off all of the other PDF writers, then declare the PDF as dead since there is nobody making writers anymore, then drop support for it in favor of Metro (XPS). Who knows?

The bottom line for me as a customer of Microsoft's and as someone who admittedly passionately dislikes Adobe's software (due to the difficulty of installing and managing them in a LUA environment) this really leaves me thinking even worse of Adobe. The funny thing is, this may be all Microsoft's fault - but I don't even care. I want the ability to write to PDF's without installing some software that won't install properly, won't upgrade or patch correctly, and tries to run regedit behind the scenes every time you launch it (yes, I combined 2 or 3 Adobe products there, but you get the idea).

Some references:
Brian Jones Blog
Another perspective

Anyway, it looks like for now MS plans to still have this feature as a download. Hopefully that will remain an option.

Can’t install that MSI on your OS? Orca to the rescue!

2006-05-30T14:01:00Z

Defining the problem space

If you are a Vista tester or packager, or even a developer that runs a server OS as your primary machine (like Windows Server 2003 or Longhorn server), you have probably come across software that is “blocked” on your OS. You’ll start the install by running setup or double-clicking the MSI file and it will say something stupid like this:

Or maybe this:

Or even this:

Sometimes you have to wonder about these folks logic skills; in that Cisco one, did anyone catch that it “requires Windows 2000 Service Pack 3 or greater AND Windows XP Service Pack 1 or greater”. This would reduce to something like this in pseudo code:

If ((OS is Win2000) AND (SP Level is >= SP3)) AND ((OS is WinXP) AND (SP Level is >= SP1)) THEN INSTALL.

How exactly are we supposed to be running both OS’es at the same time? I hope the person writing the text strings isn’t the same dev that writes any of the logic in the application!

Anyway, those first two were applications that were blocked for no good reason on Windows Server 2003 (since Windows Server 2003 is a superset of Windows XP, all software that runs on Windows XP should be able to run on Windows Server). Other things that are blocked on Windows 2003 server for no good reason are things like HP Scanner software. The third bitmap is from some Cisco software that implements version checking incorrectly in their MSI file.

The good news? All of these can be “fixed” using Orca!

So what’s this Orca thing?

An Orca is a killer whale. Oh wait, – in the context of this article, Orca is a bare-bones, no frills MSI database editor. That’s right, a Windows Installer file (MSI) is a database of things like actions, files to install, registry entries, and, most importantly for what we are trying to achieve here, Launch Conditions. Launch Conditions tell Windows Installer what requirements a machine must meet before the software will be allowed to install. It’s what drove all three of those annoying “I’m not going to install, neener neener neener” boxes above.

To get Orca from Microsoft, follow the instructions here: Getting Orca. Once you have Orca installed you will need to get your hands on the MSI file that you need to edit. Sometimes these are packed inside of a monstrously large self-extracting EXE file named “setup.exe” or “install.exe”. Often you can run these with a parameter like “/X” or “/Extract” or “/C c:\files” or something to get the MSI file extracted. Other times, just run the EXE and when the error telling you that you have the wrong OS appears, go to your temp folder and grab the files from there (often times they are in a funny named folder under temp like IPX0001.tmp or something like this). Save off the contents of that folder before you click OK to the dialog box.

Now that you have the MSI, file open it in Orca. The UI will show the “Tables” on the left side. For this task, we want the “LaunchCondition” table as shown here:

Notice that the condition is set to “VersionNT = 501 OR VersionNT > 502”. This means “If the version is WindowsXP or the version is greater than Windows Server 2003, then install”. This was Microsoft’s way of saying only run on Windows XP or Vista. To make it run on Windows 2003 server, it was just a matter of making this say the following:

After this simple change, just click Save and now it will install on Windows XP or greater. By the way, Windows XP is version 5.1.2600 and Windows Server 2003 is 5.2.3790, while Windows Vista Beta 2 is 6.0.5384. I’m not sure why in Windows Installer 5.1.2600 = 501 and 5.2.3790 = 502.

Here’s the Cisco one:

Notice that they have a more complex set of rules including a Pentium 3 or greater and 120 MB of RAM or greater. The salient section for us is this one:

(VersionNT=501 And WindowsBuild>=2264 And ServicePackLevel >=1) OR (VersionNT=500 And WindowsBuild=2195 And ServicePackLevel>=3)

As you can see, unlike the person who came up with the string error message suggesting that we needed to be running Windows 2000 and Windows XP at the same time, the person who did the logic here got most of it right. It requires the production version of Windows 2000 (VersionNT=500, with the build 2195 and the SP3 or greater) OR Windows XP Beta version or greater with SP1 or greater. (The production build of Windows XP is 2600, so where they got the 2264 had to be a beta release – at least they got the >= in there to cover it). To fix this one, we could either add another OR line with something like this OR (VersionNT=600) which would get it running on Vista for now, or we could just replace the whole line with something like this VersionNT >= 500 and forget the service packs since for our testing we won’t be running SP0 of Windows XP or SP2 or older of Windows 2000.

So why doesn’t the software work?

All the work we have done so far is to remove “stupid” blocks that are there for no reason or are there only because the software hasn’t been tested on a particular platform. None of our work guarantees that an application will actually work on Vista or Windows 2003 server. Many times they do work, but sometimes they will fail. Also, sometimes the vendor will have coded an OS version check right into the exe file that makes up the main program. You may need to setup the “Version Lie” shim using the Application Compatibility ToolKit (ACT) or by right-clicking on the EXE and setting it to run it as if it was Windows XP SP2. If this still fails, then the application probably isn’t going to run on your particular OS. Time to call the vendor and ask for a version that does work. However, if it works then you’ve just “fixed” the vendor install! Note that the vendor actually supporting the software on your platform is a different animal.

Trying to build a Vista Beta 2 machine in VMWare workstation using WDS?

2006-05-26T16:40:00Z

Unfortunately, at some point Microsoft dropped support for the network card that VMWare emulates. If you recall WinPE 1.1, it loaded the network fine in VMWare. Alas that is no longer the case with Vista PE (also known as PE 2.0). All is not lost however. If you have access to the Windows AIK (WAIK – Windows Automated Install Kit), you can “fix” the missing driver issue pretty quickly. Here’s how:

Install the Windows AIK for Beta 2
Create a folder on your hard drive (for this example I will use C:\5384, which is the build number for Beta 2). Create a subfolder under that called Mount (so C:\5384\Mount).
Copy the Boot.wim file from the Beta 2 DVD to the C:\5384 folder. Boot.wim is in the sources folder on the DVD.
You’ll need the VMWare drivers. To get them, either use your favorite mount tools such as VCD, Daemon Tools, etc. to mount the “C:\Program Files\VMWare\VMWare Workstation\Windows.iso” file. An alternate method is to boot a working VM and assign the CD drive to be the Windows.iso and copy the files that way. From that ISO copy the following:
ISO file root\Program Files\VMWare\VMWare Tools\Drivers\vmxnet\win2k. Copy all the files in that folder to C:\5384\vmnet
Pull up a command prompt and execute “C:\Program Files\Windows AIK\Tools\x86\imagex.exe” /mountrw c:\5384\boot.wim 2 c:\5384\mount
Now in the command prompt execute:
“C:\Program Files\Windows AIK\Tools\PETools\peimg.exe” /inf=c:\5384\vmnet\vmxnet.inf c:\5384\mount\windows
Next execute this:
“C:\Program Files\Windows AIK\Tools\PETools\peimg.exe” /inf=c:\5384\vmnet\vmxnet.inf c:\5384\mount\windows
Last, run “C:\Program Files\Windows AIK\Tools\x86\imagex.exe” /unmount /commit c:\5384\mount
Once that finishes, you will have a Boot.wim where the 2^nd image in it (the Vista Setup) contains the files needed to support the VMWare Workstation network card. Import that updated boot.wim (c:\5384\boot.wim) into your WDS server and give it a unique name. Select that boot.wim when you are network booting your VM and install Vista quickly.

Vista Feb CTP contains service session 0 mitigation code. Cool!

2006-02-24T22:14:00Z

If you're an IT Pro or a developer, you've probably taken an interest in the new session seperation in Windows Vista. This is the new design in Windows Vista that moves users out of "session 0" and reserves session 0 for services and drivers. Unfortunately, this means that a common "shortcut" that many developers used to take no longer works. In the past, devs could simply pop stuff up from their services on "WinSta0\Default" and know that it would appear on your screen (as long as you weren't on a terminal server).

Now though Vista has introduced a very terminal server like environment as a security enhancement. User sessions start with session 1 and will increment as you use "Switch User" or logoff and on. Services, like the nulls that they are, still hang out in session 0 all by themselves. Services like Symantec's Anti-Virus product (and many others) will need to be re-written to be able to pop UI up on the user's screen. Microsoft has seen that this can be a real problem for some vendors and even some LOB applications, so they have shimmed it in the most recent build of Vista (the Feb CTP or build 5308). For example, see what Vista now shows when SAV detects a virus and pops up their UI on session 0:

This allows the user to very easily access that session 0 info without exposing any other session 0 UI and without incurring a security risk. When I clicked "Check request...", I then got taken to a session 0 desktop like this:

Here, we can interact with the Symantec UI even though Symantec has not released a real Vista compliant version of their AV product yet. The same would hold true for services that your companies may have developed.

This seems to be a fairly elegant bridging technology to allow users applications to still work, while being enough of a pain that their vendors will definitely hear about it. All the while maintaining the session seperation and security.

Kudos to Microsoft for this design.

Windows Vista Feb CTP Performance Problems? Try removing Windows Explorer!

2006-02-24T00:44:00Z

This one is from the "Who thought that one up" department (or the "You must be smoking crack" department). On several machines with the February CTP build (5308) of Vista we've seen either the performance center or the problem troubleshooter come up with some helpful advice for us about what is causing slow performance in Vista:

So according to this, the reason that Microsoft Windows Vista is starting slowly is that Microsoft wrote it? The funny thing is, at least on my machines, this build of Vista actually starts pretty quickly and logs on quickly too.

I was almost thinking some developer stuck this in as a joke and if I clicked the "How can I avoid this problem?" link it would take me to the SuSe site or the Red Hat site or maybe even Gentoo or Ubuntu. But alas it didn't do that so it must just be a plain bug. Probably the exclusion list hasn't been added yet or something like that. Anyway, this could be a useful feature when it gets fully implemented. Hopefully by Beta 2 that will happen. Then it can warn us about the Adobe Acrobat "quick loader", the Apple Quicktime tray app, and other ubiquitous performance sapping garbage like that. Many non-techie users don't know that they should get rid of those types of foistware and this feature could actually help them. Hopefully the exception list will be extended to be sure that Anti-Virus and non-MS Anti-Spyware packages don't get flagged. That same home user would end up disabling their protection if it flagged it as a problem. I'm sure they'll get this one right.

For now though, it just gave me a good a laugh. LOL.

Trouble signing on as THE Administrator on 5308?

2006-02-22T22:24:00Z

Those of you who have hurriedly downloaded the Windows Vista Feb CTP (build 5308) may have noticed something sinister: unless you join a domain, it is awfully difficult to logon to the built in Administrator account.

To work around this using AutoLogon:

Logon as the account you created during the installation.
From the Start menu, go to "All Programs", "Accessories"
Right-click on "Command Prompt" and choose "Run as Administrator"
Click "Allow" from the ConsentUI prompt
In the resulting Command window, enter "regedit" and press enter
In regedit, browse to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
In the Winlogon key, create a new value of type REG_SZ (string) titled AutoAdminLogon and set the value to 1.
Also create a string value titled "DefaultPassword" and set it to the password you want for the Administrator account.
In the value "DefaultDomainName" enter the name of your computer
In the value "DefaultUserName" enter "Administrator"
Close regedit
Back in the command prompt, enter "Net User Administrator password*" (replace password with the password you entered for DefaultPassword).
Log off or reboot. You are now logged on with the local Administrator account. To stop it from auto logging on, remove that "AutoAdminLogon" value or set it to 0.

To work around this using a registry hack (the same one that works for enabling the Administrator account on XP Home):

Logon as the account you created during the installation.
From the Start menu, go to "All Programs", "Accessories"
Right-click on "Command Prompt" and choose "Run as Administrator"
Click "Allow" from the ConsentUI prompt
In the resulting Command window, enter "regedit" and press enter
In regedit, browse to HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon
Add a new key at that level called SpecialAccounts
In the SpecialAccounts key, create a sub-key called UserList
At this point the path is: HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\SpecialAccounts\UserList
In the UserList key, create a new value of type DWORD (32 bit) called Administrator and set the value to 1.

(Thanks to Ed LaLonde for calling my attention to this trick.)

For those of you who join your computer to a domain, you can easily logon as the local administrator account using Switch User.

Remember to get Connected on WindowsConnected.

Common Dialog: How useless you’ve become

2006-02-22T16:30:00Z

So when you saw the title Common Dialog you were probably thinking about some rough verbiage from a B movie. But being computer geeks, what we are really talking about here is the CFD or Common File Dialogs. If you’ve ever click “File” | “Open” then you know what I’m talking about. That little Window that allows you to go browsing for a file, find that file, and then open the file. Those more advanced users out there may have even used the “File” | “Save” command in an application to do something wonderful like persist some data to disk.

Back in the heyday of Windows XP, the CFD didn’t get much respect. Not that it complains much about it. It just went about it’s job, quietly allowing users a viewport into their storage. But now, the CFD is on the move. Someone at Microsoft thought that it needed an overhaul. So now in the latest Vista build (the February CTP or 5308 as of this writing), the CFD has become a powerful force for evil. That’s right; evil. We’ll dive into the specifics on that in a bit.
As a “frequent beta tester”, I’ve become inured to the constant change introduced by new versions, new builds, fresher bits, etc. For example there’s the Office 2007 Ribbon and Floatie. There’s the Windows Vista Sidebar. Who can forget the Messenger 8 advertisements and videos – some of which are not “corporate friendly” – those of you who’ve ever had to take a class entitled “Harassment training” know what I mean. But along comes the deal breaker. Now, we have the CFD to end all CFD’s. The Common File Dialog box that just makes you pray that Microsoft gets search working correctly so that you’ll NEVER have to use the “File” | “Open” again. Oh, the humanity.
Some of you may be wondering what is so bad about the new dialog. Let’s take a walk through nostalgia corner first and look at the last truly great CFD (from Windows XP):

Look at that classic layout. Notice the functional “Common Places” bar along the left side. That bar has things like “My Computer”, “My Documents”, “Desktop”, “My Network Places”. These are locations we can all relate to. In corporate environments it is even possible to use Group Policy Objects (GPO) to set which items appear in the Common Places bar. This dialog has it all. Simple, non-pretentious, succinct, concise – that about sums it up. Anyone who has used a computer can use this guy to browse for a file.
As shown here, you can even open a SharePoint site through My Network Places in this doozy of a classic:

Now, along comes the new kid on the block – the Super Duper new contender, the Vista CFD:

In this eyesore of a dialog, you can sometimes open files – if you can find out how to get to them. At first, I thought it was just me. But then, I started noticing that all of my coworkers would get the same haunted look in their eyes when they made the mistake of clicking “File” | “Open”. That look that says either, “Help, I’m being held prisoner in a dialog of bad design” or “Get out of the way, I’m sprinting for the bathroom.” (I’m betting on the first one.)

For those of you brave enough to essay the “File” | “Open” command in Vista, one thing you’ll want to note well is that little “up arrow” near the bottom left of the listview control – where it says “Folders”. If you always click that arrow as your first step after entering the CFD from Hell you’ll be better off. Unfortunately to date, I haven’t been able to figure out a way to make the folder list STAY open between uses.
Did anyone else notice the strangely placed “Share” and “Sync with other PC’s” commands in this version of CFD? Isn’t that what you’d always do when opening a file? Stop what you are doing and realize that instead of opening and editing that important file – what you really MEANT to do was share out your documents folder? Or maybe you really wanted to sync with other machines? Is it just me, or do those buttons not belong in a task based dialog for opening and saving files? Can I really go an entire paragraph of rhetorical questions?

All joking aside, has anyone else found that the CFD something to be worked around instead of simple to work with? If so, be sure to send in your Beta feedback and maybe we can get the evil dialog put out of our misery.

BitLoser Drive Embalming

2006-01-01T15:55:00Z

Hopefully many of you fall into the intersection of the following sets:

The set of people who regularly read WindowsConnected.

The set of people who are testing Windows Vista

The set of people who read Josh’s article on BitLocker Drive Encryption and tried it out.

If you did fall into all of those sets of people I imagine you have now rebuilt the computer that you used for testing BitLocker. Why is that you ask? Well, it seems that the feature formerly known as a piece of Palladium, and part of NGSB, and then as Corner Stone, later as Full Volume Encryption, sometimes as Secure Startup, and finally as BitLocker Drive Encryption works too well. It makes me think of a quote from the Jake Preston character (Nicolas Cage) in Fire Birds. No, not “I am the greatest!”, although I do hear that Josh mumbles that from time to time. Instead I was thinking of the quote where he said, “All gone bye-bye.” It’s appropriate because that’s what happened to your data if you followed Josh’s instructions and enabled BitLocker using a USB key on build 5270 of Windows Vista. That’s right, your data was indeed “All gone bye-bye.”

Why is this you ask? Who knows? Maybe the Shadow knows. Obviously the CTP builds of Vista are just snapshots in time of the current development of Vista. They aren’t guaranteed to work, and of course you have to expect bugs. It just happens that this one is a doozy. Hopefully you weren’t dual booting the partition that you encrypted, since that would be gone too. The feature doesn’t appear to have gotten any testing from within MS during the stabilization of the release for CTP either or there would have been warnings about turning it on. Hey, that’s one of the hazards of getting to play in the strange and sometimes bizarre world of Beta Testing.

I know I managed to hit this bug numerous times. I just was unable to believe that it did such a good job of encrypting and forgetting that it had saved the key for me. So the first time I hit it I just figured some key piece of data had corrupted on the USB key and that I should format the thing and try again after rebuilding Windows. So I did that. It didn’t help. I then thought that it could have something to do with the specific memory key. After all, I was using a USB 1.1 32 MB generic one. So I rebuilt again and used a USB 2.0 Kingston 2 GB key. The same problems occurred. One more rebuild, this time with a USB 2.0 64 MB key from Microsoft (no, they don’t make it, but it says Windows Rights Management Services on the side and has a MS logo). This one had the same problem. So that was about 6 hours of building Windows.

At that point, I could have just decided that I hated the feature and given up. However, I hadn’t managed to make anyone else hate the feature yet so I couldn’t have been done. Instead, I conspired to get some of my co-workers (who had been shirking their beta test duties and hadn’t tried BitLocker with USB yet) to lose their data too. Actually, I wanted to see if it had anything to do with the specific hardware I had. So we tried it on my Boss’s machine, which promptly went “All gone bye-bye”. I hope that wasn’t my performance review on there! We also tried it on two other user’s machines. This totaled three distinct types of hardware and 6 types of USB key, so at that point we were sure we had just hit an unfortunate bug in the 5270 build.

As for what you actually see onscreen when this happens to you, take a look here:

OK, so everybody who tests Vista sees the “Codename Longhorn” screen. But most of you probably can’t say that you’ve left that screen happily running its progress bar overnight. Yes, that’s what happens when you finally enter the key manually and Windows accepts it. It just dies at the progress bar screen.

An interesting piece of the issue is that if you leave a bootable Vista DVD in the drive (which gives you that “Press and key to boot from CD or DVD” message and a 5 second delay), then Windows Vista does indeed find your decryption key on the USB key. Wait – before you go try to recover your lost data that way – it still hangs at the “Codename Longhorn” screen. It’s just joking with you when it says that it loaded your key and you can remove the media.

All in all, testing BitLocker Drive Encryption at this point in time on build 5270 is not a very rewarding experience. However future iterations of this are a must test for corporations. How many companies out there never have any notebooks lost or stolen? How many can look their CEO in the eye and tell him that the data on those machines was protected? For those of you using EFS and laughing smugly: What was in the temp folder on the machine? What was in other folders that weren’t encrypted like the Temporary Internet Files, etc.? BitLocker looks to be a good solution to this problem. For more info on BitLocker and how to enable it, see both Josh’s Post and the Microsoft Step-by-Step guide (although do note that the MS guide as originally published had the partitions backwards – they may fix that, so it might not be backwards anymore).

Manifest Destiny

2005-12-21T13:56:00Z

If you are a developer, IT administrator, or application packager you should know about manifest files and how they interact with Windows to control how your applications run. Manifests were first supported with Windows XP and were commonly used to do things like turn on support for the Windows XP style themes. For instance, on Windows XP if you crack open regedit.exe in Visual Studio, you will see a resource of type RT_MANIFEST (run-time manifest) with the number 1. This reads like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
processorArchitecture="x86"
version="1.0.0.0"
name="Microsoft.Windows.Regedit" type="win32" />
<description>Registry Editor</description>
<dependency>
    <dependentAssembly>
        <assemblyIdentity
            type="win32"
            name="Microsoft.Windows.Common-Controls"
            version="6.0.0.0"
            publicKeyToken="6595b64144ccf1df"
            processorArchitecture="x86"
        />
    </dependentAssembly>
</dependency>
</assembly>

That manifest just tells Windows XP to use the "new" (version 6.x) of the Windows Common Controls instead of the default version 5. Version 5 is the default because many legacy applications won't run properly with the new, themed controls. If you are a developer, you may have provided manifests like this to allow theme support in your Visual Studio.Net applications.

You may not have realized that the manifest file can be either compiled into the EXE or just in the file system. Take the fictitous program "NoteCard.exe". If you were to place the file "NoteCard.exe.manifest" in the same folder as "NoteCard.exe", it would operate just like it would if it was compiled into the program. This gives administrators and packagers the same types of control as that available to the developers of applications. In fact, to see this in operation it is instructive to copy the XML above into Notepad and save it as a file on your system in the same folder as an application written in VB6 (Visual Basic 6). Name the file <exename>.exe.manifest. You'll normally get to see the VB6 application crash when you run it, as most VB apps can't handle the newer themed controls. This shows why Microsoft did not make the common controls 6 library the default for Windows XP. Delete or rename the manifest file and your VB6 application runs as it did before. For more information on how manifests work with common controls, see this article on MSDN.

Vista, UAC, and manifests

With Vista, the roll of the manifest grows to encompass run levels. For example, many testers have seen that an administrator on a Vista machine doesn't actually have the administrator level token unless they "elevate" or "permit" an action. (See this article on Windows Connected for information about the split token for User Account Control or UAC). Have you wondered how some applications like MMC.exe will ask you to elevate when you are a protected administrator, but won't ask when you are just a standard user? Do you think the answer is that "Windows is just smart and figures it out?" Bzzzzt. Wrong! It's the manifest.

Crack open the Vista 5270 version of MMC.exe in Visual Studio and open the resource of type RT_MANIFEST and number 1. Notice that it now has some run level information in it? It looks something like this:

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>

<assembly xmlns="urn:schemas-microsoft-com:asm.v1" manifestVersion="1.0">
<assemblyIdentity
processorArchitecture="x86"
version="5.1.0.0"
name="Microsoft.Windows.MMC"
type="win32"
/>
<description>Microsoft Management Console</description>
<trustInfo xmlns="urn:schemas-microsoft-com:asm.v3">
<security>
  <requestedPrivileges>
   <requestedExecutionLevel
    level="highestAvailable"
    uiAccess="false"
   />
  </requestedPrivileges>
</security>
</trustInfo>
</assembly>

This is telling Windows to attempt to run the application at the highest execution level that is available. In the context of a regular user, the highest available is just that lowly user level. This means there would be no prompting for a standard user. For the built-in Administrator account (which has UAC off always) there is also no prompting because the token is already administrator level. However, things are different for the accounts that have been aded to the Administrators group. These accounts are running with the split token. When Windows sees this, and sees an application manifested to run with "highestAvailable" it will throw the "ConsentUI" prompt asking you to permit or deny the application from running with the full administrator token. (Note: it is impossible to have the application automatically elevate. Consent is required!). Info on CredUI and ConsentUI is here on MSDN.

In the same way as we could put a manifest file into the file system instead of compiled into the EXE for common controls library selection, we can also do it for the run level. There are several levels available:

highestAvailable
requireAdministrator
asInvoker

Those are pretty self-explanatory, but you can see the full Microsoft documentation for this and the run level manifest here on MSDN.

Now, some of you may have noticed that on the compatibility tab of the properties sheet for an EXE, Vista has the "Run as Administrator" check box. This is equivalent to "requireAdministrator" and puts the information into the SDB file (Solution DataBase). However, the GUI there doesn't allow you to set the "highestAvailable" option. For this, you can use a manifest. Most likely down the line you will be able to use the application compatibility toolkit - we'll have to see what's in this when it ships. But for now, the solution is manifest.

File and Registry Virtualization – the good, the bad, and the ugly

2005-12-19T20:37:00Z

With Windows Vista, Microsoft is evangelizing the use of “Standard User” accounts for most all users. You will also hear these accounts called LUA, or Least-privileged User Account. Running as LUA users will enable a much more secure environment and help to ensure that machine configurations remain stable. In order to ease the application compatibility woes that this major change is sure to generate, Windows Vista introduces a bridging technology know as File and Registry Virtualization (called affectionately “Virt” here). This technology makes it possible to run many applications as a standard user, even when the applications required either Administrator or Power User rights on Windows XP. This is accomplished by re-directing (or “Virt’ing”) application writes from secured areas of the system to a virtual store under the user’s profile. This technology is intended to make deployments of Vista less dependent on waiting for vendors to release new versions of their software that work with LUA. It isn’t designed to be used forever: in fact, Microsoft hopes to deprecate the virtualization feature in the next version of Windows after Windows Vista. The thought is that by that time, vendors and customers should have applications that work correctly in the low rights environment.

Here’s the good news first:

With “Virt”, many off the shelf and custom in-house applications will just work. No tweaks needed. Are you wondering how applications that write to “C:\Program Files” or HKEY_LOCAL_MACHINE could possible work within a low rights user account? The magic of Virt, that’s how!

When an application attempts to do something “bad” like write to an INI file like “C:\Program Files\PoorlyBehavedApp\Options.ini”, Windows will detect that the user’s token does not grant them access to save to that location. Instead, it will copy the existing file (if it already exists) to “C:\Users\<your_account>\AppData\Local\VirtualStore\Program Files\PoorlyBehavedApp\Options.ini”. It will then allow the write operation to succeed to this new file in the VirtualStore folder. Subsequent read operations for that file will always preferentially use the copy in the VirtualStore. Here’s a simplified flow chart outlining these read and write operations.

The same type of magic is used with certain parts of the registry. For example, if an application writes to “HKLM\Software\PoorlyBehavedApp\2.0\Settings”, windows will send that write operation to “HKCR\VirtualStore\Machine\Software\PoorlyBehavedApp\2.0\Settings”. In the same fashion as with the files, subsequent read operations will read from the VirtualStore preferentially. The registry store is backed by the file “C:\Users\<your_account>\AppData\Local\Microsoft\Windows\UsrClass.dat” in the same way that the classic HKCU area of the registry is backed by “C:\Users\<your_account>\NTUser.dat”.

So what’s bad about this?

All in all, this is a good thing and Virt should prove to be a great enabler of legacy applications. However, there is a dark side. For example, what happens if ISV’s and customers come to depend too much on Virtualization? Will they create proper applications that adhere to the principles of least privilege? Or, will they choose to save money now and just hope that Microsoft can be talked into keeping Virt around forever? Will new development be done properly? Or will developers continue to code the way that they always have since it will work OK anyway? As you can see, there is a very real risk that virt will “succeed too well” and just push that big app compat problem out into the future without actually forcing apps to be fixed now. In general, customers should check to see which applications are “virt’ing”, report them to the vendor and ask for new versions that are truly LUA aware. Optimally, new applications would only be purchased if they can pass the “Virt” test (not causing entries to be virtualized in the file system or registry). It goes without saying that any non-administrative application that doesn’t run without administrator privileges should not be purchased.

How about the Ugly?

Let’s take the fictitious application “PoorlyBehavedApp” as an example. This application was originally built on Windows 95. The lack of a security model on Win9x led the developers to an easy method of storing data: The INI file in the Program Files folder. Unfortunately, the developers fell prey to that classic problem of mixing user and machine data. Take this section of their Options.ini file as an example:

[Data]
Server=MyServer.MyCompany.com
Database=ImportantStuff
[Toby]
WindowX=100
WindowY=50
WindowWidth=800
WindowHeigh=900

As you can see, the database server and user preferences (in this case the last position of the application window on the screen) are saved in this same file. So, when the user Toby exits the application it will write the last window position to the file. Since Toby is not an administrator, this causes a copy of the Options.ini file to be created under his profile in the VirtualStore. So far so good, right? When Toby logs on and starts the application, he will get the proper settings. The same thing even works when Abby later logs on: her window position gets saved in her own VirtualStore since she is running as “Protected Admin”. Protected Admin is the default mode for administrators. Read our Split Token post for more on how the administrator will still have a user level token.

So where’s the problem? Here’s where it gets troublesome! Later, the IT staff needs to take the server down and wants to replace it with a new one that has a different name. The new server is MySecondServer.MyCompany.com. The IT staff uses SMS to push out a change to the INI file in “C:\Program Files\PoorlyBehavedApp”. What happens? Well, new users will work correctly. However users like Toby and Abby who have already used the application (and gotten virt’ed) will fail since their virtual copies of the INI file have not been updated! Their INI files are still pointed to MyServer.MyCompany.com. Here is a graphic showing where the user’s copy of the file would be.
At this point, you can probably see that the script in SMS just got much more complex. You probably need to iterate through the profiles on the machine and update the file in each of the VirtualStores. Testing just became more complex too since you need to have scenarios for existing users, new users, admin users, etc. However, don’t forget that this same thing can happen to the VirtualStore in the registry as well. This makes it even harder to update people correctly as there will only be one UsrClass.dat mounted to HKCR\VirtualStore. To update the other users you will need to perform some API magic and use RegLoadKey and RegUnloadKey to sequentially mount, update, and unmount each of the other user’s registry VirtualStores.

OK, so that was ugly – is there anything worse?

I’m glad you asked that! There are indeed possible scenarios that would allow an application level “Denial of Service” (DoS) or escalation of privilege. Let’s take a common example: Microsoft Word. Let’s say that there is a registry key set at “HKLM\SOFTWARE\Microsoft\Office\11.0\Word\Security”. There is a value there called “Level” and it is a DWORD of 2 (which means Medium security). This security level causes Word to prompt the user before running any macros that are either unsigned or signed with an untrusted certificate. In today’s world on Windows XP a non-admin user has no way to change that value. It is enforced, even though it is not under the true “policy” section of the registry. However with virt, it becomes possible for code running as the user to “update” this value (it will cause it to virtualize into the user’s registry VirtualStore). When the application reads the value, it will see the virtual entry. So maybe it has been changed to a 1 for “low” which will allow any macro to run with no prompt. Now security has effectively been lowered for this user. It’s important to note that this would have no affect on other users on the machine. To help combat this, Microsoft has built some API’s that will allow developers to specify certain folders and registry keys to never virtualize. There is also an extendable list of file types that will never be virtualized. In fact, MS Office will be set to not virtualize any security related keys like this. Other applications (LOB apps, third party apps, etc.) may need to make use of the API to block certain files from being virtualized too.
How about troubleshooting machines?
That’s another good question. In general, it will be a bit harder to tell what the “real” settings are for a specific user. It won’t be enough to look in their HKCU and the machine HKLM to see the settings. You’ll also need to check both of their VirtualStores (the registry and the file system) to see what settings may be hiding there. In some rare cases, it may be necessary to delete the VirtualStore to be sure of the settings the user has.

In Summary

Taken as a whole, virt is our friend. It will hopefully allow deployment of Vista in a secure manner without requiring that all of the applications be fixed to be LUA aware. Just remember to beware the dark side of the virt.

LUA, UAC, and the split personality token

2005-12-17T16:13:00Z

With Windows Vista, you now have UAC or "User Account Control", sometimes known as PA or "Protected Admin". What does this mean in a practical sense? Well, for instance let's say you take a domain account (or a new local account) and place it in the Administrators group. With all prior versions of Windows based on Windows NT, that would be it - that user would be an Administrator when they logged on and could install all the spyware and trojan horses they wanted. When they clicked on "<SomeFamousPersons>Boobs.jpg.exe", it could do anything it wanted to the system. The least likely thing it would do is display what it sounds like it would in the title, right? Now, your account won't really BE an admin - at least not all the time.

A different style of logon
The login process now creates two tokens. The normal one that in our sample case would have granted admin rights (this one is held onto by the kernel and used only when you need to elevate), and a new token - based on the standard one - that is used for UAC. This new token has the Administrators group set as a restricted group or "deny only". So if you run "whoami /groups", you'll see

"BUILTIN\Administrators S-1-5-32-544 Group used for deny only"

(I chopped a bit of extra text out of that to simplify it, but it's clear that the token has been restricted. If you were to then run a command prompt "elevated" (by right-clicking the shortcut for the command prompt and choosing "elevate"), you'd get a different token. Run the "whoami /groups" again in that elevated command prompt and you'll see that you now have:

"BUILTIN\Administrators S-1-5-32-544 Mandatory Group, Enabled by default, Enabled Group".

As you can see - a different token.

All of the whining on the newsgroups and other places on the net that reduce to "my account is supposed to be an admin, but it can't do anything" are about either bugs or design elements with UAC and the restricted token. Take for example control panel applets. By the time we see final versions of Vista, the built in control panel applets will either prompt for elevation immediately when they are opened (if they have to; generally if all of their functions are administrative), or they will be re-factored to seperate any admin-required functions from their "per user" functions and will show a shield symbol and button to "enable" the admin functions. You'll need to click the shield and either hit ConsentUI (for users who are in the Administrators group but have the restricted token; this is just a "is it OK to do admin things" dialog), or hit CredUI (this is for folks who are not admins; they can then enter alternate credentials if they have them in order to elevate).

I know today there are a large number of scenarios where this just isn't implemented yet, or doesn't work. Many are due to "we haven't gotten to that yet", while others are just plain bugs. One of the first things I happened to encounter was when I logged on as a standard user, then needed to do some administrative work. I used my trusty method of starting a command prompt as the standard user, and then executing "runas /u:MyDomain\MyAccount cmd.exe". When I got my new command prompt, it should have admin rights since that domain account is my admin one and is in the administrators group. When I tried to run something that was on the standard user's desktop (by CD \users\...) I got access denied!

But I was an Admin! "Not today Zurg", Vista says. My runas had activated my restricted token. Not the most usable thing; the only reason I had done the runas was to get credentials that had admin rights. This, and other scenarios are ones that we need to see fixed before Vista RTM's. Today, with UAC on, the only account that never gets a restricted token is the builtin adminstrator account. That one, in our environment - following best practices, is scrambled. Both the name of the account and the password are 25 random characters and nobody knows them. No escrowing them, nothing. Domain accounts are used for all admin tasks. So all users who logon are either standard users or protected admins.

If you've been testing Vista, please make sure to file bugs on any problems that you have with UAC and elevation. Don't just rely on the built in administrator account to workaround it. You'll be doing the other enterprise customers out there a favor by submitting that bug and getting it fixed.

Why Toby can't backup

2005-12-15T03:28:00Z

One of the coolest things to come out of Microsoft’s soon-to-be-released operating system Windows Vista is a greatly enhanced ability to successfully run users as standard users. This is enabled by many features such as a revised design in the OS separating UI for admin tasks from UI for tasks that users should be allowed to perform (such as setting the time zone). Another enabler is the new file and registry virtualization technology that allows applications to succeed when they write to say C:\Program Files or to HKLM\Software. In that case, the write is virtualized to a location under the user’s profile with the application none the wiser.
However, at least one of the Microsoft feature teams seems to have completely missed the boat and fallen into the water. That’s right, they are all wet. As Short Round in Indiana Jones and the Temple of Doom would say, “haha, all wet, very funny!” Which feature is it that should throw in the proverbial towel? Would you believe it is SafeDocs? SafeDocs is the new incarnation of the old NT Backup that we all knew and… Wait. Well at least we knew it.

Toby is a LUser
No, not a loser! He is a “Limited User” with a Least-privileged User Account (LUA). He’s actually a standard “role” that Microsoft uses in scenario testing. In a similar fashion Abby is an administrator. For those that may be unfamiliar with these named roles, you can see a small example here: http://www.microsoft.com/technet/windowsvista/evaluate/sgtour.mspx.

So why can’t Toby backup?
That’s a great question that all enterprises should send directly to Microsoft. Why indeed? It turns out that the feature team that brings you SafeDocs believes that only administrators need to have docs that are safe. That’s right: you need to be an administrator to do a backup! I guess that pretty much throws out the ability for any home user to run as a non-admin. For many corporations this means evaluating and purchasing a replacement backup tool so that users can backup their files. This will mean either running as an admin (not too smart!) or raising Windows Vista’s TCO as you pay for a product and maintenance for something that used to be included in Windows for free. Interestingly, on Windows XP a non-admin user could perform a backup using NT Backup without any problem whatsoever.

Are there workarounds?
Yes, you can apparently configure the SafeDocs program via group policy. This of course means that the destination where the backup goes and the time it kicks off are now out of the user’s control. What if they want the backup to go to their home drive? How about a USB attached drive? Second hard drive anyone? The stock answer here is that “their admin can configure it for them.” Doesn’t that strike you as funny? In this day and age when people are interested spending less on IT support, Microsoft actually makes it sound like there is an administrator standing there behind every user ready to hook them up with the configuration that they need today. Maybe before logon, this admin will ask the user, “Where do you want to go today?” To which the user will respond that he just wants to make a backup and needs an operating system installed that will let him do it.

New type of answering machine needed

2005-11-27T20:11:00Z

Have you ever hit this scenario? The phone rings, and you answer it. You say "hello?" (or if you like to mess with people you say "Gut?" or "¿Hola?"). Then, a recorded voice comes on with "Please hold for an impor". This is cut off in the middle and music starts playing. After 20 seconds or so, someone comes on and says "Hello?". This one happened to me yesterday. I actually did hold the 20 seconds this time. I wanted to see what was so important to ME that I would think was worth the holding time, but so unimportant to them that they would hire a machine to call me and not bother connecting me to an agent for 20 seconds. (I'm on the "do not call list" by the way, so this had to be one of those millions of "exempt" groups like politicians, insurance, your credit card company, or anyone from whom you've ever bought something). Anyway, I hung up as soon as the person said "Hello?". I'm pretty sure it was Sears trying to get me to buy an extended warranty on some product I bought from them a couple of years ago. I think they got the priority wrong though: the message was important - but only to them, not to me.

The experience was similar to the endless polictical messages from the most recent elections although most of those were just recordings.

This all makes me think I need a new toy to combat this new extended method of wasting my time. I need (gasp) a new "call screening answering machine". Somehow, this new machine needs to not even allow my phone to ring until it has vetted the call. If it is one of these recordings the machine would pick up, detect the irrelevant call type, hang up, and I would never even need to know the phone rang. If it was a person, they would have to prove to the machine that their call should be routed to me. If it was someone I know, this could be very simple (I don't know, voice reco, something). If it was someone I don't know, I'd want this to be more difficult. Sure, build in the "right stuff" to cause real calls from emergency services type things to get through with no delay while still blocking the policeman's fund and the fireman's ball. Sorry guys, I gave at the office.

So what do you think? We've got spam filters for email. Who's down with a bozo filter for the real phone?