Using Orca to fix "the operating system is not adequate" MSI failures

Packaging up an MSI install for Windows 7 x64 I got this message-

"The operating system is not adequate for running [app]". Obviously Windows 7 x64 is adequate, but how do we get round this problem?

The simplest of all options is to right click the MSI and on the Compatibility tab tick the box "Run this program in compatibility mode for: Previous version of Windows". However, knowing that this is probably just a spurious error, I wanted to patch the MSI so that I don't need to worry about this condition in the future.

Launching Orca I can see straight away there is a LaunchCondition set that will probably be causing the issue-

(Version9X = 400) OR (Version9X = 410 And Not WindowsBuild = 2222) OR (Version9X = 410 And WindowsBuild = 2222) OR (Version9X = 490) OR (VersionNT = 400) OR (VersionNT = 500) OR (VersionNT = 501)

I could just remove the condition and save the modified MSI, but I always prefer to leave the MSI intact and create a transform file. So, from the Transform menu choose New Transform. The title bar will change to say "[app].msi (transformed by Untitled)".

Right click the row we want to delete and choose "Drop Row"

A green line should now appear through the row. From the Transform menu choose Generate Transform and save the mst file in the same folder as your MSI. I called mine platformfix.mst.

Now try installing the app. To check the transform is working, run the MSI without the transform, then with the transform. This command should return the original error-

msiexec /i Plastics.msi

Whereas this should bypass the version check-

msiexec /i Plastics.msi TRANSFORMS=platformfix.mst

Top 10 reasons to avoid Windows 7 32-bit

When considering a Windows 7 deployment you'll have the additional headache of whether to go 32-bit only, 64-bit only or a mixture of both. People in your organisation will have a requirement for 64-bit Windows for any number of reasons, such as large data set processing, or just to use all the RAM in the machine. With most systems shipping with at least 3GB of RAM these days, you really need a strategy on 64-bit Windows, but what should you do?

You should go 64-bit only! And this is why.

1. You'll have one less driver set to maintain
   
   If you are the person in charge of OSD then this should a concern. You really don't want to be maintaining extra sets of drivers for your machines when you don't have to.
   
   Windows 7 64-bit can't use 32-bit drivers, and the 64-bit drivers have to be signed. If you already use OSD for XP, you may end up with three driver sets for each type of hardware you have.
   
   
2. It's easier for the helpdesk
   
   User- "Hi, I've got a problem with my Windows. I think it's Windows 7."
   Desk- "Is it Windows 7 64-bit or 32-bit?"
   User- "Uhhhhh......"
   
   
3. It's easier for your technicians
   
   At the moment you probably only have Windows XP. Your techs can roll out some new machines without thinking. If you add Windows 7 x86 you'll suddenly give them 3 choices-
   
   1. Windows XP
   2. Windows 7 x86
   3. Windows 7 x64
   
   Why would they choose one OS build over another? What software/hardware requires a certain build?
   
   Wouldn't it be easier if they just had-
   
   1. Windows XP for legacy hardware/software
   2. Windows 7 (x64) for everything else
   
   
4. It's easier for you
   
   Let's say you want to disable Adobe Updater on all your Windows 7 machines. You roll out a registry key that contains the following information
   
[HKEY_LOCAL_MACHINE\SOFTWARE\Adobe\Updater]
"Enterprise"=dword:00000001

   You then realise that, although your 64-bit machines have the key added, it didn't take effect. This is because you had to deploy this instead
   
   [HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Adobe\Updater]
"Enterprise"=dword:00000001

   There's similar confusion to be had with %PROGRAMFILES%. This will resolve to C:\Program Files\ on both 32-bit and 64-bit machines. But some (not all) 32-bit apps install to C:\Program Files (x86)\ on a 64-bit machine instead.
   
   The 32-bit / 64-bit differences are confusing. Making your Windows 7 rollout 64-bit only can help.
   
   
5. Your users don't care
   
   Windows 7 looks and feels exactly the same to your end users whether it's the x86 or x64 version. If you can mitigate the potential hardware and software issues your users will face, give them the 64-bit version.
   
   
6. You have a perfectly good 32-bit operating system at the moment
   
   Windows XP is still perfectly fine for most environments. You understand it, and probably have a rock-solid image. Why introduce another 32-bit OS and a 64-bit OS at the same time? XP can be your 32-bit OS and Windows 7 can be your 64-bit OS. With MED-V you can even run both side by side.
   
   
7. You want to get rid of all those 16-bit apps
   
   Yes, you'll have issues with some apps when moving to Windows 7, so why not add to those problems by breaking all your 16-bit apps too? You should probably be looking at things the other way round - why is your business causing itself problems by running 16-bit apps?
   
   Moving to Windows 7 x64 can be a driving force to get the majority of these ancient apps off your network.
   
   Some of these apps are not mission critical. Get rid of them! When we were in the process of moving to Windows 7 x64 I found some apps that required Video For Windows 1.1 - we managed to get agreement to move away from stuff like this!
   
   
   
   For the mission critical apps - are they still supported? If not, why not? Are management aware of the risk to your business of continuing with these apps?
   
   There will probably be 16-bit apps you still need to run. If these can run in a sandbox, with no need for networking or printing you could use DosBox in conjunction with Windows 3.1. (If you have Software Assurance you should be able to use your downgrade rights to run Windows 3.1 in this way, but check with your Microsoft licensing person).
   
   For mission critical 16-bit apps that require networking look at MED-V. This MDOP component allows you to deploy and manage an XP virtual machine to your Windows 7 desktops.
   
   If you don't have 16-bit apps, you shouldn't have many problems moving to 64-bit Windows. If you do, consider this: Microsoft introduced 32-bit Windows in 1993 - the same year both Jurassic Park and Groundhog Day were released. You've probably got people from high school joining your organisation who are younger than those apps!
   
   (64-bit Windows drops support for OS/2 and POSIX apps too. The mitigation strategies for 16-bit apps should apply here too.)
   
   
8. You want to use more than 4GB of RAM
   
   64-bit Windows 7 can use up to 192GB of RAM. 32-bit Windows is stuck at 4GB of RAM, and even then, each process is only allocated 2GB of virtual memory. You'll start to see machines come with 4GB of RAM by default in the next 18 months.
   
   If this is not an issue for you now, it will be soon.
   
   
9. Kernel mode protection
   
   Windows 7 64-bit includes PatchGuard, a technology that prevents third party software from patching the kernel. (See Wikipedia for a good overview of benefits and limitations of this).
   
   PatchGuard will prevent 32-bit filesystem filters (such as some antivirus software), 32-bit network and video adapter drivers and 32-bit kernel mode printer drivers from installing. This is generally a good thing, as a poorly written kernel mode driver can cause the OS to bluescreen.
   
   
10. The majority of your machines probably support 64-bit Windows already.
    
    A common misconception is that moving to 64-bit Windows will involve replacing your entire desktop estate. It's hard to argue against this unless you have statistics. Try running the following report
    
SELECT
CASE V_GS_PROCESSOR.Is64Bit0
WHEN 0 THEN '32 bit'
WHEN 1 THEN '64 bit'
END AS [CPU Type],
COUNT(*) AS [Count]
FROM
V_GS_PROCESSOR
GROUP BY
V_GS_PROCESSOR.Is64Bit0

    
    Armed with this information you can make a more informed decision. Any PC bought in the last 3 years or so should be 64-bit capable. You may need to add more RAM, and check the graphics hardware has 64-bit drivers, but I'm willing to bet the majority of your machines are 64-bit.
    
    

A simple check to see if the TPM is enabled

The Deployment Guys have an interesting post on how to check if the TPM chip is enabled and activated as part of a task sequence (see here).

When we deployed Windows 7 we ran into the same problem. Our solution was a bit simpler!

Connecting to root\cimv2\Security\MicrosoftTPM and executing

select * from win32_tpm

will only return a value if the TPM is enabled. This can be added as a condition in your Task Sequence so that your Bitlocker steps only run if the TPM is on.



A note of caution though - this query does not check whether the TPM is activated. It only checks that the TPM is enabled.

Using DISM to fix a broken Windows 7 image

The best way to create your gold image is by running a build and capture in a virtual machine. The reason for this is that you don't get extra drivers hanging about in your image.

One of our team accidentally created a fresh image on real hardware. This image worked fine on most models, but failed on a Toshiba Tecra A11. After a long investigation it turned out that the image contained an old Intel network driver that would not work on the Tecra. Even though we had the new driver in our driver store, the Tecra would always choose the driver in the image. Not having a working network driver during OSD is a bit of a problem!

The solution is to use DISM to remove the drivers from the image*.

First of all, make a copy of your image and work on this copy. Once you've done this you need to mount the image. From an administrative command prompt run the following commands-

mkdir C:\mountfolder

dism /mount-wim /wimfile:yourwimfile.wim /index:1 /mountdir:C:\mountfolder 

Once the image has been mounted, run the following

dism /image:C:\mountfolder /get-drivers 

This should show you all the extra drivers that have been added to your image. The drivers will be listed as oem1.inf, oem2.inf and so on. Here's the sample output from an image I recently had to edit-

Deployment Image Servicing and Management tool

Version: 6.1.7600.16385

Image Version: 6.1.7600.16385

Obtaining list of 3rd party drivers from the driver store...

Driver packages listing:

Published Name : oem0.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7600.16385

Published Name : oem1.inf
Original File Name : prnms001.inf
Inbox : No
Class Name : Printer
Provider Name : Microsoft
Date : 21/06/2006
Version : 6.1.7601.17514

Published Name : oem2.inf
Original File Name : sthda.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem3.inf
Original File Name : sthda64.inf
Inbox : No
Class Name : MEDIA
Provider Name : SigmaTel
Date : 09/08/2005
Version : 5.10.4647.0

Published Name : oem4.inf
Original File Name : b57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

Published Name : oem5.inf
Original File Name : k57nd60a.inf
Inbox : No
Class Name : Net
Provider Name : Broadcom
Date : 02/12/2010
Version : 14.4.2.2

The operation completed successfully.

To remove, for example, the Broadcom k57nd60a.inf driver, just run the command

dism /image:C:\mountfolder /remove-driver /driver:oem5.inf 

You should see dism reporting success

Found 1 driver package(s) to remove.
Removing 1 of 1 - oem5.inf: The driver package was successfully removed.
The operation completed successfully.

Once you've removed the drivers you want, unmount the image and commit the changes

dism /unmount-wim /mountdir:C:\mountfolder /commit

And that should be that. Create a new OS install package and test your image. Once you're happy you can use that image instead of the original.

*Of course, the real solution is to recreate the image in a VM, but that's not always practical!