Today we have guest author for this blog. Peter Felts is a Senior Program Manager in the developer platform group and is going to discuss Display Scaling improvements and changes with Windows 10 Anniversary Update (version 1607)

Overview

Steve Wright’s previous blog post about display scaling for high dots-per-inch (DPI) displays in Windows 10 does a great job of giving an overview of the concepts of how Windows handles DPI scaling. In this article I’m going to focus more on the technical side of what we’ve been working on for the Windows 10 Anniversary Update to help improve the display-scaling story for desktop applications. Note that most of what this article discusses does not apply to Universal Windows Applications (UWA) as they already handle display scaling well.

During Windows 10 significant work was done to improve the display-scaling story for Windows itself, which Steve’s article covers. While this resulted in an improved experience for some of the in-box UI of Windows itself and for UWA, many third-party (and Microsoft’s own) desktop applications were not able to benefit from this work and could still display blurry or sized incorrectly in some common scenarios. For the Windows 10 Anniversary Update we wanted to tackle this problem so we focused on making it easier (and less expensive) for software developers to update their desktop applications to scale properly.

Problem Statement:

As was discussed in Steve’s article, many desktop applications do not render well on some of the latest high DPI displays. There are three symptoms of display-scaling problems we typically see with desktop applications:

1. Blurry text and UI components.

2. Applications sized incorrectly (too big or too small).

3. Applications are sized correctly and are not blurry, but have other layout issues (such as clipped text or other UI components).

These problems are most frequently seen whenever the display scale factor of a Windows PC changes while the user is logged in and/or if an application is moved from the “main display” to a display that has a different display scale factor.

One very common scenario where applications start to experience these problems is when a device with a high display scale factor (say 200% display scaling) is docked or undocked with an external display that has a different display scale factor (and the external display is used as the “main display” or the PC uses “Second screen only” display mode). In this scenario applications render as expected on the internal display (#1 below) before the PC is docked but once connected to the external display they are stretched by Windows such that they are sized correctly on the external display (#2 below). This stretching results in the application looking blurry. At this point the only thing that the end user can do is to close all of their applications and completely log out and back into Windows. Once the user has logged out and logged back into Windows, most applications should render correctly on the external display (#3 below). Needless to say this is not an acceptable workaround as it interrupts a user’s workflow. To add insult to injury, if the user does completely log out and back into Windows, once they un-dock their device the same problem will occur in the reverse (#4 below). This scenario forms the cycle shown below:

Background:

There are many reasons why some desktop applications do not render correctly, but at a high-level one of the biggest challenges desktop applications face in this space is that many apps were written without considering that the display factor on Windows could change while the app was running, and so they don’t respond to those changes. This is true if you don’t ever connect an external display that has a different display scale factor, remote into Windows from a device with a different display scale factor, or change the display scaling settings. Once any of these things happen though, the scale factor of the system is suddenly different from what the application was told it was when it launched, and applications that not expecting the display-scale factor to change are not made aware of this change, and therefore they do not know that they should respond. When this happens, Windows jumps in and stretches the on-screen image of the application such that it will be sized appropriately for the new scale factor. This, at least, results in applications being physically sized correctly on a display but they can be blurry as result of being stretched.

PCs today are being equipped with displays with increasingly high pixel densities, also referred to as dots-per-inch (DPI). The Surface Pro 4, for example, ships with a display that accommodates a 200% display scale factor. This means that if you were to connect a Surface Pro 4 to a “standard” external display (a display with 96 DPI or 100% display scaling) there would be a 2-to-1 difference between the scale of an application on the Surface display and that of when it was rendered on the external display. For applications that don’t handle dynamic display scaling, this means that the image of the application shown on screen would either be reduced by half when displayed on an external display or doubled (depending on which monitor was configured as the “main display” when the user logged into Windows). As the difference between the display scaling of monitors increases the blurriness of applications becomes more and more noticeable. This is a problem that is only going to get worse as display manufactures produce displays with even higher DPI.

While it is technically possible for legacy desktop applications to be updated to understand the concept that the display scale factor can change at any time, it is clear that not all applications will be updated and that some many never be updated for this. Furthermore, until the Windows 10 Anniversary Update, Windows did not even offer enough of the functionality that an application developer required in order to do this work. So much key functionality was missing that it was not practical for developers to update their desktop applications in many cases, even if the will was there to do so. So, this is what we focused on for the Windows 10 Anniversary Update.

During the development cycle for the first Windows 10 release we started to tackle this problem by updating the Windows File Explorer application to dynamically handle a display-scale-factor change. Through this process we learned a great deal about the type of challenges Windows desktop developers will hit when trying to update their applications, and we wanted to address as many of those as we could.

Why doesn’t Microsoft Just Fix Display Scaling on Windows?

This is a valid question that many of us have asked ourselves when joining teams that are working on this problem space. The main challenge that we face, however, is that many, many, applications that run on Windows are using a design pattern where they ask Windows for information about the system when they launch (questions such as how big the display is, what is the display scale factor, what is the size of the font that should be used for default text, as well as others) and then cache this information and never expect it to change. Because of this, even if Windows did start giving these applications information about a DPI change, most, if not all, of these applications wouldn’t even be asking and therefore would not respond correctly. Furthermore, if Windows did start providing dynamic display-scale-factor-related information this would be a nightmare for application compatibility and would probably cause more problems for application stability than it would help in terms of high DPI display issues.

RS1 Improvements

Non-client area scaling

One of the first (and biggest) blockers than any desktop application developer runs into when they try to update their application to handle dynamic display-scale changes is that what we refer to as the “non-client area” of a window does not respond to scale-factor changes. The term non-client area (NCA) refers to parts of a typical desktop application window that the application itself does not draw… such as the title/caption bar, system menus, traditional menu bars (such as in Notepad), scrollbars, and other UI that application developers require the system to handle on their behalf. In other words: all the standard “Windows stuff” that make up a typical desktop application window, but that aren’t drawn by the applications themselves.

Before the Windows 10 Anniversary Update, if an application developer tried to update their desktop application to respond to a display-scale-factor changes, they would soon discover that the NCA would not resize when the scale factor changed. This meant that their application would have undersized or oversized titlebars when the scale-factor changed (Figure 1). This is not something that application developers could live with and the only option available to them to address this was to have the developer handle all of the drawing of these UI components themselves, which is a prohibitively-expensive proposition for most developers (note that some applications, such as Google Chrome and the FireFox browser do draw most of the UI that is typically NCA themselves, because they have highly-stylized application UI).

Figure 1. Non-Client Area not scaling for DPI (left) and scaling correctly (right)

For the Windows 10 Anniversary Update we now support automatic scaling of NCA via use of a new “EnableNonClientDpiScaling” API.

Mixed-Mode DPI scaling

One lesson that we learned while making File Explorer dynamically handle display-scale-factor changes was that the current model for an application to tell Windows how it wanted to handle display scaling was too inflexible for complicated applications. The model has been that an application would either tell Windows that it knew how to scale when it started (System DPI awareness), that it could handle dynamic display-scale factor changes (Per-Monitor DPI awareness), or that it would say nothing and Windows would stretch/scale it appropriately.

This is an adequate model for simple applications, or applications that are being created from scratch, but when a developer tries to update even a moderately-complicated application with many windows, they’ll be in a position where they have to update all of their UI… an all-or-nothing proposition. They either update all of their UI or live with some UI not rendering at the correct size. For any application with many windows this could become a ton of work quickly. Also, developers for applications that present third-party content (such as plugins) might not even have access to the source code for this content, so handling the display scaling for these windows wouldn’t even be an option.

To make it easier for desktop applications to be updated to handle display scaling well, we realized that this had to be changed. So we’ve broken the process-wide constraint on an application’s display-scaling mode such that developer can now specify a different scaling mode for each (top-level) window. In other words: developers can focus their development time on making the important parts of their UI handle display scaling well, while letting Windows handle the other windows in the application. The API that enables this functionality is SetThreadDpiAwarenessContext. This should significantly reduce the cost for developers to update their desktop applications.

Figure 2 and Figure 3 show an example of an application that utilizes this functionality to make its primary UI render crisply while having Windows handle DPI scaling of less-frequently used UI. Notepad’s primary window renders natively at the DPI of the display it’s primarily located on while the Print dialog is scaled by Windows (and may be blurry). Figure 3 shows a close-up of the two windows, showing that the system-scaled Print dialog is somewhat blurry while the Notepad UI is crisp:

Figure 2. Notepad’s primary window is natively scaling while Windows is scaling the Print dialog

Figure 3. Close up of the Notepad window and the system-scaled Print dialog

Office

Some of the biggest feedback we’ve received about display scaling has been related to Lync/Skype for Business and PowerPoint being sized incorrectly in scenarios such as docking a Surface Pro, Surface Book, or any high-DPI device to a standard DPI display (or any display with a different display scale factor). I’m happy to say that with the new functionality (mentioned above), that is part of the Windows 10 Anniversary Update, the Office team is now working on updates to these applications that will enable them to render at the correct size when the display scale factor changes (the updates to these Office applications will only apply when running on PCs with the Windows 10 Anniversary Update (or newer)).

WPF

Windows Presentation Framework (WPF) is a heavily used application framework used for making many desktop applications. Unfortunately, WPF applications hit the same problems with non-client area (NCA) scaling as other desktop applications did (mentioned above) when they were updated to handle display-scale-factor changes on the fly. For the Windows 10 Anniversary Update WPF is being updated to support automatic NCA scaling.

What we didn’t get to:

For the Windows 10 Anniversary Update we focused on some of the biggest rocks that needed to be moved in order to make it easier for developers to update desktop applications to handle dynamic display-scale-factor changes, but there are still more things we need to tackle:

Desktop Icon Scaling

In previous Windows releases, desktop icons would not scale properly when the scale factor changed (they would be too big or too small in some scenarios). We’ve improved this for many common scenarios such as docking and undocking with displays that have a different scale factor, but desktop icons still do not scale on a per-display basis if you are in “extend” display mode. This means that if a user has their desktop spread across displays (“extend” display mode) with different scale factors, the icons will be sized incorrectly on some displays.

Common Control scaling and WinForms

Unfortunately, we weren’t able to deliver per-monitor display-scale-factor scaling support for Win32 common controls in the Windows 10 Anniversary Update. Application developers that want to create a native Win32 application that uses common controls and want to natively scale the controls will still face challenges due to lack of support for this in Windows.

WinForms is a very widely used framework for creating desktop applications, which is partially built upon Win32 common controls. Unfortunately, WinForms controls have not been updated to support dynamic display-scale-factor changes.

Addressing the need to log out and log back into Windows after a display-scale factor change

Due to the common architecture of applications asking Windows what the display-scale factor is once at startup, and not asking again while they’re running, often the only way to have an application pick up the new display-scale factor is to log out of Windows and log back in. Until we find a way to work around the constraints that this pattern imposes on applications, users will continue to have to log out and log back into Windows, unfortunately.

Conclusion

For the Windows 10 Anniversary Update our goal was to make it easier and less expensive for application developers to update their desktop applications to handle display-scale-factor changes while they’re running, so that they don’t show up blurry or sized incorrectly in common use cases. Hopefully developers will find this work useful and we’ll start to see more desktop applications updated to render correctly. We’ve still got a lot of work ahead of us in the high-DPI space until we get to a point where most desktop applications scale properly, but we recognize how critical this is for Windows users. We feel the same pain ourselves.

Hi,

My name is Scott McArthur and I am a Supportability Program Manager for Surface. Today I have a quick blog on some important deployment information regarding the Surface Ethernet Drivers. When doing a deployment, it is necessary to add the Surface Ethernet drivers to boot images (ConfigMgr, MDT, WDS). This blog will discuss where to get the drivers.

First some technical details on the drivers themselves:

• PNPID: VID_045E&PID_07C6. This is partial PNPID
• Windows 10 X86
  • msux86w10.inf
  • msux86w10.sys
• Windows 10 X64
  • msux64w10.inf
  • msux64w10.sys
• Windows 8.1 X86
  • msu30x86w8.inf
  • msu30x86w8.sys
• Windows 8.1 X64
  • msu30x64w8.inf
  • msu30x64w8.sys

Where to get the driver:

• Starting with Windows 10 Version 1607 the Surface Ethernet driver is included so if you are deploying it should just work. Note the inbox version is 10.2.504.2016. A later version has already been released.
• The .MSI package which is used to update existing installs of Surface contains the Surface Ethernet Drivers.
• The .ZIP package used for bare metal deployments (For example Surface Pro 4) do not contain the Surface Ethernet drivers.

To download the latest drivers for Surface Ethernet adapter, do the following:

1. Browse to the Microsoft Update Catalog here.
2. In the search box enter Surface Ethernet Drivers.

When looking at the drivers pay special attention to the version column. At the time of this blog publication the latest drivers were:

• Windows 10: 10.2.704.2016
• Windows 8.1: 8.18.303.2015

Notes:

• Check back regularly for any new versions.
• There are 2 entries. One for x86 and one for x64. x86 is primarily for customers who have purchased the Surface Ethernet Adapter and using it on another device although you may be booting X86 based boot image but installing X64 operating system. Best practice is to include both in your deployments.
• The drivers support the older 10/100 adapter (model 1552), newer USB 3.0 1GB adapter (model 1663), and Surface docks

Hope this helps with your deployments.

Hi Everyone,

This is Kim Johnson from the Windows 10 client supportability team.  I wanted to share some exciting news around some new updates for display scaling issues in Skype for Business 2016 and PowerPoint 2016.  In previous blogs we discussed some of the issues encountered with display scaling on high dpi devices:

· Display Scaling changes for the Windows 10 Anniversary Update

· Display Scaling in Windows 10

We also have a KB article that discusses these issues:  Windows scaling issues for high-DPI devices

The Office team has released updates to address some of these scaling issues with Skype for Business 2016 and PowerPoint 2016.  Please take a look at the following support article which tells you prerequisites and how to get the update:

· Office apps appear the wrong size or blurry on external monitors

Windows 7 with SP1

Support Lifecycle: https://support.microsoft.com/en-us/lifecycle?C2=14019

This blog post is part of a series of posts, detailing the build process and activating capabilities of a KMS host on a particular host operating system. The operating system dictates which KMS host key (CSVLK) can be installed on that particular host, and that CSVLK determines what KMS-capable clients can be activated. When implementing KMS activation in an environment, it is best to determine all of the potential volume license operating systems for your KMS clients and then pick the best key. To simplify this, it is recommended that the most current KMS CSVLK be used, insuring that all KMS-capable operating systems that have been released at that time can be activated. For newer KMS CSVLKs to be hosted on previously released operating systems, a hotfix is needed to make the host operating system aware of the newer operating system.

Note: Desktop KMS CSVLKs can only be installed on hosts with desktop operating systems (that support that CSVLK) and Server KMS CSVLKs can only be installed on hosts with server operating systems (that support that CSVLK).

This blog post pertains to a KMS host with Windows 7 with SP1 as the operating system.

Windows 7 can host the following desktop KMS CSVLKs:

• Windows 7
• Windows 8
• Windows 8.1
• Windows 10

The KMS CSVLKs can activate the following KMS clients:

KMS Host Build Steps:

1. Install Windows 7 with SP1
2. Patch completely
3. If a firewall is used, verify that there is an exception for KMS
4. Obtain the desired CSVLK from the VLSC site
5. If the KMS CSVLK is newer than the Windows 7, install the hotfix required as per the table above
6. Install the KMS CSVLK

a. Open an elevated command prompt
b. Run cscript.exe slmgr.vbs /ipk XXXXX-XXXXX-XXXXX-XXXXX-XXXXX using your KMS CSVLK
c. Wait for success message

7. Activate the KMS CSVLK

a. If system has external internet connectivity:

i. Open an elevated command prompt
ii. Run cscript.exe slmgr.vbs /ato
iii. Wait for success message

b. If system does not have external internet connectivity:

i. Phone activate with UI

1. Open an elevated command prompt
2. Run slui.exe 4 to open the Phone Activation wizard
3. Follow the prompts to complete

ii. Phone activate via command prompt

1. Open an elevated command prompt
2. Run cscript.exe slmgr.vbs /dti to obtain the installation ID
3. Call Microsoft’s Phone Activation using a phone number listed in %SystemRoot%System32\SPPUI\Phone.inf
4. Follow the prompts to obtain the confirmation ID
5. Run cscript.exe slmgr.vbs /atp <ConfirmationID w/o hyphens> to apply the confirmation ID
6. Wait for a success message

8. Run cscript.exe slmgr.vbs /dlv and verify that the License Status indicates that the KMS host is licensed.

The Windows 7 KMS host is now ready to begin accepting KMS activation requests. The host needs to meet the minimum threshold of twenty-five unique KMS (desktop) client requests before it will begin activating KMS (desktop) clients. Until the minimum threshold is met, KMS (desktop) clients attempting to activate against this host will report the following error:

When the threshold is met, all KMS (desktop) clients requesting activation (that are supported by the CSVLK installed) will begin to activate. Those KMS clients that previously erred out with 0xC004F038 will re-request activation (default interval is 120 minutes) and will be successfully activated without any user interaction. An activation request can be prompted on a KMS client immediately by running cscript.exe slmgr.vbs /ato in an elevated command prompt.

Scenario:

You want to build a KMS host on Windows 7, to activate Windows 7 and Windows 10 KMS clients. Here are the steps necessary to achieve your goal.

1. Determine what CSVLK is needed – You determine that CSVLK needed to activate both Windows 7 and Windows 10 is the Windows 10 CSVLK as per this TechNet article, under the “Plan for Key Management Services activation” section.
2. Obtain the CSVLK – Log onto your Volume License Service Center site and locate the Windows 10 KMS key listed. Note this for Step #5.
3. Build a Windows 7 system from Volume License media and patch – Using volume license media, build a system or utilize a system that is already built. Completely patch the system using Windows Update or whatever solution you use for applying updates/hotfixes.
4. Apply the required hotfix – Because Windows 7 was released before Windows 10, the system needs to become aware of the newer operating system. Applying the hotfix from KB Article 3079821 will accomplish this and enable your Windows 7 KMS host to activate Windows 10 KMS clients (along with Windows 7, Windows 8, and Windows 8.1 KMS clients).
5. Install the CSVLK – Open an elevated command prompt. Install the CSVLK on the KMS host by running the following command: cscript.exe slmgr.vbs /ipk <your CSVLK as it appears on the VLSC site>
6. Activate the CSVLK – In the elevated command prompt, activate the CSVLK by running the following command: cscript.exe slmgr.vbs /ato
7. Verify – In the elevated command prompt, display the licensing information by running the following command: cscript.exe almgr.vbs /dlv
8. Phone activate if necessary – If you have issues with online activation from Step #6, you can open the phone activate by running the following command: slui.exe 0x4 and follow the prompts to activate your system. Once complete, repeat verification if necessary.

The KMS host is now ready to begin activating any Windows 7, Windows 8, Windows 8.1, and Windows 10 KMS clients. Here is a quick video to show the steps.

Note: Reminder, the minimum required threshold of twenty-five KMS client activation requests to this new host will need to be met before the KMS host begins activating as per Step #8 under “KMS Host Build Steps” above.

References:

• “Planning for Volume Activation” – https://technet.microsoft.com/en-us/library/dd996589.aspx
• “Determine Product Keys Needs” – https://technet.microsoft.com/en-us/library/ff793411.aspx
• “Understanding KMS” – https://technet.microsoft.com/en-us/library/ff793434.aspx
• “Deploying KMS Activation” – https://technet.microsoft.com/en-us/library/ff793409.aspx
• “Reactivating Computers” – https://technet.microsoft.com/en-us/library/ff793428.aspx

Links for other blogs in this series:

Windows Server 2016 Volume Activation Tips

https://blogs.technet.microsoft.com/askcore/2016/10/19/windows-server-2016-volume-activation-tips/

Hi,

This is Scott McArthur, a Supportability Program Manager for Windows and Surface. With the launch of Windows Server 2016 I wanted to share some information on volume activation:

• Updating your existing KMS hosts to support Windows Server 2016
• Setting up a new Windows Server 2016 KMS host
• Activating Windows 10 Enterprise 2016 LTSB

Updating existing KMS Hosts

If your KMS host is Windows Server 2012 you need to install the following updates

• Update: activate Windows 10 from Windows 8 or Windows 8.1, and Windows Server 2012 or Windows Server 2012 R2 KMS hosts
• July 2016 update rollup for Windows Server 2012

If your KMS host is Windows Server 2012 R2 you need to install the following updates:

• Update: activate Windows 10 from Windows 8 or Windows 8.1, and Windows Server 2012 or Windows Server 2012 R2 KMS hosts
• July 2016 update rollup for Windows 8.1 and Windows Server 2012 R2

Once updated you need to obtain a Windows Server 2016 CSVLK. Do the following

1. Log on to the Volume Licensing Service Center (VLSC).
2. Click License.
3. Click Relationship Summary.
4. Click License ID of their current Active License.
5. After the page loads, click Product Keys.
6. Look for a key called “Windows Srv 2016 DataCtr/Std KMS”

If you are unable to locate your product key please contact the Volume licensing service center

Once you have the key then run the following commands at elevated cmd prompt

1. Install the Windows Server 2016 CSVLK

    Cscript.exe %windir%\system32\slmgr.vbs /ipk <insert Windows Srv 2016 DataCtr/Std KMS CSVLK here>

2. Activate the Windows Server 2016 CSVLK

    Cscript.exe %windir%\system32\slmgr.vbs /ato

Windows Server 2008 R2 is not supported as a KMS Host for Windows Server 2016 or Windows 10 Enterprise 2016 LTSB edition

Setting up new Windows Server 2016 KMS host

If you want to setup a new Windows Server 2016 KMS host normally you can use the Volume Activation services role wizard or command line to configure the KMS host.

We are aware of issue where when you run the Volume Activation Services role wizard, it will report the error “vmw.exe has stopped working” during the product key management phase of the wizard

Microsoft is investigating this issue and will update this blog when a fix is available but in meantime you will need to configure it using the steps below

1. Open elevated cmd prompt

2. Install the Windows Server 2016 CSVLK

    cscript.exe %windir%\system32\slmgr.vbs /ipk <insert Windows Srv 2016 DataCtr/Std KMS CSVLK here>

3. Activate the Windows Server 2016 CSVLK

    Cscript.exe %windir%\system32\slmgr.vbs /ato

If system does not have internet connectivity do the following to activate via the command line:

1. Open an elevated command prompt

2. Obtain the Installation ID

    Cscript.exe %windir%\system32\slmgr.vbs /dti

3. Look up Microsoft phone activation number using phone number listed in %windir%System32\SPPUI\Phone.inf

4. Call the number and follow the prompts to obtain the confirmation ID

5. Apply the confirmation ID (do not include hyphens)

    Cscript.exe %windir%\system32\slmgr.vbs /atp <ConfirmationID>

6. Wait for a success message (numbers blurred on purpose)

7. Verify that the license status shows licensed:

    Cscript.exe %windir%\system32\slmgr.vbs /dlv

Windows 10 Enterprise 2016 LTSB Edition volume activation

Note: In addition to activating Windows Server 2016 the “Windows Srv 2016 DataCtr/Std KMS” KMS host(CSVLK) key also activates Windows 10 Enterprise 2016 LTSB edition

Hope this helps with your Windows Server 2016 deployments

Scott McArthur

With the changes that have occurred to further align the Windows Server and Client desktop experiences, one of the most commonly asked questions is “Does Windows Server 2016 ship with Adobe Flash?”

Answer: Adobe is included and does ship on the Windows Server 2016 media. It can be installed by adding the Remote Desktop Session Host (RDSH) role.

Your thoughts, questions and feedback are very valuable to us and we encourage you to share them in the comments section below.

Derk Benisch
Senior Program Manager

Starting with the Windows 1607 release, MSN News and MSN Finance are no longer included with the Windows installation, but they are still available via Windows Store.

For most, this change will be seamless.

• If users upgrade from a previous version of Windows 10, applications that were previously installed will update automatically.
• If users upgrade to Windows 10 1607 from a previous version of Windows (7 or 8) or does a clean installation (no previous install), the system will have the default apps available and any modern apps associated with a Microsoft account will be listed in the Store app, under My Library. MSN News and MSN Finance can be quickly reapplied to the machine from there.

In some Enterprise or Domain scenarios, the standard Windows Store app may not be available or network restrictions make access less than optimal. I want to outline the three methods for adding apps to Windows 10 and call out caveats to each.

First is the default option where users access and download apps via Windows Store.

• Users need to use a Microsoft Account (MSA) to get apps
• All apps will be tied to that user’s MSA account (as seen in My Library)
• Systems need access to the Internet to install and update apps

The second option is the Windows Store for Business.

• System Admins/Organizations/Enterprises can choose to publish only the apps that are desired in their environment.
• This requires an Azure Active Directory (AAD) account, either one for Admins or AAD account for all users.

Note: The standard Windows Store can then be hidden from users by group Policy (User Configuration\Policies\Administrator Templates\Windows Components\Store\Only display the private store within the Windows Store app)

This is documented here:

https://technet.microsoft.com/en-us/itpro/windows/manage/windows-store-for-business

The third option for installing Apps is called “sideloading”.

• For applications with an offline license, Appx packages can be added into a base image for deployment or pushed via Group Policy.
• This can be used when Windows Store is disabled via Group Policy, MSA accounts are blocked or AAD accounts are not available.
• The drawback here is that the applications will not update via Windows Update or the Store engine.  Admins will have to check for updated versions and push updates manually.

This is documented here:

https://technet.microsoft.com/en-us/itpro/windows/deploy/sideload-apps-in-windows-10

In conjunction with System Center:

https://blogs.msdn.microsoft.com/teju_shyamsundar/2016/05/30/deploy-an-application-from-windows-store-for-business-via-system-center-configuration-Manager/

Here is more information on managing access to the Windows Store:

https://technet.microsoft.com/en-us/itpro/windows/manage/stop-employees-from-using-the-windows-store

Kim Johnson
Sr. Support Escalation Engineer
Windows Beta

Hello, my name is Ritesh Sinha and I am a Support Escalation Engineer on the Windows team.  Today’s blog will cover “Why Bitlocker takes longer to complete the encryption in Windows 10 as compared to Windows 7”.

A brief summary of Bitlocker is: Bitlocker is a disk encryption system provided by Microsoft with the Windows operating system. Bitlocker uses a set of protectors (both hardware and software) to encrypt the data on the drive which makes sure that the data is accessible to only the authorized person, and only on the authorized machine.

Recently, we heard from our customers that they are noticing a significant increase in time for the encryption to complete on Windows 10 machines compared to Windows 7 machines.

To understand why Bitlocker takes longer to complete the encryption in Windows 10 as compared to Windows 7, we need to understand the points listed below.

1. BitLocker in Windows 10 has been made to run less aggressive for its background conversion. This makes sure that you are not experiencing slow performance of the machine while the encryption is in progress.
2. This is compensated by the fact that this new conversion model BitLocker now uses (on all client SKUs and any internal drives) ensures that any new writes are always encrypted regardless of where on the disk they land (which was not the case for the original BitLocker watermark-based conversion model).
3. The new conversion mechanism, called Encrypt-On-Write, immediately guarantees the protection (encryption) of all writes to disk AS SOON AS BitLocker is enabled on the OS or fixed (internal) volumes.  Removable drives work in the older mode for backwards compatibility.
4. The pre-Windows 10 conversion mechanism could only make such a claim AFTER the conversion reached 100%.
5. If one thinks about it, #2 and 3 are very significant because:
   • Regardless of the version of Windows used, without Bitlocker enabled and the drive fully encrypted, you could not guarantee that data wasn’t already compromised or stolen.
   • Therefore, those serious about any such compliance claims would have to wait for the older BitLocker conversion process to reach 100% before placing any sensitive data on drive.  This means possibly waiting a long time if the drive is large.
   • With the new method, they could safely copy sensitive data as soon as BitLocker is enabled and the volume is in the encrypting state.
6. Due to achieving compliance status for all writes immediately upon enabling BitLocker, the pressure of reaching 100% conversion status is less and converting all pre-existing data happens at a slower rate (further lessening the impact on interactive user).

Apart from this reason, there are several new feature enhancements which have been made to Bitlocker since Windows 7.  Some of these enhancements are:

· New encryption algorithm XTS-AES.  The new algorithm provides additional protection from a class of attacks on encryption that rely on manipulating cipher text to cause predictable changes in plain text.

• This is also FIPS-compliant, which is a set of United States Government standards that provide a benchmark for implementing cryptographic software.
• Bitlocker can be administered through various means such as BitLocker Wizard, Manage-BDE, Group Policy, MDM policy, Windows PowerShell, or WMI to manage it on devices
• Integration with Azure Active Directory for easier online Bitlocker key recovery.
• DMA port protection using MDM policies to block the DMA ports and secure the device during its startup.
• Bitlocker Network Unlock
• Support for Encrypted Hard Drive for faster encryption time.
• Support for classes of HDD/SSD hybrid disks (small SSD used as a non-volatile cache in front of slower spinning HDD, known as Intel RST technology).

To get these enhancements, the whole product has gone through a major design change to make sure that Bitlocker is more secure, the machine stays much more responsive during the encryption process and we provide the latest feature and manageability to the users.

Because Window 10 and Windows Server 2016 share the same kernel base, these changes are applicable to Windows Server 2016 as well.

You may notice significant improvement in Windows 10 Bitlocker encryption time after installing the Windows 10 Creators Update which is expected to release in 2017 but encryption time is also dependent on the hardware you are using as well as the workload on the machine.

I hope this article will help everyone understand that Bitlocker is better than before even though it may seem like it is slower when encrypting existing data on a hard drive.

Ritesh Sinha
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Welcome to the AskCore blog. My name is Eriq Stern and today we are going to discuss Failover Cluster networks.  This information applies to Windows 2008 up thru Windows 2012 R2 Failover Clusters.

What does a Windows Failover Cluster consider a “Cluster Network”?

In a Windows Failover Cluster, Cluster Networks are created automatically by the Cluster Service for each configured subnet on any active network interfaces (NICs) on each node of the cluster. If a single node has a NIC configured with a subnet that is not configured on other nodes, a Cluster Network will be created even though it cannot be used by any nodes that do-not have an active NIC on it. Disabling any NICs on a single node has no effect on Cluster Network objects if there are still active NICs on those subnets on any node. To remove or re-create a Cluster Network, all NICs on the desired subnet must be disabled or removed until the Cluster Service discovers the change and removes the related Cluster Network, which should happen within a few seconds of disabling or removing the NICs.

How are Cluster Networks configured for cluster use by default?

Cluster Networks are always enabled for Cluster use by default when created, even if the same network has been previously configured otherwise. If the network has a default gateway, then it will also be enabled for Public use.  This is because when all NICs on a subnet have been removed or disabled, the network is completely removed from the cluster database, and is re-added as a new entry if the network is rediscovered. Because of this, in some cases it may be necessary to reconfigure a previously configured network after a Cluster Network has been removed and re-added, for example after disabling and re-enabling a NIC on a single-node cluster.

How are Cluster Network names/numbers determined?

Cluster networks are automatically named “Cluster Network” followed by the next available number that is not assigned to an existing network. For example, if “Cluster Network 1” exists, a new network would be named “Cluster Network 2” – but if “Cluster Network 1” has been manually renamed, when another NIC is enabled on a different subnet, a new Cluster Network will be created and automatically named “Cluster Network 1”. The number will not be incremented based on the previously identified networks.

Manually renamed Cluster Networks:

Newly added cluster network:

I hope that this post helps you!

Thanks,
Eriq Stern
Support Escalation Engineer
Windows High Availability Group

John Marlin here again. I know it’s been a while, but it’s time to resurface.

In my dealings with a lot of Beta and TAP Customers, there are still some that still are on Windows Server 2016 TP5. I am here to say it is getting time to go ahead and upgrade to the released version. I say this as soon, you will not have an option.

Originally, the “timebomb” for every two-hour reboots were set for December 15, 2016. However, with the slip of release, this was moved back as well. As of February 28, 2017, TP5 servers have now “timebombed” and reboot every two hours. However, the expiration of Windows Server TP5 will be on Tuesday, April 18, 2017.

So if you are still running on TP5 and have plans in place of moving off of it, please ensure those plans occur before mid-April.

Thanks
John Marlin
Senior Support Escalation Engineer

My name is Shannon Gowen and I am a Serviceability Support Escalation Engineer for Windows Client and Server Beta. This is a short blog describing an issue that you might see utilizing the Volume Activation Management Tool (VAMT) with Windows Server 2016 and Windows 10 2016 LTSB product keys and how to resolve it.

This issue was reported previously for VAMT3.1 v1507 under KB Article 3094354, listed below under References.

Upon attempting to enter a Windows Server 2016 product key (for this example, the three Windows Server 2016 Client Setup keys are used) to VAMT (installed from the Windows ADK for Windows 10 version 1511), you receive the following pop-up:

Figure 1 – Failed attempt to add Windows Server 2016 Client Setup keys to VAMT 3.1 (1511)

If you attempt to do the same with Windows 10 product keys (for this example, the Windows 10 Professional, Enterprise, and Education Client Setup keys are used), the addition is successful.

Figure 2 – Successful attempt to add Windows 10 Client Setup keys to VAMT 3.1 (1511)

If you attempt to do the same with Windows 10 LTSB product keys (for this example, the Windows 10 2015 and 2016 LTSB Client Setup keys are used), the addition of the Windows 10 2015 LTSB Client Setup key was successfully, while the Windows 10 2016 LTSB Client Setup key failed.

Figure 3 – Failed attempt to add the Windows 10 2016 LTSB Client Setup key to VAMT 3.1 (1511)

Figure 4 – Successful addition of the Windows 10 2015 LTSB Client Setup key to VAMT 3.1 (1511)

This occurs because the Windows ADK for Windows 10 v1511 was released prior to the release of Windows Server 2016 and Windows 10 2016 LTSB. The code is not aware of newer releases. This is why VAMT 3.1 v1511 reports that the product key configuration files could not be found and why the Windows Server 2016 and Windows 10 2016 LTSB product keys cannot be added successfully.

To resolve this, you can either update your VAMT v1607 with the Windows ADK for Windows 10, version 1607 or update the code in VAMT 3.1 v1511.

Update to VAMT 3.1 v1607 (Highly recommended, supported method)

1. Uninstall the Windows ADK for Windows 10, version 1511.

a. Open Control Panel à Programs à Programs and Features.

b. Click on Windows Assessment and Deployment Kit – Windows 10 (version 10.1.10586.0.

c. Click on Uninstall.

Figure 5 – Uninstall Windows ADK from Control Panel

2. Once the uninstall is complete, download the Windows ADK for Windows 10, version 1607.

3. Run through the installation with at least the Volume Activation Management Tool selected.

Figure 6 – Installing VAMT 3.1 v1607 via Windows ADK

4. Open the Volume Activation Management Tool and attempt to add any issue key. For this example, the Windows Server 2016 and Windows 10 2016 LTSB Client Setup (shown) and KMS host (not shown) keys are used.

Figure 7 – Successful addition of Product Keys

5. All product keys now listed.

Figure 8 – List of Installed Product Keys

Update VAMT 3.1 v1511 Code

1. Download either July 2016 Update Rollup (KB 3172614 or KB 3172615 mentioned below under References). For this example, KB 3172614 is used and the MSU, saved to C:\KB3172614.

2. In an elevated command prompt, navigate to the location of the saved MSU, and extract the contents of the update with the following command: expand <path to MSU> -f:* <path to location to extract to>. For this example, the following command is used:

expand Windows8.1-KB3172614-x64.msu –f:* C:\KB3172614

Figure 9 – Expansion of KB 3172614’s MSU

3. Next, extract the contents of the .cab file using the following command: expand <path to the .cab> -f:* <path to location to extract to>. For this example, the following command is used:

Expand Windows8.1-KB3172614-x64.cab –f:* C:\KB3172614\KB3172614CAB

Figure 10 – Command Line used to Expand KB 3172614’s CAB File

4. Copy all XrML Digital License files in the subfolders to the pkconfig directory for VAMT. The default location is C:\Program Files (x86)\Windows Kits\10\Assessment and Deployment Kit\VAMT3\pkconfig. This can quickly be accomplished by opening File Explorer, navigating to the expanded CAB location, and searching for “xrm-ms”. Copy all of the resulting files into the previously mentioned pkconfig directory.

Figure 11 – List of XrML Files

5. Close and reopen VAMT. Attempt to add the issue keys. The Windows Server 2016 and Windows 10 2016 LTSB Client Setup keys will not be able to be added, but Windows Server 2016 and Windows 10 2016 LTSB MAK and KMS host keys (CSVLKs) can be added.

Figure 12 – Successful Addition of a KMS Host Key (CSVLK)

Figure 13 – List of Successfully Added Product Keys

References:

“Can’t add CSVLKs for Windows 10 activation to VAMT 3.1” – https://support.microsoft.com/en-in/help/3094354/can-t-add-csvlks-for-windows-10-activation-to-vamt-3.1

“Download the Windows ADK” – https://developer.microsoft.com/en-us/windows/hardware/windows-assessment-deployment-kit

Direct Download of Windows ADK for Windows 10, version 1607 – https://go.microsoft.com/fwlink/p/?LinkId=526740

“What’s new in ADK kits and Tools” – https://msdn.microsoft.com/windows/hardware/commercialize/what-s-new-in-kits-and-tools

Direct Download of Windows ADK for Windows 10, version 1511 – https://go.microsoft.com/fwlink/p/?LinkId=823089

“Appendix A: KMS Client Setup Keys” – http://technet.microsoft.com/en-us/library/jj612867.aspx

“July 2016 update rollup for Windows 8.1 and Windows Server 2012 R2” – https://support.microsoft.com/en-us/help/3172614/july-2016-update-rollup-for-windows-8.1-and-windows-server-2012-r2

“July 2016 update rollup for Windows Server 2012” – https://support.microsoft.com/en-us/help/3172615/july-2016-update-rollup-for-windows-server-2012

Support Lifecycle: https://support.microsoft.com/en-us/lifecycle?p1=14134

In some cases, it may be necessary to uninstall and reinstall the Windows Failover Clustering feature on a server that is currently a member of a Failover Cluster.  This can be done via either Server Manager, or PowerShell.  Below are the steps to complete the process using each method.  These instructions document the process for Windows Server 2012 R2, however the steps are similar for other versions of Windows.

Uninstall the Windows Failover Clustering feature via Server Manager

Complete the following steps with a user account that has administrative rights over the cluster, from any server that has access to the cluster.  If the desired server is not listed, first add it by clicking Manage > Add Servers in Server Manager.

1. In the Nodes view of Failover Cluster Manager, right-click on the node where the Failover Clustering feature is being uninstalled, select More Actions > Evict, and wait for the node to be removed from the Nodes view.
2. Open Server Manager and click Manage > Remove Roles and Features.
   • If prompted, click Next on the “Before you begin” window.
3. Select the server where the Failover Clustering feature is being uninstalled, and click Next.
4. Click Next on the “Remove server roles” window.
5. On the “Remove features” window, deselect the checkbox next to “Failover Clustering” and click Next.
   • If prompted, deselect the checkbox next to “Remove management tools (if applicable)” to retain the Failover Cluster Management Tools and PowerShell modules, if desired, and click Continue.
6. On the “Remove features” window, click Next.
7. Select the checkbox next to “Restart the destination server automatically if required”, and confirm that the server will be restarted if required if prompted before clicking Remove.
8. The server will be rebooted when the feature is successfully removed.

Install/reinstall the Windows Failover Clustering feature and add the node to a cluster via Server Manager and Failover Cluster Manager

Complete the following steps with a user account that has administrative rights over the cluster, from any server that has access to the cluster.  If the desired server is not listed, add it by clicking Manage>Add Servers in Server Manager.

1. Open Server Manager and click Manage>Add Roles and Features.
2. If prompted, click Next on the “Before you begin” and “Select installation type” windows, then select the server on which the Failover Clustering feature is to be installed.
3. Click Next on the “Select server roles” window.
4. Select Failover Clustering on the “Select features” window, and click Next.
   • If prompted, select the checkbox next to “Include management tools (if applicable)” to install the Failover Cluster Management Tools and PowerShell modules, if desired, and click “Add Features”.
5. Select the checkbox next to “Restart the destination server automatically if required”, and confirm that the server will be restarted if required if prompted before clicking Install.
6. The server will be rebooted when the Feature is successfully installed.
7. When the reboot is complete, open Failover Cluster Manager, Click “Add Node”, and follow the instructions in the “Add Node Wizard” to add the node to a cluster.

Uninstall the Windows Failover Clustering feature via PowerShell

Complete the following steps from an elevated PowerShell prompt with a user account that has administrative rights over the cluster, from any server that has local or remote access to the cluster.  If necessary, run the following commands first to import the Failover Clustering and Server Manager PowerShell modules:

Import-Module FailoverClusters
Import-Module ServerManager

Once the modules have been loaded or verified:

1. Run the following command to evict the node where the Failover Clustering feature is being uninstalled:
   Remove-ClusterNode -Cluster <clustername> <nodename>
   • Select Yes if prompted for confirmation.
2. Run the following command to confirm that the desired node is not listed as a member of the cluster:
   Get-ClusterNode -Cluster <clustername>
3. Run the following command to remove the Failover Clustering feature from and reboot the desired node:
   Remove-WindowsFeature Failover-Clustering -ComputerName <nodename> -Restart

Install or reinstall the Windows Failover Clustering feature and add the node back to the cluster via PowerShell

Complete the following steps from an elevated PowerShell prompt with a user account that has administrative rights over the cluster, from any server that has local or remote access to the cluster.  If necessary, run the following commands first to import the Failover Clustering and Server Manager PowerShell modules:

Import-Module FailoverClusters
Import-Module ServerManager

Once the modules have been loaded or verified:

1. Run the following command to remove the Failover Clustering feature from and reboot the desired node:
   Install-WindowsFeature Failover-Clustering -ComputerName <nodename> -Restart
2. When the reboot is complete, run the following command to add the node back to a cluster:
   Add-ClusterNode -Cluster <clustername> <nodename>
3. Run the following command to confirm that the desired node is listed as a member of the cluster:
   Get-ClusterNode -Cluster <clustername>

I hope you find this information useful.  Happy clustering!

Eriq Stern
Support Escalation Engineer
Windows High Availability Team

Hello, my name is Ayushie Bhat and I’m a Support Engineer with the Windows Core team.

Today, I’m going to talk about the authentication in Windows Server 2016 and discuss the case of creating a VM on a CORE server from a different graphical user interface (GUI) server through Hyper-V Manager in Windows Server 2016.  In this blog, we have taken the example of a CORE server managed through a remote GUI server because that is how a variety of customers secure their environment. However, the content of this blog is applicable to all the following scenarios on OS Server 2016: GUI server managed by another GUI server, CORE server managed by remote GUI server, NANO server managed by remote GUI server or any of these servers managed by Windows 10 RSAT tools.

Now let’s discuss more about the case mentioned above of a 2016 Hyper V Core server being managed remotely through 2016 GUI server: The VM creation works fine on the CORE server locally using PowerShell but when we try to create a VM from remote GUI server, the VM creation fails with error:

‘The server encountered an error while creating <virtual_machine_name>. Failed to create a new Virtual machine.’

Below is a screenshot of the error:

The error is seen when we try to store the VM files on a local share on the GUI server or on the SOFS share in the GUI server cluster or even locally on the CORE server.

CORE server used in lab: CORE2016
GUI server used in lab: 2016GUI

Upon checking the Hyper-V event logs on the CORE server, we notice below errors:

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Event ID:      13000
Level:         Error
Description:
User ‘XXXX\Administrator’ failed to create external configuration store at <SOFS share>\SMB-01-TEST: General access denied error. (0x80070005)

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Event ID:      16350
Level:         Error
Description:
Cannot change the storage location of checkpoints for ‘SMB-01-TEST’ to <SOFS share>\SMB-01-TEST: General access denied error (0x80070005) (Virtual machine ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX). Ensure the path is valid and the directory exists. If the directory is remote, ensure that it is properly configured for sharing, and that the current user and computer accounts have read/write access. If the virtual machine is managed by a failover cluster, ensure that the file is located at a path that is accessible to other nodes of the cluster.

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Event ID:      16352
Level:         Error
Description:
Failed to change Smart Paging store for virtual machine ‘SMB-01-TEST’ to <SOFS share>\SMB-01-TEST\:General access denied error (0x80070005). (Virtual machine ID XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX)

Notice that all the errors giving Access Denied messages. Even if Everyone is given Full Control on the SOFS share (both share and NTFS permissions), the error continues. Another curious fact is that when you use a Windows Server 2012 R2 machine as the GUI server for storing the VM files and creating the VM remotely through Hyper-V manager, the VM creation is successful.

Hence to track the root cause of the problem, we captured a network trace while reproducing the issue and found that CORE2016 was requesting the cifs/2016GUI service and it was failing with error “KDC_ERR_BADOPTION”. On the domain controller in the Active Directory Users and Computers snap-in, we added the Service Principle Name (SPN) cifs/2016GUI in the delegation properties of CORE2016.

The delegation option selected was Trust this computer for delegation to the specified services only “Kerberos Only”. After this, the VM creation still failed with the same error.

After doing some research, we found that there has been a change in Hyper-V remoting.  Between Windows Server 2012R2 and Windows Server 2016, we shifted from using the Hyper-V WMI Provider *v1* over *DCOM* to the Hyper-V WMI Provider *v2* over *WinRM*. It unifies Hyper-V remoting with other Windows remoting tools (e.g. PowerShell Remoting).  This change matters for constrained delegation because:

• WinRM runs as NETWORK SERVICE, while the Virtual Machine Management Service (VMMS) runs as SYSTEM.
• The way WinRM does inbound authentication stores the nice, forwardable Kerberos ticket in a location that is unavailable to NETWORK SERVICE.

The net result is that WinRM cannot access the forwardable Kerberos ticket, and VM creation fails on Windows Server 2016.  To get around this, the option is to change the delegation from “Kerberos only” to “Use any authenticated protocol”.

This would ensure that you do not have to depend on Kerberos only.  VM creation should work successfully after this.

To summarize, the steps to be implemented are:

1. Enable Delegation Trust this computer for delegation to specified services only “Use any authentication protocol” on the core server object (CORE2016) in Active Directory.
2. Add SPN cifs/2016GUI [GUI server]
3. Restart the server for the changes to take effect or run gpupdate /force on all servers involved.

If the VMs are to be stored on a SOFS share in the GUI server cluster and the VM hosted on the CORE server cluster, we should enable the delegation on both CORE cluster nodes objects in AD to add SPN cifs/SOFS2016 <SOFS distributed name>. This will allow VM creation on the CORE servers with files stored on the SOFS share and you can create the VM from any of the GUI cluster nodes. Below are the steps for that:

1. Enable Delegation Trust this computer for delegation to specified services only “Use any authentication protocol” on the core server object (CORE2016) in Active Directory. Do this for all CORE cluster nodes.
2. Add SPN cifs/SOFS2016 [SOFS network name]
3. Restart the server for the changes to take effect or run gpupdate /force on all servers involved.

Once these steps are followed, VM creation should be successful.

Thanks,
Ayushie Bhat
Support Engineer | Windows Core

Hi, my name is Scott McArthur and I am Supportability Program Manager in Surface.  Today I am going to walk through deploying Windows 10 Enterprise Version 1703(Creators Update) to a Surface Studio using Microsoft Deployment Toolkit 8443.  Microsoft Deployment Toolkit is the preferred tool to use when building reference images or just deploying Windows to a device.  Reference images you build using Microsoft Deployment Toolkit can be used with System Center Configuration Manager or other deployment tools.  In this scenario, I am using Gen1 virtual machine as my reference image.  We do not recommend using physical devices for reference images

Assumptions:

• You have already installed Windows ADK for Windows 10, version 1703
• You have already installed Microsoft Deployment Toolkit Build 8443
• You have downloaded Windows 10 Enterprise 1703 (Creators update) ISO from the MVLS site
• You have downloaded the latest Surface Studio driver download.  Currently, at the writing of this blog, that driver package is called SurfaceStudio_Win10_15063_1701606_0.msi

Notes:

• These same steps would apply if you decided to deploy Windows 10 Professional instead of Enterprise
• These same steps would apply if you want to deploy Windows 10 Version 1607(Anniversary update/RS1). Surface Studio requires at least Windows 10 1607

Step 1:  Extract Studio drivers

• Copy SurfaceStudio_Win10_15063_1701606_0.msi to c:\bin
• At elevated cmd prompt run the following:
  • msiexec /a c:\bin\SurfaceStudio_Win10_15063_1701606_0.msi targetdir=C:\SurfaceStudioDrivers /qn

Step 2:  Add Operating System

• Under operating systems create folder structure SourceFiles\Windows 10 Enterprise 1703 X64
• Right click “Windows 10 Enterprise 1703 X64” and choose import operating system
• Browse to Windows 10 Enterprise 1703 ISO mounted to DVD drive

Step 3:  Add latest cumulative update

• Go to the Windows 10 Update history page
• Locate the latest cumulative update for the operating system you are deploying
• Download the update (*.msu) from the Microsoft Update catalog and put it in a folder, c:\update
• Right click packages and choose import OS package
• Browse to c:\update
• Choose Finish

Note:
It should be easy now to add any future updates in same manner to update your image to latest updates.  I would recommend replacing the current cumulative update with the latest one since these updates are cumulative

Step 4:  Add Surface Studio Drivers to Out of Box Drivers

• Under “Out of box drivers” create folder called WindowsPEX64
• Under “Out of box drivers” create folder structure Windows10\x64\Surface Studio
• Right click “Surface Studio” and choose import drivers
• Browse to c:\SurfaceStudioDrivers

Step 5:  Create selection profile for Lite Touch (WindowsPE)

It is best practice to create a selection profile for Lite Touch (WindowsPE) so that only the necessary storage and network drivers are added instead of all drivers under Out Of Box Drivers

• Under Advanced configuration right click selection profile and choose “New selection profile”
• Name the selection profile WindowsPEX64
• Choose the WindowsPEX64 folder under Out Of Box Drivers

Step 6:  Add Surface Studio storage controller driver and Intel network card driver to Lite Touch Boot image (WindowsPE)

The following imports the Hybrid Drive Intel Chipset SATA Raid Controller driver and the Intel Ethernet Connection I219-LM drivers.  This ensures that you can talk to the Hybrid Drive and network during Lite Touch

• Right click WindowsPEX64 and choose import drivers
• Browse to C:\SurfaceStudioDrivers\SurfacePlatformInstaller\SurfaceStudio_Win10_1701006_0\Drivers\System\RST_AHCI
• Right click WindowsPEX64 and choose import drivers
• Browse to C:\SurfaceSTudioDrivers\SurfacePlatformInstaller\SurfaceStudio_Win10_1701006_0\Drivers\Network\Ethernet

Step 7:  Configure Lite Touch for selection profile

• Right click the Deployment Share and choose properties
• Click the WindowsPE tab
• Click Drivers and Patches
• Choose X64 for platform.  NOTE:  Make sure you are configuring X64
• For selection profile choose WindowsPEX64

Step 8:  Create Task Sequence

• Right click Task Sequences and choose “new task sequence.  Set the following options:
  • Task Sequence ID:  1
  • Task Sequence Name: “Build Windows 10 Enterprise 1703”
  • Standard Client Task Sequence
  • Choose the Windows 10 Enterprise 1703 source files install.wim
  • Do not specify product key
  • Set your organization
  • Set local admin password

Step 9:  Set DriverGroup001 variable

The following sets up a variable so that when “Surface Studio” is detected as model, the drivers under the Surface Studio folder in Out Of Box Drivers will get added to the deployment.  A best practice is to only install those drivers for that particular device you are deploying to.  This ensures that no other drivers from other devices or platforms get added to the deployment to this device

• Right click “Build Windows 10 Enterprise 1703” task sequence and choose properties
• Click Task Sequence tab
• Under Preinstall section choose Enable Bitlocker (offline)
• Click add, general, set task sequence variable
• Set:
  • Name:  Set DriverGroup001 to Model
  • Task Sequence Variable:  DriverGroup001
  • Value:  Windows10\X64\%model%

• Choose Apply
• Choose the Inject Drivers step
• Set “Choose a selection profile” to nothing
• Choose “install all drivers from the selection profile”

Step 10:  Update Lite Touch Images

• Right click the deployment share and choose “Update Deployment Share”
• Choose “completely regenerate the boot images”
• This updates the Lite Touch boot images located in \DeploymentShare\Boot

Step 11:  Boot Lite Touch

How you boot Lite Touch varies based on your configuration

• Import Lite Touch Images(DeploymentShare\Boot\LiteTouchPE_X64.wim) into your Windows Deployment Server (WDS) and PXE boot.
• Boot Lite Touch from USB drive (which connects back to your MDT server over network)
• Create MDT Media deployment on USB drive.  This is basically a copy of your entire deployment share on USB drive and does not require any network connectivity back to MDT server.  See steps below for creating

Steps to create MDT Media Deployment

If you want to deploy to Surface Studio using USB drive(no network connection required to MDT server)you can use the following steps to create one.  Make sure the drive is large enough to hold all the content

• Under Advanced Config right click Selection Profile, choose new selection profile
• Name it “Offline Media Deployment 1703”
• Choose these folders

Note:  Be sure and choose all folders noted

• Choose Ok
• Create a folder c:\mediadeployment
• Under Advanced Config, right click media and choose “new media”
• Choose the “Offline Media Deployment 1703” selection Profile
• Choose c:\mediadeployment

• Click the Windows PE tab
• Choose X64 platform.  NOTE:  Be sure and choose X64
• Choose Drivers and patches tab
• Set the selection profile to WindowsPEX64

• Choose OK
• Right mouse click Media001 and choose Update Media Content
• This will create the following files/folders:

• Format a USB drive as FAT32
• Copy everything under the content folder to the root of the USB drive
• You can now boot from this USB drive on Surface Studio and do your deployment

Additional Surface Studio Deployment Notes

• When PXE booting Lite Touch you will have to use the OSK keyboard (located in lower right corner of screen) or physical USB keyboard to press Enter if required by your PXE server.
• During Lite Touch, touch is available to choose options but in order to type in credentials or other information you will need a physical USB keyboard attached.  It is possible to fully automate Lite Touch by adding appropriate entries into customsettings.ini
• The keyboard and mouse included with Surface Studio are Bluetooth and require pairing once setup is complete.

I know this blog has been a long one but once you get this setup it is pretty easy to customize and update it easily.  Hope this helps with your Surface Studio Deployments

Scott McArthur

Hi, my name is Scott McArthur and I am Supportability Program Manager in Surface.  Today I am going discuss two scenarios involving deploying Windows 10 to Surface Studio.

Today if you don’t follow the steps outlined below you will see the following symptoms:

• Windows Setup runs and does not report errors but on 1st reboot of setup, it boots into the OS that is currently on the drive and not back into setup.  So, to the admin it’s as though setup didn’t do anything
• During setup or manually running DISKPART.EXE you format the drive but after reboot the drive is still formatted.

I should preface this blog with that I would normally recommend you leverage a tool like Microsoft Deployment Toolkit (MDT) to build reference images (which can then be deployed by MDT or Configuration Manager) since it handles all what I am going to outline automatically but I understand that sometimes manual instructions are needed.

For information on how to use Microsoft Deployment Toolkit to do a full deployment to Surface Studio see my other blog notes.

• Surface Studio ships with Hybrid Drive Configuration.  In order to talk to this drive configuration, you need the Intel Chipset SATA Raid Controller driver that ships with latest Surface Studio driver download.
• Surface Studio requires the use of the “Intel Chipset SATA Raid controller”, iastora.sys that ships in latest Surface Studio driver download.  It is not supported to use any version of this driver from other sources (Intel.com, other OEM vendors, etc.)
• Changing the configuration of the Hybrid Drive is not supported currently.  There is no mechanism in UEFI or any Microsoft supplied driver to change the cache size or disable the cache

Scenario #1:  Install Windows 10 from USB drive

This scenario is where you want to put Windows 10 source files (Surface Studio requires RS1 or later) on USB drive and boot from it to install on Surface Studio.  This is a very simple scenario but it requires some additional work on Surface Studio.

In order for this to work you must inject this driver into the BOOT.WIM where setup runs from as well as in the INSTALL.WIM where Windows is installed from

Assumptions:

• Latest Windows ADK is installed
• Latest Surface Studio .MSI is downloaded from here and extracted
  • msiexec /a SurfaceStudio_Win10_15063_1701606_0.msi targetdir=C:\SurfaceStudioDrivers /qn
  •  Note: When extracting driver files from the MSI, the destination folder (targetdir) must be different than the folder containing the MSI file.
• Windows 10 Version 1607 ISO (or later) contents are copied to USB drive E:\

Steps:

1. Mount the boot image index #2(where setup runs from)
   • DISM /MOUNT-IMAGE /IMAGEFILE:E:\SOURCES\BOOT.WIM /INDEX:2 /MOUNTDIR:C:\MOUNT
2. Add the Intel Chipset SATA Raid Controller driver(iastora.sys) to the boot image
   • DISM /IMAGE:C:\MOUNT /ADD-DRIVER /DRIVER: C:\SURFACESTUDIODRIVERS\SURFACEPLATFORMINSTALLER\SURFACESTUDIO_WIN10_15063_1701606_0\DRIVERS\SYSTEM\RST_AHCI\IASTORAC.INF
3. Unmount the boot image and commit changes
   • DISM /UNMOUNT-IMAGE /MOUNTDIR:C:\MOUNT /COMMIT
4. Mount the install.wim image
   • DISM /MOUNT-IMAGE /IMAGEFILE:E:\SOURCES\INSTALL.WIM /INDEX:1 /MOUNTDIR:C:\MOUNT
5. Add the Intel Chipset SATA Raid Controller driver(iastora.sys) to the install image
   • DISM /IMAGE:C:\MOUNT /ADD-DRIVER /DRIVER: C:\SURFACESTUDIODRIVERS\SURFACEPLATFORMINSTALLER\SURFACESTUDIO_WIN10_15063_1701606_0\DRIVERS\SYSTEM\RST_AHCI\IASTORAC.INF
6. Unmount the install.wim and commit changes
   • DISM /UNMOUNT-IMAGE /MOUNTDIR:C:\MOUNT /COMMIT

The steps above are geared specifically at the storage controller driver.  Once Windows is installed you would want to install the full .MSI to get all the other Surface Studio drivers installed

Scenario #2:  Creating Generic Windows PE image

If you are using some other deployment tool that leverages Windows PE the steps would be similar.  The following list out how you would create a generic Windows PE image that supports Surface Studio

1. Create Windows PE image
   • COPYPE.CMD AMD64 C:\WINPE_X64
2. Mount Windows PE image
   • DISM /MOUNT-WIM /WIMFILE:.C:\WINPE_X64\MEDIA\SOURCES\BOOT.WIM /INDEX:1 /MOUNTDIR:C:\WINPE_X64\MOUNT
3. Add the Intel Chipset SATA Raid Controller driver(iastora.sys) to the WinPE boot image
   • DISM /IMAGE:C:\WINPE_X64\MOUNT /ADD-DRIVER: C:\SURFACESTUDIODRIVERS\SURFACEPLATFORMINSTALLER\SURFACESTUDIO_WIN10_15063_1701606_0\DRIVERS\SYSTEM\RST_AHCI\IASTORAC.INF
4. Dismount the image
   • DISM /UNMOUNT-WIM /MOUNTDIR:C:\WINPE_X64 /COMMIT
5. Create the USB Windows PE image
   • MAKEWINPEMEDIA /UFD C:\WINPE_X64 E:

Hope this helps with your Surface Studio Deployments !!

Scott McArthur

Hi, my name is Scott McArthur and I am Supportability PM with commercial Surface. Today’s blog will discuss how to enable the keyboard on the new Surface Laptop during a Microsoft Deployment Toolkit deployment. The information in this blog could be used for other deployment methodologies also

On most devices, the keyboard should work while in Lite Touch. Surface Laptop requires some additional drivers to enable the keyboard. Use the following steps:

1. Download the latest Surface Laptop .MSI from https://www.microsoft.com/en-us/download/details.aspx?id=55489

2. Extract the contents to folder

Msiexec.exe /a SurfaceLaptop_Win10_15063_1703008_1.msi targetdir=c:\surface_laptop_drivers /qn

Best practice with MDT is to create a folder for WindowsPE and use selection profile to limit what drivers are injected into Lite Touch.

For example, the WindowsPEX64 folder below

You should import the following folders into the WindowsPEX64 folder.

• C:\surface_laptop_drivers\SurfacePlatformInstaller\Drivers\System\GPIO
• C:\surface_laptop_drivers\SurfacePlatformInstaller\Drivers\System\SurfaceHidMiniDriver
• C:\surface_laptop_drivers\SurfacePlatformInstaller\Drivers\System\SurfaceSerialHubDriver

The following shows the 3 folders imported (5 drivers). It also contains the latest Surface Ethernet Driver.

Selection profile configuration

You should also have a selection profile configured for the folder

Configuration of Windows PE.

Then in the configuration of Windows PE you choose that selection profile, WindowsPEX64.

Notes

· Make sure you are choosing X64 architecture

· Make sure you choose “include all drivers from the selection profile” option.

Just as added note you should configure the rest of the Surface Laptop drivers using selection profile or DriverGroup001 variable. The model is Surface Laptop

When deploying a new image to Surface Laptop you should also be aware of the following issue:

4032347 “Your organization used Device Guard to block this app” error on Surface Laptop

https://support.microsoft.com/en-US/help/4032347

Hope this helps with your deployments.

Scott McArthur

Recently, we’ve seen an increase in the number of high CPU/High Memory usage problems with WSUS, including WSUS in a System Center Configuration Manager environment – these have mostly corresponded with Update Tuesdays.

Microsoft support has determined that the issue is driven primarily by the Windows 10 1607 updates, for example KB4022723, KB4022715, KB4025339, etc. See here for the list of Windows 10 1607 updates.

Microsoft is also aware of a known issue with KB4034658 that will cause Windows 10 1607 clients to run a full scan after install – Microsoft is investigating and the latest information is available here.

These updates have large metadata payloads for the dependent (child) packages because they roll up a large number of binaries. Windows 10, versions 1507 (Windows 10 RTM) and 1511 updates can also cause this, though to a lesser extent.  Windows 10, version 1703 is still recent enough that the metadata is not that large yet (but will continue to grow).

The WSUS team is investigating improvements to metadata processing. We will update this blog when as updates become available.

Symptom

The symptoms include

• High CPU on your WSUS server – 70-100% CPU in w3wp.exe hosting WsusPool
• High memory in the w3wp.exe process hosting the WsusPool – customers have reported memory usage approach 24GB
• Constant recycling of the W3wp.exe hosting the WsusPool (identifiable by the PID changing)
• Clients failing to scan with 8024401c (timeout) errors in the WindowsUpdate.log
• Mostly 500 errors for the /ClientWebService/Client.asmx requests in the IIS logs

Cause

Microsoft support has determined that the issue is driven primarily by the Windows 10 1607 updates, for example KB4022723, KB4022715, KB4025339, etc. See here for the list of Windows 10 1607 updates.

These updates have large metadata payloads for the dependent (child) packages because they roll up a large number of binaries. Windows 10, versions 1507 (Windows 10 RTM) and 1511 updates can also cause this, though to a lesser extent. Windows 10, version 1703 is still recent enough that the metadata is not that large yet (but will continue to grow).

How to determine if the 1607 Updates are the cause

To determine if WSUS is affected by this problem, decline the Windows 10 updates (including the latest cumulative update). If CPU and memory quickly drop back to normal, then the issue is likely the result of metadata size from the Windows 10 updates. They can be reapproved after you have determined if the updates are causing this issue, assuming you want to deploy them.

If declining the Windows 10 updates does not help, then the problem may be due to too many superseded updates in the WSUS server. Take the steps outlined in The Complete Guide to Microsoft WSUS and Configuration Manager SUP maintenance to decline the superseded updates. If, after doing this you are still having problems, read on.

This blog post may help alleviate some of these problems, but is not a magic bullet. After these changes are made, you will still see high CPU and memory until the system stabilizes as I explain further down.

WSUS Caching

WSUS has a caching mechanism whereby the first-time update metadata is requested by any client WSUS will store it in memory. Further requests for the same update revision will retrieve the update metadata from memory instead of reading it from the database. Some of the metadata in the database is compressed, so not only must it be retrieved, it must be decompressed into memory, which is an expensive operation.

You can monitor the current number of updates stored in the cache via Performance Monitor with the counter WSUS: Client Web Service/Cache size and instance spgetcorexml. Keep in mind that this counter provides the number of cached items, not the amount of memory consumed by cached metadata. w3wp.exe process memory can be used as a proxy for the amount of space consumed by the metadata cache.

The Problem

For large metadata packages and many simultaneous requests, it can take longer than ASP.NET’s default timeout of 110 seconds to retrieve all of the metadata the client needs. When the timeout is hit, ASP.NET disconnects the client and aborts the thread doing the metadata retrieval. If you look at Program Files\Update Services\LogFiles\SoftwareDistribution.log, the abort looks like this:

System.Threading.ThreadAbortException: Thread was being aborted.

   at System.Buffer.__Memcpy(Byte* dest, Byte* src, Int32 len)

   at System.Buffer._Memcpy(Byte* dest, Byte* src, Int32 len)

   at System.Buffer.Memcpy(Byte* dest, Byte* src, Int32 len)

   at System.String.CtorCharPtrStartLength(Char* ptr, Int32 startIndex, Int32 length)

   at Microsoft.UpdateServices.Internal.CabUtilities.ExpandMemoryCabToString(Byte[] src)

   at Microsoft.UpdateServices.Internal.DataAccess.ExecuteSpGetCoreUpdateXml(Int32[] revisionIds)

   at Microsoft.UpdateServices.Internal.DataAccessCache.GetCoreUpdateXml(Int32[] revisionIds,
DataAccess da, Int64 maxXmlPerRequest)

   at Microsoft.UpdateServices.Internal.ClientImplementation.GetSyncInfo(
Version clientProtocolVersion, DataAccess dataAccess, Hashtable stateTable,
Hashtable deploymentTable, Boolean haveGroupsChanged, Boolean driverSyncNeeded,
Boolean doChunking)

   at Microsoft.UpdateServices.Internal.ClientImplementation.SoftwareSync(DataAccess dataAccess,
UnencryptedCookieData cookieData, Int32[] installedNonLeafUpdateIds, Int32[] leafUpdateIds,
Boolean haveGroupsChanged, Boolean expressQuery, Guid[] filterCategoryIds,
Boolean needTwoGroupOutOfScopeUpdates)

   at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cookie cookie,
SyncUpdateParameters parameters)

   at Microsoft.UpdateServices.Internal.ClientImplementation.SyncUpdates(Cookie cookie,
SyncUpdateParameters parameters)

Note: What you are looking for is a ThreadAbortException with ExecuteSpGetCoreUpdateXml on the stack (ThreadAbortExceptions could happen for other reasons as well – we are concerned with this specific scenario).

When the thread abort happens, all of the metadata that has been retrieved to that point is discarded and is not cached. As a result, WSUS enters a continuous cycle where the data isn’t cached, the clients can never complete the scan and continue to rescan.

Another issue that can occur is the WSUS application pool keeps recycling because it exceeds the private memory threshold (which it is very likely to do if the limit is still the default of 1843200). This recycles the app pool, and thus the cached updates, and forces WSUS to go back through retrieving updates from the database and caching them.

Solution

Configure IIS to stop recycling the App Pool

The goal is to stop the app pool recycling since a recycle clears the cache. The defaults in IIS for Private Memory limit of 1843200 will cause the pool to constantly recycle. We want to make sure it doesn’t recycle unless we intentionally restart the app pool.

• Open IIS Manager for the WSUS server
• Expand <Server name> and click Application Pools.
• Find WSUSPool > Right-click > Advanced Settings.
• Find the setting Private Memory Limit (KB) under Recyling and set it to 0.
  • Check and verify Virtual Memory Limit (KB) is set to 0 .
  • This will prevent IIS from recycling due to a memory limit.
• Find the setting Regular Time Interval (minutes) below the Private Memory limit and set to 0.
• Find the Ping Enabled setting and set it to False.
  • This will prevent IIS from recycling the pool if it gets too busy and doesn’t respond to the ping.
• Click OK.
• From an elevated command prompt, run IISReset to restart IIS.

Limit the number of inbound connections to WSUS

Reducing the number of allowed connections will cause clients to receive 503 errors (service not available), but they will retry. If the performance counter Web Services | Current Connections for the website on which WSUS is hosted has more than 1000 connections, complete this step:

• Open IIS Manager for the WSUS server.
• Expand <Server name> and then Sites.
• Select the site hosting WSUS.
  • If you aren’t sure, expand each site and look for the ClientWebService directory underneath it – that is the WSUS site the clients use.
• With the site selected, click the Limits link in the toolbar on the right side.
• Check the option Limit number of connections and change it to 1000 (or even smaller).
• Click Ok to save the changes.
• From an elevated command prompt, run IISReset to restart IIS.

Increase the ASP.NET timeout

• Make a copy of \Program Files\Update Services\WebServices\ClientWebService\Web.Config.
• Open \Program Files\Update Services\WebServices\ClientWebService\Web.Config.
• Find the element “<httpRunTime”. It will look like this (in an unmodified web.config):

<httpRuntime maxRequestLength="4096" />

• Modify httpRunTime by adding an executionTimeout attribute:

<httpRuntime maxRequestLength="4096" executionTimeout="3600" />

• Save the web.config to a different location and copy the modified one into the directory.
• From an elevated command prompt, run IISReset to restart IIS.

Monitor

Open Windows Performance monitor and add the following counters

• WSUS: Client Web Service | Cache Size counter for spgetcorexml instance.
• Process | Private Memory counters.
  • If there is more than one w3wp.exe, add them all – the one with the highest memory usage is probably the WSUSPool, but you can also add Process | ID Process to determine which worker process should be monitored.

Monitor the cache size counter – it should increase and eventually reach a peak value that does not change. This indicates all metadata that clients need is cached. It can take several hours for this to stabilize, so be patient.

Monitor the IIS logs and filter on ClientWebService/Client.asmx. The majority will be 500s, but as the cache increases, the number of 200s will increase with it. Once the cache is fully built, you should see mostly 200s.

If you see the cache size drop, then one of two things has happened:

1. The App pool was recycled (or it crashed), or
2. The cache was purged due to memory pressure

If the app pool process ID didn’t change and you didn’t make any changes to IIS config that would cause the app domain to unload (such as changing IIS connection limit), then you have most likely hit scenario #2. To get around this, you can force the cache to be a certain size before items will be trimmed from it. You can also make this change beforehand if you wish.

• Make a copy of \Program Files\Update Services\WebServices\ClientWebService\Web.Config.
• Open \Program Files\Update Services\WebServices\ClientWebService\Web.Config.
• Find the element <system.web>.
• Immediately under it add a new element:

<caching>

          <cache privateBytesLimit = "8000000000"/>

</caching>

• The privateBytesLimit value can be changed to be larger. 8,000,000,000 is usually enough
• Save the web.config to someplace else, backup the old one, then copy the modified one into the directory.

• From an elevated command prompt, run IISReset to restart IIS.

Again monitor the cache size – if it continues to bounce around and the PID isn’t changing and memory is high ( > 8GB) then you probably need increase the privateBytesLimit further.