Update: Alternatively refer to the Restore Policy Console utility to try this process for the administrator.

This article describes behind-the-scenes changes in the group policy User Interface (UI) in XenDesktop 7.x Studio.

Background

One of the most important decisions made in the XenDesktop 7.0 Studio group policy UI is eliminating the process required to identify the type (user or computer) of settings. XenDesktop administrators can now define the policy settings based on the intended usage without having to determine if a setting is a user setting or computer setting.

The new UI now combines the user and computer settings. When an administrator wants to create a policy, settings can be defined from both types and only one policy is required. Previously, the administrator would have to create a user policy and a computer policy. The new implementation makes policy creation more efficient.

To maintain backward compatibility the policy data format remains the same. The user and computer types are also maintained. Hence, the merging of user and computer policies are only done in the Studio UI. The PowerShell interface remains the same, when policies are accessed through PowerShell, administrators still need to separately access the user and computer settings of a policy that is displayed as one policy in the Studio UI.

Maintaining backward compatibility at the data level is important. It allows customers to upgrade their existing deployment without changing the database. It also allows the existing PowerShell scripts to work without significant modifications.

Discrepancy Detection

In the following descriptions, when Citrix discusses merging two policies, it means the merging of a computer policy and a user policy of the same name. Citrix never allows two policies of the same type to have the same name; therefore, the concept of merging applies only to a user and a computer policy.

Merging policies at the UI level means that the UI must ensure that two policies (one user policy and one computer policy) with the same name can always be correctly managed in the UI. When two policies contain inconsistent data, the UI must be able to detect the inconsistencies. At the same time, the UI code ensures that as long as policy data is accessed through the UI, the data is always consistent.

Basically, the UI must do two things in addition to maintaining data consistency. First, it must detect data inconsistency every time it reads data from the database. Second, it must decide what to do with the inconsistency.

A policy contains three blocks of data, the policy properties, for example, policy name, the settings, and the object assignments (also known as filters in previous releases). All the data must be consistent for the UI to be able to merge two policies.

Merging Settings

Policy settings are the easiest to merge. The intersection of user settings and computer settings is an empty set. This can be simply put together.

Merging Policy Properties

There are just four policy properties for each policy. The names of two policies must be the same (case-insensitive) for them to be considered as merge candidates. If two policies have different names, they cannot be merged, they will be simply regarded as two separate policies in the UI.

The policy description can be merged if the two policies can be merged and the descriptions are different (case-insensitive). When the descriptions are merged, its simply concatenates the descriptions together and prefixes each portion as Computer Settings and User Settings.

The enabled bits of two policies must be the same. If they are different, they cannot be merged.

The priorities of the two policies do not have to be equal to be considered for merging. The priority of a policy is basically used to indicate the order of application of its settings when the same settings are also used in other policies. This is also the display order of the policy in the UI. Therefore, the actual priority value is not important. What is important is the relative position of the policies among each other.

The algorithm that decides the relative orders of policies to be merged involves considering all policies. The UI must ensure that all the policies have the same order after some of them are merged. If two policies of the same name would cause the inversion of priorities in either the user or computer policies, the two policies cannot be merged.

Merging Object Assignments

The most complicated part in determining if two policies can be merged is the object assignments. First, defining if two object assignments are the same is a challenge. There are many assignment types and each type contains different data. The data are all in different formats and the relationships among the values of each assignment can be complex. For example, an assignment that involves a domain user or group name can be hard to resolve.

We opted to use the most conservative measures to ensure the equality of two assignments. Two assignments can be considered same if we are 100% certain that the two assignments have the same values. For all other cases, we consider the two assignments different.

When the object assignments are different for two policies, the policies cannot be merged.

If any two policies of the same name cannot be merged for any reason, the UI displays a message about the problem that needs fix. Now, the second part of the decision, what to do if inconsistencies are found.

Example:

Users who upgrade from their existing XenDesktop deployments might see a message that looks like the following when they open the Policy node in the Studio. 
"Changes made to policies outside of this console, such as in PowerShell or management tools from previous versions, resulted in a discrepancy between policies."

This message is displayed because the group policy UI detected inconsistencies between the user and computer component of the Unfiltered policy.

How to Fix the Inconsistencies

Many options were considered. We tried to completely fix the inconsistencies, partially fix the inconsistencies, and leave everything to the user. After carefully evaluating all the possible methods, the simplest approach was elected, and considered as the best approach, which is to leave everything to the user. The main reason for choosing this route is because, to accurately merge the policies, we need additional information from the user.

What should an administrator do to fix the inconsistencies

User intervention is required only if the policies have been modified using the PowerShell interface that result in inconsistencies, or after an upgrade from a previous release. When policy merge is required and inconsistencies are detected by the Studio UI, a message like what is shown above is displayed. Read this message carefully, it should contain enough information for the administrator to fix the issue.

Basically, the name of the policies to be merged and the inconsistency is displayed. For the given example, the offending policy is Unfiltered and the inconsistency is the Enabled bit is not the same. In this case, the administrator can simply change the Enabled bit to true or false for both the user Unfiltered policy and the computer Unfiltered policy.

Most of the time inconsistencies are found in the object assignments, which can contain multiple and complex values, and therefore hard to fix. For these inconsistencies, we recommend a simple method, renaming one of the policies. For example, if you have a user policy and computer policy named as Policy0, you can rename the user policy to Policy0_User. Because the names are different, the UI will not attempt to merge them.

For those who are not familiar with PowerShell or the Citrix Group Policy Provider, the following PowerShell commands can be used as a reference. Launch Windows PowerShell, and then execute the following commands:

PS>Add-PSSnapin Citrix.Common.GroupPolicy

PS>New-PSDrive Site –PSProvider CitrixGroupPolicy –Root \ -Controller localhost

PS>cd Site:\User

PS>ren "Policy0" Policy0-User

Here it is assumed that the commands are executed on a XenDesktop DDC. If the DDC is a remote server, replace localhost with the name of the remote server. The provider drive name here is Site. 

The Studio UI displays one message at a time. So if there are multiple policy merges and inconsistencies, only one inconsistency is shown at a time. 

In general it is a good idea to avoid having both user and computer policies with the same name before an upgrade to XenDesktop 7.0. This eliminates the possible messages about policy inconsistencies. In fact, during the upgrade, the XenDesktop 7.0 upgrade scripts rename all policies with the same names. 

One might wonder what to do with the inconsistencies in the Unfiltered policies, given that this policy cannot be renamed. It is fortunate that Unfiltered policies do not have filters. Therefore, administrators should be able to fix the Enabled bit, which should be the only possible reason for inconsistencies. The PowerShell command to change the Enabled bit are as follow, after the provider drive has been mounted as Site.

PS>cd Site:\User\Unfiltered
PS>Set-ItemProperty . –Name Enabled –Value False

Here the user policy Unfiltered is set to disabled. 

Where are my Object Assignments

This section has information on another subject that might be the source of some confusion in the new XenDesktop 7.0 group policy UI.

Some users might have noticed that the object assignment view of the policy wizard sometimes shows different entries. For example, in this view, only four object assignments are shown.

However, at other times, more assignments are displayed, as displayed in the following screen shot.

How to get the object assignments you want to display

The UI has done that for you. Each object assignment (filter) applies only to certain type of settings. If an assignment is applicable only to user settings, the assignment is not displayed in the list of available assignments if the settings you have picked are all computer settings. Assignments applicable to user settings are displayed only if there is at least one user setting picked in the previous screen.
Assignments applicable to computer settings are all applicable to user settings. They are always displayed.

Additional Resources

Alternatively try the Restore Policy Console utility for the process to run automatically for the administrator.

This software application is provided to you as is with no representations, warranties or conditions of any kind. You may use and distribute it at your own risk. CITRIX DISCLAIMS ALL WARRANTIES WHATSOEVER, EXPRESS, IMPLIED, WRITTEN, ORAL OR STATUTORY, INCLUDING WITHOUT LIMITATION WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, TITLE AND NONINFRINGEMENT. Without limiting the generality of the foregoing, you acknowledge and agree that: (a) the software application may exhibit errors, design flaws or other problems, possibly resulting in loss of data or damage to property; (b) it may not be possible to make the software application fully functional; and (c) Citrix may, without notice or liability to you, cease to make available the current version and/or any future versions of the software application. In no event should the software application be used to support ultra-hazardous activities, including but not limited to life support or blasting activities. NEITHER CITRIX NOR ITS AFFILIATES OR AGENTS WILL BE LIABLE, UNDER BREACH OF CONTRACT OR ANY OTHER THEORY OF LIABILITY, FOR ANY DAMAGES WHATSOEVER ARISING FROM USE OF THE SOFTWARE APPLICATION, INCLUDING WITHOUT LIMITATION DIRECT, SPECIAL, INCIDENTAL, PUNITIVE, CONSEQUENTIAL OR OTHER DAMAGES, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. You agree to indemnify and defend Citrix against any and all claims arising from your use, modification or distribution of the software application.

This article describes behind-the-scene changes in the group policy UI in XenDesktop 7.x Studio.