Home :

Is Now The Time To Deploy 64-bit Windows?

The Windows client operating system has had a 64-bit version available since Windows XP Professional x64 Edition was released in 2004. Unfortunately third-party driver support for this version of Windows was limited at the time, which meant that users who installed it were often unable to use their printers, scanners, and other peripherals. When Windows Vista became available in early 2007, it boasted much improved third-party 64-bit driver support, but the reality was that in many cases the support simply wasn't there, limiting memory access still to 3GB.

So where does this leave us today? If your organisation is currently running Windows XP on your client computers and you are eager to move forward with migrating your client computers to Windows 7, should you take the plunge and deploy only 64-bit Windows 7 if the chipsets in all your systems support it? Well we suggest that there is virtually no reason any longer to prefer 32-bit over 64-bit Windows, provided you are going to deploy Windows 7 on x64 systems that are only a year or two old.

Here is a short list of reasons why you should choose a 64-bit Windows 7 edition over the 32-bit edition:

  • If you want to get the best performance possible, there are three things you can do: use a faster processor, add more RAM, or replace your drive with a Solid State Disk (SSD) drive. Processors are often tied to motherboards, so replacing them is not trivial. RAM is cheap now, and boosting your system's memory to 4, 8 or even 16 GB is cost effective. Good SSDs are still very expensive however—much more so than RAM. So if you want to boost your performance while keeping your budget under your control, adding lots of RAM is the way to go, and 64-bit Windows 7 Ultimate edition can use up to 192 GB of RAM if your system's motherboard can hold that much.
  • The 64-bit version of Windows 7 only occupies a couple of more GB on your hard drive than the 32-bit version.
  • If your users rely on some mission-critical 16-bit applications then you might consider installing the 32-bit version of Windows 7 instead of the 64-bit version. That's because 64-bit Windows 7 doesn't support running 16-bit applications. However, you can get around this issue by using Windows Virtual PC and the Windows XP Mode environment, which lets users run a virtual instance of a 32-bit Windows XP operating system on Windows 7 while still being able to take advantage of the many enhancements and new features now available. There's one catch: the user's system must support hardware virtualization (Intel VT or AMD-V) in order to run Windows Virtual PC.
  • Virtually all peripherals sold in the last couple of years have 64-bit drivers available for them. Most peripherals these days use USB as their interface with the computer. Windows Virtual PC and the Windows XP Mode environment supports USB.

Microsoft Deployment Toolkit

Microsoft Deployment Toolkit 2010 is the newest version of Microsoft Deployment Toolkit, a Solution Accelerator for operating system and application deployment. MDT 2010 supports deployment of Windows 7 and Windows Server 2008 R2 in addition to deployment of Windows Vista, Windows Server 2008, Windows Server 2003, and Windows XP.

MDT 2010 is the latest version of MDT and has a lot of changes over the previous version MDT 2008 Update 1.

A big change in MDT 2010 is that distribution shares and deployment points are now combined into a single thing called a deployment share. This change simplifies the process of preparing and using your MDT-based deployment infrastructure. Here are some additional enhancements concerning deployment shares:

  • Deployment shares can be hosted on local drives, network shares, or in a standalone DFS namespace
  • Multiple deployment shares can be opened at the same time in the Deployment Workbench
  • Deployment shares can be managed from any machine where the Deployment Workbench is installed—provided the NTFS and shared folder permissions are appropriate on the share
  • Deployment shares can be linked so that when the content of one share is updated the content in the other share is also updated

Another big change in this version of MDT is that the underlying scripting logic has been migrated from VBScript to Windows PowerShell. In other words, most of the tasks you perform using the Deployment Workbench are actually accomplished using Windows PowerShell commands. In addition, you can use Windows PowerShell commands directly to perform various MDT configuration and management tasks and automate them, something that was difficult to do in previous versions of MDT as it required editing complex scripts.

The Deployment Workbench, which is the integrated workspace from which you can perform all of your deployment-related tasks, has also been enhanced in MDT 2010. For example, you can now create a hierarchical tree of folders in each deployment share in order to help you organize items such as operating systems, device drivers, and task sequences for that share. Plus you can cut/copy/paste and drag/drop items within these folder trees. And you can use selection profiles to manage groups of similar items (such as device drivers for a specific type of machine) as a single item. These changes all make it easier than ever to manage your deployment resources and tasks.

Finally, there are a number of other enhancements in MDT 2010 relating to security, stability and performance. For example, you can now refresh a computer that has a volume protected by Windows BitLocker Drive Encryption without having to decrypt and re-encrypt the protected volume. This makes this particular refresh scenario more secure and much faster than before.