Managing Windows 7 and Windows 8 Side-by-Side
Recommendations and Best Practices for the Enterprise from Microsoft IT
Technical White Paper
Published: March 2013
The following content may no longer reflect Microsoft’s current position or infrastructure. This content should be viewed as reference documentation only, to inform IT business decisions within your own company or organization.
This white paper discusses the planning, line-of-business application compatibility, imaging, security, and backend system considerations and experiences of the Microsoft IT team when managing desktop and laptop machines running Windows 8 and Windows 7 within the same corporate network. Many of the techniques and best practices described in this paper can be employed by other companies to help them streamline their side-by-side client system management processes – and ultimately to ease their transition to Windows 8.
Technical White Paper, 336KB, Microsoft Word file
Products & Technologies
With the recent availability of Windows 8, Microsoft IT needed to prepare for the large-scale introduction of the new operating system into the same corporate network where client systems running Windows 7 are still being managed.
Microsoft IT planned for side-by-side management of both client operating systems by thoroughly testing for LOB application compatibility, reviewing and updating their system imaging, security, and backend system management processes to accommodate the new OS.
With more than 150,000 users in 89 countries connecting 300,000 client systems to Microsoft's corporate network, Microsoft Information Technology (Microsoft IT) is responsible for managing one of the largest enterprise infrastructures in the world. The rollout of Windows 8―the company's flagship client operating system―requires Microsoft IT to manage systems running the new operating system within the same environment where other client machines are using Windows 7.
The intent of this white paper is to discuss the planning, line-of-business application compatibility, imaging, security, and backend system considerations and experiences of the Microsoft IT team when managing desktop and laptop machines running Windows 8 and Windows 7 within the same corporate network. Many of the techniques and best practices described in this paper can be employed by other companies to help them streamline their side-by-side client system management processes―and ultimately to ease their transition to Windows 8.
This paper assumes that readers are technical decision makers who are already familiar with managing clients running Microsoft Windows 7 and Microsoft Internet Explorer® 9.
Note: This paper is based on Microsoft IT’s experience and recommendations and is not intended to serve as a procedural guide. Each enterprise environment has unique circumstances; therefore, each organization should adapt the plans and best practices described in this paper to meet its specific operating system management needs.
Adopting new client operating systems is a process that organizations typically undertake every few years to keep their machines up to date and to support the latest applications. In some cases, a company might develop a formal plan to migrate existing hardware to a new operating system (OS) to gain the benefits offered by the new OS. The number of new operating systems in a company can also grow over time as users purchase devices that run on the latest OS and connect devices to the corporate network.
For enterprises whose daily operations depend on the proper functioning of an array of line—of-business (LOB) applications, any transition to a new generation of operating system most likely will require time and effort to test and validate compatibility of their business-critical applications with the new OS. In a perfect world, organizations would be able to update all their machines to the latest operating system instantly with the push of a single button. But the reality is that the speed of shifting client systems from an older OS to a newer one varies from company to company. Businesses with a culture of rapid adoption might promote a short transition time, yet more conservative entities might plan for a prolonged period where different versions of operating systems are found throughout the corporate network.
Regardless of the pace of the adoption of a new operating system, the factor for any company to consider is to plan for a time period when the IT team must manage the old OS and the new system together in the same corporate network. So if this adoption of new operating systems is a necessary and recurring aspect of an enterprise's operations, what impact does the process have on corporate IT teams? How should they plan to manage an environment where the new version of the operating system is running side-by-side with other systems that still use an older OS? What compatibility issues might there be? What security considerations are there? How should IT best manage system images in such an environment?
In the following sections of this paper, we will discuss these considerations in more detail, focusing on Microsoft IT's enterprise strategy for deploying, testing, and managing Windows 8 desktop and laptop systems with other Windows 7-based machines in a managed environment. Each section also provides best practices to help enterprises streamline how they manage multiple client operating systems within their own corporate network.
How well an IT team plans for supporting multiple client operating systems side-by-side within their corporate network will determine whether deployment and management of the mixed-OS environment is relatively streamlined or burdensome.
There are three major areas that must be considered when planning for any new operating system deployment:
- Compatibility with existing line-of-business (LOB) applications and other business-critical applications
- Deployment of the new operating system
- User education about the new operating system
The following sections discuss each of these areas in more detail.
The starting point for any accurate assessment of application compatibility is an understanding of the underlying environment. This is a fundamental requirement: the IT department must have a good understanding of their own infrastructure, including details concerning the current types and versions of client operating systems, service packs, version of Internet Explorer used for web-based LOB applications and their dependencies on plug-ins, and so forth. Without this knowledge, there is no means to create an effective plan to manage change.
However, surveying the existing OS ecosystem is just the beginning in the quest to determine LOB application compatibility with a new OS -- especially when the new OS comes in various versions to support desktops, laptops, tablets, and smart phones. Effort must be made to survey all applications in use and identify the subsets that are business-critical. For Windows 8, this research might include determining which types of tablets and smart phones are used to access the key LOB applications.
The resulting information can be used to build a test matrix of the type and level of testing that should be performed on each key application running on Windows 8. In addition, the test matrix should identify whether the application is an executable that runs directly within the OS, or whether instead it is a web-based application, which might require web browser testing in addition to the OS testing to confirm compatibility.
Tip: Knowing which applications are the most critical in your environment and what technologies are used by these applications will help you determine which applications must be tested with the new OS.
Microsoft IT's Approach to Compatibility Checking
Microsoft IT is similar to other enterprises in that it manages large numbers of domain-joined clients and servers within their corporate infrastructure. A top priority is to ensure Microsoft IT has a good understanding of its managed client systems, applications, and dependencies. Consequently, Microsoft IT performs monthly reviews of System Center 2012 Configuration Manager data to understand the business. From an application portfolio perspective, Microsoft IT also performs annual (and sometimes more frequent) reviews to align with product releases.
Out of approximately 1,300 applications, Microsoft IT focuses iterative (repeated) testing on about 85 key business continuance applications during each compatibility test cycle. In addition, Microsoft IT performs voluntary testing of additional non-critical applications on an ad hoc basis, which expands the total number of applications tested to approximately 400. In total, this set of applications represents the most critical, most used, and typically most complex applications in the portfolio.
Web Applications Versus Desktop Applications
With approximately 94 percent of Microsoft IT's application portfolio being web-based, Microsoft IT focuses most of its compatibility testing on any browser updates that come with a new version of Windows. These tests are designed to learn how incorporating a new OS might affect any key web-based LOB application.
At the end of an application compatibility test, Microsoft IT has identified the set of applications that are confirmed to work within the new Windows 8 environment, as well as the subset of applications that have some aspect that is incompatible with Windows 8. This latter set is flagged to remain running on Windows 7 for the time being. When appropriate, details concerning application incompatibilities are noted so that once the particular technology dependency is resolved in the future, the application can be considered to be compatible with Windows 8.
After the infrastructure is well understood, dependencies are mapped and application-OS incompatibilities are identified, the next major area IT must tackle is defining how the new operating system will be deployed―and to whom. The following areas must all be considered by the IT team that is planning to deploy the new OS.
- How will the new OS be deployed? Is the new OS being deployed to existing hardware, or is new hardware with Windows 8 already in place being distributed to employees? When upgrading existing systems, will it be a user-driven event or backend-driven via policy? For managed deployments, what will the mechanism be―management tools like Microsoft System Center 2012 Configuration Manager Operating System Deployment? If no existing solution is in place, a company might want to plan to build out a new management solution before tackling the OS deployment.
- Who gets Windows 8? Not all enterprises will want to have users decide what OS to run and when they should make the change. In fact, some organizations might need to mandate who gets what and when. Should the deployment process be prioritized by role or by department? What criteria should be used? Is there a compelling business function for a certain group that can be enabled with the new OS? Furthermore, what devices does this group use? Should all their systems receive the new OS or just their primary machines? Will new devices with the new OS be deployed, or will existing devices be upgraded? Which existing devices are able to be upgraded? What is the common screen size in use by the most productive workers? What network access edges are most prevalent for over 50 percent of the client census? For wireless? For mobile broadband? If the organization is always connected at scale and mobile, what is the calculated benefit of Windows 8 rapid boot time and expanded battery run time? Is there another customer problem solved or a sale that could be landed in that extra two hours' capacity of the mobile workday?
- What impact will the side-by-side deployment have on support? IT must work closely with the company's support team to ensure they will be ready to offer support to employees when they have questions concerning Windows 8. Consider the expected timeline for the transition period when both Windows 7 and Windows 8 are actively supported. What does this mean in terms of call volume? How similar or different are the two supported operating systems, and how might that map to planning for changes to support call volume?
- What impact will the side-by-side deployment have on administration? Building and maintaining multiple images is an obvious factor. Regardless of the selected deployment mechanism, IT must be able to distribute images for both operating systems to the end users. That process could be fairly simple if the deployment will be user-driven, but placing restrictions on which department or user role can access a particular image can add complexity. How will IT admins control who has access to which images?
- What deployment considerations should be addressed for LOB application standards for modern applications? Organizations must manage a separate process to develop and deploy Modern applications that run in Windows 8. Are the LOB developers familiar with the Modern application development process and tools? Do they know how to deploy the applications through the corporate application store? Has support for the corporate application store feature been enabled for Windows 8 users to access? Are users aware of the corporate application store, and do they understand that the applications are only supported on Windows 8 systems? Do users know how to register their Windows 8 devices so they can access the store? In addition, consider the following points:
- A policy has to be applied to allow for sideloading of LOB applications so that the Windows 8 clients will install and run applications from outside of the public application store.
- If applications are installed through a corporate application center, that will relate to a product or service that is generally used for the purpose of security controls and reporting, such as Windows Intune.
- Application developers need to learn not only about how to make good Modern applications but especially to understand the differences in security when developing them.
Note: Security considerations are covered in more detail in a later section of this paper.
Microsoft IT’s Approach to Windows 8 Deployment
At Microsoft, the corporate culture is one of rapid adoption of the latest technologies with relatively few administrative mandates for client systems. Instead of making prescriptive changes to domain-joined systems, Microsoft IT encourages users to adopt the latest and greatest OS while allowing them to choose when to make the change.
The technical background of Microsoft employees enables Microsoft IT to promote self-installation of client operating systems. The expectation is that users should be able to perform most client OS installations on their own with minimal assistance from the company's support team.
Knowledge is what enables this type of deployment. For Windows 8, Microsoft IT wanted to provide users with clear guidance to help them make appropriate choices of which OS to use for each device. To do so, Microsoft IT:
- Reviewed the actual user installation experience and compared it with the expected installation experience.
- Developed scenarios based on these experiences to help guide users with the end-to-end user self-installation process.
- Established a pilot program to test the installation scenarios and to validate that the process was effective.
- Determined that the call volume for Windows 8 was comparable for Windows 7, and then rolled out a production-scale program based upon the positive results of the pilot.
- Created a special internal website and produced additional user-oriented communications to educate users about the availability of upgrading their systems to Windows 8 and where they could obtain more guidance about the process. The site offered FAQs, lists of top and known issues, and other related information to help users self-serve their move to Windows 8.
Note: More information concerning Microsoft IT's user education for Windows 8 self-installation is provided in the following section.
The third aspect of planning for a new operating system deployment is educating users on any application compatibility issues and describing what the deployment process will be. To ease user adoption of a new OS, the IT team should consider the following:
- What recommendations to make? When a new OS becomes available to employees, which OS should they use? What choices do they have, and how will people know what they are? Were any incompatibilities with existing LOB applications identified that should be communicated?
- Who to contact? As discussed in the deployment considerations previous section, who receives communications and guidance concerning the new OS―everyone? Only select groups? Will IT initially target a small group to help test the communications and overall process before sending out communications corporate-wide?
- What training materials to develop? How will employees learn about the availability of the new OS and what options they have? What types of materials should be created to help users gain familiarity with the new OS? What types of scenarios will be covered? Will information be posted in a new portal or Microsoft SharePoint® site? Will quick reference guides or short, how-to videos be created to help end users with initial installation, configuration, and basic usage?
Microsoft IT's Approach to User Education
Developing an effective set of materials to educate employees about self-installing and using Windows 8 was critical to Microsoft IT's success in driving this process as a self-installation process. In order to help users help themselves, Microsoft IT:
- Created a custom internal application that provides a "one-stop shop" for all sorts of information about Windows 8 and how to install it.
- Built a number of task-oriented training materials such as Work Smart guides and/or how-to videos to help users onboard to Windows 8 quickly. Topics included:
- Navigating the new Start screen
- Working with the new Internet Explorer 10 browser that comes with Windows 8
- Connecting to devices, such as printers
- IT services, including using virtual private networks or Direct Access to connect to the corporate network remotely
- Launched a moderated forum called Pointers where:
- Users can help other users with Windows 8 questions
- Moderators track and help resolve issues
- Microsoft IT could identify and update their materials to better serve the self-installation effort
- Understand your environment. First and foremost, you must perform a thorough survey of your systems and identify what OS and browser dependencies your LOB applications and other business-critical applications have. Not knowing one's environment can be an automatic blocker to adopting any new technology―OS, application, or otherwise. Only by understanding your environment can you accurately identify which subset of applications should be tested and where incompatibilities are most likely to occur. Although such a survey can require time and budget, knowledge of your infrastructure is the foundation that enables good decision-making for any future change. Microsoft IT regularly surveys the company's infrastructure and performs compatibility testing for each new OS and browser release for desktop, tablet, and smartphone platforms.
- Find the right balance between too much and too little testing. Unless you are dropping support of an older OS after a new OS becomes available, adding support for a new OS can effectively double your compatibility test matrix. Estimate the additional time and cost required to perform each type of test and balance its impact against the criticality of the particular application's compatibility. Over time, Microsoft IT has built a list of a subset of applications that are tested on each new Windows OS. These represent applications that are critical to business continuance as well as those most likely to have issues with OS changes.
- Keep as much of the client environments between Windows 8 and Windows 7 the same. Promote use of the same browser and the same version of Microsoft Office to minimize the amount of variables that you must test. This allows you to focus your testing on what is specific to the new OS.
- Plan for a pilot. Start small. Test and validate that things work as expected. Expand the scope of your pilot until you are into production deployment. Microsoft IT used this approach, deciding to work with a small number of systems that initially tested only with Internet Explorer 10’s desktop style browser (which resembles Internet Explorer 9). Over time, the tests have expanded to include many more users and testing on Internet Explorer 10’s modern style browser (which is a leaner version of the browser that mirrors the Windows 8 look-and-feel).
- Create targeted user training to streamline adoption and potentially reduce support calls. Being proactive with your communications and providing clear educational material is essential for any self-installation effort. Furthermore, the more information is readily available to end users, the less likely they are to contact your support team for help.
Enterprises that run browser-based LOB applications need to consider the impact that a new web browser that comes with a new OS might have on their operations. When considering browser-based LOB application compatibility and Windows 8, compatibility has more to do with the differences between Internet Explorer 10 Classic Browser and Modern Browser than the OS-level differences between Windows 7 and Windows 8.
When considering web browsers and browser-based LOB applications in Windows 8, the IT team should consider the following:
Which technologies are supported by which browser. A new feature of Microsoft Internet Explorer version 10 is that it is now available either in Classic Browser (the traditional look-and-feel similar to Internet Explorer 9), or in the new Modern Browser (whose style reflects the new Windows 8 look-and-feel). In many ways, the Classic Browser is functionally equivalent to Internet Explorer 9, supporting many plug-ins and extensions. The Modern Browser, however, is a simplified subset of Classic Browser functionality that does not support Microsoft Silverlight® or any Microsoft ActiveX® plug-in except for Flash. Therefore, browser-based LOB applications that depend on plug-ins are more likely to be incompatible with Modern Browser.
How to ensure LOB applications correctly identify the new browser. Based on the survey of an enterprise's infrastructure that was described in this paper's Planning section, are there any ASP applications running Microsoft ASP.NET 2.0? If so, has the patch that enables ASP.NET 2.0 to recognize the Internet Explorer 10 2-digit value correctly been installed sitewide? How are the browser-based applications coded to parse the user agent (UA) string―will they at least treat any new browser as equal to or greater than Internet Explorer 9?
Microsoft IT's Approach to Browser Testing
As discussed previously, approximately 94 percent of the company's LOB applications are browser-based. Consequently, Microsoft IT focused a significant proportion of its application compatibility testing on Internet Explorer 10.
Microsoft IT tested browser compatibility by:
- Testing for browser-based LOB applications compatibility on Internet Explorer 10 Classic Browser on Windows 8. This initial test sequence ran through two complete test cycles that comprised 403 applications on Classic Browser and 346 applications on Modern Browser. Each application had its own test process that reflected its functionality, ranging from a half-dozen manual test cases for simpler applications to hundreds of test cases for some larger, automated applications.
- Including as close to 100 percent of the primary applications as possible within each test cycle, plus whatever voluntary applications were selected for testing in a particular cycle.
Note: The list of voluntary applications is not consistent from test cycle to test cycle. New applications may be tested on subsequent test cycles that were not previously tested, and previously tested applications may not be tested again.
- Providing separate compatibility results for Classic and Modern Browsers in a single report to help users understand what to expect when using either browser.
- Try to reduce the scope of your test matrix. A complete browser-based application compatibility test matrix includes two operating systems (Windows 8 and Windows 7), three platforms (desktop, tablet, and smartphone), two browser versions (Internet Explorer 10 and Internet Explorer 9), and two forms of browser per platform (Classic Browser and Modern Browser). How you reduce scope depends on what relevant compatibility testing you have already performed.
- If you have already performed browser-based application compatibility testing for Internet Explorer 9 on Windows 7, you can reduce your testing on Internet Explorer 10 on Windows 8. Why? Internet Explorer 10 is more standards-based than Internet Explorer 9. Therefore, if your application is compatible with Internet Explorer 9, it is likely to be compatible in the Internet Explorer 10 Classic Browser.
- If you have not yet performed any Internet Explorer 9 testing or if you want to future-proof your environment as much as possible, then focus your compatibility testing using Internet Explorer 10 on Windows 8. Assuming you will not have users working with Internet Explorer 9, limit your compatibility testing to Internet Explorer 10 to gain the benefits of its improved W3C compliance and enhanced security features.
- Focus your compatibility tests using Classic Browser. Classic Browser's support of browser plug-ins and extensions makes Classic Browser more likely to be compatible with your LOB applications. This is an easy approach that should provide compatibility results very similar to Internet Explorer 9.
- Perform shallow testing on Modern Browser. Modern Browser's lack of support for Java, ActiveX, Silverlight, and other plug-ins translates to a greater likelihood that more applications will be incompatible. Consider limiting your Modern Browser testing to a small set of applications or to a specific scenario that needs to be supported (such as Field Sales personnel using Windows Phone 8 devices who need to access a particular LOB application in Modern Browser).
- Profile your applications properly. As mentioned previously, any web application that performs specific tasks or formatting based on the browser version should have its script updated to recognize Internet Explorer 10 as a new browser. Furthermore, any site that uses ASP.NET 2.0 should also be updated so that ASP.NET will properly recognize Internet Explorer 10. At a minimum, any current updates to your site code should either identify a new browser as Internet Explorer 9 or greater. Ensure that your web pages use page-based redirect or site-based redirects as appropriate.
Effective management of client OS images begins with a good understanding of an enterprise's infrastructure and knowledge of the desktop LOB applications that are in place and their dependencies. One obvious concern for IT administrators who are managing machines running Windows 8 and with other systems running Windows 7 is imaging support for the two operating systems. Which differences in the operating systems require modifications to how an enterprise manages its client images?
From a compatibility perspective, desktop applications that work in Windows 7 are likely to run in Windows 8 without requiring any change in their code. However, there are other differences between Windows 7 and Windows 8 that could effect client OS images:
- Customization of the start screen: The start screens are treated differently between Windows 7 and Windows 8. In Windows 8, the Start screen has effectively supplanted the Desktop metaphor. The Windows 8 Start screen is the "prime real estate" whose content and look-and-feel can be controlled by administrators if a team or organization wants to standardize the user experience. Do existing Windows 7 images have applications, shortcuts or other items pinned to the desktop? How will these items translate to the new Windows 8 Start screen? Are there variations of how the Start screen should appear to different teams or
Tip: Using the AppFolderLayout.bin file to control the default Windows 8 Start screen layout is documented on TechNet.. This technique gives administrators total control over the appearance of the Windows 8 Start screen, which is the new system's prime real estate. The "Desktop" is no longer a key interface component in Windows 8.The Start screen is more than a new look and feel. It is a key resource whose contents and layout can be customized by enterprise administrators to standardize employee user experience―and even to offer specific configurations for various departments or roles.
- Managing language packs: Language packs are installed and managed differently between Windows 7 and Windows 8. In Windows 8, the Input Method Editor (IME) decouples the various language settings, such as the keyboard layout is now independent of the OS language. For multinational enterprises, which language settings should be taken into account for client OS imaging? Is there a need for systems in locations that support multiple languages to have multiple language packs installed?
At Microsoft, each user is the administrator of their own machine, so there is no need to manage multiple personas. Instead, Microsoft IT uses a single persona that highlights key internal resources and applications for all domain-joined Windows 8 systems.
Microsoft IT also offers guidelines on what applications can be published as a part of corporate standard image and controls which applications go into the default package. General guidance includes:
- Include applications which are relevant to 95 percent of the user population.
- Applications should meet the "productivity enhancer" application rule. Examples of these are Microsoft DirectAccess, Microsoft IT VPN, Microsoft Office, and other applications that are used by a large percentage of employees on a daily basis.
- Customize and/or standardize the Start screen enhance the user experience. With Windows 8, administrators have the opportunity to define the look-and-feel and content that appears on users' start screens. For certain companies that restrict administrative access of client systems to IT administrators, a set of Windows 8 images could be created with different pre-defined Start screen experiences that cater to the needs of various teams, roles, and regions (such as, Sales, HR, Finance, Executive, Americas, and Europe).
- Confirm that your images are bundled with the appropriate language packs and settings. If your enterprise is global and supports multiple languages within your systems, ensure that your standard image includes the relevant language packs. Microsoft IT currently supports five languages in its default client installation images.
- Utilize Unified Extensible Firmware Interface (UEFI) mode in your client OS images to improve system boot time. Windows 8 has been fine-tuned to take advantage of the 64-bit UEFI mode that effectively replaces the older and slower 16-bit BIOS mode. Windows 7 can also be deployed in UEFI mode so be sure to build images that utilize UEFI to speed boot times for all UEFI-compatible hardware for both Windows 7 and Windows 8.
Note: Security aspects related to UEFI are discussed in this paper's Security section.
Management of many security aspects in Windows 8 is similar to Windows 7, so enterprises who have been working with Windows 7-based clients can leverage most of their security processes with minimal change. However, there are a few aspects of client OS security that should be considered when managing a side-by-side Windows 7-Windows 8 infrastructure:
- Security differences between Modern applications and traditional applications. When working with Modern applications, keep the following points in mind:
- By design, Modern applications run in a sandboxed environment, and therefore they do not have the same system access that a traditional application does. Remember that a traditional application can do anything that the user account has authorization to do. New for Modern applications is the requirement that they must list which capabilities they do have.
- Whereas users can install traditional applications from any source, Modern applications can only be installed from approved sources―and they must be signed using a certificate from a trusted authority.
- In addition to installing Modern applications from the public store, there can be other Modern application sources, such as a Windows Intune Company Portal. With the Company Portal, IT departments can manage their own application catalog for deploying their own LOB Modern applications. Additionally, Microsoft IT put some Modern applications into the install build on the internal deployment servers.
- Supporting UEFI on Windows-compatible hardware. In addition to improving system boot time as discussed in the previous Imaging Considerations section, UEFI offers security benefits that include supporting boot hard drives larger than 2.2 TB and mitigating security issues traditionally found in root kits and boot kits. But older hardware might not be UEFI-compatible. Even if a corporate policy is adopted to ensure that all new hardware is compatible, how will the IT department manage the existing systems running on incompatible computers and peripherals? Will IT managers migrate their user base to the secure boot profile to prevent undetected tampering exposures in legacy boot OEM hardware?
- Touch devices and BitLocker PINs. Organizations who have a corporate policy to use Microsoft BitLocker® with a personal identification number (PIN) need to be aware of applying such a policy to touch devices that have no keyboard, as they will not have the ability to enter PINs. How does IT detect a tablet device and apply an alternate policy that does not enforce a PIN?
- Potential conflicts between EAS policies and group policies. Windows 8 uses Microsoft Exchange ActiveSync® (EAS) to set certain policies on the system. If the same machine is also receiving group policies, policy conflicts can occur if multiple management systems are configuring the same settings―such as what period of inactivity will prompt the system to lock the device's screen. This can be a special concern for users who are working with a variety of different domain-joined devices. If not properly planned and managed, the flexibility of Microsoft Active Directory® in applying GPs differently to different machines might result in conflicts. For example, are policies set at the user role and therefore likely to cause conflicts between the user's different devices? Consider the following possible issues that can arise from Windows 8 machines obtaining policies from various sources (such as Active Directory, EAS, System Center 2012 Configuration Manager, and Windows Intune):
- The same machine gets multiple configurations for the same thing (such as screen lock timer) from multiple sources. Although the more strict policy is enforced, the result may confuse both users and IT.
- Variable user experience. For example, a domain-joined laptop running Windows 7 that is not using the Modern Mail application
(which is available only on Windows 8) might be locked after 15 minutes. However, a domain-joined Windows 8 machine that is using the
Modern Mail application might be locked after 5 minutes. These different behaviors might also be confusing if someone was expecting a
certain behavior (such as lock mail after 15 minutes), but he or she experienced a different behavior (such as lock mail after 5 minutes)
because a more restrictive policy was applied to the same machine from a different policy source.
Figure 1: Multiple policy sources might confuse Windows 8 users and IT.
Keeping these potential conflicts in mind, have all client OS policies been reviewed and aligned across policy sources such as Windows 8 System Center 2012 Configuration Manager and Windows Intune?
- Password syncing between personal and corporate systems. In both Windows 7 and Windows 8, the Credential Vault is used to store cached passwords. The potential security and privacy issue arises when a user links a personal account in Windows 8, because these passwords could be synced between devices. Although the sync password setting is off by default and users need to explicitly opt in to sync passwords, organizations might want to establish a policy to disable password syncing on domain-joined machines. Has the IT team established group policies to control the syncing of passwords through the Credential Vault?
- Setting policy for AppLocker for Modern applications. Windows 8 maintains a separate policy for Microsoft AppLocker® for Modern applications as opposed to the traditional AppLocker settings for applications found in a Windows 7 environment. What this means for domain-joined machines is that the Windows 8 domain-joined machines will get the same AppLocker settings for traditional applications that Windows 7 machines do. But if there are AppLocker policies that IT wants to apply to Modern applications on Windows 8 systems, they will have to manage a separate set of AppLocker policies for Modern applications in addition to managing their existing traditional AppLocker policies for traditional applications on both Windows 8 and Windows 7.
- In order to gain the security benefits of UEFI, Microsoft IT is implementing UEFI mode on all machines whose hardware is UEFI-compatible, as default for Windows 8-based systems, and for Windows 7 machines by running the UEFI-compatible mode with support for legacy BIOS.
- Microsoft IT has enabled a group policy for employee devices that connect to the corporate network. By default, the policy will not synchronize information such as browser favorites and browsing history, but users can explicitly change the setting to synchronize data if they wish.
Note: This policy helps protect privacy when employees connect their devices using the same Microsoft account that is also used on non-work machines.
- Microsoft IT configured the synchronization of users' web browser settings, history, and favorites to be enabled but set to off by default. When a user connects their personal Microsoft account (formerly known as a Live ID) to their Active Directory logon on a particular device, this configuration allows them to enable the synchronization if they want to, but synchronization will not occur with the user specifying it.
- Even before deploying Windows 8, Microsoft IT created an AppLocker policy for Modern applications that was configured to allow all applications to run. The proactive testing and deployment of the policy allows Microsoft IT to block a Modern application at any point in the future simply by configuring the application to be blocked.
- Adopt UEFI wherever possible. The security benefits UEFI brings to client systems are significant. Consider establishing a purchasing policy to ensure that all new client hardware is UEFI-compatible. If there are UEFI-compatible systems that are currently running Windows 7, consider upgrading them to Windows 8―or if there is a need to stay with Windows 7, consider running UEFI in its compatibility mode.
- Review group policies and EAS policies that apply to Windows 8 systems to ensure there are no overlaps or conflicts. Make sure to review your policies and to confirm which system is using policies to control the appropriate settings on client systems. You might also want to consider educating your support team and your user community about the options they have when working with different devices. This might help mitigate potential policy conflicts.
- Be proactive in testing and deploying Windows 8 policies. Given that Modern applications and AppLocker for Modern applications are new, IT should test and deploy policies proactively for Windows 8 systems and Modern applications. Early testing mitigates the risk of encountering a problem with a Modern application in the future and not already having the appropriately vetted policies in place to block it quickly.
The final area of consideration for managing a Windows 7-Windows 8 in a side-by-side environment relates to backend systems and which technologies or settings might need to be adjusted.
Ccmexec is the System Center service (agent) that runs on both Windows 7 and Windows 8 client systems. However, in Windows 8, the "always on, always connected" state of a client machine enables ccmexec to operate much more intelligently, optimizing when maintenance tasks are activated. This is achieved by ccmexec determining whether to run processes based on the following:
- Network state: Is it connected to LAN or WLAN?
- Power state: Is the system running under AC power or on battery?
- Idle state: How much CPU and drive activity is there?
- Existing/pending maintenance processes: Does Windows Automatic Maintenance already have maintenance processes running or pending?
Microsoft IT incorporates changes across products to ensure the best user experience and consistency, based upon the following guidelines:
- Avoid periodic CPU activity. Use event-driven designs instead (assuming average frequency of events is low (under 1Hz)). Remove polling, spinning, and endless loops. Performance team members can help investigate how to implement event-driven functionality.
- Use a coalescable timer with periodicity of 1 second (or a multiple of 1s) and set the tolerance parameter to an acceptable value when the previous guideline is not or is only partially doable. Threadpool timers are another viable alternative.
- Tolerance parameter rules of thumb: Maximum of either 25 percent of the periodicity or 300ms.
- Use true periodic timers rather than repetitive "one shot" timers.
Important: Do not base dependencies on the expiration of any timer. Scheduling expectations might be broken for application threads during idle periods, especially when the screen is off and/or the user is not present.
- Avoid periodic disk activity (logging, timestamps, watchdog-style behavior) and minimize explicit synchronization (meaning, write-throughs, and flushes). This allows Disk Coalescing to reduce power consumption of the storage subsystem.
- Avoid periodic network activity. Radios (especially those utilizing the 3G wireless band) can be very expensive. A Windows 8 centralized notification infrastructure that batches network I/O and decouples network requests from server responses can be leveraged to reduce excessive network activity.
- All periodic activity should cease when the display is off or the user is not present. When a system becomes inactive and the display is turned off, make sure to halt all activity – including stopping rendering of any UI updates.
- Do not adjust system timer resolution. Leave it at the default tick rate. All audio and video playback should use hardware codec offloads if available to avoid timer resolution changes.
- Convert background activity to tasks. The task scheduler provides flexibility in initiating and executing background code. Custom triggers, schedules, and conditions can be defined. Background activity that doesn’t need to occur more than once per day (such as data scanning or archiving) should be deferred to the maintenance hour, which executes when it is the most energy efficient and least impactful to the user experience (typically when the machine is connected to a power source and the user not present).
- Optimize hot code paths for performance. In general, accomplishing the same work with fewer resources saves power.
- Ensure that dependencies do not break the above guidelines. If you are dependent on external platforms, libraries, or APIs, make sure to test your code for periodic activity and resource usage.
- Optimize your client system maintenance by combining Windows 8 with System Center 2012 Configuration Manager. When reviewing how your backend system maintenance systems manage domain-joined client machines, combine Windows 8 and the System Center 2012 Configuration Manager agent (ccmexec) as much as possible. Doing so enables you to benefit from the intelligence ccmexec obtains about the operational state of the Windows 8 machine―and from its automatic optimization when maintenance processes are run.
- Build similar operational state intelligence into packages for Windows 7 systems. If you want to approach a similar level of operational state intelligence (such as to deploy software only when a PC is connected to a wired LAN) for your Windows 7-based systems running ccmexec, you will need to build custom "checks" into your package/application model executables.
- Align policies across all backend server systems. Review client-side policies that are being sent by all backend systems, including Configuration Manager, EAS, and ActiveSync, so that Windows 8 desktops and laptops have a consistent set of policies. Microsoft IT is currently reviewing the full set of group policies that include Configuration Manager, EAS, ActiveSync, and Windows Intune, to ensure that all new Windows 8-based machines are aligned with existing policies that are used on Windows 7 systems across the enterprise.
Over time, IT departments will support newer client operating systems―it is not a question of if, but when and how. The rate of technological change continues to accelerate. Cloud technologies, the rapid proliferation of smart mobile devices, and the consumerization of IT are challenging enterprises to determine how to best manage all these domain-joined machines and the various operating systems that they run.
The time to start planning is now. IT must take the lead on determining the best client OS management processes and must communicate their recommendations and policies to employees. The objective should be to minimize the impact on the business by leveraging a common image between the two operating systems that uses the same Internet Explorer, Microsoft Office, and other core applications; only the operating system is different. This will minimize compatibility test requirements and save on costs.
Of course, each organization is different. Although there is no "one size fits all" approach that companies should follow when determining how to best manage Windows 7 and Windows 8 machines in the same corporate environment, every IT department should properly plan, test, and configure their environments to best support managing both Windows 8 and Windows 7 systems.
For enterprises, LOB application compatibility is a top concern. Having a long-term mixed environment of Windows 8 and Windows 7 systems might influence LOB application updates or new application development, because Modern applications will not run on the Windows 7 systems. Similarly, browser-based LOB applications might have additional functionality restrictions based on what browser is in use. By standardizing on Internet Explorer 10 and providing versions of your LOB applications that can run in Modern Browser or Classic Browser, you can minimize your development costs and provide the optimal user experience regardless of which system users are running.
Any time an enterprise is going to allocate resources for LOB application development effort, the common sense approach and the best means of mitigating risk to business operations is to take the "low hanging fruit" first. Instead of trying to convert an existing complex LOB application as a Modern application, focus on developing a smaller, more targeted Modern application that complements the existing application. The Modern application could perform a subset of the complex application's functions where the touch elements and other immersive capabilities available in Modern applications offer the best productivity gains. As an example, the finance department might have a large monolithic LOB application that includes a function for people to use when reviewing and processing expense reports. Building a Modern application that provides a greatly improved user experience for expense report processing―one that could run on a variety of mobile devices―could significantly improve Finance's productivity with a relatively small-scale development effort.
Enterprises also need to think through their strategy for connected accounts when onboarding Windows 8. You should expect to leverage your current investment in group policies, making incremental changes for some new features. However, Microsoft IT strongly recommends that you review your entire set of existing group policy objects and remove any unnecessary ones to maximize system performance.
Now that Windows 8 is here, take the opportunity to review how you manage all domain-joined desktop and laptop clients―Windows 7, Windows Vista, and other systems in addition to your new Windows 8 machines. You can also review your management processes on a larger scale: Windows 8 automates many important security processes such as BitLocker encryption, but what are you doing to help secure older systems? IT departments should make this review period an opportunity to improve their overall security strategies.
By following the best practices discussed in this paper, Microsoft IT was able to drive down costs for onboarding and deploying Windows 8 into the same managed environment where Windows 7 is used. And Microsoft IT has adjusted its client system management processes to accommodate the side-by-side support of both operating systems. As with all enterprise-scale IT shops, Microsoft IT is working on improving its client system management processes. And Microsoft IT hopes that the considerations and best practices offered in this paper might help you streamline your own processes to simplify administration and drive down costs when onboarding Windows 8.
For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada information Centre at (800) 563-9048. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary.
For more information about the various subjects discussed in this paper, visit the following locations on the World Wide Web:
Microsoft main site: http://www.microsoft.com
Microsoft IT Showcase: http://www.microsoft.com/technet/itshowcase
Planning and Preparing Links
Plan for Windows 8
Windows 8 Work Smart Guides
Work Smart productivity guides: http://technet.microsoft.com/library/bb687781.aspx
Internet Explorer Resources
Microsoft IT Tests Line of Business Application Compatibility for Internet Explorer 9
UEFI and Windows: http://msdn.microsoft.com/windows/hardware/gg463149
Use the ApplicationsFolderLayout.bin file to control the default Windows 8 Start screen layouthttp://technet.microsoft.com/library/jj134269.aspx
The information contained in this document represents the current view of Microsoft Corporation on the issues discussed as of the date of publication. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information presented after the date of publication.
This White Paper is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED, OR STATUTORY, AS TO THE INFORMATION IN THIS DOCUMENT.
Complying with all applicable copyright laws is the responsibility of the user. Without limiting the rights under copyright, no part of this document may be reproduced, stored in or introduced into a retrieval system, or transmitted in any form or by any means (electronic, mechanical, photocopying, recording, or otherwise), or for any purpose, without the express written permission of Microsoft Corporation.
Microsoft may have patents, patent applications, trademarks, copyrights, or other intellectual property rights covering subject matter in this document. Except as expressly provided in any written license agreement from Microsoft, the furnishing of this document does not give you any license to these patents, trademarks, copyrights, or other intellectual property.
© 2013 Microsoft Corporation. All rights reserved.
Microsoft, Active Directory, ActiveSync, ActiveX, AppLocker, BitLocker, Internet Explorer, SharePoint, Silverlight, SkyDrive, and Windows, are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries.
All other trademarks are property of their respective owners.