While user profiles allow users to customize the settings of their own environments, policies allow you (the administrator) to force settings in your users' environments. Policies (and their mandatory configuration settings) can be applied to servers globally, affecting all users that logon, or conditionally, affecting only specific users that logon. This conditional application can be based on user accounts or group memberships.
There are two types of user policies: Microsoft Windows user policies and Citrix MetaFrame user policies. Conceptually, these two types of policies work in the same way. Windows user policies allow you to control Windows-related settings, and Citrix user policies allow you to control Citrix-related settings.
Windows User Policies
Before we look at the details of how Microsoft Windows policies work, it's important to understand the differences between policies and user profiles.
Differences between Windows User Policies and Profiles
Both policies and user profiles affect registry settings. A user profile contains registry settings (in the ntuser.dat file) that are used to create the user's unique HKEY_CURRENT_USER registry hive when they log on. Policies also contain registry settings. They dictate which values are allowed or not allowed in the HKEY_CURRENT_USER registry hive as its being created from the user profile. Policies can also affect computer-wide HKEY_LOCAL_MACHINE settings, which are applied as the computer is booted before any users log on.
Application settings and configurations that are maintained in the registry can be set with either a user profile or a policy. If there is a conflict, the policy setting will take precedence over the user profile setting.
For example, a user might configure their desktop background to be bright red. Doing this would set the bright red color value in a desktop settings registry key in the user's HKEY_CURRENT_USER registry hive. This updated value would become part of the user's profile, taking effect at every logon. At any time, the user could decide to change the desktop background color.
However, if you wanted to force the user's desktop to be a specific color, then you would apply a policy. The policy would affect the exact same value in the same registry location as when the user set it (in their profile), except that the policy could not be changed by the user. That's all policies really are-an administrator's way to force settings onto users.
Of course, you don't generally use policies to set the desktop color in Windows. You would use policies to set elements that affect how the users use the system such as Start menu items, file save locations, search options, and local drive access.
- User Profile: Applied to a user; Policy: Applied to a computer, group, or user
- User Profile: Only one per user; Policy: Many can be layered per user
- User Profile: Settings are the user's choice; Policy: Settings are the administrator's choice
- User Profile: Affects the user's registry hive; Policy: Affects the user's or server's registry hive
- User Profile: Registry settings, folders, files; Policy: Registry settings only
Figure 5.6: Differences between profiles and policies
People often wonder whether they should use profiles or policies to manage the user environment. In the real world, the two are meant to complement each other and are used together. Situations are rare where one is used to the exclusion of the other.
Creating and Editing Windows Policies
Policies are created and edited in different ways, depending on what type of policy you are working with.
Windows NT 4.0-compatible policies, which can be applied to Windows NT 4.0 and Windows 2000 servers as well as Windows NT 4.0 domains, are created and edited with the System Policy Editor (poledit.exe). Windows 2000 policies, configured as part of the Active Directory, are edited with the Group Policy snap-in for the Microsoft Management Console (gpedit.msc).
Since policies are no more than a collection of registry keys and values, these policy editing tools are merely graphical interfaces that allow you to set registry values. These registry values can then be directly applied to the local server or saved as policy files.
Whether you're using Windows NT or Windows 2000, you'll need at least one ADM policy template file in order to create a policy. ADM files contain all of the policy settings and options, as well as the corresponding registry keys and values needed to create a policy. ADM template files are added as plug-ins to the policy editing utilities. Without any ADM template files plugged-in, the policy editing tools are useless, kind of like the MMC without any snap-ins. Once the ADM files are plugged-in to the policy editing utility, you can point-and-click your way through the configuration of policies.
ADM policy templates are simply text files with the ".adm" extension, such as winnt.adm or common.adm. The policy editors for both Windows NT and Windows 2000 come with several ADM files plugged-in out of the box. These default ADM files let you configure policies for several Windows options. However, if you have other applications installed, such as Microsoft Word, you'll probably want to extend your policy editor to include Microsoft Word options. This is because the default ADM templates only cover Windows options. You can't use them to configure any Microsoft Word options.
In order to create policies that include Microsoft Word options, you would need to obtain a Microsoft Word ADM policy template file. There are hundreds of Microsoft Word templates available. You can download the "official" ones from Microsoft's web site. (They are included as part of the Office Resource Kit.) As soon as you add the Microsoft Word ADM template to your policy editing utility, you will instantly see options for configuring Microsoft Word settings. For example with Microsoft Word, these policy settings include paths to office assistants, the ability to disable certain features, and menu options.
You will need to find (or create) ADM policy templates for all the applications that you want to regulate with policies. Check out the THIN list at http://thethin.net for a great collection of ADM policy templates.
Really, ADM policy template files are nothing more than cool interfaces that give you a graphical way to set and force desktop and application settings onto users.
Citrix User Policies
One of the new features included with Feature Release 2 for MetaFrame XP is "Citrix User Policies." Citrix User Policies are similar to Windows user policies, except that Citrix user policies only contain Citrix-specific information. You configure Citrix user policies via the CMC, and you can apply them to groups or users. You can create multiple policies and set relative priorities, allowing you to create an extremely granular environment. Citrix user policies are the "killer app" of Feature Release 2. They make the Feature Release 2 upgrade worth paying for.
There are dozens of different configuration options that you can specify within Citrix policies, including client device settings, drives, printers, ports, limiting concurrent logon sessions (with XPa or XPe), shadowing, and encryption. Basically, Citrix user policies allow you to turn on or off any Citrix setting on a per-user or a per-group basis. The policies are then stored in the IMA data store.
The nice thing about Citrix user policies is that they apply to the user session itself, and so are enforced no matter what type of client or connection each user is using. In fact, Citrix user policies override all settings that are configured in other places, including the CMC-configured properties of a server or farm.
Refer to the chart in Appendix C of this book for a listing of all the MetaFrame XP configuration options (including policies) and where they can be set.
Creating Citrix User Policies
Creating a Citrix user policy is a two-step procedure. First, you need to create the policy itself. This is where you specify its name and configure the policy rules for it, such as enabling client drive mappings, disabling LPT port mapping, etc.
Every Citrix user policy contains dozens of policy rules, and you can set each individual policy rule to be "Enabled," "Disabled," or "Not Configured." Let's look at an example to understand what each setting means. If you create a Citrix user policy and set the client drive mapping policy rule to be enabled (by highlighting "Client Drive Mapping" in the left pane and selecting the "Rule Enabled" radio button in the right pane), then all users or groups who have that policy applied will have client drive mapping enabled. Similarly, if you set the policy rule to "Rule Disabled," then all users or groups who have that particular policy applied will find that client drive mappings are disabled.
The "Rule Not Configured" option is the default setting for all policy rules in new policies. This option indicates that this rule is not set to "Enabled" or "Disabled," allowing it to be configured by another policy. In our example, configuring the client drive mapping rule for "Rule Not Configured" would mean that the policy would not affect client drive mappings, allowing us to set the options for client drive mappings as part of the server's connection properties, or as part of another policy applied to different people. In the real world, you use the "Not Configured" policy option whenever a Citrix policy option is going to be configured somewhere outside of the policy.
Applying Citrix User Policies
Once you create and configure a Citrix user policy, it doesn't affect anything until you apply it to users or groups. You can literally have hundreds of Citrix policies listed in the CMC that don't affect anything if you don't apply them to anyone.
You can create as many Citrix user policies as you want. In fact, large server farms might have dozens of policies. Applying Citrix policies to users or groups is pretty straightforward (CMC | Policies | Right-click on the Policy | Assign Users).
Citrix user policies get interesting when you have users that are affected by multiple policies. For example, you might decide to create one policy called "Farm Users" and apply it to your "Domain Users" group so that it affects everyone who logs on to your servers. You would use this "Farm Users" policy to configure all your MetaFrame configuration options.
Then, you might decide to create a second policy called "Remote Users" and apply it to users who dial-in to your MetaFrame environment. You could use this policy to turn off bandwidth-intensive features, such as client drive mapping.
However, if you do this a user logging on to your MetaFrame XP server from home would have two Citrix policies applied-the "Farm Users" policy applied to their domain group, and the "Remote Users" policy applied to their user account. On the surface, this may seem fine, but what happens if there is a conflict between settings from policy to policy? What happens, for example, if the "Farm Users" policy is configured to enable sound, but the "Remote Users" policy applied to the user is configured to disable sound?
You might think that "standard" Windows rules apply here and that the most restrictive policy settings would win out. However, policies don't work like that. When you configure multiple policies in a server farm, you need to "rank" the policies in order of precedence.
Every Citrix user policy in your server farm has a rank. A policy's rank (or "priority") is a unique integer that directly affects the order in which it is applied. The first policy that you create has a priority of "1." The next policy you create has a priority of "2," and so on.
Whenever a user logs on that has more than one policy applied (via their user account and any groups that they belong to), the system resolves any conflicting policy settings by using the setting from the policy with the higher priority. (Remember that with Citrix user policies, a smaller priority number equates to a higher priority. The policy whose priority is set to "1" has the highest preference, and so on.)
You can change the priority of any policy at any time via the CMC (CMC | Right click on the policy name | Priority). One interesting quirk about the CMC is that by default, the CMC displays the list of the farm's Citrix user policies in "list" mode. As with anything in the CMC, "list" mode shows the policy names only. It does not indicate their priorities. Even worse, the CMC lists the policies in alphabetical order, not priority order. This means that the policy order you see may not be the order in which they are applied.
To effectively work with Citrix user policies in the CMC, you need to change the CMC's view to "details" mode (CMC | View Menu | Details). This mode will show the policy's name, priority, status, and description. Once you switch the view to details mode, you can click the "priority" column header in the CMC to sort the list of the policies in the order that they will be applied.
As you start to apply multiple policies, you will begin to appreciate the "Rule Not Configured" policy option, since this option does not affect the policy rule one way or the other. While the "Enabled" setting will force that option to be enabled and the "Disabled" setting will force that option to be disabled, the "Not Configured" setting causes the policy processor to ignore that option-allowing it to be applied with a different policy (or with a different method altogether, such as a Citrix connection option).
Managing Citrix User Policies
Once you create more than a few Citrix user policies, they will become hard to manage. The main challenge is that when you have several policies applied to different users and groups, it can be hard to figure out the "effective" policies that are applied to single users. This comes from the fact that a single user account could have multiple policies in effect for it, depending on the groups that the user belongs to and the policies that affect those groups.
The easiest way to find all the policies that affect a single user is to use the CMC's "search" capabilities (New with SP-2). Right-click on the "Policies" item in the left-hand pane, and then click "Search" from the little menu that pops up. You can then search for policies that apply to a specific user or group.
Whenever you perform a search, your search results will include all policies that apply to the user or group you searched for. The results will also contain an additional policy called "Resultant Policy" with a priority of "0." You can double-click this "Resultant Policy" to see the effective policy rules that will be applied to the user or group that you searched. Basically, this Resultant Policy is like a query result that sorts through the policy rules and priorities of all policies that apply to the user or group you searched for, and then displays the specific policy rules and configurations that will actually apply. Since the Resultant Policy is not a "real" policy, you cannot change any policy options when you view it.
If you ever run into problems when using Citrix user policies, the Resultant Policy is an excellent troubleshooting tool. It can help you figure out what's really happening, especially if you have many policies.
Another technique that's useful when troubleshooting policies is to disable certain policies. At any time, you can disable a policy via the CMC (CMC | Right-click on the Policy | Disable). Disabling a policy causes it not to be applied as users log on, although the policy is still listed in the CMC.
If you're doing a lot of troubleshooting with policies in the CMC, remember that each MetaFrame XP server in the farm needs to receive the updated policy information from the IMA data store before you can successfully test new policy settings. Some people make a policy change and then instantly log on to a server to test that change. Then they curse when their change did not work, when in fact they just didn't wait long enough for the server that they tested on to receive that change. (Remember that any time you change anything in the CMC, the CMC writes the change to the IMA data store, and each server's local host cache must receive the new information from the data store.)
An easy way to ensure that a MetaFrame XP server has received the change from the IMA data store is to use Windows Explorer to view the timestamp of the local host cache. (The local host cache was discussed in Chapter 3.) By default, the local host cache is %systemroot%\Program Files\Citrix \Independent Management Architecture\imalhc.mdb. Most people keep one session logged on to the MetaFrame server with an Explorer window open to the path. Then they make their policy change within the CMC. As soon as the timestamp of the local host cache file changes to the current time, they log in via another session to test the policy.
Advantages of Citrix User Policies
- Because they are applied at the server level, they apply no matter what type of client is connecting.
- Multiple policies and be layered and ranked to create customized environments.
- They provide an easy way to configure and control MetaFrame options.
Disadvantages of Citrix User Policies
- Feature Release 2 is required.
Why should you care about user policy design?
Now that you understand the basics or how user policies work, you can see that there are two reasons that you need to think about user policy design on your system:
- Policies affect your users' ability to customize their own environment.
- Policies affect the security of your system.
Users' Ability to Customize Their Environment
If policies are too restrictive, then users will not be able to do their jobs or to fully use the system. If policies are not restrictive enough, security and integrity of the MetaFrame XP system will be affected. Users may be able to use unauthorized programs or even worse, they may be able to access configuration and system administration areas of the server that affect everyone.
User profiles and policies will directly affect the options and settings users see in their MetaFrame XP sessions. Properly designed policies will allow them to use the servers without risk of the users changing inappropriate settings or accessing unwanted areas.
Shane Broomhall, a Citrix instructor, says it best:
Most likely, you have a certain user in your environment with a copy of "MCSE for Complete Brain-Dead Idiots in 24 Hours" on his desk. This person is the really dangerous one. The one with a little knowledge and even less common sense. The one who (just by reading one thing) can completely break his desktop computer. From your perspective, if this person has broken his desktop by playing around with it (because it was not locked down) it's no big deal, because he has only really affected himself. However, now that you're using MetaFrame XP, when this user does the same thing with a MetaFrame XP desktop that has not been locked down properly, he's affecting potentially hundreds of other users. It is this user that forces us to spend time designing policies and profiles.
What are the user policy design options?
When it comes down to actually designing your policies, you have a few options depending on your platform.
What type of NT 4.0 policies will you use?
If your MetaFrame servers are running Terminal Server 4.0, you can create and apply policies in three different ways:
- Local computer policy.
- Domain-wide policy.
- Manual, computer-based policy.
Windows NT 4.0 policies are configured with System Policy Editor, available in the administrative tools or from the command line (poledit.exe). Policy Editor has the ability to open two types of policies:
- The local registry.
- Policies saved as files with the ".pol" extension.
NT 4.0 Local Computer Policies
You can edit the policy of the local server by opening its registry from within the System Policy Editor (File | Open Registry). Editing the policy in this way produces the same result as if you manually edited the registry. Most people choose to use the System Policy Editor because it is easier than editing the registry. With Policy Editor, you don't have to know where anything is or what the options are. Just find what you want to change and check the box.
While editing the local registry of a server will work, most people choose not to because it must be manually done on each server.
Advantages of Local Computer Policies
- Simple to apply.
- Easy to change.
- Works well for single-server environments.
- Allows each server to have unique policy settings.
Disadvantages of Local Computer Policies
- Must be manually configured at every server.
- Do not scale very well.
There are two ways that NT 4.0 policies can be applied to more than one computer. The first allows you to create a policy that is applied to all computers in the entire domain.
NT 4.0 Domain-Wide Policies
Instead of manually editing the registry of every MetaFrame XP server in your environment with System Policy Editor, you can create a single policy applied to an entire domain. To do this:
- Use System Policy Editor to create the settings and configurations you want. This can include entries for multiple computers, groups, or users.
- Save the policy as a file called "ntconfig.pol."
- Copy ntconfig.pol to the domain controller with the master Netlogon$ share (repl$ share).
- Directory replication between the domain controllers' Netlogon$ share will ensure that this policy file is updated on all domain controllers. There is no additional configuration that must be done.
You'll have many users, groups, and computers that will all require unique policy settings within your domain. Users and groups may have unique HKEY_CURRENT_USER settings, and Terminal Servers may have unique HKEY_LOCAL_MACHINE settings. Fortunately, you can add different policy settings that apply to different users, groups, and computers-all within a single ntconfig.pol file. From within the System Policy Editor (as in step one above), click the Add User, Add Group, or Add Computer button to add a specific user, group, or server that does not get the Default User or Default Computer policy settings. (There are more details in the System Policy Editor's help menu.) If you decide to create custom policies for users, you should first create a policy for the "administrator" that is excluded from other policies that you create. This is important because it is very easy to "accidentally" create a policy that locks everyone out of important system functions, including the administrator.
By specifying unique policy settings for your MetaFrame XP servers in a domain policy file, you can create restrictive computer policies that only apply to the MetaFrame XP servers in your domain.
One of the downsides to creating policies that affect the entire domain is the fact the users log onto MetaFrame XP servers with the same accounts they use at their local workstations. Because of this, it's not possible to create user-level policies that apply on some computers and not others. All computers on the domain will get the same ntconfig.pol policy file from the domain controllers.
Additionally, because only one policy file can exist for the entire domain, that policy will become quite large as it fills with dozens of computer, user, and group settings. Anytime the policy is applied, the target computer will need to sort through the entire policy, looking for entries that apply to it. If users or groups are specified in the policy, the computer must sort through the policy when they log on, increasing logon time and network utilization.
Advantages of Creating NT 4 Domain-Wide Policies
- Simple to create and implement.
- Easy to maintain, since only one file needs to be updated for the entire domain.
- Multiple computer, user, and group entries can exist in the single policy file.
Disadvantages of Creating NT 4 Domain-Wide Policies
- Complex policies can take a long time to be applied.
- Large policies could increase logon time for users.
- "All or nothing" approach. There is no way to allow the policy to apply to users when they log into some computers but not others.
NT 4.0 Manual Computer-Based Policies
Instead of applying a single policy to an entire domain, it is possible to create a policy that is only applied to selected computers. This will allow you to have different policies for different computers.
In order to do this:
- Use System Policy Editor to create the settings and configurations you want.
- Save the policy as a file with any name.
- Copy the policy file to a location where it can be accessed by the computers you want to apply it to.
- Each computer that you want to use the policy file must be configured for it. To do this, you must edit the registry of each computer. (See the procedure below.)
Even though you must manually configure each computer to access the policy file, you can change the policy for all the configured computers simply by updating the policy file. (Open it in Policy Editor, make the changes, save the policy file.)
Advantages of Creating Manual Computer-Based Policies
- Different policies can be applied to different computers.
- These "localized" policy files are usually smaller than domain-wide policy files.
- Local files allow fast policy application.
Disadvantages of Creating Manual Computer-Based Policies
- Increased management effort.
Procedure for Creating Manual Computer-Based Policies
After you create your policy file with the System Policy Editor, you need to edit the registry of the MetaFrame XP server to tell it to use the new policy file. You can do this manually via the registry or by using the System Policy Editor to edit the local registry.
When you specify the location of the policy file, you can use the %LogonServer% variable in your UNC path. Using this will prevent you from having a single point of failure as long as you copy the policy file to the same location on all of your domain controllers. You can use the Netlogon$ share's directory replication for this. Just name your policy something other than ntconfig.pol, so that your policy is not accidentally applied to all computers.
Data: 0 = no policy. 1 = automatic policy from domain controller. 2 = manually specify the location of the policy file (via the data in the "NetworkPath" value.)
Data: UNC or local network path to the policy file.
System Policy Editor Location
Policy Editor | Open Registry | Local Computer | Network | System Policies Update. Check the "Remote Update" box. Set the update mode to "Manual." Enter the UNC path to the policy file.
What type of Windows 2000 Policies will you use?
The manner in which policies are applied in Windows 2000 environments is different from Windows NT 4.0 environments. Policy techniques outlined in the Windows NT 4 section are still applicable for Windows 2000 servers, allowing for backwards-compatibility in mixed environments. However, if you have Windows 2000 MetaFrame XP servers, you'll probably find the Windows 2000-specific policies more flexible and easier to apply.
As with Windows NT 4 policies, Windows 2000 policy application varies, depending on what you want the policies to affect. There are two different types of Windows 2000 policies:
- Local computer policies.
- Group Policy Objects.
Windows 2000 Local Computer Policies
Local computer policies are a fancy way of saying "the local registry settings" of a Windows 2000 computer. They are applied with the Group Policy MMC snap-in (gpedit.msc). By default, there is no shortcut for this procedure. You can launch the Group Policy snap-in manually (Start | Run | gpedit.msc). Just as in Windows NT 4.0, changing settings in the local computer policy sets registry values on the local server. After you are done changing policy settings, you can simply close the Group Policy editor. Nothing needs saved because the Group Policy editor, in this case, is in direct connection with the local computer's registry. The downside to editing the registry directly with Group Policy editor is that any policy settings you change will only apply to the local computer.
Advantages of Local Computer Policies
- Simple to apply.
- Easy to change.
- Works well for single-server environments.
- Allows each server to have unique policy settings.
Disadvantages of Local Computer Policies
- Must be manually configured at every server.
- Does not scale very well.
Windows 2000 Group Policies
If your MetaFrame XP servers belong to an Active Directory domain, policy application becomes very flexible (and very cool). In Active Directory environments, policies are stored in the directory as "Group Policy Objects." A Group Policy Object (GPO) is a single policy file containing policy settings for users and computers. GPOs are stored in the directory itself, and there is no limit to the number that can be stored. Once they are created and stored in the directory, GPOs are applied to Active Directory Sites, Domains, or Organizational Units. The policies defined within the GPO apply to whatever objects (such as users and computers) are in the container where they are applied.
Such policy architecture allows you to create extremely flexible policies. For example, you can put all of your MetaFrame XP servers into one Organizational Unit (OU). You can then create a locked-down Group Policy Object and apply it to the OU, effectively securing your MetaFrame XP servers while not restricting user access to other systems not part of that OU.
Because Group Policy Objects can be applied at multiple levels, (sites, domains, and organizational units), designs can become complex very quickly when you apply different GPOs at different levels to the same objects.
The details of Active Directory GPO design will not be covered in this book. If you plan to make heavy use of them, there are several excellent white papers on Microsoft's website that explain how they are applied and how settings are inherited between levels. The important thing to realize is that GPOs are often used with great success in MetaFrame environments.
Advantages of Group Policy
- Extremely flexible.
- Granular application.
- Easy to apply.
- The best policy solution in existence (so far).
Disadvantages of Group Policy
- Requires Active Directory.
- Multiple policies can be difficult to maintain and troubleshoot.
How will you apply policies? (All platforms)
When applying policies, there are several design decisions that you will have to make regardless of whether your MetaFrame XP servers are running Windows NT 4.0 or Windows 2000. To make these decisions, you must answer the following questions:
- Where will the policy files be stored for manual computer-based policies?
- What settings will you configure in the policy?
Typically, you would only use manual policy files if you do not have Active Directory and do not want to create one large domain-wide policy. Manual policies are technically NT 4.0-specific, but they can be used on Windows 2000 servers as well.
If you decide to use manual computer-based policies, you must decide where the policy files will be located. (This is the file that the computer will access when it is booted.) You have two choices for the location of this policy file:
- One file locally on every server.
- A central policy file, accessible to every server via a network connection.
By storing a policy file locally on every MetaFrame XP server where it is to be applied, you can rest assured that the policy will always be applied quickly and efficiently. The only downside is that if you make a change to the policy, you will need to copy that new policy file to every server where it is used. (Of course, this copying can be scripted with little effort.)
Advantages of Storing Policy Files on Individual Terminal Servers
- Fast access to policy files.
- Fast logons.
- Policy will always be applied.
Disadvantages of Storing Policy Files on Individual Terminal Servers
- Policies can be difficult to update.
- There is a chance that the policy files could get out of sync, with different versions on different servers.
Alternately, some administrators choose to keep the policy files in a centralized location. Often there may be a dozen or more policy files in one location, with each file unique for different groups of servers. Every server that has the policy applied connects to the central location and downloads the policy when it is booted. This method allows you to easily update policy files, with MetaFrame XP servers automatically receiving the new policy when they are rebooted.
Advantages of Storing Policy Files in Central Locations
- Only one file has to be updated each time the policy changes.
Disadvantages of Storing Policy Files in Central Locations
- Policy files must be acquired via the network every time the server is booted.
- If the master policy location is not available, the server will not receive a policy.
What settings will you configure in the policy?
There are literally hundreds of options that can be configured with policies. (The options are almost endless with the availability of plug-in ADM policy template files.) It is important to consider the various choices before starting to actually build your policies. You don't want to have to make decisions about policy options on the fly. Many policy options affect more than one component, so an uninformed policy setting can have adverse consequences.
When deciding what aspects should be locked down with a policy, remember that roaming profiles will retain user settings from one session to the next. In general, you should only use policies to specify settings that you want to force upon the users. Settings that the users should be able to customize are better left to user profiles.
Things to Consider when Designing User Policies
Now that you know what your user policy options are, you can begin to design your policies. As you design them, consider the following:
- Will users run full desktops or just published applications?
- How important is security?
- Which MetaFrame XP Feature Release are you using?
If users are running full desktops on your MetaFrame servers then it's important that you lock down those desktops with policies. On the other hand, if users only run published applications then you don't need to worry as much about policies.
The tighter you lock down your policies, the more secure your environment will be. Of course, this will also lead to more restrictive, less flexible environments. See Chapter 15 for the full details about securing your MetaFrame XP environment.
Feature Release Level
Citrix user policies are extremely useful and convenient, except that they require Feature Release 2.