Hope everyone is having a good day.  Today, we have a guest among us.  Steve Wright is a Senior Program Manager in the Developer Platform Group.  He is authoring this blog regarding scaling in Windows 10 with how it works and how users will benefit from the work we have done with scaling.

Overview/Introduction

Windows 10 is an important release for Windows display scaling. It implements a unified approach to display scaling across all SKUs and devices aimed at these goals:

1) Our end users enjoy a mix of UWP and classic desktop applications on desktop SKUs which reliably provide content at a consistent size

2) Our developers can create UWP applications that deliver high quality reliably-sized content across all display devices and all Windows SKUs

Windows 10 also delivers desktop and mobile UI which looks polished and crisp across a wider range of display densities and viewing distances than we have ever before supported on Windows. Finally, Windows 10 drives support for high quality multi-monitor scaling for docking and projection into more of both our desktop and our mobile UI.

This article covers the basics of scaling in Windows 10, how it works, and how users will benefit from the work we have done. It wraps up by charting the course forward and show what we want to tackle in future updates to Win10.

Our vision for display scaling

For our end users, display scaling is a platform technology ensuring that content is presented at a consistent and optimal–yet easily adjustable–size for readability and comprehension on every device. For our developers, display scaling is an abstraction layer in the Windows presentation platform, making it easy for them to design and build apps, which look great on both high and low density displays.

Basic concepts and terms

We need a basic glossary of terms and some examples to show why scaling is important:

While these examples use phones for the sake of simplicity, the same concepts apply to wearables, tablets, laptops, desktop displays and even conference room wall-mounted TVs and projectors.

Dynamic scaling scenarios

Note that more than one display may be used on the same device—either all at the same time, or at different times in sequence. Scale factor and effective resolution are therefore dynamic concepts and depend on where content is displayed at a particular time.

Some everyday scenarios where this dynamic scaling can take place include projecting, docking, moving apps between different monitors, and using remote desktop to connect your local display to a remote device.

Who does the scaling, and how do they do it

Because Windows supports many different kind of applications and presentation platforms, scaling can occur in different places. This table illustrates the major scaling categories:

What this means for the user:

1. UWPs and most Windows UI looks great on high DPI displays and in any multi-monitor scenarios where different display scale factors are in play
2. A few important classic desktop apps (and all WPF apps) look great on high DPI primary displays but a little blurry on other secondary displays
3. A large number of older classic desktop apps look blurry on high DPI displays.

What we have done in Windows 10

Now we can talk about the work done in Windows 10 to improve our support for both high DPI displays and for dynamic scaling scenarios. This works falls into several major areas:

1. Unifying how content is scaled across all devices running Windows to ensure it consistently appears at the right size
2. Extending the scaling system and important system UI to ensure we can handle very large (8K) and very dense (600 DPI) displays
3. Adding scaling support to the mobile UX
4. Improve Windows support for dynamic scaling: more OS and application content scales dynamically, and the user has greater control over each display’s scaling

Let’s take a closer look at each of these.

Unified and extended scaling system

In Windows 8.1 the set of supported scale factors was different for different kinds of content. Classic desktop applications scaled to 100%, 125%, 150%, 200% and 250%; Store apps scaled to 100%, 140% and 180%. As a result, when running different apps side by side in productivity scenarios, content could have inconsistent sizes in different apps. In addition, on very dense displays, the scaling systems “capped out” at different points, making some apps too small on them.

This chart shows the complexity and limits of the 8.1 scaling systems:

For Windows 10, we unified all scaling to a single set of scale factors for both UWP and classic applications on both the Desktop and Mobile SKU:

In Windows 8.1 all scaling topped out at 180% or 250%. For Windows 10 we knew that devices like 13.3” 4K laptops and 5.2” and 5.7” QHD phones would require even higher scale factors. Our unified scaling model for Windows 10 runs all the way to support 450%, which gives us enough headroom to support future displays like 4K 6” phones and 23” 8K desktop monitors.

As part of this effort, Windows 10 has polished the most commonly used desktop UI to look beautiful and clear even at 400% scaling.

Making the mobile shell scalable

We have also overhauled our Mobile SKU so that the mobile shell UI and UWP apps will scale to the Windows 10 scale factors. This work ensures that UWP apps run at the right size on phones and phablets as well as desktop displays, and that the mobile shell UI is presented at the right size on phones of different sizes, resolutions and pixel densities. This provides our users with a more consistent experience, and makes it easier to support new screen sizes and resolutions.

Improve Windows’ support for dynamic scaling

When we added dynamic scaling support in Windows 8.1, there was relatively little inbox UI that worked well with dynamic scaling, but in Windows 10, we have done work in many areas of the Windows UI to handle dynamic scaling.

UWP application dynamic scaling

As noted above, UWP HTML and XAML apps are designed to be dynamically scalable. As a result, these applications render crisply and with the right size content on all connected displays.

Windows “classic” desktop UI

Windows 10 makes large parts of the most important system UI scale properly in multi-monitor setups and other dynamic scaling scenarios so that it will be the right size on any display.

Start Experience

For example, the desktop Start and Cortana experiences are built on the XAML presentation platform, and because of that, they scale crisply to the right size on every display.

File Explorer

File Explorer—a classic desktop application built on the Win32 presentation platform—was not designed to dynamically rescale itself. In Windows 10, however, the file explorer app has been updated to support dynamic scaling.

Windows Taskbar

In Windows 8.1 the Windows taskbar had similar historical limitations. In Windows 10, the taskbar renders itself crisply at every scale factor and the correct size on all connected displays in all different scenarios. Secondary taskbar UI like the system clock, jumplists and context menus also scale to the right size in these scenarios.

Command shells et al.

We have done similar work elsewhere in commonly used parts of the desktop UI. For example, in Windows 10 “console windows” like the command prompt scale correctly on all monitors (provided you choose to use scalable fonts), and other secondary UI like the “run dialog” now scales correctly on each monitor.

Mobile shell and frameworks

In Windows 10 the mobile platform also supports dynamic scaling scenarios. In particular, with Continuum, the phone can run apps on a second attached display. In most cases external monitors have different scale factors than the phone’s display. UWP apps and shell UI can now scale to a different DPI on the secondary display applications so that Continuum works correctly at the right size on the Mobile SKU.

User scaling setting

Windows 8.1 users reported frustration with the user setting for scaling:

1. There was a single slider for multiple monitors. The slider changed the scale factor for every connected monitor, making it impossible to reliably tweak the scale factor for only one of the displays.
2. Users found it confusing that there were two scale settings, one for modern apps/UI and another for classic apps/UI, and that the two settings worked in significantly different ways.

In Windows 10, there is a single scale setting that applies to all applications, and the user applies it to a single display at a time. In the fall update, this setting has been streamlined to apply instantly.

What we didn’t get to

We are already seeing a number of common feedback issues that we’re working on for future releases of Windows. Here are some of the biggest ones we are tracking for future releases:

Unscaled content: Lync, desktop icons

Some applications (for example, Lync) choose to disable bitmap scaling for a variety of technical reasons, but do not take care of all their own scaling in dynamic scaling scenarios. As a result, these apps can display content that is too large or too small. We are working to improve these apps for a future release. For example, desktop icons are not per-monitor scaled in Windows 10, but in the fall update they are properly scaled in several common cases, such as docking, undocking, and projection scenarios.

Blurry bitmap-scaled content: Office apps

Although the UWP Office applications are fully per-monitor scaled in Windows 10, the classic desktop apps are “System scale factor apps”, as described in the table above. They generally look great on a high DPI device, but when used on secondary displays at different scale factors (including docking and projection), they may be somewhat blurry due to bitmap scaling. A number of popular desktop applications (Notepad++, Chrome, Firefox) have similar blurriness issues in these scenarios. We have ongoing work on improving migration tools for developers with these complex Win32 desktop applications.

Conclusion

Scaling is a complex problem for the open Windows ecosystem, which has to support devices ranging in size from roughly 4” to 84”, with densities ranging from 50DPI to 500DPI. In Windows 10 we took steps to consolidate and simplify our developer story for scaling and to improve the end-user visual experience. Stay tuned for future releases!

If you use copyprofile when customizing your Windows 10 profiles, you may encounter a scenario where pinned icons, such as Desktop under Quick Access for Windows 10 will not be accessible and users may encounter an issue similar to the following when attempting to access or save an item to that location.

“Location is not available. C:\Users\Administrator\Desktop is not accessible. Access is denied.”

Microsoft is aware of the issue and is investigating further. To work around this issue, or to fix the issue if user profiles are already deployed and experiencing this behavior, consider implementing any of the following following options depending on your deployment scenario and requirements.

1. Before the image is created– Unpin the "desktop" shortcut from Quick Access prior to sysprep/copyprofile. The "desktop" shortcut under This PC will not be available upon profile creation. All other customizations will be retained.

2. After the image is created and deployed to address new logons– After sysprep (e.g. while in OOBE or logged in), delete the following file from the default profile . This will remove any customizations made to the Quick Access list prior to sysprep/copyprofile.

a. %systemdrive%\users\default\appdata\roaming\microsoft\windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms

3. After the image is created and deployed to address existing logons– Delete the file per-user so it's regenerated the next time Explorer is opened (again, losing any customizations):

a. %appdata%\microsoft\windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms

4. After the image is created and deployed to address existing logons – Have the user unpin and re-pin the Desktop from Quick Access after logon.

For steps 2a and 3a, you can utilize group policy preferences to deploy this to users that might be already experiencing the issue in their environment.

2a: %systemdrive%\users\default\appdata\roaming\microsoft\windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms

3a: %appdata%\microsoft\windows\Recent\AutomaticDestinations\f01b4d95cf55d32a.automaticDestinations-ms

This blog discusses on how to obtain and review the Compatibility Reports to troubleshoot Windows 10 Upgrades.
On a PC that is eligible for the free upgrade offer, you can use the "Get Windows 10" app and choosing the "Check your upgrade status". The report will be displayed within the app showing issues in separate categories for devices and apps that would have potential issues.

If your PC/Tablet does not qualify for the Free Windows 10 Upgrade Offer, you would not be able to launch the app and get the Compatibility reports. Example: You are running the Windows 8.1 Enterprise/Windows 7 Enterprise editions or other scenarios.

1. Use the Windows 10 installation media that you intend to use and launch the Windows 10 Setup Program.

2. After checking for the most recent Dynamic updates for the Windows 10 installation, the installation will run a compatibility check in the background and you should see:

3. You can see the full list of potential compatibility issues in the files located in the folder:

C:\$Windows.~BT\Sources\Panther

The files would be named as CompatData_YEAR_MONTH_DATE_HOUR_MIN_SEC… so on. These CompatData files would provide information about the compatibility of Hardware / Software issues.

You can also get the setupact.log file from the C:\$Windows.~BT\Sources\Panther folder and use the below steps to get only the Compatibility information from the logs.

To view the details that included in the Setupact.Log file, you can copy the information to the Setupactdetails.txt file by using the Findstr command, and then view the details in the Setupactdetails.txt. To do this, follow these steps:

A. Open an elevated command prompt.

B. At the command prompt, type the following command, and then press ENTER:

findstr /c:"CONX" C:\$Windows.~BT\Sources\Panther\setupact.log  >"%userprofile%\Desktop\Setupactdetails.txt"

C. Open the Setupactdetails.txt file from your desktop to review the details.

Also, see:
Troubleshooting common Windows 10 upgrade errors and issues
https://support.microsoft.com/en-us/kb/3107983

Ram Malkani
Support Escalation Engineer
Windows Core Team

In this blog, my Colleague, JP, and I would like to talk about how to start a Cluster without the need of the ForceQuorum (FQ) switch.  We have identified 3 different scenarios and how the Cluster behaves when you turn on the nodes in a certain order for Windows Server 2012 R2.  I first want to mention two articles that you should be familiar with.

How to Properly Shutdown a Failover Cluster or a Node
http://blogs.msdn.com/b/clustering/archive/2013/08/23/10443912.aspx

Microsoft’s recommendation is to configure the Cluster with a witness
https://technet.microsoft.com/en-us/library/dn265972.aspx#BKMK_Witness

Now, on to the scenarios.

Scenario 1: Cluster without a witness (Node majority)
Scenario 2: Cluster with a disk witness
Scenario 3: cluster with a file share witness

In the below scenario, we have tried starting the cluster with and without the witness.

Scenario 1: Cluster without a witness (Node Majority)
=====================================================

Let’s use the name of cluster as ‘CLUSTER’ and the name of the nodes as ‘A’ ‘B’ and ‘C’.  We have setup the witness type as Node Majority.  All
nodes have a weighted vote (meaning an assigned and a current vote).  The core Cluster Group and the other resources (two Cluster Shared Volumes) are on Node A.  We also have not defined any Preferred Owners of any group.  For simplistic sake, the Node ID of each is as follows.  You can get NodeID with the Powershell commandlet Get-ClusterNode.

Name ID State
==== == =====
A    1  Up
B    2  Up
C    3  Up

When we gracefully shut down Node A, all the resources on the node fail over to Node B, which is the next highest Node ID.  When we say a graceful shutdown, we are meaning shutting down the machine by clicking on the Start Menu or shutting down after applying patches.  All the resources are on Node B.  So the current votes would be:

Node A = 0
Node B = 1
Node C = 1

Now, let’s gracefully shut down Node B.  All the resources now failover to Node C.  As per the way dynamic quorum works with Windows Server 2012 R2, the Cluster sustains on one node as the “last man standing”.  So our current votes are:

Node A = 0
Node B = 0
Node C = 1

Now we want to gracefully shut down Node C as well.  Since all the nodes are down, the Cluster is down. 

When we start Node A, which was shut down first, the Cluster is not formed and we see the below in the Cluster log:

INFO  [NODE] Node 3: New join with n1: stage: ‘Attempt Initial Connection’ status (10060) reason: ‘Failed to connect to remote endpoint 192.168.1.101:~3343~’
DBG   [HM] Connection attempt to C failed with error (10060): Failed to connect to remote endpoint 192.168.1.101:~3343~.
INFO  [NODE] Node 3: New join with n2: stage: ‘Attempt Initial Connection’ status (10060) reason: ‘Failed to connect to remote endpoint 192.168.1.100:~3343~’
DBG   [HM] Connection attempt to C failed with error (10060): Failed to connect to remote endpoint 192.168.1.100:~3343~.
DBG   [VER] Calculated cluster versions: highest [Major 8 Minor 9600 Upgrade 3 ClusterVersion 0x00082580], lowest [Major 8 Minor 9600 Upgrade 3 ClusterVersion 0x00082580] with exclude node list: ()

When we start Node B, which was shut down second, the Cluster is not formed and below are the entries we see in the Cluster log:

INFO  [NODE] Node 1: New join with n2: stage: ‘Attempt Initial Connection’ status (10060) reason: ‘Failed to connect to remote endpoint 192.168.1.100:~3343~’
DBG   [HM] Connection attempt to C failed with error (10060): Failed to connect to remote endpoint 192.168.1.100:~3343~.
DBG   [VER] Calculated cluster versions: highest [Major 8 Minor 9600 Upgrade 3 ClusterVersion 0x00082580], lowest [Major 8 Minor 9600 Upgrade 3 ClusterVersion 0x00082580] with exclude node list: ()

Both nodes are trying to connect to Node C, which is shut down.  Since they are unable to connect to Node C, it does not form the Cluster.  Even though we have two nodes up (A and B) and configured for Node Majority, the Cluster is not formed.

WHY??  Well, let’s see.

We start Node C and now the Cluster is formed.

Again, WHY??  Why did this happen when the others wouldn’t??

This is because the last node (Node C) that was shutdown was holding the Cluster Group. So to answer your questions, the node that was shut down last  is the first node to be turned on.  When a node is shutdown, its vote is changed to 0 in the Cluster registry.  When a node goes to start the Cluster Service, it will check its vote.  If it is 0, it will only join a Cluster.  If it is 1, it will first try to join a Cluster and if it cannot connect to the Cluster to join, it will form the Cluster.

This is by design.

Shut down all the 3 nodes again in the same order. 

Node A first
Node B second
Node C last

Power up Node C and the Cluster is formed with the current votes as:

Node A = 0
Node B = 0
Node C = 1

Turn on Node B.  It joins and is given a vote.  Turn on Node A.  It joins and is given a vote. 

If you start any other node in the Cluster other than the node that was last to be shut down, the ForceQuorum (FQ) switch must be used to form the Cluster.  Once it is formed, you can start the other nodes in any order and they would join.

Scenario 2: Cluster with a disk witness
=======================================
We take the same 3 nodes and the same environment; but, add a disk witness to it.

Let’s observe the difference and the advantage of adding the witness.  To view the property of Dynamic witness weight, use the Powershell commandlet (Get-Cluster).WitnessDynamicWeight.

PS C:\> (Get-Cluster).WitnessDynamicWeight
0

NOTE:
The setting of 1 means it has a vote.  The setting of 0 means it does not have a vote.  Remember, we still go by the old ways of keeping the votes at an odd number

Initially, the Cluster Group and all the resources are on Node A with the other 2 nodes adding votes to it.  The Disk Witness also adds a vote dynamically when it is needed.

Node A = 1 vote = Node ID 1
Node B = 1 vote = Node ID 2
Node C = 1 vote = Node ID 3
Disk Witness = 0 vote

We gracefully shut down Node A.  All the resources and the Cluster Group move to Node B while Node A loses its vote.  Next, we gracefully shut down Node B and it loses its vote.  All the resources and Cluster Group move to Node C.  This leaves Node C as the “Last Man Standing” as in the previous scenario.  Gracefully shut down Node C as well and the Cluster is down.

This time, instead of powering on the last node that was shut down, i.e. Node C, power on Node B which was shut down in the order, second in the list.

THE CLUSTER IS UP !!!!!

This is because we have a witness configured and the Dynamic Quorum comes into play.  If you check the witness dynamic weight now, you will see that it has a vote.

PS C:\> (Get-Cluster).WitnessDynamicWeight
1

Because it has a vote, the Cluster forms.

Scenario 3: Cluster with a file share witness
=============================================
Again, we take the same 3 nodes, with the same environment and add a file share witness to it.

Presently, Node A is holding the Cluster Group and the other resources.  With the other 2 nodes and a file share witness adding the ability to dynamically add a vote to it if it needs it.

The votes are follows

Node A = 1 vote = Node ID 1
Node B = 1 vote = Node ID 2
Node C = 1 vote = Node ID 3
File Share Witness = 0 vote

We gracefully shut down Node A.  The resources move over to Node B and Node A loses a vote.  Because Node A lost the vote, the file share witness dynamically adjusted and gave itself a vote to keep it at an odd number.  Next, we gradefully shut down Node B. The resources move over to Node C and Node B also loses its vote.

Node C is now the “Last Man Standing” which is holding the Cluster Group and all other resources.  When we shut down Node C, the Cluster shuts down.

Let’s take a look back at the 2nd scenario where we could turn on any node and the Cluster would form.  All the resources come online and we had a disk witness in place.  In the case of a file share witness, this does not happen.

If we turn on Node A, which was shut down first, the Cluster would not form even though we have a file share witness.  We need to revert back to turning on the node that was shut down last, i.e. Node C (the “Last Man Standing”), to automatically form the Cluster. 

So what is the difference?  We have a witness configured….  This is because the file share witness does not hold a copy of the Cluster Database.

So why are you doing it this way? 

To answer this, we have to go back in time to the way the Cluster starts and what database the Cluster uses when a form takes place.

In Windows 2003 and below, we had the quorum drive.  The quorum drive always had the latest copy of the database.  The database holds all configurations, resources, etc for the Cluster.  It also took care of replicating any changes to all nodes so they would have the up to date information.  So when the Cluster formed, it would download the copy on the quorum drive and then start.  This actually wasn’t the best way of doing things as there is really only one copy and if it goes down, everything goes down.

In Windows 2008, this changed. Now, any of the nodes or the disk witness would have the latest copy.  We track this with a “paxos” tag.  When a change is made on a node (add resource, delete resource, node join, etc), that nodes Paxos tag is updated.  It will then send out a message to all other nodes (and disk witness if available) to update its database.  This way, everything is current. 

When you start a node in the Cluster to form the Cluster, it is going to compare it’s paxos with the one on the witness disk.  Whichever is later is the direction in which the Cluster database is used.  If the paxos is later on the disk witness, then it downloads to the node the latest copy and uses it.  If the local node is later, it uploads it to the disk witness and runs with it.

We do things in this fashion so that you will not lose any configuration.  For example, you have a 7 node Hyper-V Cluster with 600 virtual machines running.  Node 6 is powered down, for whatever reason, and is down for a while.  In the meantime, you add an additional 200 virtual machines.  All nodes and a disk witness knows about this.  Say that the rack or datacenter the Cluster is in loses power.  Power is restored and Node6 gets powered up first.  If there is a disk witness, it is going to have a copy of the Cluster database with all 800 virtual machines and this node that has been down for so long will have them.  If you had a file share witness (or no witness) that does not contain the Cluster database, you would lose the 200 and have to reconfigure them.

The ForceQuorum (FQ) switch will override this and starts with whatever Cluster database (and configurations) that are on the node, irregardless of paxos tags numbers.  When you use this, it makes that node’s Cluster database the “golden” copy and replicates it to all other nodes (and disk witness) as they come up.  So be cautious when using this switch.  In the above example, you start up Node 6, you lost the 200 virtual machines and will need to recreate them in the Cluster.

As a side note, Windows Server 2016 Failover Cluster follows this same design.  If you haven’t had a chance to test it out and see all the new features, come on aboard and try it out.

https://www.microsoft.com/en-us/server-cloud/products/windows-server-2016/default.aspx

Regards,
Santosh Bathija and S Jayaprakash
Microsoft India GTSC

I wanted to post about a new walkthrough that we have to help in troubleshooting an Event 1135 on a Failover Cluster. 

As a bit of a background, Failover Clustering sends a heartbeat from and to each node of a Cluster to determine its health and if it responding.  If it does not respond in certain time period, it is considered down and will be removed from Cluster membership.  In the System Event Log of the remaining nodes, an Event 1135 will be triggered stating that the non-responding node was removed.

There is now a guided walkthrough to step you through troubleshooting and aiding in determining the cause.  The walkthrough will cover a number of things including Cluster networks, Antivirus, etc.  Check it out and see what you think.  Try it out the next time to see if it helps.

Troubleshooting cluster issue with event ID 1135
http://support.microsoft.com/kb/3036113

Hi, my name is Scott McArthur and I am the Supportability Program Manager for Commercial Surface and Windows products.  A common question we get from customers is “Can you direct me to information regarding what I should be thinking about when deploying Windows 10.”  All this information is available online but it helps sometimes if someone organizes all the links.  The areas below are based on what I have seen as the most common questions and topics of discussion with Windows 10.  I hope this helps with your planning and deployment of Windows 10.

Windows 10 General Information

Windows 10 release info:  https://technet.microsoft.com/en-us/windows/release-info

Windows 10 Update history:

http://windows.microsoft.com/en-us/windows-10/update-history-windows-10

Windows 10 Servicing or updating

Windows 10 Servicing options:  https://technet.microsoft.com/library/mt574263(v=vs.85).aspx

Windows 10 servicing options for updates and upgrades:  https://technet.microsoft.com/en-us/library/mt598226(v=vs.85).aspx

Windows 10 Privacy and Telemetry

Windows 10 privacy:  http://windows.microsoft.com/en-us/windows-10/windows-privacy-faq

Configure Windows 10 Telemetry settings:  https://technet.microsoft.com/library/mt577208(v=vs.85).aspx

Windows 10 Deployment

Windows 10 unattend.xml reference:  https://msdn.microsoft.com/en-us/library/windows/hardware/dn923277.aspx

Microsoft Deployment Toolkit 2013 Update 2:  http://blogs.technet.com/b/msdeployment/archive/2015/12/22/mdt-2013-update-2-now-available.aspx

Window 10 Group policy settings reference:  https://www.microsoft.com/en-us/download/details.aspx?id=25250

Windows 10 deployment using Configuration Manager: https://blogs.technet.microsoft.com/configmgrteam/2015/12/08/now-generally-available-system-center-configuration-manager-and-endpoint-protection-version-1511/

Removing Windows 10 inbox applications in MDT task sequence:  http://blogs.technet.com/b/mniehaus/archive/2015/11/11/removing-windows-10-in-box-apps-during-a-task-sequence.aspx

Remove apps such as Candy Crush, twitter, etc..:  http://blogs.technet.com/b/mniehaus/archive/2015/11/23/seeing-extra-apps-turn-them-off.aspx

.Net Framework 3.5 deployment considerations:  https://msdn.microsoft.com/en-us/library/windows/hardware/dn898590(v=vs.85).aspx

.NET Framework 3.5 deployment considerations with MDT:  http://blogs.technet.com/b/mniehaus/archive/2015/09/01/adding-features-including-net-3-5-to-windows-10.aspx

Microsoft Edge customization and configuration:   https://technet.microsoft.com/en-us/library/mt270205.aspx

Windows 10 Activation

Windows 10 volume activation tips:  https://blogs.technet.microsoft.com/askcore/2015/09/15/windows-10-volume-activation-tips/

Windows 10 KMS Host Update for Windows 10:  https://support.microsoft.com/en-us/kb/3058168

Customizing the Start Menu or TaskBar in Windows 10

Windows 10 Start Layout Customization Deployment Guys Blog:  http://blogs.technet.com/b/deploymentguys/archive/2016/03/07/windows-10-start-layout-customization.aspx

Manage Windows 10 start layout options:  https://technet.microsoft.com/en-us/library/mt484194(v=vs.85).aspx

Customize Start Menu using group policy:  https://technet.microsoft.com/en-us/library/mt431718(v=vs.85).aspx

Customize Start Menu using export/import: https://technet.microsoft.com/en-us/library/mt592638(v=vs.85).aspx

Customizing ICD or provisioning packages:  https://technet.microsoft.com/en-us/library/mt484193(v=vs.85).aspx

Changes to group policy settings for start menu in Windows 10:  https://technet.microsoft.com/en-us/library/mt484191(v=vs.85).aspx

Customizing TaskBarLinks:  https://msdn.microsoft.com/en-us/library/windows/hardware/dn923245.aspx

Windows 10 Other

Locking down Windows 10:  https://technet.microsoft.com/en-us/library/mt592641(v=vs.85).aspx

Managing Cortana in Enterprise:  https://technet.microsoft.com/en-us/library/mt637066(v=vs.85).aspx

Intro to Configuration Service Providers(CSP):  https://technet.microsoft.com/en-us/library/mt683468(v=vs.85).aspx

Windows 10 Display Scaling:  https://blogs.technet.microsoft.com/askcore/2015/12/08/display-scaling-in-windows-10/

Windows Store for Business

Windows Store for Business:  https://technet.microsoft.com/en-us/library/mt606951(v=vs.85).aspx

Using Windows Store for Business with MDT 2013: http://blogs.technet.com/b/mniehaus/archive/2016/01/11/using-the-windows-store-for-business-with-mdt-2013.aspx

Windows Update for Business

Windows Update for Business:  https://technet.microsoft.com/en-us/library/mt622730(v=vs.85).aspx

Videos

Windows 10: Deploying and Staying Up To Date [WIN326]:  https://msftignite.com.au/sessions/session-details/1706/windows-10-deploying-and-staying-up-to-date-win326

Using the Windows Store for Business: New Capabilities for Managing Apps in the Enterprise [WIN335]:  https://msftignite.com.au/sessions/session-details/1707/using-the-windows-store-for-business-new-capabilities-for-managing-apps-in-the-enterprise-win335

Upgrading to Windows 10: In Depth:  https://channel9.msdn.com/events/Ignite/2015/BRK3307

Preparing Your Enterprise for Windows 10 as a Service:  https://mva.microsoft.com/en-US/training-courses/preparing-your-enterprise-for-windows-10-as-a-service-11813?l=uUf1tqtQB_8505094681

Windows 10 for Mobile Devices: Provisioning Is Not Imaging:  https://channel9.msdn.com/Events/Ignite/2015/BRK3301

Scott McArthur
Senior Supportability Program Manager

With Failover Clustering on Windows Server 2012 R2, we introduced the concept of Dynamic Witness and enhanced how we handle a tie breaker when the nodes are in a 50% split:

See:

• Dynamic witness
• Tie breaker for 50% node split

Today, I would like to explain how we handle the scenario where you are left with one node and the witness as the only votes on your Windows Server 2012 R2 Cluster.

Let’s assume that we have a 4 Node cluster with dynamic quorum enabled.

To see the status of dynamic quorum and the witness’ dynamic weight, you can use this PowerShell command:

Now, let’s use PowerShell to look at the weights of the nodes:

Now, let’s take down the nodes one by one until we have just one of the nodes and the witness standing. I turned off Node 4, followed by Node 3, and finally Node 2:

The cluster will continue to remain functional thanks to dynamic quorum, assuming that all of the resources can run on the single node.

Let’s look at the node weights and dynamic witness weight now:

Let’s take this further and assume that for some reason, the witness also sees a failure and you see the event ID 1069 for the failure of the witness:

Log Name: System
Source: Microsoft-Windows-FailoverCluster
Date: Date
Event ID: 1069
Level: Error
User: AUTHORITY\SYSTEM
Computer: servername
Description:
Cluster resource ‘Cluster Disk x’ in clustered service or application ‘Cluster Group’ failed.

We really do not expect that this would happen on a production cluster where nodes go offline until there is one left and the witness also suffers a failure. Unfortunately, in this scenario, the cluster will not continue running and the cluster service will terminate because we can no longer achieve quorum.  We will not dynamically adjust the votes below three in a multi-node cluster with a witness, so that means we need two votes active to continue functioning.

When you configure a cluster with a witness, we want to ensure that the cluster is able to recover from a partitioned scenario. The philosophy is that two replicas of the cluster configuration are better than one. If we adjusted the quorum weight after we suffered the loss of Node 2 in our scenario above (when we had two nodes and the witness), then your data would be subject to loss with a single failure. This is intentional, we are keeping two copies of the cluster configuration and now either copy can start the cluster back up. You have a much better chance of surviving and recovering from a loss.

That’s about the little secret to keep your cluster fully functional.

Until next time!

Ram Malkani
Technical Advisor
Windows Core Team

Hi Everyone, my name is Suganya and I am from the Windows Devices and Deployment Team. I would like to discuss one of the common issues customers face today; “Customizing the recovery partition after upgrading from Windows 8.1 to Windows 10”.

What is Windows RE and why is it used?

The Windows Recovery Environment (Windows RE) is a recovery environment that can repair common causes of unbootable operating systems. Windows RE is based on Windows Preinstallation Environment (Windows PE), and can be customized with additional drivers, languages, Windows PE Optional Components, and other troubleshooting and diagnostic tools. By default, Windows RE is preloaded into the Windows 8.1 and Windows Server 2012 R2 installations. (For more information please refer to the following article:

Windows Recovery Environment (Windows RE) Overview
https://technet.microsoft.com/en-in/library/hh825173.aspx

Consider the following scenario:  You are planning an upgrade from Windows 8.1 to Windows 10.  Before upgrading the OS, you see the following partitions in the diskpart:

• System reserved partition (350 MB)
• OS partition (126 GB)
• Recovery partition (300 MB)

After the upgrade you see the following partitions:

• Recovery partition from the old OS (300 MB)
• System reserved partition (350 MB)
• OS partition (125GB)
• New Recovery partition (450MB)

Now we have two recovery partitions, but we would like to only have one and customize the partition based on our requirements.

Delete both of the current recovery partitions on the drive and follow these steps to create a new recovery partition and customize it.

1. Open the command prompt with admin privileges and run the following commands:
   1. Type diskpart
   2. Sel disk 0
   3. create partition primary size=450
   4. format quick fs=ntfs label=”Recovery tools”
   5. assign letter=”R” (This is assuming that the drive letter R is not already in use)
2. Create the folders “Recovery” and “WindowsRE” on the R:\ drive.

Use the Windows 10 ISO to copy the winre.wim to a local drive using the following command:

• dism /mount-wim /wimfile:”D:\sources\install.wim” /index:1 /mountdir:C:\test\ /readonly

You will now have the winre.wim file in the following location: “C:\Test\Windows\System32\Recovery”

• Copy the winre.wim to the c:\perflogs folder
• Unmount the image with this command:  dism /unmount-wim /mountdir:c:\test /discard

Note: This is an example as drive letters may differ in your environment. Verify drive letters in WinRE with Diskpart.

• Copy the Winre.wim to the “R:\Recovery\WindowsRE” folder.

Now, to configure the Windows® Recovery Environment, run the following command.

• reagentc /setreimage /path R:\Recovery\WindowsRE

Now if you run the command “reagentc /info” from a command prompt it shows the Status as Disabled.  When you enable it using the command “reagentc /enable”, the Status will still show as Disabled.

This can happen if the Windows Boot Loader is not updated with the correct device information.  You will have to edit the recovery.xml which is located in C:\WINDOWS\SYSTEM32\RECOVERY as it contains the older WinRE and OS image configurations.  You will have to give everyone full control for the XML file before copying the following lines to the file.

Reagent.xml should be edited to reflect these changes:

<?xml version=’1.0′ encoding=’utf-8’?>

<WindowsRE version=”2.0″>

<WinreBCD id=””/>

<WinreLocation path=”” id=”0″ offset=”0″/>

<ImageLocation path=”” id=”0″ offset=”0″/>

<PBRImageLocation path=”” id=”0″ offset=”0″ index=”0″/>

<PBRCustomImageLocation path=”” id=”0″ offset=”0″ index=”0″/>

<InstallState state=”0″/>

<OsInstallAvailable state=”0″/>

<CustomImageAvailable state=”0″/>

<WinREStaged state=”0″/>

<ScheduledOperation state=”4″/>

<OperationParam path=””/>

<OsBuildVersion path=””/>

<OemTool state=”0″/>

</WindowsRE>

Copy the edited reagent.xml to R:\Recovery\WindowsRE.  You will need to set the location of the Windows RE boot image using the following command:

• Reagentc /setreimage /path R:\RECOVERY\WINDOWSRE /target c:\windows

When you run the command “reagent /info”, you will still see the Status as Disabled.  When you run the command “reagentc /enable”, the Windows RE Status will now show as Enabled.

Also when you check the output of the command “bcdedit /enum all”, you can see that the windows boot loader is updated with the correct device information.

Now you know how to customize the recovery partitions.  For more information, please refer to the article:

Windows PE (WinPE)
https://msdn.microsoft.com/en-us/library/windows/hardware/dn938389(v=vs.85).aspx

I hope this was helpful.

Suganya Natarajan
Technical Advisor
Windows Devices and Deployment Team

The Introducing Windows Server 2016 Technical Preview book from Microsoft Press is now available. You can download it for FREE and it’s available in both standard and mobile PDF formats. This is a great way for you and our valued customers and partners to see what’s new in Windows Server 2016.

There are ways you can download depending on what you are using:

• Standard PDF
• Mobile PDF
• Microsoft Virtual Academy (MVA)

Description

Windows Server has powered a generation of organizations, from small businesses to large global enterprises. No matter what your role in IT, you can be guaranteed that you have touched Windows Server at some point in your career or, at the very least, you have seen it from afar! No matter what your area of expertise, this ebook introduces you to Windows Server 2016 Technical Preview and its latest developments, which is the next version of Windows Server.

Each chapter has been written by either field experts or members of the product group, who provide you with the latest information on every improvement or new feature that is coming in Windows Server. This information will help you to get ready for Windows Server 2016 Technical Preview and give you an opportunity to develop and design a path to introduce this powerful technology into your environment and take full advantage of what is to come. This book was written at a time when the product was still evolving, and it should be noted that things might change or not appear in the final version of Windows Server 2016 when it is released. All guidance in these chapters is meant to be tried and evaluated in a test setting; you should not implement this in a production environment.

This book assumes that you are familiar with key Windows Server concepts (i.e., Hyper-V, networking, and storage) as well as cloud technologies such as Microsoft Azure. In this ebook, we cover a variety of concepts related to the technology and present scenarios with a customer focus, but it is not intended as a how-to guide or design manual. You should use other sources including the online Microsoft resources to stay up to date with the latest developments on the roles and features of Windows Server 2016 Technical Preview. The online resources will also contain the latest how-to procedures and information about designing a Windows Server 2016 infrastructure for your business.

Enjoy,
John Marlin
Enterprise Cloud Group

Today I would like to discuss one of the issues that you face while installing updates in Windows Server 2008 R2.  When you install an update, it may hang for a very long period of time without any progress showing.  If you open Event Viewer and look in the Setup Event log, you will get the entries as shown below (in the below example hotfix KB2545850 is facing the issue):

2/2/2016 10:29:17 AM Information server.contoso.com 1 Microsoft-Windows-Servicing N/A NT AUTHORITY\SYSTEM Initiating changes for package KB2545850. Current state is Absent. Target state is Installed. Client id: WindowsUpdateAgent.

2/2/2016 1:51:06 PM Error server.contoso.com 3 Microsoft-Windows-WUSA N/A Contoso\User Windows update ‘Hotfix for Windows (KB2545850)’ could not be installed because of error 2149842953 ” (Command line: ”C:\Windows\system32\wusa.exe’ ‘D:\temp\Windows6.1-KB2545850-x64.msu’ ‘)

2/2/2016 2:02:08 PM Information server.contoso.com 1 Microsoft-Windows-Servicing N/A NT AUTHORITY\SYSTEM Initiating changes for package KB2545850. Current state is Staged. Target state is Installed. Client id: WindowsUpdateAgent.

In these situations, checking the CBS.log (located in c:\windows\logs\cbs) can be really helpful as it captures all the details regarding update installation failures.

If you look in the CBS log you will see the entries as follows:

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_57_for_KB2868725~31bf3856ad364e35~amd64~~6.1.1.1.2868725-165_neutral_LDR to re-evaluation(install) due to the change on Component Family: amd64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_26431bf35d52e5a2, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_33_for_KB2871997~31bf3856ad364e35~amd64~~6.1.2.5.Trigger_1 to re-evaluation(Always) due to the change on Component Family: amd64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_26431bf35d52e5a2, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_120_for_KB3121212~31bf3856ad364e35~amd64~~6.1.1.2.Trigger_1 to re-evaluation(Always) due to the change on Component Family: wow64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_3097c64591b3a79d, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

2016-02-02 10:29:19, Info                  CBS    WatchList: Add package Package_121_for_KB3121212~31bf3856ad364e35~amd64~~6.1.1.2.Trigger_1 to re-evaluation(Always) due to the change on Component Family: wow64_microsoft-windows-lsa_31bf3856ad364e35_0.0.0.0_none_3097c64591b3a79d, Version: 6.1.7601.21728, change: (Owner: Package_5_for_KB2545850~31bf3856ad364e35~amd64~~6.1.1.0.2545850-5_neutral_LDR, Flag: 5, Action: 3)

Why does this happen?

When you check the file version on the machine, it is currently using the GDR (General Distribution Release) branch and the date stamp is marked as 12/30/2015. (latest date)

When you check the file version in KB2545850, it is an LDR (Limited Distribution Release) branch hot-fix that has the date stamp of 03/14/2011 (older date).

When we try to update a binary that is using the GDR branch of the hot-fix with the LDR version of the hot-fix, we cannot compare the version numbers to see if the file needs to be updated.  At this point we have to compare the dates of the files.  In this situation, the date of the file in the hot-fix we are trying to install from KB2545850 is older than the binary that is already on the machine.  This triggers a re-evaluation during the applicability checks and takes more time.  When we have to compare the dates on a lot of binaries like the example above, it causes the process of installing to take longer.

This behavior can be expected in Windows Server 2008 R2.

We will have to wait for hours or days for the installation to complete.  So, how do we speed up the servicing mechanism?

The following workaround can help in speeding up the operation. The below steps may vary for each KB. These steps are proposed based on the behavior noticed in each scenario.

Workaround steps

• Cancel the update when it is stuck and reinitiate it right away and check. At times reevaluation might be cached which would complete the installation of the updates.
• Check if the update/hotfix is superseded by checking in the Microsoft Update Catalog site: http://catalog.update.microsoft.com . Since the superseded update will have all the binaries with latest date stamp, it is least likely to trigger re-evaluation.
• To speed up the installation we can also install the hotfix/update manually using DISM and check if that helps:

1. Download problematic update from Microsoft Download Center and place it to any folder i.e. C:\Temp
2. Run cmd.exe with elevated privileges (right click on cmd.exe and choose “run as administrator”)
3. Unpack the update by using an administrative command prompt and running the following commands:

• expand -f:*{update name}.msu {destination folder}
  • Example: To unpack update Windows6.1-kb2545850-v2.msu which is stored in C:\Temp folder the command will be following:
  • expand -f:* C:\TEMP\Windows6.1-kb254580-v2.msu  C:\TEMP
  • This should result in a .cab file in the C:\Temp directory

4. Now from the elevated command prompt, run the following command:

Dism.exe /Online /Add-Package /PackagePath:c:\temp\Windows6.1- kb2545850-v2.cab

More Information on Re-evaluation:

Re-evaluation of the applicability rules vary from machine after machine and this cannot be predicted as the applicability and installation phases are working properly.

Below are some of the Applicability Evaluation Scenarios.

1. Package being installed by CBS:
Updates could be installed, possibly triggering other updates to change state, or they could be staged, waiting for their applicability to be satisfied, or they could be absent with no presence on the system.

2. Package being uninstalled by CBS:
Components being removed can cause applicability rules targeting them to change state, triggering additional servicing operations. Child packages could be triggered to be removed when their applicable parent package is uninstalled.

3. Update being installed by CBS, or selectable feature selected on:
Other updates may be triggered for installation

4. Update being uninstalled by CBS, or selectable feature selected off:
Other updates may be triggered for uninstallation.

5. Normal component being upgraded (on existing branch):
Reevaluation based on the component version change may uninstall an older version.

6. New component being installed:
Other updates may be triggered for installation.

7. Branch-forcing component being installed:
Reevaluation based on component version change may trigger patches for elevated branch.

8. Normal component being removed:
Reevaluation based on component version removal may install an older version.

9. Branch forcing component being removed (determined by mapping back to update):
If another component forcing the same branch, reevaluation is based on current branch.
If branch is released, the new active branch needs to be determined, which then triggers reevaluation.

More Information on LDR and GDR:

How does Windows choose which version of a file to install?
https://blogs.technet.microsoft.com/joscon/2011/11/30/how-does-windows-choose-which-version-of-a-file-to-install

What is the difference between general distribution and limited distribution releases?
https://blogs.msdn.microsoft.com/windowsvistanow/2008/03/11/what-is-the-difference-between-general-distribution-and-limited-distribution-releases

QFE vs GDR/LDR hotfixes
https://blogs.technet.microsoft.com/instan/2009/03/04/qfe-vs-gdrldr-hotfixes

GDR, QFE, LDR… WTH?
http://blogs.technet.com/b/mrsnrub/archive/2009/05/14/gdr-qfe-ldr-wth.aspx

Branching Out
http://blogs.technet.com/b/mrsnrub/archive/2009/05/18/branching-out.aspx

Hope this information was helpful

Poornima Venkataraman
Support Engineer
Windows Core Team, Microsoft Enterprise Platforms

Suganya Natarajan
Technical Advisor
Windows Core Team, Microsoft Enterprise Platforms