Q: I'm going to roll out Windows 7—should I deploy the 32-bit or the 64-bit version?

A. Windows 7 64-bit has become a lot more prevalent, with many organizations standardizing on 64-bit over 32-bit. However, you need to consider some key factors and ultimately remember that although you may want to standardize on 64-bit, some machines might still need the 32-bit version.

If you have a solid enterprise software deployment system like System Center Configuration Manager, having two images (a 32-bit and a 64-bit) shouldn't add too much complexity to the environment.

Before you can deploy 64-bit, you need to make sure the hardware supports 64-bit, which means a 64-bit–capable processor. However, most machines that are not Atom based and made within the last few years should be 64-bit processors.

To help find out if your organization’s machines are 64-bit capable, you can use the Microsoft Assessment and Planning Toolkit  to gather inventory on your machines and produce readiness reports.

Assuming your machines are capable, why would you want to run 64-bit Windows? There are numerous benefits mostly around hardware capabilities:

So why wouldn't you run 64-bit Windows? Assuming the hardware supports 64-bit Windows, it sounds like a no-brainer—and if you look at new retail machines, most do ship with the 64-bit version of Windows.

However, for organizations, there are additional considerations that, though they may not stop 64-bit roll out, should definitely be considered.

Applications are typically a big concern for organizations considering 64-bit Windows. The good news is 32-bit applications should run great on 64-bit Windows.

The Windows on Windows 64-bit (WoW64) subsystem provides a Windows 32 bit environment that enables the execution of 32-bit code, so the fact the applications are mostly 32-bit shouldn’t pose a problem.

Still,  testing should be performed. In Figure 1 below, we see a list of processes on my machine—any process with *32 next to it is actually a 32-bit program, and you can see there are many (even Internet Explorer, which we'll talk about later).

process32bit_0

Note that 16-bit applications are a different matter, and 16-bit applications, while compatible with a 32-bit OS (thanks to a process known as thunking, which allows 16-bit code to run on a 32-bit OS) aren’t compatible with a 64-bit OS and won’t run.

If your organization has 16-bit applications or applications that use a 16-bit installer, you should find an updated version of the application or setup program that is 32-bit or 64-bit.

f there is no updated version of the application, then look at typical application compatibility solutions, such as running the application on a remote 32-bit Terminal Service/Citrix XenApp type environment or running locally in a 32-bit Windows XP virtual machine (VM) using technologies like MED-V or XP Mode.

There are a few exceptions to 32-bit code running on 64-bit OSs. Any low-level OS interfacing application such as antivirus software or a firewall or anything that installs a driver must be 64-bit.

You can’t install 32-bit drivers on a 64-bit OS, so you need to ensure you have, for example, 64-bit malware and VPN applications, and you need 64-bit drivers for all your hardware (which for any modern piece of hardware should not be a big issue).

Some applications are now providing 64-bit versions—but just because you choose to run a 64-bit OS, should you always run the 64-bit version of the application?

It would seem the answer would obviously be yes, but that's not always the case. Office 2010 is a great example, with both 32-bit and 64-bit versions available. Although the 64-bit version of Office 2010 gives the ability to access very large Microsoft Excel and Project files, it also adds some compatibility challenges as most add-ins for Office are currently 32-bit and you can’t load a 32-bit add-in to the 64-bit version of Office.

There may also be challenges calling Windows APIs from Visual Basic for Applications (VBA) within 64-bit Office. Over time, most add-ins will be available as 64-bit, but until then most organizations choose to deploy the 32-bit version of Office 2010 with 64-bit versions deployed by exception when the Excel/Project large file support is needed. You could make the 64-bit versions available using application virtualization technologies like App-V (which has full 64-bit support).

A similar situation exists for Internet Explorer (IE). You’ll notice if you run IE on a 64-bit OS, it actually runs the 32-bit version of IE as the default, as 64-bit Windows ships with both a 32-bit and 64-bit version of IE.

The reason is that most add-ins and ActiveX components for IE are 32-bit, so the same problem we faced for Office exists with IE. The easy solution is to run the 32-bit version of IE by default. If you need the 64-bit version of IE (for a really big web page), then you can manually launch the 64-bit version of IE that’s found on the Start menu as Internet Explorer (64-bit). However, realize that most add-ins won't work.

Finally, make sure you consider the differences between 32-bit and 64-bit Windows when you look at management, including your scripts and processes. With 64-bit Windows, you have additional file system locations for the storage of 32-bit applications and libraries, so when you look for programs you would need to ensure your scripts and processes know the right location to look or the target may not be found.

For example, on 32-bit Windows I would look at C:Program Files for applications, but on 64-bit Windows I need to look at C:Program Files (x86) for 32-bit applications.

The same applies to the registry: On 32-bit Windows I may look at HKEY_LOCAL_MACHINESOFTWARE, but on 64-bit Windows I need to look at HKEY_LOCAL_MACHINESOFTWAREWow6432Node for 32-bit application information.

Remember you don't have to go all 64-bit. You may be able to deploy 64-bit for most machines but keep some 32-bit deployments for application or hardware requirements.

However, the majority of the environment can still take advantage of the 64-bit Windows benefits.