Take a company with more than 80,000 users who are administrators on their machines, mix in thousands of known applications, countless unknown ones, then just for kicks add in a move to 64 bit computing.  On top of that, give your users a new web browser and a new way of handling administrative permissions and you get a sense of the magnitude of deploying Windows 7 to Intel's enterprise.

Last year, Intel made a decision to skip deployment of Windows Vista in favor of Windows 7.  As a part of this, we partnered with Microsoft in their Technology Adopter Program (TAP) to assist in defining the OS and making it as bug-free as possible.  What Intel gained out of this is not only a stable and functional operating system, but an early look at what it would take to work within the constraints of a new security model.  As a result of these efforts, Windows 7 is now considered the "plan of record" Operating System for Intel.   Now the heavy lifting begins.

One of the heaviest lifts is application compatibility.  There are numerous vectors to "app compat", most of which require a significant investment.  In this blog, I will talk about User Account Control, 64-bit compatibility, IE8, and application compatibility with older operating systems.

The first, and most significant, is UAC (User Account Control).  UAC was introduced in Windows Vista, but for various reasons, it's implementation at most companies was delayed.  Microsoft has done a much better job with UAC in Windows 7, and it is Intel's intent to leave UAC on at the highest level, except for a few settings which simply cannot be deployed yet.  The best way to describe UAC is to talk about administrative access.  In Windows 7, a user can be an administrator, but not be provided administrative access by default.  This is described as a split token.  The security token has the capability to provide administrative access, but does not do so unless it first  "informs" the user that they are about to do something that requires administrative access, or the user does something to manually get around such a prompt.  If an application requires access to protected areas of the file system, or to the registry, it  informs a user about this need for  access by displaying messages on the desktop that the user is requesting something that requires admin control.  The user confirms that this is what they want to do, and the application proceeds.  The idea here is that a user will acknowledge it if they are aware they are doing it, but if some malware attempts to install something bad, the user will be informed, so they can deny the request.

Where this gets to be a problem is when an application is not written to inform the user.  In that case, the application just fails, with no message to the user as to why.  Microsoft has provided an easy solution to this problem; by right-clicking the application icon, the user can choose to "Run as Administrator", and the application proceeds with full administrative access.  If this resolves the problem, the user can choose to always run the application as administrator by changing the shortcut used to start the application.

A decision made by Intel during the TAP was that this was the time to make the move to 64-bit computing; this allows us to be prepared for future needs, as well as take advantage of the higher memory capability of systems available on the market today.  However, 64 bit computing brings with  it some significant challenges for application compatibility.  The primary challenge is that16 bit applications are no longer supported.  Initially, you would think this would not be a big concern; 32 bit computing has been around for many years, and most applications have been ported to 32 bit.  However, many legacy applications still exist in an environment such as ours that is required to support older operating systems; in addition, many application have been packaged using 16 bit installers.  These installers and applications will need to be changed.  How we are planning on handling that is discussed later.

Another issue with 64 bit Windows is that it uses a different path for 32 and 64 bit program files.  Applications that are hard coded to look for "Program Files" at runtime will fail when the application is installed in "Program Files (x86)".

The requirement to use Internet Explorer 8 introduces even more challenges.  Intel has delayed deployment of IE7 and IE 8 in our intranet due to known issue with some very important applications.  With the move to Windows 7, IE8 becomes a "must have" compatibility.  IE8 does offer an IE7 compatibility mode, which can mitigate some issues, but other applications are written to require IE6, and mitigation of these issues must be addressed.  There are also known issues with such things as Office Web Components, IE plug-ins, java versions, etc., that can really make this a challenge.

Finally, there are a whole lot of other issues that can crop up.  Such things as OS version checking, where an application is written to check for a specific version of the OS, rather than a minimum version, can cause an application to fail during either installation or runtime. 

What does all of this mean?  It means that a significant amount of work needs to be invested to prepare for Windows 7 application readiness.  Comprehensive application inventories,  application owner engagement,  user segment analysis, test environments, testing workflow, remediation plans & tools, and "safety net" environments all have to be  managed.  What do I mean by "safety net"?  This is a term we use internally at Intel for solutions that provide XP native functionality, usually in virtual environments.  We have some interim solutions in place using Windows Terminal Services and XP Mode, but we are also taking the time to look at all available options, including both client and server-based enterprise virtualization solutions.

I am currently working on a white paper that will provide a look at how Intel has dealt with these issues, which I will publish here as soon as it is available.  In the meantime, I would love to know how others are preparing for the move to Windows 7.  Do you see the same kinds of challenges that we do, or are there others lurking out there that we have not yet considered?

UPDATE:

I was remiss in not sharing the tremendous value we see in moving to Windows 7 in my earlier post. Any time a major company migrates to a new OS, issues will arise. We expect this and Microsoft is working closely with us on our deployment to ensure we have a fully compatible environment ready for Windows 7. So far, Intel’s deployment has been moving along routinely with no changes to either of our expectations for total success. Our deployment is on schedule and our expectation for success has not changed. You may have read this elsewhere, as we’ve shared it before, but it’s worth repeating. Intel expects to reduce operating costs by $11 million over the next three years using Windows 7 and, 97% of our employee early adopters said they’d recommend Windows 7 to their colleagues. So far, so good!