Merging Policies Why??

Till xenapp/xendesktop 7.X, we had user policy pane and computer policy pane. We have applied policies to users and computers separately. But from xa/xd 7.X citrix has introduced merging policies so that we dont have to identify which policy should be applied to whom. This merging is done in the new studio UI that combines user and computer settings.

Earlier citrix admins had to decide whether or not a policy should be applied to user or computer. But with this new UI, we dont have to decide user or computer policy. Directly choose settings you need, and apply to delivery groups.

Are policies completely merged?

Backend policy data remains same. It is only the interface in studio that merges policies and shows as one identity. User and computer types are also maintained. Merging of user and computer policies are done in 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. This is done to maintain backward compatibility. This is important because citrix admins can upgrade their citrix version to 7.X, without changing the database.

How does this new UI detect any conflicts?

In order to merge policies(a user policy and computer policy), both should have same name. Merging only happens when UI code identifies if these two policies can be managed correctly in studio. If it identifies any conflicts, it fails. UI code does two things: detect inconsistency everytime it reads policies from database, and need to decide what to do on them.

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

Merge Settings:

To merge two policies(a user policy and a computer policy), their names should be same(case-insensitive). If their names are different, UI treats them as new policies and doesn’t merge them. Policy description can me merged too, even though descriptions are different. When descriptions are merged, a prefix is added as “computer settings” followed by computer policy description  and “user settings” followed by user policy description. Both policies should be enabled.

Priorities in older environment doesn’t matter as they are just an order in which policies apply. So, user policy and computer policy has different priorities in previous environment, it doesn’t cause an impact on this merge.

Merge object assignments:

While policy settings and names generally are the easier to detect and merge the assignments are most difficult in determining if two policies can be merged because the data that makes up an assignment can be complex. 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. We have 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.

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 and the problem needs fix. We have to determine what need to be done on these policies that have a conflict.

When you see an inconsistency in policies, you would see similar message in your policies console:

Fixing inconsistencies:

Citrix left this option to admins who perform this upgrade. It is upto you to decide whether to delete the policy or rename it so that the xa/xd 7.X UI feels that they are two different policies and let them stay. User intervention is needed 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 needed and inconsistencies are detected by the Studio UI, a message like what is shown above is displayed.

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 using powershell. Remember, in powershell, policy data is still the same, as users and computers.

Best way to fix these inconsistencies is, to rename the policy. 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. Sample posh commands to rename policy:

Add-PSSnapin Citrix.Common.GroupPolicy New-PSDrive Site –PSProvider CitrixGroupPolicy –Root \ -Controller localhost cd Site:\User ren Policy0 Policy0-User

Change localhost to controller name if you are running these commands from non-controller machine. 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’s 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 we cannot rename this policy. We are lucky that Unfiltered policies don’t have filters. So 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.

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

Here the user policy Unfiltered is set to disabled.

Object Assignments:

Some users may 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:

But at other times, more assignments are displayed, like the view below:

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.

What to do if I receive error “Changes made to policies outside of this console, such as Powershell or management tools from previous versions, resulted in a discrepancy between policies”.

If you still have any questions on how to recover from above error, use restore policy utility given at: https://support.citrix.com/article/CTX213722

You can also go ahead and delete the policy that is causing this issue by following the steps given at: https://support.citrix.com/article/CTX139764