Citrix 7.6 Administer profiles within and across OUs

Administer profiles within and across OUs

Updated: 2013-07-31

Within OUs

You can control how Profile management administers profiles within an Organizational Unit (OU). In Windows Server 2008 environments, use Windows Management Instrumentation (WMI) filtering to restrict the .adm or .admx file to a subset of computers in the OU. WMI filtering is a capability of Group Policy Management Console with Service Pack 1 (GPMC with SP1). For more information on WMI filtering, see http://technet.microsoft.com/en-us/library/cc779036(WS.10).aspx andhttp://technet.microsoft.com/en-us/library/cc758471(WS.10).aspx. For more information on GPMC with SP1, see http://www.microsoft.com/DOWNLOADS/details.aspx?FamilyID=0a6d4c24-8cbd-4b35-9272-dd3cbfc81887&displaylang=en.

The following methods let you manage computers with different OSs using a single Group Policy Object (GPO) in a single OU. Each method is a different approach to defining the path to the user store:

  • Hard-coded strings
  • Profile management variables
  • System environment variables

Hard-coded strings specify a location that contains computers of just one type. This allows profiles from those computers to be uniquely identified by Profile management. For example, if you have an OU containing only Windows 7 computers, you might specify serverprofiles$%USERNAME%.%USERDOMAIN%Windows7 in Path to user store. In this example, the Windows7 folder is hard-coded. Hard-coded strings do not require any setup on the computers that run the Profile Management Service.

Profile management variables are the preferred method because they can be combined flexibly to uniquely identify computers and do not require any setup. For example, if you have an OU containing Windows 7 and Windows 8 profiles running on operating systems of different bitness, you might specify serverprofiles$%USERNAME%.%USERDOMAIN%!CTX_OSNAME!!CTX_OSBITNESS! in Path to user store. In this example, the two Profile management variables might resolve to the folders Win7x86 (containing the profiles running on the Windows 7 32-bit operating system) and Win8x64 (containing the profiles running on the Windows 8 64-bit operating system). For more information on Profile management variables, see Profile Management Policies.

System environment variables require some configuration; they must be set up on each computer that runs the Profile Management Service. Where Profile management variables are not suitable, consider incorporating system environment variables into the path to the user store as follows.

On each computer, set up a system environment variable called %ProfVer%. (User environment variables are not supported.) Then, set the path to the user store as:

upmserverupmshare%username%.%userdomain%%ProfVer%

For example, set the value for %ProfVer% to Win7 for your Windows 7 32-bit computers and Win7x64 for your Windows 7 64-bit computers. For Windows Server 2008 32-bit and 64-bit computers, use 2k8 and 2k8x64 respectively. Setting these values manually on many computers is time-consuming, but if you use Provisioning Services, you only have to add the variable to your base image.

An example of how to script this is at:

http://forums.citrix.com/thread.jspa?threadID=241243&tstart=0

This sample script includes lines for Windows Server 2000, which is unsupported by Profile management.

Tip: In Windows Server 2008 R2 and Windows Server 2012, you can speed up the creation and application of environment variables using Group Policy; in Group Policy Management Editor, click Computer Configuration > Preferences >Windows Settings > Environment, and then Action > New > Environment Variable.

Across OUs

You can control how Profile management administers profiles across OUs. Depending on your OU hierarchy and GPO inheritance, you can separate into one GPO a common set of Profile management policies that apply to multiple OUs. For example, Path to user store and Enable Profile management must be applied to all OUs, so you might store these separately in a dedicated GPO, enabling only these policies there (and leaving them unconfigured in all other GPOs).

You can also use a dedicated GPO to override inherited policies. For information on GPO inheritance, see the Microsoft Web site.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s