Hello again everyone! David here to discuss a scenario that is becoming more and more popular for administrators of Distributed File System Namespaces (DFSN): consolidation of one or more standalone namespaces that are referenced by a domain-based namespace. Below I detail how this may be achieved.

History: Why create interlinked namespaces?

First, we should quickly review the history of why so many administrators designed interlinked namespaces.

In Windows Server 2003 (and earlier) versions of DFSN, domain-based namespaces were limited to hosting approximately 5,000 DFS folders per namespace. This limitation was simply due to how the Active Directory JET database engine stored a single binary value of an attribute. We now refer to this type of namespace as "Windows 2000 Server Mode". Standalone DFS namespaces (those stored locally in the registry of a single namespace server or server cluster) are capable of approximately 50,000 DFS folders per namespace. Administrators would therefore create thousands of folders in a standalone namespace and then interlink (cascade) it with a domain-based namespace. This allowed for a single, easily identifiable entry point of the domain-based namespace and leveraged the capacity of the standalone namespaces.

"Windows Server 2008 mode" namespaces allow for domain-based namespaces of many thousands of DFS folders per namespace (look here for scalability test results). With many Active Directory deployments currently capable of supporting 2008 mode namespaces, Administrators are wishing to remove their dependency on the standalone namespaces and roll them up into a single domain-based namespace. Doing so will improve referral performance, improve fault-tolerance of the namespace, and ease administration.

How to consolidate the namespaces

Below are the steps required to consolidate one or more standalone namespaces into an existing domain-based namespace. The foremost goal of this process is to maintain identical UNC paths after the consolidation so that no configuration changes are needed for clients, scripts, or anything else that references the current interlinked namespace paths. Because so many design variations exist, you may only require a subset of the operations or you may have to repeat some procedures multiple times. If you are not concerned with maintaining identical UNC paths, then this blog does not really apply to you.

For demonstration purposes, I will perform the consolidation steps on a namespace with the following configuration:

Domain-based Namespace: \\tailspintoys.com\data
DFS folder: "reporting" (targeting the standalone namespace "reporting" below)
Standalone Namespace: \\server1\reporting
DFS folders: "report####" (totaling 10,000 folders)

Below is what these namespaces look like in the DFS Management MMC.

Domain Namespace DATA:

Standalone Namespace "Reporting" hosted by server "FS1" and has 15,000 DFS folders:

For a client to access a file in the "report8000" folder in the current DFS design, the client must access the following path:
\\tailspintoys.com\data\reporting\report8000

Below are the individual elements of that UNC path with descriptions below each:                    

Note the overlap of the domain-based namespace folder "reporting" (dark green) with the standalone namespace "reporting" (light green). Each item in the UNC path is separated by a "\" and is known as a "path component".

In order to preserve the UNC path using a single domain-based namespace we must leverage the ability for DFSN to host multiple path components within a single DFS folder. Currently, the "reporting" DFS folder of the domain-based namespace refers clients to the standalone namespace that contains DFS folders, such as "reporting8000", beneath it. To consolidate those folders of the standalone root to the domain-based namespace, we must merge them together.

To illustrate this, below is how the new consolidated "Data" domain-based namespace will be structured for this path:

Notice how the name of the DFS folder is "Reporting\Reporting8000" and includes two path components separated by a "\". This capability of DFSN is what allows for the creation of any desired path. When users access the UNC path, they ultimately will still be referred to the target file server(s) containing the shared data. "Reporting" is simply a placeholder serving to maintain that original path component.

Step-by-step

Below are the steps and precautions for consolidating interlinked namespaces. It is highly recommended to put a temporary suspension on any administrative changes to the standalone namespace(s).

Assumptions:
The instructions assume that you have already met the requirements for "Windows Server 2008 mode" namespaces and your domain-based namespace is currently running in "Windows 2000 Server mode".

However, if you have not met these requirements and have a "Windows 2000 Server mode" domain-based namespace, these instructions (with modifications) may still be applied *if* after consolidation the domain-based namespace configuration data is less than 5 MB in size. If you are unsure of the size, you may run the "dfsutil /root:\\<servername>\<namespace_name> /view" command against the standalone namespace and note the size listed at the top (or bottom) of the output. The reported size will be added to the current size of the domain-based namespace and must not exceed 5 MB. Cease any further actions if you are unsure, or test the operations in a lab environment. Of course, if your standalone namespace size was less than 5 MB in size, then why did you create a interlinked namespace to begin with? Eh…I'm not really supposed to ask these questions. Moving on…

Step 1

Export the standalone namespace.

Dfsutil root export \\fs1\reporting c:\exports\reporting_namespace.txt

Step 2

Modify the standalone namespace export file using a text editor capable of search-and-replace operations. Notepad.exe has this capability. This export file will be leveraged later to create the proper folders within the domain-based namespace.

Replace the "Name" element of the standalone namespace with the name of the domain-based namespace and replace the "Target" element to be the UNC path of the domain-based namespace server (the one you will be configuring later in step 6). Below, I highlighted the single "\\FS1\reporting" 'name' element that will be replaced with "\\TAILSPINTOYS.COM\DATA". The single "\\FS1\reporting" element immediately below it will be replaced with "\\DC1\DATA" as "DC1" is my namespace server.


Next, prepend "Reporting\" to the folder names listed in the export. The final result will be as follows:

One trick is to utilize the 'replace' capability of Notepad.exe to search out and replace all instances of the '<Link Name="' string with '<Link Name="folder\' ('<Link Name="Reporting\' in this example). The picture below shows the original folders defined and the 'replace' dialog responsible for changing the names of the folders (click 'Replace all' to replace all occurrences).


Save the modified file with a new filename (reporting_namespace_modified.txt) so as to not overwrite the standalone namespace export file.

Step 3

Export the domain-based namespace
dfsutil root export \\tailspintoys.com\data c:\exports\data_namespace.txt

Step 4

Open the output file from Step 3 and delete the link that is being consolidated ("Reporting"):

Save the file as a separate file (data_namespace_modified.txt). This export will be utilized to recreate the *other* DFS folders within the "Windows Server 2008 Mode" domain-based namespace that do not require consolidation.

Step 5

This critical step involves deleting the existing domain-based namespace. This is required for the conversion from "Windows 2000 Server Mode" to "Windows Server 2008 Mode".

Delete the domain-based namespace ("DATA" in this example).

Step 6

Recreate the "DATA" namespace, specifying the mode as "Windows Server 2008 mode". Specify the namespace server to be a namespace server with close network proximity to the domain's PDC. This will significantly decrease the time it takes to import the DFS folders. Additional namespace servers may be added any time after Step 8.

Step 7

Import the modified export file created in Step 4:
dfsutil root import merge data_namespace_modified.txt \\tailspintoys.com\data

In this example, this creates the "Business" and "Finance" DFS folders:

Step 8

Import the modified namespace definition file created in Step 2 to create the required folders (note that this operation may take some time depending on network latencies and other factors):
dfsutil root import merge reporting_namespace_modified.txt \\tailspintoys.com\DATA

Step 9

Verify the structure of the namespace:

Step 10

Test the functionality of the namespace. From a client or another server, run the "dfsutil /pktflush" command to purge cached referral data and attempt access to the DFS namespace paths. Alternately, you may reboot clients and attempt access if they do not have dfsutil.exe available.

Below is the result of accessing the "report8000" folder path via the new namespace:


Referral cache confirms the new namespace structure (red line highlighting the name of the DFS folder as "reporting\report8000"):

At this point, you should have a fully working namespace. If something is not working quite right or there are problems accessing the data, you may return to the original namespace design by deleting all DFS folders in the new domain-based namespace and importing the original namespace from the export file (or recreating the original folders by hand). At no time did we alter the standalone namespaces, so returning to the original interlinked configuration is very easy to accomplish.

Step 11

Add the necessary namespace servers to the domain-based namespace to increase fault tolerance.

Notify all previous administrators of the standalone namespace(s) that they will need to manage the domain-based namespace from this point forward. Once you confident with the new namespace, the original standalone namespace(s) may be retired at any time (assuming no systems on the network are using UNC paths directly to the standalone namespace).

Namespace already in "Windows Server 2008 mode"?

What would the process be if the domain-based namespace is already running in "Windows Server 2008 mode"? Or, you have already run through the operations once and wish to consolidate additional DFS folders? Some steps remain the same while others are skipped entirely:
Steps 1-2 (same as detailed previously to export the standalone namespace and modify the export file)
Step 3 Export the domain-based namespace for backup purposes
Step 4 Delete the DFS folder targeting the standalone namespace--the remainder of the domain-based namespace will remain unchanged
Step 8 Import the modified file created in step 2 to the domain-based namespace
Step 9-10 Verify the structure and function of the namespace

Caveats and Concerns

Ensure that no data exists in the original standalone namespace server's namespace share. Because clients are now no longer using the standalone namespace, the "reporting" path component exists as a subfolder within each domain-based namespace server's share. Furthermore, hosting data within the namespace share (domain-based or standalone) is not recommended. If this applies to you, consider moving such data into a separate folder within the new namespace and update any references to those files used by clients.

These operations should be performed during a maintenance window. The length of which is dictated by your efficiency in performing the operations and the length of time it takes to import the DFS namespace export file. Because a namespace is so easily built, modified, and deleted, you may wish to consider a "dry run" of sorts. Prior to deleting your production namespace(s), create a new test namespace (e.g. "DataTEST"), modify your standalone namespace export file (Step 2) to reference this "DataTEST" namespace and try the import. Because you are using a separate namespace, no changes will occur to any other production namespaces. You may gauge the time required for the import, and more importantly, test access to the data (\\tailspintoys.com\DataTEST\Reporting\Reporting8000 in my example). If access to the data is successful, then you will have confidence in replacing the real domain-based namespace.

Clients should not be negatively affected by the restructuring as they will discover the new hierarchy automatically. By default, clients cache namespace referrals for 5 minutes and folder referrals for 30 minutes. It is advisable to keep the standalone namespace(s) operational for at least an hour or so to accommodate transition to the new namespace, but it may remain in place for as long as you wish.

If you decommission the standalone namespace and find some clients are still using it directly, you could easily recreate the standalone namespace from our export in Step 1 while you investigate the client configurations and remove their dependency on it.

Lastly, if you are taking the time and effort to recreate the namespace for "Windows Server 2008 mode" support, you might as well consider configuring the targets of the DFS folders with DNS names (modify the export files) and also implementing DFSDnsConfig on the namespace servers.

I hope this blog eliminates some of the concerns and fears of consolidating interlinked namespaces!

Dave "King" Fisher

Hello again!  Kim Nichols here again.  For this post, I'm taking a break from the AD LDS discussions (hold your applause until the end) and going back to a topic near and dear to my heart - Group Policy loopback processing.

Loopback processing is not a new concept to Group Policy, but it still causes confusion for even the most experienced Group Policy administrators.

This post is the first part of a two part blog series on User Group Policy Loopback processing.

• Part 1 provides a general Group Policy refresher and introduces Loopback processing
• Part 2 covers Troubleshooting Group Policy loopback processing

Hopefully these posts will refresh your memory and provide some tips for troubleshooting Group Policy processing when loopback is involved.

Part 1: Group Policy and Loopback processing refresher

Normal Group Policy Processing

Before we dig in too deeply, let's quickly cover normal Group Policy processing.  Thinking back to when we first learned about Group Policy processing, we learned that Group Policy
applies in the following order: 

1. Local Group Policy
2. Site
3. Domain
4. OU

You may have heard Active Directory “old timers” refer to this as LSDOU.  As a result of LSDOU, settings from GPOs linked closest (lower in OU structure) to the user take precedence over those linked farther from the user (higher in OU structure). GPO configuration options such as Block Inheritance and Enforced (previously called No Override for you old school admins) can modify processing as well, but we will keep things simple for the purposes of this example.  Normal user group policy processing applies user settings from GPOs linked to the Site, Domain, and OU containing the user object regardless of the location of the computer object in Active Directory.

Let's use a picture to clarify this.  For this example, the user is the "E" OU and the computer is in the "G" OU of the contoso.com domain.

Following normal group policy processing rules (assuming all policies apply to Authenticated Users with no WMI filters or "Block Inheritance" or "Enforced" policies), user settings of Group Policy objects apply in the following order:

1. Local Computer Group Policy
2. Group Policies linked to the Site
3. Group Policies linked to the Domain (contoso.com)
4. Group Policies linked to OU "A"
5. Group Policies linked to OU "B"
6. Group Policies linked to OU "E"

That’s pretty straightforward, right?  Now, let’s move on to loopback processing!

What is loopback processing?

Group Policy loopback is a computer configuration setting that enables different Group Policy user settings to apply based upon the computer from which logon occurs. 

Breaking this down a little more:

1. It is a computer configuration setting. (Remember this for later)
2. When enabled, user settings from GPOs applied to the computer apply to the logged on user.
3. Loopback processing changes the list of applicable GPOs and the order in which they apply to a user. 

Why would I use loopback processing?

Administrators use loopback processing in kiosk, lab, and Terminal Server environments to provide a consistent user experience across all computers regardless of the GPOs linked to user's OU. 

Our recommendation for loopback is similar to our recommendations for WMI filters, Block Inheritance and policy Enforcement; use them sparingly.  All of these configuration options modify the default processing of policy and thus make your environment more complex to troubleshoot and maintain. As I've mentioned in other posts, whenever possible, keep your designs as simple as possible. You will save yourself countless nights/weekends/holidays in the office because will you be able to identify configuration issues more quickly and easily.

How to configure loopback processing

The loopback setting is located under Computer Configuration/Administrative Templates/System/Group Policy in the Group Policy Management Editor (GPME). 

Use the policy setting Configure user Group Policy loopback processing mode to configure loopback in Windows 8 and Windows Server 2012.  Earlier versions of Windows have the same policy setting under the name User Group Policy loopback processing mode.  The screenshot below is from the Windows 8 version of the GPME.

When you enable loopback processing, you also have to select the desired mode.  There are two modes for loopback processing:  Merge or Replace.

Loopback Merge vs. Replace

Prior to the start of user policy processing, the Group Policy engine checks to see if loopback is enabled and, if so, in which mode.

We'll start off with an explanation of Merge mode since it builds on our existing knowledge of user policy processing.

Loopback Merge

During loopback processing in merge mode, user GPOs process first (exactly as they do during normal policy processing), but with an additional step.  Following normal user policy processing the Group Policy engine applies user settings from GPOs linked to the computer's OU.  The result-- the user receives all user settings from GPOs applied to the user and all user settings from GPOs applied to the computer. The user settings from the computer’s GPOs win any conflicts since they apply last.

To illustrate loopback merge processing and conflict resolution, let’s use a simple chart.  The chart shows us the “winning” configuration in each of three scenarios:

• The same user policy setting is configured in GPOs linked to the user and the computer
• The user policy setting is only configured in a GPO linked to the user’s OU
• The user policy setting is only configured in a GPO linked to the computer’s OU

Now, going back to our original example, loopback processing in Merge mode applies user settings from GPOs linked to the user’s OU followed by user settings from GPOs linked to the computer’s OU.

GPOs for the user in OU ”E” apply in the following order (the first part is identical to normal user policy processing from our original example):

1. Local Group Policy
2. Group Policy objects linked to the Site
3. Group Policy objects linked to the Domain
4. Group Policy objects linked to OU "A"
5. Group Policy objects linked to OU "B"
6. Group Policy objects linked to OU "E"
7. Group Policy objects linked to the Site
8. Group Policy objects linked to the Domain
9. Group Policy objects linked to OU "A"
10. Group Policy objects linked to OU "C"
11. Group Policy objects linked to OU "G"

Loopback Replace

Loopback replace is much easier. During loopback processing in replace mode, the user settings applied to the computer “replace” those applied to the user.  In actuality, the Group Policy service skips the GPOs linked to the user’s OU. Group Policy effectively processes as if user object was in the OU of the computer rather than its current OU. 

The chart for loopback processing in replace mode shows that settings “1” and “2” do not apply since all user settings linked to the user’s OU are skipped when loopback is configured in replace mode.

Returning to our example of the user in the “E” OU, loopback processing in replace mode skips normal user policy processing and only applies user settings from GPOs linked to the computer.

The resulting processing order is: 

1. Local Group Policy
2. Group Policy objects linked to the Site
3. Group Policy objects linked to the Domain
4. Group Policy objects linked to OU "A"
5. Group Policy objects linked to OU "C"
6. Group Policy objects linked to OU "G"

Recap

1. User Group Policy loopback processing is a computer configuration setting.

• Loopback processing is not specific to the GPO in which it is configured. If we think back to what an Administrative Template policy is, we know it is just configuring a registry value.  In the case of the loopback policy processing setting, once this registry setting is configured, the order and scope of user group policy processing for all users logging on to the computer is modified per the mode chosen: Merge or Replace.

• The order of processing determines the precedence. GPOs with users settings linked to the computer object apply last and therefore have a higher precedence than those linked to the user object.
• Use merge mode in scenarios where you need users to receive the settings they normally receive, but you want to customize or make changes to those settings when they logon to specific computers.

Those are the basics of user group policy loopback processing. In my next post, I'll cover the troubleshooting process when loopback is enabled.

Kim “Why does it say paper jam, when there is no paper jam!?” Nichols

Hello, Joji Oshima here to dive deeper into the Claims Rule Language for AD FS. A while back I wrote a getting started post on the claims rule language in AD FS 2.0. If you haven't seen it, I would start with that article first as I'm going to build on the claims rule language syntax discussed in that earlier post. In this post, I'm going to cover more complex claim rules using Regular Expressions (RegEx) and how to use them to solve real world issues.

An Introduction to Regex

The use of RegEx allows us to search or manipulate data in many ways in order to get a desired result. Without RegEx, when we do comparisons or replacements we must look for an exact match. Most of the time this is sufficient but what if you need to search or replace based on a pattern? Say you want to search for strings that simply start with a particular word. RegEx uses pattern matching to look at a string with more precision. We can use this to control which claims are passed through, and even manipulate the data inside the claims.

Using RegEx in searches

Using RegEx to pattern match is accomplished by changing the standard double equals "==" to "=~" and by using special metacharacters in the condition statement. I'll outline the more commonly used ones, but there are good resources available online that go into more detail. For those of you unfamiliar with RegEx, let's first look at some common RegEx metacharacters used to build pattern templates and what the result would be when using them.

Using RegEx in string manipulation

RegEx pattern matching can also be used in replacement scenarios. It is similar to a "find and replace", but using pattern matching instead of exact values. To use this in a claim rule, we use the RegExReplace() function in the value section of the issuance statement.

The RegExReplace() function accepts three parameters.

1. The first is the string in which we are searching.
   1. We will typically want to search the value of the incoming claim (c.Value), but this could be a combination of values (c1.Value + c2.Value).
2. The second is the RegEx pattern we are searching for in the first parameter.
3. The third is the string value that will replace any matches found.

Example:

Real World Examples

Let's look at some real world examples of regular expressions in claims rules.

Problem 1:

We want to add claims for all group memberships, including distribution groups.

Solution:

Typically, group membership is added using the wizard and selecting Token-Groups Unqualified Names and map it to the Group or Role claim. This will only pull security groups, not distribution groups, and will not contain Domain Local groups.

We can pull from memberOf, but that will give us the entire distinguished name, which is not what we want. One way to solve this problem is to use three separate claim rules and use RegExReplace() to remove unwanted data.

Problem 2:

We need to compare the values in two different claims and only allow access to the relying party if they match.

Solution:

In this case we can use RegExReplace(). This is not the typical use of this function, but it works in this scenario. The function will attempt to match the pattern in the first data set with the second data set. If they match, it will issue a new claim with the value of "Yes". This new claim can then be used to grant access to the relying party. That way, if these values do not match, the user will not have this claim with the value of "Yes".

Problem 3:

Let's take a second look at potential issue with our solution to problem 2. Since we are using the value of one of the claims as the RegEx syntax, we must be careful to check for certain RegEx metacharacters that would make the comparison mean something different. The backslash is used in some RegEx metacharacters so any backslashes in the values will throw off the comparison and it will always fail, even if the values match.

Solution:

In order to ensure that our matching claim rule works, we must sanitize the input values by removing any backslashes before doing the comparison. We can do this by taking the data that would go into the initial claims, put it in a holding attribute, and then use RegEx to strip out the backslash. The example below only shows the sanitization of data1, but it would be similar for data2.

Problem 4:

Employee numbers vary in length, but we need to have exactly 9 characters in the claim value. Employee numbers that are shorter than 9 characters should be padded in the front with leading zeros.

Solution:

In this case we can create a buffer claim, join that with the employee number claim, and then use RegEx to use the right most 9 characters of the combined string.

Problem 5:

Employee numbers contain leading zeros but we need to remove those before sending them to the relying party.

Solution:

In this case we can pull employee number from Active Directory and place it in a holding claim, then use RegEx to use the strip out any leading zeros.

Conclusion

As you can see, RegEx adds powerful functionality to the claims rule language. It has a high initial learning curve, but once you master it you will find that there are few scenarios that RegEx can't solve. I would highly recommend searching for an online RegEx syntax tester as it will make learning and testing much easier. I'll continue to expand the TechNet wiki article so I would check there for more details on the claims rule language.

Understanding Claim Rule Language in AD FS 2.0

AD FS 2.0: Using RegEx in the Claims Rule Language

Regular Expression Syntax

AD FS 2.0 Claims Rule Language Primer

Until next time,

Joji "Claim Jumper" Oshima

Hey all, David here.  Now that we’ve broken the silence, we here on the DS team felt that we owed you, dear readers, an explanation of some sort.  Plus, we wanted to talk about the blog itself, some changes happening for us, and what you should hopefully be able to expect moving forward.

So, what had happened was….

As most of you know, a few months ago our editor-in-chief and the butt of many jokes here on the DS support team moved to a new position.  We have it on good authority that he is thoroughly terrorizing many of our developers in Redmond with scary words like “documentation”, “supportability”, and other Chicago-style aphorisms which are best not repeated in print.

Unfortunately for us and for this blog, that left us with a little bit of a hole in the editing team!  The folks left behind might have been superheroes, but the problem with being a superhero is that you get called on to go save the world (or a customer with a crisis) all the time, and that doesn’t leave much time for picking up your cape from the dry cleaners, let alone keeping up with editing blog submissions, doing mail sacks, and generally keeping the blog going.

At the same time, we had a bit of a reorganization internally.  Where we were formerly one team within support, we are now two teams – DS (Directory Services) and ID (Identity).  Why the distinction?  Well, you may have heard about this Cloud thing…. But that’s a story best told by technical blog posts, really.  For now, let’s just say the scope of some of what we do expanded last year from “a lot of people use it” to “internet scale”.  Pretty scary when you think about it.

Just to make things even more confusing, about a month ago we were officially reunited with our long-lost (and slightly insane, but in a good way) brethren in the field engineering organization.  That’s right, our two orgs have been glommed[1] together into one giant concentration of support engineering superpower.  While it’s opening up some really cool stuff that we have always wanted to do but couldn’t before, it’s still the equivalent of waking up one day and finding out that all of those cousins you see every few years at family reunions are coming to live with you.  In your house.  Oh, and they’re bringing their dog.

Either way, the net effect of all this massive change was that we sort of got quiet for a few months.  It wasn’t you, honest.  It was us.

What to Expect

It’s important to us that we keep this blog current with detailed, pertinent technical info that helps you resolve issues that you might encounter, or even just helps you understand how our parts of Windows work a bit better.  So, we’re picking that torch back up and we’ll be trying to get several good technical posts up each month for you.  You may also see some shorter posts moving forward.  The idea is to break up the giant articles and try to get some smaller, useful-to-know things out there every so often.  Internally, we’re calling the little posts “DS Quickies” but no promises on whether we’ll actually give you that as a category to search on.  Yes, we’re cruel like that.  You’ll also see the return of the mail sack at some point in the near future, and most importantly you’re going to see some new names showing up as writers.  We’ve put out the call, and we’re planning to bring you blog posts written not just by our folks in the Americas, but also in Europe and Asia.  You can probably also expect some guest posts from our kin in the PFE organization, when they have something specific to what we do that they want to talk about.

At the same time, we’re keen on keeping the stuff that makes our blog useful and fun.  So you can continue to expect technical depth, detailed analysis, plain-English explanations, and occasional irreverent, snarky humor.  We’re not here to tell you why you should buy Windows clients or servers (or phones, or tablets) – we have plenty of marketing websites that do that better than we ever could.  Instead, we’re here to help you understand how Windows works and how to fix problems when they occur.  Although we do reserve the right to post blatant wackiness or fun things every so often too.  Look, we don’t get out much, ok?  This is our outlet.  Just go with us on this.

Finally, you’re going to see me personally posting a bit more, since I’ve taken over as the primary editor for the site.  I know - I tried to warn them what would happen, but they still gave me the job all the same.  Jokes aside, I feel like it’s important that our blog isn’t just an encyclopedia of awesome technical troubleshooting, but also that it showcases the fact that we’re real people doing our best to make the IT world a better place, as sappy as that sounds. (Except for David Fisher– I’m convinced he’s really a robot).  I have a different writing style than Ned and Jonathan, and a different sense of humor, but I promise to contain myself as much as possible.  :-)

Sound good?  We hope so.  We’re going to go off and write some more technical stuff now – in fact:  On deck for next week:  A followup to Kim’s blog on Loopback Policy Processing.

We wanted to leave you with a funny video that’s safe for work to help kick off the weekend, but alas our bing fu was weak today.  Got a good one to share?  Feel free to link it for us in the comments!

Welcome back!  Kim Nichols here once again with the much anticipated Part 2 to Circle Back to Loopback.  Thanks for all the comments and feedback on Part 1.  For those of you joining us a little late in the game, you'll want to check out Part 1: Circle Back to Loopback before reading further.

In my first post, the goal was to keep it simple.  Now, we're going to go into a little more detail to help you identify and troubleshoot Group Policy issues related to loopback processing.  If you follow these steps, you should be able to apply what you've learned to any loopback scenario that you may run into (assuming that the environment is healthy and there are no other policy infrastructure issues).

To troubleshoot loopback processing you need to know and understand:

1. The status of the loopback configuration.  Is it enabled, and if so, in which mode?
2. The desired state configuration vs. the actual state configuration of applied policy
3. Which settings from which GPOs are "supposed" to be applied?
4. To whom should the settings apply or not apply?
1. The security filtering requirements when using loopback
2. Is the loopback setting configured in the same GPO or a separate GPO from the user settings?
3. Are the user settings configured in a GPO with computer settings?

What you need to know:

Know if loopback is enabled and in which mode

The first step in troubleshooting loopback is to know that it is enabled.  It seems pretty obvious, I know, but often loopback is enabled by one administrator in one GPO without understanding that the setting will impact all computers that apply the GPO.  This gets back to Part 1 of this blog . . . loopback processing is a computer configuration setting. 

Take a deep cleansing breath and say it again . . . Loopback processing is a computer configuration setting.  :-)

Everyone feels better now, right?  The loopback setting configures a registry value on the computer to which it applies.  The Group Policy engine reads this value and changes how it builds the list of applicable user policies based on the selected loopback mode.

The easiest way to know if loopback might be causing troubles with your policy processing is to collect a GPResult /h from the computer.  Since loopback is a computer configuration setting, you will need to run GPResult from an administrative command prompt.

The good news is that the GPResult output will show you the winning GPO with loopback enabled.  Unfortunately, it does not list all GPOs with loopback configured, just the one with the highest precedence. 

If your OU structure separates users from computers, the GPResult output can also help you find GPOs containing user settings that are linked to computer OUs.  Look for GPOs linked to computer OUs under the Applied GPOs section of the User Details of the GPResult output. 

Below is an example of the output of the GPResult /h command from a Windows Server 2012 member server.  The layout of the report has changed slightly going from Windows Server 2008 to Windows Server 2012, so your results may look different, but the same information is provided by previous versions of the tool.  Notice that the link location includes the Computers OU, but we are in the User Details section of the report.  This is a good indication that we have loopback enabled in a GPO linked in the path of the computer account. 

   
Understand the desired state vs. the actual state

This one also sounds obvious, but in order to troubleshoot you have to know and understand exactly which settings you are expecting to apply to the user.  This is harder than it sounds.  In a lab environment where you control everything, it's pretty easy to keep track of desired configuration.  However, in a production environment with potentially multiple delegated GPO admins, this is much more difficult. 

GPResult gives us the actual state, but if you don't know the desired state at the setting level, then you can't reasonably determine if loopback is configured correctly (meaning you have WMI filters and/or security filtering set properly to achieve your desired configuration). 

     
Review security filtering on GPOs

Once you determine which GPOs or which settings are not applying as expected, then you have a place to start your investigation. 

In our experience here in support, loopback processing issues usually come down to incorrect security filtering, so rule that out first.

This is where things get tricky . . . If you are configuring custom security filtering on your GPOs, loopback can get confusing quickly.  As a general rule, you should try to keep your WMI and security filtering as simple as possible - but ESPECIALLY when loopback is involved.  You may want to consider temporarily unlinking any WMI filters for troubleshooting purposes.  The goal is to ensure the policies you are expecting to apply are actually applying.  Once you determine this, then you can add your WMI filters back into the equation.  A test environment is the best place to do this type of investigation.

Setting up security filtering correctly depends on how you architect your policies:

1. Did you enable loopback in its own GPO or in a GPO with other computer or user settings?
2. Are you combining user settings and computer settings into the same GPO(s) linked to the computer’sOU?

The thing to keep in mind is that if you have what I would call "mixed use" GPOs, then your security filtering has to accommodate all of those uses.  This is only a problem if you remove Authenticated Users from the security filter on the GPO containing the user settings.  If you remove Authenticated Users from the security filter, then you have to think through which settings you are configuring, in which GPOs, to be applied to which computers and users, in which loopback mode....

Ouch.  That's LOTS of thinking!

So, unless that sounds like loads of fun to you, it’s best to keep WMI and security filtering as simple as possible.  I know that you can’t always leave Authenticated Users in place, but try to think of alternative solutions before removing it when loopback is involved. 

Now to the part that everyone always asks about once they realize their current filter is wrong – How the heck should I configure the security filter?!

Security filtering requirements:

1. The computer account must have READandAPPLY permissions to the GPO that contains the loopback configuration setting.
2. If you are configuring user settings in the same GPO as computer settings, then the user and computer accounts will both need READandAPPLY permissions to the GPO since there are portions of the GPO that are applicable to both.
3. If the user settings are in a separate GPO from the loopback configuration setting (#1 above) and any other computer settings (#2 above), then the GPO containing the user settings requires the following permissions:  

Merge mode requirements (Vista+):

Replace mode requirements:

Tools for Troubleshooting

The number one tool for troubleshooting loopback processing is your GPRESULT output and a solid understanding of the security filtering requirements for loopback processing in your GPO architecture (see above).

The GPRESULT will tell you which GPOs applied to the user.  If a specific GPO failed to apply, then you need to review the security filtering on that GPO and verify:

• The user has READ and APPLYpermissions
• Depending on your GPO architecture, the computer may need READor it may need READ and APPLY if you combined computer and user settings in the same GPO.

The same strategy applies if you have mysterious policy settings applying after configuring loopback and you are not sure know why.  Use your GPRESULT output to identify which GPO(s) the policy settings are coming from and then review the security filtering of those GPOs. 

The Group Policy Operational logs from the computer will also tell you which GPOs were discovered and applied, but this is the same information that you will get
from the GPRESULT.

Recommendations for using loopback

After working my fair share of loopback-related cases, I've collected a list of recommendations for using loopback.  This isn’t an official list of "best practices", but rather just some personal recommendations that may make your life easier.  ENJOY!

I'll start with what is fast becoming my mantra: Keep it Simple.  Pretty much all of my recommendations can come back to this point.

1. Don't use loopback  :-) 

OK, I know, not realistic.  How about this . . . Don't use loopback unless you absolutely have to. 

• I say this not because there is something evil about loopback, but rather because loopback complicates how you think about Group Policy processing.  Loopback tends to be configured and then forgotten about until you start seeing unexpected results. 

2. Use a separate GPO for the loopback setting; ONLY include the loopback setting in this GPO, and do not include the user settings.  Name it Loopback-Merge or Loopback-Replace depending on the mode.

• This makes loopback very easy to identify in both the GPMC and in your GPRESULT output.  In the GPMC, you will be able to see where the GPO is linked and the mode without needing to view the settings or details of any GPOS.  Your GPRESULT output will clearly list the loopback policy in the list of applied policies and you will also know the loopback mode, without digging into the report. Using a separate policy also allows you to manage the security of the loopback GPO separately from the security on the GPOs containing the user settings.

3. Avoid custom security filtering if you can help it. 

• Loopback works without a hitch if you leave Authenticated Users in the security filtering of the GPO.  Removing Authenticated Users results in a lot more work for you in the long run and makes troubleshooting undesired behaviors much more complicated.

4. Don't enable loopback in a GPO linked at the domain level!

• This will impact your Domain Controllers.  I wouldn't be including this warning, if I hadn't worked several cases where loopback had been inadvertently applied to Domain Controllers.  Again, there isn’t anything inherently wrong with applying loopback on Domain Controllers.  It is bad, however, when loopback unexpectedly applies to Domain Controllers.
• If you absolutely MUST enable loopback in a GPO linked at the domain level, then block inheritance on your Domain Controllers OU.  If you do this, you will need to link the Default Domain Policy back to the Domain Controllers OU making sure to have the precedence of the Default Domain Controllers policy higher (lower number) than the Domain Policy.
• In general, be careful with all policies linked at the at the domain level.  Yes, it may be "simpler" to manage most policy at the domain level, but it can lead
  to lazy administration practices and make it very easy to forget about the impact of seemingly minor policy changes on your DCs.
• Even if you are editing the security filtering to specific computers, it is still dangerous to have the loopback setting in a GPO linked at the domain level.  What if someone mistakenly modifies the security filtering to "fix" some other issue.
• TEST, TEST, TEST!!!  It’s even more important to test when you are modifying GPOs that impact domain controllers.  Making a change at the domain level that negatively impacts a domain controller can be career altering.  Even if you have to set up a test domain in virtual machines on your own workstation, find a way to test.

5. Always test in a representative environment prior to deploying loopback in production.

• Try to duplicate your production GPOs as closely as possible.  Export/Import is a great way to do this.
• Enabling loopback almost always surfaces some settings that you weren't aware of.  Unless you are diligent about disabling unused portions of GPOs and you perform periodic audits of actual configuration versus documented desired state configuration, there will typically be a few settings that are outside of your desired configuration. 
• Duplicating your production policies in a test environment means you will find these anomalies before you make the changes in production.

That’s all folks!  You are now ready to go forth and conquer all of those loopback policies!

Kim “1.21 Gigawatts!!” Nichols

Editor's note:  This is the first of very likely many "DS Quickies".  "Quickies" are shorter technical blog posts that relate hopefully-useful information and concepts for you to use in administering your networks.  We thought about doing these on Twitter or something, but sadly we're still too technical to be bound by a 140-character limit :-)

For those of you who really look forward to the larger articles to help explain different facets of Windows, Active Directory, or troubleshooting, don't worry - there will still be plenty of those too. 

Hi! This is Gonzalo writing to you from the support team for Latin America.

Recently we got a call from a customer, where one of the administrators accidentally executed a script that was intended to delete local users… on a domain controller. The result was that all domain users were deleted from the environment in just a couple of seconds. The good thing was that this customer had previously enabled Recycle Bin, but it still took a couple of hours to recover all users as this was a very large environment. This type of issue is something that comes up all the time, and it’s always painful for the customers who run into it. I have worked many cases where the lack of proper protection to objects caused a lot of issues for customer environments and even in some cases ended up costing administrators their jobs, all because of an accidental click. But, how can we avoid this?

If you take a look at the properties of any object in Active Directory, you will notice a checkbox named “Protect object from accidental deletion” under Object tab. When this enabled, permissions are set to deny
deletion of this object to Everyone.

With the exception of Organizational Units, this setting is not enabled by default on all objects in Active Directory.  When creating an object, it needs to be set manually. The challenge is how to easily enable this on thousands of objects.

ANSWER!  Powershell!

Two simple PowerShell commands will enable you to set accidental deletion protection on all objects in your Active Directory. The first command will set this on any users or computers (or any object with value user on the ObjectClass attribute). The second command will set this on any Organizational Unit where the setting is not already enabled.

Get-ADObject -filter {(ObjectClass -eq "user")} | Set-ADObject -ProtectedFromAccidentalDeletion:$true

Get-ADOrganizationalUnit -filter * | Set-ADObject -ProtectedFromAccidentalDeletion:$true

Once you run these commands, your environment will be protected against accidental (or intentional) deletion of objects.

Note: As a proof of concept, I tested the script that my customer used with the accidental deletion protection enabled and none of the objects in my Active Directory environment were deleted.

Gonzalo “keep your job” Reyna

Just in case you missed the announcement, the preview build of Windows Server 2012 R2 is now available for download.  If you want to see the latest and greatest, head on over there and take a gander at the new features.  All of us here in support have skin in this game, but Directory Services (us) has several new features that we'll be talking about over the coming months.  Including a lot of this stuff named in the announcement:

"Empowering employee productivity– Windows Server Work Folders, Web App Proxy, improvements to Active Directory Federation Services and other technologies will help companies give their employees consistent access to company resources on the device of their choice."

Obviously this is still a beta release.  Things can change before RTM.  Don't go doing anything silly like deploying this in production - it's officially unsupported at this stage, and for testing purposes only.  But with all that in mind, give it a whirl, and hit the TechNet forums to provide feedback and ask questions.  You will also want to keep an eye on some of our server and tools blogs in the near future.  For your convenience, a bunch of those are linked in the bar up top for you.

Happy previewing!

--David "Town Crier" Beach

Hello folks, this is Herbert from the Directory Services support team in Europe!

Kerberos is becoming increasingly mandatory for really cool features such as Protocol Transition.  Moreover, as you might be painfully aware, managing Service Principal Names (SPN’s) for the use of Kerberos by applications can be daunting at times.

In this blog, we will not be going into the gory details of SPNs and how applications are using them. In fact, I’m assuming you already have some basic knowledge about SPN’s and how they are used.

Instead, we’re going to talk about an interesting behavior that can occur when an administrator is doing their due diligence managing SPN’s.  This behavior can arise when you are checking the status of the account the SPN is planned for, or when you are checking to see if the SPN that must be registered is already registered in the domain or forest.

As we all know, the KDC’s cannot issue tickets for a particular service if there are duplicate SPN’s, and authentication does not work if the SPN is on the wrong account.

Experienced administrators learn to use the SETSPN utility to validate SPNs when authentication problems occur.  In the Windows Server 2008 version of SETSPN, we provide several options useful to identifying duplicate SPNs:

-      If you want to look for a duplicate of a particular SPN: SETSPN /q <SPN>

-      If you want to search for any duplicate in the domain: SETSPN /x

You can also use the “/f” option to extend the duplicate search to the whole Forest. Many Active Directory Admins use this as a proactive check of the forest for duplicate SPNs.

So far, so good…

The Problem

Sometimes, you’ll get an error running SETSPN -x -f:

c:\>SETSPN -X -F -P
Checking forest DC=contoso,DC=com
Operation will be performed forestwide, it might take a while.
Ldap Error(0x55 -- Timeout): ldap_get_next_page_s

“-P” just tells the tool not to clutter the output with progress indications, but you can see from that error message that we are not talking only about Kerberos anymore. There is a new problem.

What are we seeing in the diagnostic data?

In a network trace of the above you will see a query against the GC (port 3268) with no base DN and the filter “(servicePrincipalName=*)”. SETSPN uses paged queries with a page size of 100 objects. In a large Active Directory environment this yields quite a number of pages.

If you look closely at network capture data, you’ll often find that Domain Controller response times slowly increase towards the end of the query. If the command completes, you’ll sometimes see that the delay is longest on the last page returned. For example, when we reviewed data for a recent customer case, we noted:

”Customer also noticed that it usually hangs on record 84.”

Troubleshooting LDAP performance and building custom queries calls for the use of the STATS Control. Here is how you use it in LDP.exe:

Once connected to port 3268 and logged on as an admin, you can build the query in the same manner as SETSPN does.

1. Launch LDP as an administrator.

2. Open the Search Window using Browse\Search or Ctrl-S.

3. Enter the empty base DN and the filter, specify “Subtree” as the scope. The list of attributes does not matter here. 

4. Go to Options:

5. Specify an “Extended” query as we want to use controls. Note I have specified a page size of 100 elements, but that is not important, as we will see later. Let’s move on to “Controls”:

5. From the List of Controls select “Search Stats“. When you select it, it automatically checks it in.

6. Now “OK” your way out of the “Controls” and “Options” dialogs.

7. Hit “Run” on the “Search” dialog.

You should get a large list of results, but also the STATS a bit like this one:

Call Time: 62198 (ms)

Entries Returned: 8508

Entries Visited: 43076

Used Filter: (servicePrincipalName=*)

Used Indices: idx_servicePrincipalName:13561:N

Pages Referenced          : 801521

Pages Read From Disk      : 259

Pages Pre-read From Disk  : 1578

Pages Dirtied             : 0

Pages Re-Dirtied          : 0

Log Records Generated     : 0

Log Record Bytes Generated: 0

What are these stats telling us?

We have a total of 8508 objects in the “Entries Returned” result set, but we have visited 43076 objects. That sounds odd, because we used an Index “idx_servicePrincipalName”. This does not really look as if the query is using the index.

So what is happening here?

At this point, we experience the special behavior of multi-valued non-linked attributes and how they are represented in the index. To illustrate this, let me explain a few data points:

1. A typical workstation or member server has these SPNs:

servicePrincipalName:
WSMAN/herbertm5

servicePrincipalName:
WSMAN/herbertm5.europe.contoso.com

servicePrincipalName:
TERMSRV/herbertm5.europe.contoso.com

servicePrincipalName:
TERMSRV/HERBERTM5

servicePrincipalName:
RestrictedKrbHost/HERBERTM5

servicePrincipalName:
HOST/HERBERTM5

servicePrincipalName:
RestrictedKrbHost/HERBERTM5.europe.contoso.com

servicePrincipalName:
HOST/HERBERTM5.europe.contoso.com

2. When you look at the result set from running setspn, you notice that you’re not getting all of the SPNs you’d expect:

dn:CN=HQSCCM2K3TEST,OU=SCCM,OU=Test Infrastructure,OU=Domain Management,DC=contoso,DC=com

servicePrincipalName: WSMAN/sccm2k3test

servicePrincipalName: WSMAN/sccm2k3test.contoso.com

If you look at it closely, you notice all the SPN’s start with characters very much at the end of the alphabet, which also happens to be the end of the index. These entries do not have a prefix like “HOST”.

So how does this happen?

In the resultant set of LDAP queries, an object may only appear once, but it is possible for an object to be in the index multiple times, because of the way the index is built. Each time the object is found in the index, the LDAP Server has to check the other values of the indexed attribute of the object to see whether it also matches the filter and thus was already added to the result set.  The LDAP server is doing its diligence to avoid returning duplicates.

For example, the first hit in the index for the above workstation example is “HOST/HERBERTM5“.

The second hit“HOST/HERBERTM5.europe.contoso.com“ kicks off the algorithm.

The object is read already and the IO and CPU hit has happened.

Now the query keeps walking the index, and once it arrives at the prefix “WSMAN”, the rate of objects it needs to skip approaches 100%. Therefore, it looks at many objects and little additional objects in the result set.

On the last page of the query, things get even worse. There is an almost 100% rate of duplicates, so the clock of 60 seconds SETSPN allows for the query is ticking, and there are only 8 objects to be found. If the Domain Controller has a slow CPU or the objects need to be read from the disk because of memory pressure, the SETSPN query will probably not finish within a minute for a large forest.  This results in the error Ldap Error(0x55 -- Timeout): ldap_get_next_page_s.  The larger the index (meaning, the more computers and users you have in your forest), the greater the likelihood that this can occur.

If you run the query with LDIFDE, LDP or ADFIND you will have a better chance the query will be successful. This is because by default these tools do not specify a time-out and thus use the values of the Domain Controller LDAP Policy. The Domain Controller LDAP policy is 120 seconds (by default) instead of 60 seconds.

The problem with the results generated by these tools is that you have to correlate the results from the different outputs yourself – the tools won’t do it for you.

So what can you do about it?

Typically you’ll have to do further troubleshooting, but here are some common causes/resolutions that I’ve seen:

1. If a domain controller is short on memory and encounters many cache misses and thus substantial IO. You can diagnose this using the NTDS performance counters in Performance Monitor.  You can add memory to reduce the IO rate and speed things up.
2. If you are not experiencing memory pressure, the limiting factor could be the “Single-Thread-Performance” of the server. This is important as every LDAP query gets a worker thread and runs no faster than one logical CPU core can manage.  If you have a low number of logical cores in a system with a high amount of CPU activity, this can cause the threads to delay long enough for us to see an  nconsistent query return.  In this situation your best bet is to look for ways to reduce overall processor load on the domain controller – for example, moving other services off of the machine.
3. There is an update for Windows Server 2012 which helps to avoid the problem:

2799960          Time-out error when you run SETSPN.exe in Windows 8 or Windows Server 2012

http://support.microsoft.com/kb/2799960/EN-US

The last customer I helped had a combination of issues 1 and 2 and once he chose a beefier DC with more current hardware, the command always succeeded.  Another customer had a much bigger environment and ended up using the update I listed above to overcome the issue.

I hope you have enjoyed this journey explaining what is happening on such a SETSPN query.

Cheers,

Herbert "The Thread Master" Mauerer

Time for a quick lesson in blog history.  There'll be a quiz at the end!  Ok not really, but some history all the same.

Back a few years ago when we here at Microsoft were just starting to get savvy to this whole blog thing, one of our support escalation engineers, Tim Springston, decided to start up a blog about Active Directory.  You might have seen it in the past.  Over the years he's posted some really great insights and posts there that are definitely worth reading if you have the time.

Of course, the rest of us decided to do something completely different and started up AskDS a little later.  Rumor has it that it had something to do with a high-stakes poker game (Tim *is* from Texas, after all), but no one is really sure why we wound up with two support blogs to be honest - it's one of those things that just sort of happened.

Anyway, all this time while we've been partying it up over here on TechNet, our AD product team has been marooned over on MSDN with an audience of mostly developers.  Not that developers are bad folks - after all, they make the apps that power pretty much everything - but the truth is that a lot of what we do in Active Directory in terms of feature development is also targeted at Administrators and Architects and IT Pros.  You know, the people who read blogs on TechNet and may not think to also check MSDN.

After a lot of debate and discussion internally, the AD product team came to the conclusion that they really should have a presence on TechNet so that they could talk to everyone here about the cool features they're working on.

The problem?  Well, we sort of had a monopoly over here in support on AD-related blog names. :)

Meetings were convened.  Conferences were held.  Email flew back and forth.  Their might even have been some shady dealings involving gifts of sugary pastries.  In the end though, Tim graciously agreed to move his blogging efforts over to AskDS and cede control of http://blogs.technet.com/ad to the Active Directory Product team.

The result?  Everyone wins.  Tim's now helping us write cool stuff for AskDS (you'll see plenty of that in the near future, I'm sure), and the product team has already startedpostinga bunchof things that you might have missed when they were on MSDN.

If you haven't seen what they're up to over there, go and take a look .  And as we get out of summer and get our people back from vacation, and, you know, roll a whole new server OS out the door, keep an eye on both blogs for updates, tips, explanations, and all manner of yummy AD-related goodness.

--David "Wait, we get another writer for AskDS??" Beach

[Editor's note:  Everything Mark mentions for Windows 8 clients here is also true for Windows 8.1 clients.  Windows 8 and Windows 8.1 clients use the same (v3) profile version, so the 8.1 upgrade will not prevent this from happening if you have roaming profiles in your environment.  Something to be aware of if you're planning to migrate users over to the new OS version. -David]

Hi. It’s Mark Renoden, Senior Premier Field Engineer in Sydney, Australia here again. Today I’ll offer a workaround for an issue that’s causing a number of customers around the world a degree of trouble. It turns out to be reasonably easy to fix, perhaps just not so obvious.

The Problem

The knowledge base article "Unpredictable behavior if you migrate a roaming user profile from Windows 8 to Windows 7" - http://support.microsoft.com/kb/2748329 states:

Windows 7 and Windows 8 use similar user profile formats, which do not support interoperability when they roam between computers that are running different versions of Windows. When a user who has a  windows 7 profile signs in to a Windows 8-based computer for the first time, the user profile is updated to the new Windows 8 format. After this occurs, the user profile is no longer compatible with Windows 7-based computers. See the "More information" section for detailed information about how this issue affects roaming and mandatory profiles.

This sort of problem existed between Windows XP and Windows Vista/7 but was mitigated by Windows Vista/7 using a profile that used a .v2 extension.  The OS would handle storing the separate profiles automatically for you when roaming between those OS versions.  With Windows 7 and Windows 8, both operating systems use roaming profiles with a .v2 extension, even though Windows 8 is actually writing the profile in a newer format.

Mark’s Workaround

The solution is to use separate roaming profiles for each operating system by utilizing an environment variable in the profile path.

Configuration

File server for profiles:

1. Create profile share “\\Server\ProfilesShare” with permissions configured so that users have write access
2. In ProfilesShare, create folders “Win7” and “Win8”

Active Directory:

1. Create OU for Windows 7 Clients (say “Win7OU”) and create/link a GPO here (say “Win7GPO”)
2. Create OU for Windows 8 Clients (say “Win8OU”) and create/link a GPO here (say “Win8GPO”)

Note:As an alternative to separate OUs, a WMI filter may be used to filter according to Operating System:

Windows 7 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.1%” and ProductType = “1″

Windows 8 - SELECT version FROM Win32_OperatingSystem WHERE Version LIKE “6.2%” and ProductType = “1″

3. Edit Win7GPO

1. Expand Computer Configuration -> Preferences -> Windows Settings
2. Under Environment create an environment variable with
1. Action: Create
2. System Variable
3. Name: OSVer
4. Value: Win7

4. Edit Win8GPO

1. Expand Computer Configuration -> Preferences -> Windows Settings
2. Under Environment create an environment variable with
1. Action: Create
2. System Variable
3. Name: OSVer
4. Value: Win8

5. Set user profile paths to \\Server\ProfilesShare\%OSVer%\%username%\

Clients:

1. Log on with administrative accounts first to confirm creation of the OSVer environment variable

2. Log in as users and you’ll observe that different user profiles are created in the appropriate folder in the profiles share depending on client OS

Conclusion

I haven't run into any issues in testing but this might be one of those cases where it's important to use "wait for network". My testing suggests that using "create" as the action on the environment variable mitigates any timing issues.  This is because after the environment variable is created for the machine, this variable persists across boots and doesn't depend on GPP re-application.

You may also wish to consider the use (and testing) of a folder redirection policy to provide users with their data as they cross between Windows 7 and Windows 8 clients. While I have tested this to work with
“My Documents”, there may be varying degrees of success here depending on how Windows 8’s modern apps fiddle with things.

 - Mark “Square Peg in a Round Hole” Renoden

Over at the Filecab blog, AskDS alum and all-around nice guy Ned Pyle has posted the first of several blogs about new features coming your way in Windows Server 2012 R2.  If you're a DFS administrator or just curious, go take a look!

Ned promises more posts in the near future, and Filecab is near and dear to our hearts here in DS (they make a bunch of things we support), so if you don't already have it on your RSS feed list, it might be a good time to add it.

Hi everyone, David here with a quick announcement.

Yesterday, MSRC announced a timeframe for deprecation of built-in support for certificates that use the MD5 signature hash. You can find more information here:

http://blogs.technet.com/b/srd/archive/2013/08/13/cryptographic-improvements-in-microsoft-windows.aspx

Along with this announcement, we've released a framework which allows enterprises to test their environment for certificates that might be blocked as part of the upcoming changes (Microsoft Security Advisory 2862966). This framework also allows future deprecation of other weak cryptographic algorithm to be streamlined and managed via registry updates (pushed via Windows Update).

Some Technical Specifics:

This change affects certificates that are used for the following:

• server authentication
• code signing  
• time stamping
• Other certificate usages that used MD5 signature hash algorithm will NOT be blocked.

For code signing certificates, we will allow signed binaries that were signed before March 2009 to continue to work, even if the signing cert used MD5 signature hash algorithm.

Note:  Only certificates issued under a root CA in the Microsoft Root Certificate program are affected by this change.  Enterprise issued certificates are not affected (but should still be updated).

What this means for you:

1) If you're using certificates that have an MD5 signature hash (for example, if you have older web server certificates that used this hashing algorithm), you will need to update those certificates as soon as possible.  The update is planned to release in February 2014; make sure anything you have that is internet facing has been updated by then.

You can find out what signature hash was used on a certificate by simply pulling up the details of that certificate's public key on any Windows 8 or Windows Server 2012 machine.  Look for the signature hash algorithm that was used. (The certificate in my screenshot uses sha1, but you will see md5 listed on certificates that use it).

If you are on Server Core or have an older OS, you can see the signature hash algorithm by using certutil -v against the certificate.

2) Start double-checking your internal applications and certificates to insure that you don't have something older that's using an MD5 hash.  If you find one, update it (or contact the vendor to have it updated).

3) Deploy KB 2862966 in your test and QA environments and use it to test for weaker hashes (You are using test and QA environments for your major applications, right?).  The update allows you to implement logging to see what would be affected by restricting a hash.  It's designed to allow you to get ahead of the curve and find the potential weak spots in your environment.

Sometimes security announcements like this can seem a little like overkill, but remember that your certificates are only as strong as the hashing algorithm used to generate the private key.  As computing power increases, older hashing algorithms become easier for attackers to crack, allowing them to more easily fool computers and applications into allowing them access or executing code.  We don't release updates like this lightly, so make sure you take the time to inspect your environments and fix the weak links, before some attacker out there tries to use them against you.

--David "Security is everyone's business" Beach

Update (8/19/13):

We have republished MS13-066 with a corrected version of the hotfixes that contributed to this problem.  If you had held off on installing the update, it should be safe to install on all of your ADFS servers now.

The updated security bulletin is here: http://technet.microsoft.com/en-us/security/bulletin/MS13-066

Thanks everyone for your patience with this one.  If anyone is still having trouble after installing the re-released update, please call us and open a support case so that our engineers can get you working again!

===============================================================

Hi everyone, Adam and JR here with an important announcement.

We’re tracking an important issue in support where some customers who have installed security update MS13-066 on their AD FS 2.0 servers are experiencing authentication outages.  This is due to a dependency within the security update on certain versions of the AD FS 2.0 binaries.  Customers who are already running ADFS 2.0 RU3 before installing the update should not experience any issues.

We have temporarily suspended further downloads of this security update until we have resolved this issue for all ADFS 2.0 customers. 

Our Security and AD FS product team are working together to resolve this with their highest priority.  We’ll have more news for you soon in a follow-up post.  In the meantime, here is what we can tell you right now.

What to Watch For

If you have installed KB 2843638 or KB 2843639 on your AD FS server, you may notice the following symptoms:

1. Federated sign-in fails for clients.
2. Event ID 111 in the AD FS 2.0/Admin event log:

The Federation Service encountered an error while processing the WS-Trust request. 

Request type: http://schemas.xmlsoap.org/ws/2005/02/trust/RST/Issue 

Additional Data 

Exception details: 

System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. ---> System.TypeLoadException: Could not load
type ‘Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

   at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)

   --- End of inner exception stack trace ---

   at System.RuntimeMethodHandle._InvokeConstructor(Object[] args, SignatureStruct& signature, IntPtr declaringType)

   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)

   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)

   at Microsoft.IdentityModel.Configuration.SecurityTokenServiceConfiguration.CreateSecurityTokenService()

   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateSTS()

   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.CreateDispatchContext(Message requestMessage, String requestAction, String responseAction, String
trustNamespace, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, WSTrustSerializationContext serializationContext)

   at Microsoft.IdentityModel.Protocols.WSTrust.WSTrustServiceContract.BeginProcessCore(Message requestMessage, WSTrustRequestSerializer requestSerializer, WSTrustResponseSerializer responseSerializer, String requestAction, String responseAction, String trustNamespace, AsyncCallback callback, Object state)

System.TypeLoadException: Could not load type 'Microsoft.IdentityModel.Protocols.XmlSignature.AsymmetricSignatureOperatorsDelegate' from assembly 'Microsoft.IdentityModel, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.

   at Microsoft.IdentityServer.Service.SecurityTokenService.MSISSecurityTokenService..ctor(SecurityTokenServiceConfiguration securityTokenServiceConfiguration)

What to do if the problem occurs:

1. Uninstall the hotfixes from your AD FS servers.
2. Reboot any system where the hotfixes were
   removed.
3. Check back here for further updates.

We’ll update this blog post with more information as it becomes available, including links to any followup posts about this problem.

Hello Everyone,

This is Shijo from our team in Bangalore once again.  Today I’d like to briefly discuss account lockouts, and some UI behaviors that can trip admins up when dealing with account lockouts.

If you’ve ever had to troubleshoot an account lockout issue, you might have noticed that sometimes accounts appear to be locked on some domain controllers, but not on others.  This can be very confusing since you
typically know that the account has been locked out, but when you inspect individual DCs, they don’t reflect that status.  This inconsistency happens because of some minor differences in the behavior of the UI between Windows Server 2003, Windows Server 2008, Windows Server 2008 R2, and Windows Server 2012.

Windows Server 2003

In Windows Server 2003 the "Account is locked out" checkbox can be cleared ONLY if the account is locked out on the domain controller you are connected to. This means that if an account has been locked out, but the local DC has not yet replicated that information, you CANNOT unlock the account on the local DC.

Windows 2003 account properties for an unlocked account.  Note that the checkbox is grayed out.

Windows Server 2008 and Windows Server 2008 R2

In Windows Server 2008/2008 R2 the "Unlock account" checkbox will always be available (regardless of the status of the account). You can tell whether the local DC knows if the account is locked out by looking at the label on the checkbox as shown in the screenshots below:

Windows 2008 account properties showing the “Unlock Account” checkbox.  Notice that the checkbox is available regardless of the status of the account on the local DC.

Windows 2008 (and higher) Account Properties dialog box showing locked account on this domain controller

If the label on the checkbox is just "Unlock account" then this means that the domain controller you are connected to recognizes the account as unlocked. This does NOT mean that the account is not locked on other DCs, just that the specific DC we're working with has not replicated a lockout status yet.  However, unlike Windows Server 2003, if the local DC doesn’t realize that the account is locked, you DO have ability to unlock it from this interface by checking the checkbox and applying the change.

We changed the UI behavior in Windows Server 2008 to help administrators in large environments unlock accounts faster when required, instead of having to wait for replication to occur, then unlock the account, and then wait for replication to occur again.

Windows Server 2012

We can also unlock the accounts using the Active Directory Administrative Center (available in Windows Server 2008 R2 and later).  In Windows Server 2012, this console is the preferred method of managing accounts in Active Directory. The screen shots are present below about how we can go about doing that.

You can see from the account screenshot that the account is locked which is denoted by the padlock symbol. To unlock the account you would have to click on the “Unlock account” tab and you would see a
change in the symbol as can be seen below.

You can also unlock the account using the PowerShell command shown in the screenshot below.

In this example, I have unlocked the user account named test by simply specifying the DN of the account to unlock . You can modify your powershell command to incorporate many more switches, the details of which are present in the
following article.

http://technet.microsoft.com/en-us/library/ee617234.aspx

Hopefully this helps explain why the older operating systems behave slightly differently from the newer ones, and will help you the next time you have to deal with an account that is locked out in your environment! 

If you’re looking for more information on Account Lockouts, check out the following links:

Troubleshooting Account Lockout

Account Lockout Policy

Account Lockout Management Tools

Shijo “UNLOCK IT” Joy

So, we’ve been quiet for a few months, which is extraordinarily embarrassing after I basically told everyone that we were going to not do that. The reality of what we do in support is that sometimes it’s “All Hands on Deck”, which is where we’ve been lately.

At any rate, here’s some assorted news, updates, and announcements. Today we’re going to talk about ADMT, SHA-1, Folder Redirection, Roaming Profiles, STOP errors, and job opportunites. Yup, all in one big post. It’s not quite a mail sack but hopefully you all will find it interesting and or useful – especially the bit at the end. We’ll try to get the regular posts moving again asap as we get into 2014.

ADMT OS Emancipation

Update coming to allow you to install on any supported server OS version

News just in: There’s an updated version of ADMT on the way that will allow you to install on newer OS versions. Here’s what we got from the ADMT product team:

In short, the update will allow ADMT to install on our newer OSs (both the ADMT and PES components). This should help alleviate some of the problems that customers have been reporting with the tool. We know that there are many of you who would like to see improvements or additional features in the tool beyond this, but we made the decision to focus this update on the OS compatibility issues, since that’s the thing that is impacting migrations the most right now.  We currently do not have any plans for further updates after this one (beyond bug fixes).

The changes we have made require a fair bit of testing before we can release them – among other things, we have to test full-scale migrations against each combination of OS versions to make sure that nothing unexpected occurs.  Once that testing is complete, we’ll publish the new version for public download, probably as an update to the existing 3.2 version.  We don’t have an exact date right now, since it’s likely to take us a few months to finish our testing, but we’re hoping to have it out and available in the first quarter of 2014.

Out with the old (and the insecure)

We’ve announced the deprecation of SHA-1 algorithms

This one comes to us from former AskDS writer Mike Stephens. Mike changed roles last summer, and most of what he works on these days we can’t talk about – but some things we can:

Some of you may remember this security advisory where we announced the deprecation of RC4-based cryptographic algorithms. Some of you may also remember this blog post from a few months ago where we talked about the upcoming deprecation of MD5-based algorithms.

Deprecation is a fancy word for “we don’t support it anymore moving forward, so you should look at turning it off.”

If you’re sensing a trend here, you’re not wrong. We just announced yesterday that we are planning the deprecation of SHA-1 algorithms.

This means that moving forward, the minimum security you want on anything cryptographic is SHA-2 with a 2048-bit key. Those of you running certificate authorities should start planning on transitioning to stronger keys as soon as you can. Those you who have server or web applications in your environment (pretty much everyone) should start reviewing your applications to find any applications that are using weak certificates. Update them if you can, contact the application vendor if you can’t.

Just like the previous updates, we’re not going to issue a hotfix that turns off SHA-1 on all your servers and workstations. We know that there are lots of older applications out there that might need to be updated before your environments are ready for this kind of change so you are in control. What we will do is give you a KB article that tells you how to turn SHA-1 off when you’re ready. That, and we’ll turn it off by default in the next version of the OS.

That being said, two notes of caution. First, make sure you really, really check before disabling support for older cryptography algorithms in your environments. We’ve had a few cases where admins didn’t check the certificates their applications were using, and caused an outage with one or more of their applications when they turned off RC4. The point here is to test and verify application dependencies and compatibility before you make a widespread change. Second, have a plan to roll back the change if something you didn’t expect breaks. Finally, don’t wait to start transitioning your environment to stronger [using] crypto graphic algorithms. The longer your environment is using less secure cryptography, the more vulnerable you are to attacks. You can get ahead of the curve by updating your application requirements now to higher standards, and starting the work to transition your existing apps over to new certificates.

One way, or the other…

Folder Redirection Group Policy doesn’t apply to Windows 8 and Windows 8.1 clients when you also configure it in System Center

This one comes to us from one of our tech leads, Kapil Chopra. Among many other duties, part of Kapil’s role is to watch for trends in the support cases that come into our frontline engineers, so that we can prioritize fixes that are affecting lots of customers.

I had a chance to work on multiple cases where in folder redirection doesn’t gets applied on Windows 8 and Windows 8.1. So I thought of posting the details to make sure that everyone is aware of the fact and should be able to resolve the issue.

In all the cases that I addressed, we see the below mentioned symptoms on the client:

1. In the RSOP, under the properties of User Configuration, we see that the Folder Redirection settings got applied successfully.

2. Under the RSOP, when we browse to the User Configuration > Policies > Windows Settings, we don’t see Folder Redirection folder.

3. Under the GPRESULT /v output we see that the folder redirection setting is showing up as N/A.

4. There is no failures reported under the Application / System logs.

5. Group Policy Logging states that the policy is applied as mentioned below:

GPSVC(32c.b6c) 12:55:50:136 ProcessGPOs(User): Processing extension Folder Redirection
GPSVC(32c.b6c) 12:55:50:136 ReadStatus: Read Extension's Previous status successfully.
GPSVC(32c.b6c) 12:55:50:136 CompareGPOLists: The lists are the same.
GPSVC(32c.b6c) 12:55:50:136 CompareGPOLists: The lists are the same.
GPSVC(32c.b6c) 12:55:50:136 GPLockPolicySection: Sid = S-1-5-21-2130729834-1480738125-1508530778-62684, dwTimeout = 30000, dwFlags = 0x0
-
-
GPSVC(32c.b6c) 12:55:50:136 ProcessGPOList: Entering for extension Folder Redirection
GPSVC(32c.b6c) 12:55:50:136 UserPolicyCallback: Setting status UI to Applying Folder Redirection policy...
GPSVC(32c.b6c) 12:55:50:136 ProcessGPOList: No changes. CSE will not be passed in the IwbemServices intf ptr
GPSVC(32c.43c) 12:55:50:136 Message Status = <Applying Folder Redirection policy...>
-
-
GPSVC(32c.b6c) 12:55:50:152 ProcessGPOList: Extension Folder Redirection returned 0x0.

6. Under the folder redirection tracing, it isn't getting past fdeploy.dll into the shell components and is not even attempting to read the fdeploy.ini files.

From the above symptoms, it is pretty evident that there is something that is stopping the Folder Redirection engine from proceeding further. So we went ahead looked into the Folder Redirection operational logs under “Event viewer > Application and Services Logs > Microsoft > Windows > Folder Redirection > Operational Logs”.

Under the Operational logs we found an interesting event which might be causing the problem:

Log Name: Microsoft-Windows-Folder Redirection/Operational
Source: Microsoft-Windows-Folder Redirection
Date: 11/4/2013 11:54:58 AM
Event ID: 1012
Task Category: None
Level: Information
User: SYSTEM
Computer: WIN8TEST.contoso.com
Description: Folder Redirection configuration is being controlled by WMI configuration class Win32_FolderRedirectionUserConfiguration.

In order to confirm if it’s only the Folder Redirection or other components as well getting controlled by WMI, we ran the powershell command “gwmi Win32_UserStateConfigurationControls” and found that all components i.e. Folder Redirection / Offline Files / Roaming User Profiles were controlled by WMI.
===================================================
__GENUS : 2
__CLASS : Win32_UserStateConfigurationControls
__SUPERCLASS :
__DYNASTY : Win32_UserStateConfigurationControls
__RELPATH : Win32_UserStateConfigurationControls=@
__PROPERTY_COUNT : 3
__DERIVATION : {}
__SERVER : WIN8TEST
__NAMESPACE : root\cimv2
__PATH : \\WIN8TEST\root\cimv2:Win32_UserStateConfigurationControls=@
FolderRedirection : 1
OfflineFiles : 1
RoamingUserProfile : 1
PSComputerName : WIN8TEST
===================================================

Now the question is, what this WMI Class “Win32_FolderRedirectionUserConfiguration” has to do with Folder redirection?

In order to answer that, everyone should be aware of the fact that with Windows 8 we have introduced new WMI classes to manage and query Folder Redirection and Remote User Profiles configuration using WMI controls. These WMI classes are mentioned below:

So, the big question is - who is giving the control on FR/CSC/RUP to WMI?
In all the cases that we have dealt with, we found that the machines were deployed and managed using SCCM. So there might be something in the SCCM configuration which is changing the default behavior and passing on the control to WMI. We looked into the System Center Configuration Manager and found the setting which might be causing all the pain. The exact configuration is mentioned below:

Under the SCCM Configuration manager,
- Select Administration
- Select Client Settings

- Pull up PROPERTIES of Default Client Settings configuration and click on Compliance Settings

- Enable User Data and Profiles mentioned above is the setting which drives the control of Folder Redirection and Remote User Profiles.

The above configuration by Default is set to NO. Once enabled (set to YES), it passes the control of Folder Redirection, Offline Files, and Remote User Profiles to WMI and stores this configuration under the registry path: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\UserState\UserStateTechnologies\ConfigurationControls

This is evident from the fact that FolderRedirection, OfflineFiles, and RoamingUserProfiles registry entry mentioned in the above snippet is set to 1.

More details about Managing UserState via System Center Configuration is documented under the articles mentioned below:
- How to Create User Data and Profiles Configuration Items in Configuration Manager : http://technet.microsoft.com/en-us/library/jj591610.aspx
- Example Scenario for User Data and Profiles Management in Configuration Manager : http://technet.microsoft.com/en-us/library/jj870707.aspx

RESOLUTION

To resolve the issue we need to change the value of “Enable User Data and Profiles” to NO under the Compliance settings in SCCM Configuration.

Another important fact that I need to point out is, changing the value of above registry entries to “0” will resolve the issue for a while on a client but the registry entries will automatically be flipped to 1 once the SCCM configuration client piece gets executed on the Win8 or Win8.1 machines. By default, this configuration runs every hour to pull changes from the System Center Configuration Manager server. So you have to make the change in System Center if you want it to stick.

Most customers don’t realize what they are doing when they set this value to YES, so they will want to make sure it is set to NO in their environments. If a customer does want to use it, then they will need to make sure they are managing Folder Redirection through WMI and not through Group Policy or they will run into the problems mentioned above.

Getting Rid of Pesky STOP Errors

Hotfix released to correct a crash in TCP/IP.

Here is a fix you will want to test and then deploy to your servers as soon as you can. For the past few months we have been tracking a large number of cases where servers would crash (blue screen) with a STOP 0xD1 error. We’ve been tracking this issue for a long time, but we were never able to figure out what exactly caused it because it only happened under specific circumstances on multiprocessor computers It took us so long to figure this out. Those conditions used to be pretty rare but as multiprocessor computers are now the norm, problem frequency has increased.  We now have a hotfix for Windows Server 2008 R2 available just in time for the holidays.

Windows Server 2012 and Windows Server 2012 R2 versions of the same hotfix are being tested and will be released in January 2014 if the testing pans out.

Making the kids play nice together

Roaming profiles now coexist properly for Windows 7, Windows 8 and Windows 8.1 computers.

Some of you may recall a blog post from one of our friends in PFE about problems roaming user profiles between computers running Windows 7 and Windows 8. In the original blog, we presented a workaround that, while it helped, was not really a fix for the issue.

Well, now we have a fix for the issue. Twoof them, rather. I’ll explain.

To set expectations: Windows 8 uses a new profile format (just like Windows 7 had a new format when compared to XP). Windows 8.1 uses a third (or fourth) new profile format. So, if you want to move data between computers running Windows 7, Windows 8, and Windows 8.1, you will need to use Folder Redirection…. OR you can consider using the cool new feature called Work Folders, which we’ll be adding support for Windows 7 in the coming months. But if you don’t do one of these things, then the two profiles are separate – no data gets shared between the two OS versions.

KB 2887239 and KB 2890783 allow roaming profiles to “roam” properly even if you’re in a mixed OS environment. That means users will be able to log in seamlessly to different devices without having to follow the workaround mentioned in Mark’s blog post.

Last, but definitely not least:  We’re hiring.

I mentioned at the start of this that the last few months for us in DS (and really in all of support) have been “All Hands on Deck”. And while things slow down a little over the holidays, we have more work to do than we have hands and minds to do it right now.

So we’re hiring. If you’re the sort of person who enjoys fixing hard problems, who likes getting into the guts of how software works, and who’s not afraid to constantly be asked to learn something new, you really should check out our careers page. There are positions available in Charlotte, NC, in Las Colinas, TX, and in Fargo, ND. And this isn’t just for DS – it’s for all of our Windows support teams (and others). If you’re interested, look for Support Engineer positions and send in your resume.

What we do is possibly the most technically demanding and challenging infrastructure job there is. Every day we work on problems that impact hundreds or thousands of users out there in the world, and some with more impact with that. It’s not an *easy* job. But it is a very fulfilling one.

If you’re interested in applying, check out these two blog posts we put up a while back, and we’ll look forward to talking to you.

Post-Graduate AD Studies

Accelerating Your IT Career

Hi All!

My name is Saurabh Koshta and I am with the Core Team at Microsoft. Currently I work in the client space so supporting all aspects of Windows 8 and Windows 8.1 is my primary role.

We very often get calls from customers who are evaluating Windows 8/Windows 8.1 for deployment, but are concerned about some of the changes in the UI that may confuse their users. A typical concern we hear is that users are used to having shortcuts on the desktop for Computer, Documents, and Network. So, I wanted to take a minute to show you how you can easily add those shortcuts (or others) to desktops using Group Policy Preferences.

I have an OU in my domain called “Domain Computers”, which has Windows 8 machines.

The next step is to create a policy and link in to the “Domain Computers” OU. In this case it is called “Shortcut”

Edit the policy and go to the following location:

Computer Configuration -- > Preferences -- > Windows Settings -- > Shortcuts

Highlight Shortcuts and on the right pane, right click and select new Shortcut

In the ‘New Shortcut Properties’, make the following changes so the values look like below:

1. Action : Update

2. Target type : Shell Object

3. Location : All Users Desktop

4. For Target object, click on the browse option and then chose ‘Computer’

5. Name : My Computer

Leave rest of the options as default. Once you have made all the changes, it would look like below:

Similarly for Network the options are:

1. Action : Update

2. Target type : Shell Object

3. Location : All Users Desktop

4. For Target object, click on the browse option and then chose ‘Network’

5. Name : My Network Places

And for Libraries the options are:

1. Action : Update

2. Target type : Shell Object

3. Location : All Users Desktop

4. For Target object, click on the browse option and then chose ‘Libraries’

5. Name : My Documents

So we have the following three shortcuts

Restart the client and once logged in with a domain user, the desktop would have the three shortcuts as listed above and it would look something like below:

The above steps also work with Windows 8.1. Here is how it looks:

Hope you all find this information useful.

Thanks,

Saurabh Koshta

Hi! Its Linda Taylor here again from the Directory Services Escalation team in the UK. In this post, I want to tell you – We are hiring in the UK!!

Would you like to join the UK Escalation Team and work on the most technically challenging and interesting Active Directory problems? Do you want to be the next “Ned Pyle”?

Then read more…

We are an Escalation Team based in Microsoft Campus in Reading (UK). We are part of Microsoft Global Business Support and we work with enterprise customers helping them resolve the most critical Active Directory infrastructure problems as well as enabling our customers to get the best of Microsoft Windows and Identity related technologies. The work we do is no ordinary support – we work with a huge variety of customer environments and there are rarely two problems which are the same. We are the experts in our field and we work closely with the product group to help make Windows and all our other technologies better. 

You will need strong AD knowledge, great customer services skill, strong troubleshooting skills and great collaboration and team work.

You can find more of the job details here:

https://careers.microsoft.com/jobdetails.aspx?ss=&pg=0&so=&rw=1&jid=130665&jlang=EN&pp=SS

Linda.

Hi, David here.  Over the past year we’ve gotten a lot of feedback from our customers about the pain of changing from older versions of Windows over to Windows 8 and Windows 8.1.  While it’s a great OS with a lot of compelling features, it’s a big change – and as any desktop administrator will tell you, change is a really scary thing for users who just want to be able to log in and get their work done every day.  Well, we listened, and in the update we’re releasing this week, we’ve made it easier for you to help manage the change for your users and make the transition to Windows 8.1 a little more friendly for them.  Below is some awesome information courtesy of the inestimable Warren Williams.

First, a quick history lesson.  Don’t worry, there’s not a quiz at the end.

Start Screen history

Starting with Windows 8.0 Start is the main application launch pad in Windows. Start replaces the Start Menu used in previous versions of Windows going back to Windows 95.

With each update of Windows 8.0, more control over Start’s configuration has been added.

Windows 8.0

The Start Menu was removed from Windows and replaced by Start. The default behavior in Windows 8.0 is that users always boot to Start. There was no Microsoft supported method of controlling the boot to Start behavior in Windows 8.0.

Windows 8.1

In Windows 8.1 Microsoft added the ability for users and administrators to control what environment would be displayed when the user logged on. The user can either boot to the Start screen or the Desktop. The behavior was still to always boot to the Start screen however the behavior could be controlled manually with a setting in the Taskbar Navigation properties. Administrators could use a new a Group Policy “Go to the desktop instead of Start when signing in” to specify what environment the user would see after signing in.

Everyone got that?  Ok, let’s talk about the new stuff now.

Windows 8.1 Update

In Windows 8.1 Update Microsoft added the ability for the OS to perform device type detection. After applying Windows 8.1.update Tablet devices will boot to the Start Screen and have modern application file associations. All other device types boot to the desktop and the desktop application file associations. The two preceding behaviors occur if the default setting for Taskbar Navigation properties have not changed.  Some things to note:

• If customizations to the Start Screen behavior had been made by the user before applying Windows 8.1 Update those customizations will remain in effect.
• Group policy will take precedence over Windows 8.1 update 1 default behavior. If the Boot to Desktop settings are controlled by Group Policy a user will not be able to makes changes to the Taskbar Navigation Properties.

How Device Type Detection works in Windows 8.1 Update

Device type detection in Windows 8.1 Update is accomplished by querying the value of Power_Platform_Role and taking action based on the value set. The value for Power_Platform_Role is set by the manufacturer of the device and cannot be changed. If the value for Power_Platfor_Role is set to a value of 8 the user will sign in to Start. Any value other than 8 will cause the user to sign in to the desktop, instead of the Start Screen.

The possible values for Power_Platform_Role are:

Table 1Power_Platform_Role Values

See this MSDN page for more information: “POWER_PLATFORM_ROLE enumeration”

How to query a device’s Power_Platform_Role value

Run this PowerShell command: “(gwmi win32_computersystem).pcsystemtype” locally on a PC or Tablet to determine the value of “Power_Platform_Role”

3 Example of using PowerShell to query the value of Power_Platform_Role. In this example the value returned was "2"

Tablets that boot to the desktop

It is possible for a tablet device to boot to the Desktop if the tablet’s Power_Platform_Role was set to a value other than 8 by the manufacturer. Windows does not set the value of Power_Platform_Role nor can the value be changed. The value is set by the device manufacturer in the BIOS and is read by Windows at boot time and stored in WMI.

See: “POWER_PLATFORM_ROLE enumeration” - http://msdn.microsoft.com/en-us/library/windows/desktop/aa373174(v=vs.85).aspx

Options to Control Sign in to Desktop Behavior in Windows 8.1 Update

Fortunately, you can change the behavior without having to be an OEM.

Manually - Taskbar Navigation Properties

To manually change the environment that the user logs on to perform the following steps

1. Open the desktop

2. Right click on the taskbar and select properties

3. Select the “Navigation” tab

a. If you want the Start Screen to load when a user logs on uncheck the box “When I sign in or close all apps on a screen, go to the desktop instead of Start”

b. If you want the Desktop to load when a user logs on check the box “When I sign in or close all apps on a screen, go to the desktop instead of Start”

Figure 4Taskbar Navigation Properties

Administrative - Group Policy

A Domain Administrator can use Group Policy to control the Boot to desktop behavior on many machines from a centralized location. If Group Policy is used to control this setting the user will not be able to change the Boot to desktop behavior. If an administrator wants users to be able to set the desired behavior they should set the default behavior in their image. The Group Policy is located in the this path

“User Configuration\Administrative Templates\Start Menu and Taskbar\Go to the desktop instead of Start when signing in”

Description of this Group Policy

“This policy setting allows users to go to the desktop instead of the Start screen when they sign in.

If you enable this policy setting, users will always go to the desktop when they sign in.

If you disable this policy setting, users will always go to the Start screen when they sign in.

If you don’t configure this policy setting, the default setting for the user’s device will be used, and the user can choose to change it.”

Figure 5Group Policy to control "Go to desktop instead of Start" behavior

Administrative – Deployment using a Unattend.xml answer file

Deployment Admins can specify if the user go to Start or the desktop after signing in using the DesktopOptimization tag in their unattend.xml file. This method allows admins to specify a default behavior and still allow users the ability to set their preferred Sign in environment.

<DesktopOptimization>

<GoToDesktopOnSignIn>true</GoToDesktopOnSignIn>

</DesktopOptimization>

For more information consult the Windows Assessment and Deployment Kit (ADK) helpfile. The ADK can be downloaded from here. http://www.microsoft.com/en-us/download/details.aspx?id=30652

Hopefully this information helps all of you out there with giving your users a better experience on Windows 8.1.

- Warren “The Updater” Williams

Warren here, posting with more news regarding the Windows 8.1 Update. Among the many features added by Windows 8.1 Update is that the Store icon will be pinned to the users taskbar when users first logon after updating their PC with Windows 8.1 Update.

Some companies will not want the Store icon pinned to the taskbar on company owned devices.  There are currently two Group Policy options to control the Store tile pin - one that you can use before deploying the update that will prevent the Store app from being pinned to the Taskbar, and another that you can use after the update has been deployed and the Store app has been pinned to the Taskbar.

Option 1:  Turn off the Store application before Installing the Windows 8.1

Use the Group Policy “Turn off the Store application”

As mentioned earlier, the Store Icon is pinned to the Taskbar at first logon after Windows 8.1 Update is applied. The Store application will not be pinned to the taskbar if the Group Policy “Turn off the Store application” is applied to computer. This option is not retroactive. The Group Policy must be applied to the workstation before the update is applied. The full path to this Group Policy is:

Computer Configuration\Administrative Templates\Windows Components\Store\Turn off the Store application

Or

User Configuration\Administrative Templates\Windows Components\Store\Turn off the Store application

You can use either Group Policy. As the name of the policy indicates, this will completely disable the Store. If your desire is to allow access to the Store but do not want the Store tile pinned to the Taskbar see option 2.

Important note: By default the Group Policy setting “Turn off the Store application” will not show up in GPEDIT.MSC or GPMC.MSC if you run the tools on a Windows Server. You have two options: Install the Remote Server Admin Tools (RSAT) tools on a Windows 8.1 client and edit the group policy from that machine or install the Desktop Experience feature on the server used for editing Group Policy. The preferred method is to install the RSAT tools on a workstation. You can download the RSAT tools for Windows 8.1 here: http://www.microsoft.com/en-us/download/details.aspx?id=39296

Option 2:  Use Group Policy to remove Pinned applications from the Taskbar after Installing the Update

Use the Group Policy “Remove pinned programs from the Taskbar”

This GP is a big hammer in that it will remove all pined tiles from the task bar and users subject to the policy will not be able to pin any applications or tiles to the Taskbar. This accomplishes the goal of not pinning the Store tile to the taskbar and leaves the Store accessible from Start.

User Configuration\Administrative Templates\Start Menu and Taskbar\Removed pinned programs from the Taskbar”

Other Options

The last available option at this time is to have users unpin the Store app on their systems. Programmatically changing the Taskbar pins is not supported nor encouraged by Microsoft. See http://msdn.microsoft.com/en-us/library/dd378460(VS.85).aspx

Hi everyone, David here.  Today over at the Springboard series blog we announced some important news that applies to anyone who has been trying to roll out the Windows 8.1 update in an enterprise environment.  We don’t usually do announcements about things being covered by other Microsoft blogs, but this one addresses something we’ve gotten a lot of questions about.

If you haven’t read the blog, here’s the super-short version:

- We have a fix for the Windows Update problem that prevents organizations from using WSUS to deploy the Windows 8.1 Update.

- We’ll be issuing security updates for Windows 8.1 (without the update) in the catalog until August, instead of stopping next month as originally announced.  This gives enterprises more time to test the feature changes in the Windows 8.1 Update and deploy them, without having to worry about not getting critical security updates.

Click here to read the full announcement.