Export (0) Print
Expand All

High-Volume Windows 8.1 Update

Using Configuration Manager to Deploy Windows 8.1 Across Microsoft

Technical White Paper

Published: February 2014


Download Technical White Paper, 984KB, Microsoft Word file


Executive Overview


Products & Technologies

Microsoft Information Technology (Microsoft IT) wanted to deploy the Windows 8.1 operating system as an upgrade to the Windows 8 release to manufacturing (RTM)–based computers in a rapid, phased manner. The intent of the deployment was to retain the user data and applications and execute the upgrade process with minimal user interaction on a large number of Windows 8–based computers already deployed in the environment. Microsoft IT accomplished this by using the Application Management feature of Microsoft System Center 2012 R2 Configuration Manager.

  • Ability to use the existing System Center 2012 R2 Configuration Manager infrastructure to deploy the upgrade worldwide at large scale
  • Preservation of user data and applications
  • Ability to use Configuration Manager to track deployment progress and for error reporting
  • Efficiency gains due to easier configuration and management than traditional deployment methods for operating systems
  • User-centric deployment of the Windows 8.1 upgrade with minimal interaction
  • High success rate, resulting in reduced helpdesk calls
  • Microsoft System Center 2012 R2 Configuration Manager
  • Windows 8.1
  • Windows 8


Dn582032.arrow_px_down(en-us,TechNet.10).gif Introduction

Dn582032.arrow_px_down(en-us,TechNet.10).gif Situation

Dn582032.arrow_px_down(en-us,TechNet.10).gif Solution

Dn582032.arrow_px_down(en-us,TechNet.10).gif Application Building

Dn582032.arrow_px_down(en-us,TechNet.10).gif User Experience

Dn582032.arrow_px_down(en-us,TechNet.10).gif Upgrade Process

Dn582032.arrow_px_down(en-us,TechNet.10).gif Windows 8.1 Reporting

Dn582032.arrow_px_down(en-us,TechNet.10).gif Report Customization for Rollback Scenario

Dn582032.arrow_px_down(en-us,TechNet.10).gif Wrapper Script Details

Dn582032.arrow_px_down(en-us,TechNet.10).gif Conclusion

Dn582032.arrow_px_down(en-us,TechNet.10).gif For More Information


This document provides details about how we (Microsoft IT) used Microsoft System Center 2012 R2 Configuration Manager for modern application deployment to deploy the Windows 8.1 upgrade seamlessly to the users of Windows 8 RTM–based computers. This document contains guidance for IT managers and IT administrators who want to handle similar situations in their organizations by using Configuration Manager. Though this document is generally limited in scope to an operating system upgrade from Windows 8 to Windows 8.1, it contains useful tips if you want to consider a similar solution for deploying the Windows 8.1 upgrade to Windows 7 users.


After the Windows 8 release in 2012, all Microsoft employees adopted it (with a few exceptions for testing of older products). When the Windows 8.1 upgrade was ready, we had to deploy it to approximately 220,000 Windows 8 RTM–based computers connected to the corporate network worldwide.

To encourage a rapid rate of adoption, we had the following goals for the Windows 8.1 deployment:

  • User-centric process: easy for users to initiate with a minimal number of clicks
  • Reduced complexity by taking advantage of native capabilities in the Windows upgrade process
  • Preservation of all user data, settings, and apps with no customization or configuration required
  • Ease of deployment, management, reporting, and support for Microsoft IT
  • Deployment in multiple cycles: around 20,000 computers for the preview build and 220,000 computers for the Windows 8.1 RTM/General Availability (GA) build

To meet these goals in such a high-volume upgrade, we opted for System Center 2012 R2 Configuration Manager as the primary solution.


To deploy the upgrade, we used the Application Deployment feature of Configuration Manager in conjunction with an internal tool called Company Portal as the user interface (UI) for end users. Company Portal is a modern application that enables Windows 8 users to install other modern applications directly with minimal user interaction.

The Windows 8.1 upgrade application merely opens the appropriate Windows Setup.exe file on a Windows 8 RTM–based computer, according to the processor architecture and the language of the operating system. The Configuration Manager client reports the success or failure of the setup process before the initial restart. It also reports on cancellations or compatibility issues that Setup.exe returns.

However, the Configuration Manager client does not control the upgrade application end to end, because Setup.exe performs the system restarts as a part of the Windows upgrade process. After the Windows 8.1 upgrade is successful, the CCMEXEC service automatically repairs the Configuration Manager client because of the change in the operating system version. After the client repair finishes successfully, the Application Evaluation cycle starts and reports on the success of the upgrade process.

Figure 1 shows the infrastructure that we used to deploy the upgrade.

Figure 1. Solution infrastructure
Figure 1. Solution infrastructure

Note: For the Redmond region where the bulk of computers are located, we dedicated 25 distribution points for hosting the Windows 8.1 upgrade package.

Application Building

This section describes the various configurations that we used while building the upgrade application in System Center 2012 R2 Configuration Manager.

Deployment Target

Company Portal is strictly a user-targeted UI. It is visible only when a targeted user is logged on to the system. We therefore deployed the upgrade application as an optional deployment targeted to a user collection. We used the user collection that included all full-time employees (FTEs) who did not have a Windows 8.1–based system at the time of deployment.

Note: A mandatory application deployment can be targeted to a computer collection or to a user collection.

Deployment Type Configurations

The Windows 8.1 upgrade supports five languages and two processor types for each language. So we were faced with 10 deployment types.

Requirement Rules

Table 1 shows the requirement rules that we established for the 10 deployment types.

Table 1. Requirement rules.

Deployment type

Required operating system

Required language

Required build

x64 English

Windows 8 64-bit or Windows 8.1 64-bit

English (en-us)

9200 or 9600

x86 English

Windows 8 32-bit or Windows 8.1 32-bit

English (en-us)

9200 or 9600

x64 German

Windows 8 64-bit or Windows 8.1 64-bit

German (de-de)

9200 or 9600

x86 German

Windows 8 32-bit or Windows 8.1 32-bit

German (de-de)

9200 or 9600

x64 French

Windows 8 64-bit or Windows 8.1 64-bit

French (fr-fr)

9200 or 9600

x86 French

Windows 8 32-bit or Windows 8.1 32-bit

French (fr-fr)

9200 or 9600

x64 Japanese

Windows 8 64-bit or Windows 8.1 64-bit

Japanese (ja-jp)

9200 or 9600

x86 Japanese

Windows 8 32-bit or Windows 8.1 32-bit

Japanese (ja-jp)

9200 or 9600

x64 Chinese

Windows 8 64-bit or Windows 8.1 64-bit

Chinese (zh-cn)

9200 or 9600

x86 Chinese

Windows 8 32-bit or Windows 8.1 32-bit

Chinese (zh-cn)

9200 or 9600

The Windows 8.1 build number value (9200 or 9600) is part of the requirements to allow reporting after successful completion of the upgrade. If Windows 8.1 was not listed as a requirement, the system would no longer meet the requirements after the upgrade, and the user would receive a "Requirements not met" message instead of a "Success" message.

Table 2 shows the basic conditions for the requirement rules.

Table 2. Basic conditions.

Requirement type



Operating system


All Windows 8 (64-bit or 32-bit) or All Windows 8.1 (64-bit or 32-bit)

Operating system language


(de-de, en-us, fr-fr, ja-jp, zh-cn)

Operating system build


(9200, 9600)

We had to create a custom expression for the build number, because nothing is set up for this by default. Because the default requirement rule for All Windows 8 and All Windows 8.1 systems also includes non-RTM builds, the build number requirement is needed to prevent systems that have non-RTM builds (>9200 and <9600) from being eligible to run the upgrade.

Detection Rules

Table 3 shows the detection rules that we configured to determine the successful installation of the Windows 8.1 upgrade application in each deployment type.

Table 3. Detection rules.

Detection rule


Presence of Registry HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion|CurrentBuild


Build number Value at HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion|CurrentBuild

Greater than or equal to 9600

Folder Structure

As shown in Figure 2, there is one folder per source location per deployment type (10).  

Figure 2. Folder structure for the 10 deployment types.
Figure 2. Folder structure for the 10 deployment types.

Each source location contains a copy of the WinBlue_Update.PS1 script, and a copy of the source content from the appropriate Volume Licensing media location, as shown in Figure 3.

Figure 3. Folder structure under each deployment type.
Figure 3. Folder structure under each deployment type.

Each media location has the file structure shown in Figure 4 for hosting the respective language media bits.

Figure 4. Installation bits in the media folder.
Figure 4. Installation bits in the media folder.

Other Deployment Type Settings

Table 4 lists the other important settings that we used in each deployment type.

Table 4. Other settings.





Command line

Powershell.exe -executionpolicy bypass -WindowStyle Hidden -NoProfile -file "winblue_update.ps1" -locale -mode pre

  • –Executionpolicy bypass: Allows Windows PowerShell to run regardless of normal restrictions.
  • –WindowStyle Hidden: Hides the Windows PowerShell window.
  • –NoProfile: Does not load custom profiles, and uses default Windows PowerShell settings.
  • –file "winblue_update.ps1" -locale -mode pre
  • <Locale>: Represents en-us, de-de, fr-fr, ja-jp, or zh-cn, depending on the language of the deployment type.
  • -mode pre: Tells the script that it is being run prior to Setup.exe.

User experience

Installation behavior

Install as System account (Upgrade will run under administrative rights all the time.)

Logon requirement

Only when user is logged on (User will be logged on when selecting to install.)

Installation program visibility


Allow users to interact with the program installation

Selected (User will see the Windows Setup Wizard and can cancel if wanted.)

Software installation program might force a device restart

Selected (Setup.exe will cause a reboot during the installation process, which allows the rest of the upgrade to continue.)

Maximum allowed run time

120 minutes

User Experience

Company Portal is a modern application that is installable on the Windows 8 operating system. Users who are running Windows 7 cannot install Company Portal, so they cannot use a modern UI for the Windows 8.1 upgrade. Besides, on Windows 7–based computers, the Windows 8.1 Setup.exe upgrade process does not retain all the applications that are installed on the system. Therefore, the described process can work only for an upgrade from Windows 8 RTM to Windows 8.1 through Company Portal.

Figure 5 shows how the Windows 8.1 upgrade appears in the Featured Apps area in Company Portal.

Figure 5. Windows 8.1 in Company Portal.
Figure 5. Windows 8.1 in Company Portal.

Windows 8 RTM

For a user running Windows 8 RTM, select Windows 8.1 Enterprise in the Featured Apps area of Company Portal opens the installation page shown in Figure 6.

Figure 6. Screen from which the user can install  Windows 8.1.
Figure 6. Screen from which the user can install Windows 8.1.

Shortly after the user clicks Install, a flag appears in the upper right of Company Portal. If the user clicks the flag, Installing Windows 8.1 Enterprise appears, as shown in Figure 7.

Figure 7. Indication that the user has started the installation application.
Figure 7. Indication that the user has started the installation application.

A couple of minutes later, a notification appears in the upper right to indicate that downloading has started.

Figure 8. Download notifications.
Figure 8. Download notifications.

A few minutes later, the actual installation begins. But if the user is still in Company Portal, he or she will not notice it until the system restarts or until the user switches back to the desktop.

Figures 9 and 10 show the screens that appear on the user's desktop during the setup process for the Windows 8.1 upgrade. The Cancel button shown in Figure 10 enables the user to cancel setup.

Figure 9. Initial Windows setup activities.
Figure 9. Initial Windows setup activities.

Figure 10. Setup screen when the installation is in progress.
Figure 10. Setup screen when the installation is in progress.

The Windows 8.1 upgrade was designed to be as fast as possible. Some of the higher-performance computers on a fast network can be upgraded in a little as 15 minutes. On a slower network and on slower computers, the upgrade can take up to three hours. Because it all occurs in the background, users can use their computers until the initial restart.

On the first day when we made the deployment available to all users, we received a few helpdesk tickets reporting that some systems took a longer time (two to three hours) to complete the Windows 8.1 upgrade. However, after first two days, we rarely received any helpdesk tickets related to slow installation time.

Windows 8.1 Pre-RTM Upgrade

The process does not support an upgrade from the Windows 8.1 pre-RTM build to the Windows 8.1 RTM/GA build. We sent a communication to the users of pre-RTM builds to use a fresh installation to upgrade their systems to the Windows 8.1 RTM build.

However, users whose computers have pre-RTM builds still see Windows 8.1 Enterprise as a featured application in Company Portal. Attempting to install this application on such computers will result in a "Requirements not met" message a few minutes later, as shown in Figure 11. A user who tries this must exit Company Portal and use another method of installing the Windows 8.1 RTM version on the computer.

Figure 11. "Requirements not met" message that appears when a user tries to install the upgrade on a pre-release build by using Company Portal.
Figure 11. "Requirements not met" message that appears when a user tries to install the upgrade on a pre-release build by using Company Portal.

Upgrade Process

The diagram in Figure 12 illustrates the flow of the upgrade process.

Figure 12. Process flow.
Figure 12. Process flow.

Note: The process does not work if the user is off the corporate network, because the UI must communicate with the Configuration Manager hierarchy to receive the installation policies. If the user is logged on to the corporate network through remote access, the upgrade process does work. However, we do not recommend updating remotely because downloading the installation bits of around 3.6 gigabytes (GB) over slower links can take a long time.

Administrator Context

The user must run Setup.exe with full administrative rights. If the user is not an administrator, the script will stop running and return an error code of 0x20000009. To avoid such a scenario, the application is configured to run under system context (which should always be an administrator), so that it runs successfully.

Folder Structure Check

Setup.exe completes a very basic check of the folder structure by verifying that the setup files can be found and accessed. If the script cannot find and access the files, it will stop running and return an exit code of 0x2000000A.

Script Local Copy

For post-upgrade checks (see Figure 14.) to run. The installation process copies the wrapper script locally and creates a scheduled task to run after the process is complete.

Pre-upgrade Checks

Just before a computer runs Setup.exe as part of the upgrade process, a registry key is stamped with information about the state of the operating system. Figure 13 shows what this information includes.

Figure 13. Custom stamping of the registry.
Figure 13. Custom stamping of the registry.

Scheduled Task

The upgrade process includes a task that is scheduled to run when the system starts and the user logs on after the upgrade is complete. The task records information about completion in the registry, as shown in Figure 14. After the information is recorded it identifies specific details (such as total time for installation and status of installation) about the upgrade. [Noun] then sends these details to the appropriate primary site as a custom status message.

Figure 14. Information recorded in the registry.
Figure 14. Information recorded in the registry.

Setup Parameters

Setup.exe runs with the following parameters:

  • /auto:upgrade. Run through the wizard without user interaction.
  • /noautoexit. If an error occurs during setup, do not exit. Wait at the appropriate wizard page for user input.
  • /performdu. Pull down needed dynamic updates.

The possible scenarios and related outcomes of the setup/upgrade process are as follows:

  • Setup.exe does not finish properly or ther user cancels.
  • Setup.exe finishes, but something causes a rollback.
  • Setup.exe finishes, and the upgrade finishes successfully.

In each of these scenarios, Setup.exe runs the scheduled task and sends the result details.

Setup Wizard Exit Status

If Setup.exe does not initiate a restart, the Windows PowerShell wrapper script takes over after Setup.exe stops running. At this time, the Windows PowerShell script runs the same command that was scheduled via the Task Scheduler. The Windows PowerShell script does the following:

  • Reads \$Windows.~BT\sources\panther\setupact.log and looks for a line that contains ‘CONX Exit code ='2013-09-10 13:29:00, Info     CONX Exit code = 3
  • Uses the exit code number to determine the result:
    • 1: User cancel
    • 3: Reboot required
    • 5: Compatibility check
    • 7: Auto install failure
    • <Line not found>: Unexpected/Unknown exit out of setup.
  • Stamps the result into the registry
  • Stamps the other details into the registry
  • Sends details to the reporting location
  • Deletes the scheduled tasks

Setup Wizard Finishes, but a Failure Occurs Before the Upgrade Finishes

After Setup.exe starts successfully, the system initiates a restart to continue with the upgrade process. During the rest of the upgrade process, if a failure occurs, the system triggers the rollback of the operating system.

When a rollback occurs, the operating system reverts to its original setup. This includes any scheduled tasks that were set up (including the one that was created for this purpose). After the rollback occurs, and the system is restarted and the user logs on, the scheduled task runs and Setup.exe does the following:

  • Detects that the operating system is still the same version
  • Detects that this is a result of a rollback
  • Stamps the result into the registry as rollback
  • Stamps other details into the registry
  • Sends the details to the reporting location
  • Deletes the scheduled task

Note: If an unexpected restart occurs while Setup.exe is running, Setup.exe treats it as a rollback.

Setup Wizard Finishes, and the Upgrade Finishes Successfully

As part of the upgrade process, Windows migrates any scheduled task for which it can find the task's executable file under the new operating system. The tasks created earlier will run after the system restarts and the user logs on. Setup.exe then performs the following tasks:

  • Detects that the operating system is a new version
  • Determines that the upgrade was a success
  • Stamps the result into the registry
  • Stamps other details into the registry
  • Sends details to the reporting location
  • Deletes the scheduled tasks

Note: Because the task will not run until after the upgrade is complete, the system restarts, and the user logs on, the details will not be available in Configuration Manager immediately after the upgrade process finishes. There may be a lag time between completion of the process and data availability for reporting.

Capturing the Status

After the installation process writes the before-and-after details in the registry of the system the information is sent to the site server in the form of a custom status message.

Configuration Manager provides software development kit (SDK) calls that you can use to create custom informational messages. The scheduled task uses the recorded data in the registry when sending the status message. Messages are deleted during the normal deletion cycle for status messages in site configuration.

Windows 8.1 Reporting

You can use the standard System Center 2012 Configuration Manager reports to monitor the status of the deployment. However, because we had to create customization around generating and reporting Setup.exe status in a detailed manner, we created custom reports. The data in the reports is very close to real time (margin of up to two hours, from our observation), and we run the reports against the Central Administration Site (CAS) database.

Standard Windows Setup Codes

Table 5 lists the exit codes that Windows 8.1 Setup.exe generates and the custom mapping for these exit codes in Configuration Manager.

Table 5. Exit codes from Setup.exe.




Configuration Manager mapping



User initiated cancellation




Expected success




Likely cause: compatibility check needs resolution




Likely cause: installation option (upgrade, data only) was not available


We observed that sometimes, Setup.exe does not return the standard exit codes during failures. In such cases, the process generated the custom codes shown in Table 6 to report accurately on the failures.

Table 6. Custom error codes to categorize failed installations.




Non-Administrative rights


Folder structure not set up


Unknown result

Reporting Considerations

A summary report tracks the progress of the deployment. System Center 2012 Configuration Manager  generates this report against the CI_CurrentComplianceStatus table in the Central Administration Site (CAS) database that hosts the state data for enforcement states and compliance states of an application.

As described earlier, the Configuration Manager client loses control over the Windows 8.1 upgrade application installation, and the process abruptly ends when the first system restart happens through Setup.exe. In such a scenario, the Configuration Manager client returns the error code 1073807364 (0x40010004), and the application state changes to "Compliant" only after the subsequent application evaluation cycle runs successfully. The state of all such clients is categorized as "In Progress - OS upgrade in progress. Waiting for post install evaluation to clear Setup script termination error 1073807364."

In general, System Center 2012 Configuration Manager uses the logic around the enforcement state, compliance state, and error code (wherever available) to determine the detailed status of the Windows 8.1 upgrade application installation on the computer.

The summary report has the following details:

  • The top table displays data based on the enforcement state and compliance state of the application on targeted user computers.
  • The middle table provides operating system data collected from an Active Directory Domain Services system discovery process scheduled to run delta discovery every hour.
  • The bottom table represents the number of computers rolled back to Windows 8 during the setup process. Configuration Manager collects this data from custom status messages.
  • The pie chart illustrates the status indicated in the top table.

Figure 15 illustrates the summary report.

Figure 15. Summary report.
Figure 15. Summary report.

Selecting the number of errors from the summary report shows details about the errors, grouped by error code description, as shown in Figure 16.

Figure 16. Errors returned from the user computers in the deployment
Figure 16. Errors returned from the user computers in the deployment.

For easy troubleshooting, you can drill down further in the summary report to get details about the failure of an individual computer. These details include computer name, domain, user, organizational unit (OU), error code, and more, for easy troubleshooting. Figure 17 shows the column headings that appear in the report.

Figure 17. Column headings for the drilled-down report that provides individual computer details.
Figure 17. Column headings for the drilled-down report that provides individual computer details.

Report Query

The Transact-SQL query for reporting the summary data is available at:


Report Customization for Rollback Scenario

During the Windows 8.1 setup, if any of the prerequisite checks (for example, application incompatibility, unsupported driver, insufficient disk space) fail, Setup.exe rolls back the computer to the original operating system (Windows 8). For the upgrade deployment at Microsoft, we captured the rollback scenario by using the following customization. The helpdesk used these details to assist users in remediating the issues and completing the upgrade at a later stage. We also occasionally use the customization to determine the approximate time required to complete the upgrade process on specific computers, for troubleshooting user complaints about long installation time.


When a system has been imaged through Microsoft IT's standard imaging solutions, details are placed in the HKLM\SOFTWARE\MicrosoftIT\ITStatusUI hive. We store details of the Windows 8.1 upgrade under the Microsoft IT key for ease of finding them:



Result Codes

The result codes are based on the result codes from the Setupact.log file that Setup.exe logs to. For a list of result codes, refer to Table 5 earlier in this document.

The result codes are therefore limited. To ensure that the result is a known code and not an unexpected result, we use a user-defined-code mask for all error codes that are returned (0x20000000). Any results that do not have this mask are unexpected results.

In addition to the results that we pull from the Setupact.log file, we can use custom error codes. For a list of custom codes, refer to Table 6 earlier in this document.

All result codes (other than 0) that the upgrade script returns should have the 0x20000000 bit set. If a return code does not include 0x20000000, the error is coming from outside the script execution.

Query for Custom Status Message Data

The following TSQL Query Language returns the results of the upgrade process, as seen through the scheduled task that runs after completion. We can use other queries to get other results, but this is most useful to discover systems that failed after initial restart and had to roll back to the original operating system.

SELECT msg.MachineName,msg.InsString2 AS Result,InsString3 AS StartTime,InsString4 AS EndTime,InsString5 AS Locales,InsString6 AS Versions FROM  

v_StatMsgWithInsStrings msg

LEFT JOIN v_StatMsgAttributes atr ON msg.RecordID=atr.recordid

WHERE MessageID=39997 AND msg.InsString1='WinBlueUpd_RTM'


Wrapper Script Details

To upgrade computers from Windows 8 RTM to Windows 8.1, we developed a Windows PowerShell script as a wrapper to start Windows 8.1 Setup.exe. This script is available at:


You can attempt to upgrade Windows 7 to Windows 8.1 by using the same script, after further testing. By identifying the operating system version, 6.1.7601, on the Windows 7–based computer, you can use the wrapper script to enter an appropriate Setup command:

Setup.exe /auto:dataonly /noautoexit /performDU

However, the upgrade experience is different from the experience of updating from the Windows 8 RTM version. In an upgrade from Windows 7 to Windows 8.1, the previously installed applications will not be migrated because Windows 8.1 Setup.exe does not support application migration in this scenario. The user must reinstall appropriate applications after completing the Windows 8.1 upgrade.

Note: The other deployment type configurations detailed in this document will also need modifications, but that is out of the scope of this document.


At Microsoft IT, we successfully used the Application Management feature of System Center 2012 R2 Configuration Manager for deploying the operating system upgrade (from Windows 8 to Windows 8.1) to several thousand computers. We found the process easy to manage and scalable to deploy in a large-scale environment like ours. We can efficiently track the deployment status by using the state and status messages that Configuration Manager receives from the client computers during the deployment. The user experience is vastly improved from previous upgrades, because starting the Windows 8.1 upgrade on a Windows 8–based computer requires just two clicks in Company Portal and retains all the data and applications without further manual intervention.

For More Information

For more information about Microsoft products or services, call the Microsoft Sales Information Center at (800) 426-9400. In Canada, call the Microsoft Canada Order Centre at (800) 933-4750. Outside the 50 United States and Canada, please contact your local Microsoft subsidiary. To access information via the World Wide Web, go to:





© 2014 Microsoft Corporation. All rights reserved. Microsoft, Active Directory, SQL Server, Windows, Windows Intune, and Windows PowerShell are either registered trademarks or trademarks of Microsoft Corporation in the United States and/or other countries. The names of actual companies and products mentioned herein may be the trademarks of their respective owners. This document is for informational purposes only. MICROSOFT MAKES NO WARRANTIES, EXPRESS OR IMPLIED, IN THIS SUMMARY.


Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
© 2015 Microsoft