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:
Ability to use more than 4GB of memory. 32-bit OSs can address only up to 4GB of memory and that includes memory used by devices like graphics cards. So even if you have only 4GB of memory installed in your machine, with a 32-bit OS you can likely see only about 3.5GB of that RAM, as the other 500MB of address space is used by other hardware.
A 64-bit OS removes this 4GB limit, supporting much more memory: up to 192GB on Windows 7 Pro and above (for a complete list of all Windows releases, see the MSDN site).
When the OS can access more than 4GB of memory it also means applications can access the additional memory if they are 64-bit applications. A good example is the 64-bit version of Office 2010, which enables very large Excel and Project files to be opened. If your machine has more than 3GB of RAM you should probably be running 64-bit Windows.
Support for Unified Extensible Firmware Interface (UEFI. UEFI replaces the legacy 16-bit BIOS found in most machines (which was typically slow and limited to 1MB of memory, limiting its capabilities).
UEFI adds access to all memory. It supports 32-bit and 64-bit OSs, giving much faster startup and more capabilities and is found in most newer machines. UEFI also supports drives larger than 2.2TB (which when combined with GUID Partition Table (GPT) instead of Master Boot Record (MBR), which gives access to very large drives).
Only 64-bit OSs support UEFI. It allows faster initial boot and resume from hibernate in addition to supporting multicast Preboot Execution Environment (PXE) boot. More information can be found at the MSDN site.
- Additional OS integrity features. These include Hardware Data Execution Prevention (DEP) and Kernel Patch Protection, which are available only in the 64-bit version of Windows. Signed drivers must also be used for any kernel-mode driver.
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).
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_MACHINE\SOFTWARE, but on 64-bit Windows I need to look at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node 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.