Blog posts tagged with 'active directory'

Provisioning Server offers you the ability maintain Active Directory machine account password synchronization for target devices. This ability is enabled on the Provisioning Server and is configured on a per virtual disk basis.
Private virtual disks do not need to maintain Active Directory machine account password synchronization, as they are a read write virtual disk, and have the ability to retain changes and store them to the virtual disk.
Standard virtual disks do need to maintain Active Directory machine account password synchronization, as they are read only, and do not have the ability to retain changes on the virtual disk.
There are some things to take into consideration when dealing with Provisioning Server and Active Directory Machine Account Password Synchronization for a successful implementation of this feature. The following are some guidelines and best practices to follow:


If the virtual disk image that is going to created is to be used by multiple target devices, in Standard Image mode, it is best practice, that before creating a virtual disk image, to run the Device Optimizer utility on the target device and apply the "Disable Machine Account Password Changes" setting If the virtual disk image that is going to created is to be only be used in Private Image mode and never Standard Image mode, the "Disable Machine Account Password Changes" setting does not need to be applied



When creating virtual disks that will ever be used as Standard virtual disks, it is best practice, to never create a target device that will have a device name of an existing machine account in Active Directory that is, has, or will ever be running off of local disks, and is ever going to be provisioned as a Standard Virtual Disk

When creating virtual disks, it is best practice, to ensure that the Active Directory setting for "Enable automatic password support" is configured on the Provisioning Servers

When creating virtual disks, it is best practice, to ensure that the "Enable Active Directory Machine Account Password Management" setting is configured on Standard Virtual Disks

Also, it is best practice to use an Active Directory Organizational Unit to manage machine accounts for target devices that will be provisioned, and that the Group Policy Object or Security Policy setting for the Organizational Unit is set to enable the "Disable Machine Account Password Changes" setting to disable Windows Active Directory automatic password re-negotiation.

And lastly, it is best practice to ensure that the Group Policy Object or Security policy setting for that Organizational Units "Maximum machine account password age" setting is compared to the Provisioning Server Active Directory setting for "Enable automatic password support" setting. The Provisioning Server Active Directory setting for "Enable automatic password support" number of days must be less than the Group Policy Object or Security policy setting for that Organizational Units "Maximum machine account password age" setting or you could end up in a scenario where the machine accounts would not able to log on to the domain due to this restriction being in place.

If you should ever encounter a situation where the active directoy machine passwords are out of sync, in provisioning server 4.x and below there is a command line utility for reseting machine accounts. In provisioning server 5.x this has been incorporated into the management console.

Following these best practices will help you keep synchronization between Active Directory Machine Accoutns and Provisioned Target Devices that are using a Standard Virtual Disk. With the use of Provisioning Server with XenServer and XenDesktop, these best practices are also applicable, as those technologies are also used to delivery devices that may need Active Directory Machine Account Password Synchronication.

Part 3 of Choosing an Automated Deployment Strategy for XenApp gives an overview of deploying XenApp via Active Directory.

If you have followed the discussions in the XenDesktop forums, or - even better - if you've tried the beta version of XenDesktop, you'll be aware that it integrates with Active Directory. Indeed, in particular the Desktop Delivery Controller (DDC - the component responsible for brokering end users to their virtual desktops) has a strong dependency on AD, and stores some data in AD that relates to security and determines how virtual desktops discover and communicate with desktop delivery controllers. Several questions have come up on this integration, and on what is actually stored in Active Directory. This post will show in more detail what's going on under the covers. Just a note of caution: the information in this post reflects the beta release of XenDesktop; however we're not expecting major changes in this area in the final release.

When you install a DDC server, an "AD set-up wizard" will start towards the end of the installation. When you install the first DDC in a farm, the wizard will ask you for the location of an OU, and will populate it with the data that XenDesktop needs to link up virtual desktops and DDCs, and to secure their communication paths. Whenever you install an additional DDC or remove one, the wizard will also start, and add or remove the DDC-specific information from that OU, although you won't typically see this, because it happens without the wizard GUI actually popping up. You can also run the wizard manually at any time, it's installed in the start menu on a DDC, and you can also run it from the command line (c:\program files\citrix\xendesktop server\adsetup.exe; use the 'rungui' option to start the GUI wizard).

When the wizard is running for the first time, it asks you to choose an OU for that farm, as shown in the previous screen shot. Every DDC farm needs a separate OU. The OU can be at an arbitrary level of a domain, and the OU does not need to contain the computer accounts for either the virtual desktops or the DDC servers (although it'd be best practice for the DDC servers to live in the farm's OU). If the user running the wizard has sufficient privileges, they can choose to create a new OU (tick the check box in the wizard). Alternatively, a domain administrator can pre-create an empty OU, and give the XenDesktop administrator running the wizard sufficient delegated privileges over that OU (you'll need 'create child' permissions). In that case, you should select that empty OU in the wizard by using the AD browser, as shown in the example above.

Now let's look at the data that shows up in the OU after the wizard has completed. The following screen shot shows that the OU contains one security group, one service connection point (SCP), and a container that contains another service connection point object:

The 'Controllers' security group is used by virtual desktops to ensure that only authorized DDCs that are members of the farm can broker and control connections (I'll explain how virtual desktops figure out where to find this security group in a moment). Whenever a DDC invokes one of the web services implemented by the virtual desktop, the VDA (Virtual Desktop Agent, the XenDesktop component that you install on a virtual desktop) will check that the caller is a member of this security group. When you add DDCs in the AD set-up wizard, as shown in the following screen shot, one of the things it does is to add the computer account for the DDC into this security group. Because the OS service that invokes web services on the VDA runs using the NetworkService predefined account on the DDC, the VDA will see incoming calls as using the DDC's computer account. You need to exercise caution in which computer accounts are made a member of this group, because all VDAs in your farm will trust these computers to control them.

Next, the farm's OU contains a 'Farm SCP'. This is an object that contains some markers in the keyword attribute, which define the enclosing OU to be a XenDesktop OU. The keywords include a couple of GUIDs as well as the name of the farm prefixed by XDFarm:, as shown in the following screen shot.

By virtue of being a marker, the farm SCP allows the VDA installer to present a list of farms that the virtual desktop can join: when the installer runs, it searches the global catalog for all SCPs that contain the XenDesktop GUID in their keywords, and lets the user select one of the farms. This results in a registry entry being written to the registry on the VDA, as shown in the following screen shot. The FarmGUID contains the AD GUID of the OU that contains the farm SCP chosen in the installer (i.e. the OU's objectGUID attribute). You can also set this after installing the VDA, and we'll provide a group policy template that you can use to set an equivalent registry entry through policies.

If you need to find this GUID, it's also displayed in the farm's read-only properties in the AMC, as shown below:

The final piece of information stored in the farm's OU lives in a separate 'RegistrationServices' container. This contains one SCP object per DDC in the farm, and the SCP object's name is the GUID of the computer object in AD that represents the DDC (in my example, my server called ddc.martinm.local is represented by the DDC$ object in the Computers container, and that object's objectGUID attribute contains the value 84d879b8-...). This is the second piece of data that the AD set-up wizard writes to the OU when a new DDC is added. The SCP again contains a number of GUIDs and other information in its keywords attribute that mark it as a XenDesktop server SCP; this is similar to the farm SCP. In addition, it also contains the URL and binding information of a 'registration' web service that runs on every DDC, and which VDAs use to register themselves with the farm. The AD set-up wizard creates the SCP for each DDC and gives each DDC write access to its SCP. Every time the DDC starts it validates that the information in the SCP is still accurate, and updates it if necessary (e.g. if you change the TCP port used by the DDC).

Using this information, a VDA on a virtual desktop gets linked into the farm as follows: the VDA starts up, reads the farm OU GUID from its registry. It then attempts to bind to AD through LDAP, and checks that the OU is indeed a valid XenDesktop farm OU (by checking the farm SCP). It then enumerates all registration service SCPs by querying AD for all SCPs with the right keywords (GUIDs), scoped by the farm's OU. Finally, it reads the registration web service address from the SCPs it finds. This way, it ends up with a list of web services that it can invoke to register with a farm. If the server it is registered with fails, it can simply pick another one.

Finally, here's a list of other AD-related information that's relevant for XenDesktop:

• You don't have to use the AD set-up wizard. If you want to, you can create all the objects in the farm's OU manually, e.g. through tools such as AD explorer. However, you should be careful to get the keywords in the SCPs right (all GUIDs are constant, but the farm name must be correct), and you need to be careful with who has permissions to change these objects, as mentioned above.
• While the farm OU, computer accounts, and user accounts can all live in different AD domains, all these domains must be in the same AD forest - VDAs and DDCs must be able to resolve each other's identity (Windows Communication Foundation uses Kerberos to authenticate machines), and of course end users must be able to log on. You must also run the AMC on a machine that is a member of a domain that is trusted by the AD domains containing the computer and user accounts (or run it with a user account that is trusted), otherwise it will not be able to resolve user and computer names and you'll end up with SIDs displayed instead. 
• XenDesktop supports all AD functional levels. However, if you're running in Windows 2000 mixed mode, restrictions on the scope of security groups mean that the farm OU and the DDC computer accounts must be in the same domain (as pointed out above, it'd be best practice to put the DDC computer accounts into the farm OU anyway).
• The names of the objects in the XenDesktop farm OU are hardcoded and cannot be changed. We have found that some AD environments have very strict policies as to where objects, in particular security groups, can be located and how they are named. If the 'Controllers' security group is not suitable in your environment, you can use an arbitrary security group located anywhere in your forest instead. To do this, you must create this group according to your AD policies, populate it with the computer accounts of the DDCs in your farm, and then set the following registry entry on all the VDAs in your farm: the key HLKM\Software\Citrix\ADConfig needs to contain a string value called ServersGroupGuid, and the contents of this value must match the objectGUID attribute of the custom security group (without curly brackets). You can also set this registry entry on the DDC servers, before installing the DDC software: if you do so, the AD set-up wizard will add and remove the DDC computer accounts from the right (i.e. your custom) security group automatically.
• For mutual machine authentication through Kerberos to work, the DDC and VDAs must be able to resolve each other's DNS names; also, Kerberos is quite picky and you'll encounter authentication errors if there's a significant clock skew between the machines (the default settings allow the clocks to drift by up to 5 minutes).
• If you run your virtual desktops as VMs and suspend them for prolonged periods of time, they may get out of sync with computer password changes made by the domain controller. There are a range of Microsoft KB articles on this topic which you may want to check out (be aware of the associated security risks, though). The good news here is that if you use Provisioning Server, it can take over AD computer account management for you, so you don't have to worry about this.

In my last post, I talked about our plans of moving XenApp farm settings, server settings and session policies into Group Policy Objects. This time, I want to describe our plans on a related topic: how to migrate XenApp 4.x farms into this new management model.
XenApp 4.5 Administrators have two options to migrate their farms: either upgrade the existing farm over time, running the farm in mixed-mode; or create a new farm and move users and applications over time. 
The mixed-farm approach seems to be the easier of the two, but it has an important drawback: the migration cannot be staged. The recommended first step is to upgrade the Zone Data Collectors, which in turn affects all users and applications in the farm. If anything wrong happens - which is usually detected once users start to login and use their applications - there is no way to rollback without creating a farm outage.
The new farm approach is safer, as it allows Administrators to perform an "in-production" validation, migrating users and applications to the new version over time. The old production farm is not touched, which allows quick rollback of users to the previous farm if anything wrong is detected.

However, creating a new farm from scratch is not realistic in many environments. The reasons:

• Farm configuration documents may not exist, or be out-dated.
• Not sufficient hardware to maintain both farms in parallel. Servers have to move from one farm to other over time.
• The migration is not transparent to end-users. If a single Web Interface is used, it will list applications as "Application (Old Farm)" and "Application (New Farm)". If a separated WI is used, then users must configure browser and PNA to use another URL.

We do not plan to support mixed-farm migrations when we move XenApp configuration to Group Policy. Instead, we will focus on the issues above, creating the necessary tools to facilitate the transfer of configurations, users and servers from farm to farm.
This is the plan:
The first step is to create a new farm, installing a new Data Collector and creating a new IMA database. Infrastructure servers (License, Database, Edgesight, etc) may be shared between the old and new farm. The next step is to launch the Migration Wizard and go through the following steps:

• The migration tool wizard will ask information about the old farm (address, authentication). You may chose to export all the old farm data into an XML file and modify it before importing the data in the next steps.
• The wizard will ask the new farm information. It will then convert session policies, farm and server settings into Group Policies, and automatically associate GPOs with the new farm Organizational Units.
• If the old farm contained multiple application silos, the wizard will ask for a server that represents the old farm silo, and create a Group Policy Object containing that server configuration. The wizard will then associate that GPO with the OU representing the Application Silo in the new farm configuration.
• You will be able to select a list of "in-production" test users. The new farm will only enumerate applications to users in that filter list, regardless of the Application object configuration.
• Add the new farm in your Web Interface sites. Web Interface will suppress enumeration of applications coming from multiple farms, based on configuration. This change will make the migration process completely transparent to end users.

At this point, you will have a fully configured, although empty new farm. Over time, you will:

• Add more users to the new farm filter
• Remove servers from the old farm
• Upgrade XenApp software in the server (or re-image)
• Assign the server to the new farm Organizational Unit.

This method is very flexible, you may stage the process based on application silos, zones, users, or any combination of these. The migration tools provided here are also very useful for other use-cases, such as replication of settings between test and production environments.

This plan is still on the drawing board, please feel free to comment and raise scenarios where you believe it wouldn't meet your needs. Note that this is planned for the next major release after project Delaware, therefore still a long way in the future.

Hello, this is my first post in this community, so let me start with a brief introduction: my name is Juliano Maldaner, a product architect on the Presentation Server team. One of the areas I'm working on is the simplification of Presentation Server management experience for upcoming releases. We're introducing some exciting new concepts and would like to hear your feedback!

Managing a Presentation Server farm requires much more than configuring Presentation Server components: Operating System and Application settings are as important. A successful environment must maintain PS, Operating System, and Application settings correctly configured and consistent across all servers in the farm. Maintaining this consistency throughout the farm life cycle is one of the major challenges for PS Administrators.

The Windows platform provides an outstanding tool to address these configuration management challenges: Active Directory and Group Policy. An overwhelming majority of PS deployments use Group Policy in some capacity. Integrating PS settings into GPO is possible with MFCOM scripts, but far from ideal. Most use GPO for Windows and Application settings, and Citrix management consoles for PS configuration. Because all settings must be synchronized, we realized that the management experience would be greatly simplified if PS Session Policies and Server settings were within Group Policy Objects themselves!

Presentation Server settings/policies embedded into Group Policy Editor

The main benefit of this integration is the creation a single management template for platform, applications and Citrix configuration. All operations performed with Group Policy Management Console will include Presentation Server parameters as well. Resulting Set of Policy reports will show all Citrix and platform configuration - a great help for troubleshooting and planning. Backup, Restore, and Migration will allow saving and moving configurations from farm to farm, making replication of environments much easier than what it is today.

Another key benefit is the separation of PS settings and servers. Group Policy Objects are associated with Organization Units, and not with individual servers or users. Common management operations - adding capacity to a silo; repurposing a server; or replacing a broken server - are greatly simplified: simply change the server OU membership, and the settings associated with that silo will automatically apply to the server.

Application Publishing 

The Group Policy integration will NOT require Active Directory schema changes. For this reason, PS objects such as Applications and Administrators will continue to be managed via Citrix management consoles. Application Publishing will be modified to allow association of Applications with Active Directory Server Groups and Organization Units. This way, apps will be automatically published as soon as the server is assigned to the correct Organizational Unit.

Policy Filters 

Presentation Server Group Policy extension will improve GPO filtering capabilities to include all filters existing on CPS 4.5 session policies - including SmartAccess. These filters will only apply to the Citrix part of the GPO, platform configuration will apply regardless of the filter result.

The Citrix policies within GPOs will also allow filtering on a per-setting level - native Group Policy only allow filtering per-policy level. Some Presentation Server features require complex filtered settings, for example: proximity printing based on client IP address. This feature will allow the configuration of such policies within a single GPO.

What about environments without Group Policy? 

There are some important scenarios where Group Policies cannot be used:

• Environments using other Directory services;
• Applications that require anonymous (local) accounts;
• Organizations that restrict or deny AD delegation to PS administrators.

To support these environments, IMA will provide a global Group Policy Object, applied to all servers in the farm. This farm-wide GPO replicates the existing Farm Default settings. Per-server override is possible by configuring the server's Local Group Policy Object.

Our goal is to maintain feature parity with PS 4.5 if Group Policy is not used. However, the Administrator's experience will be optimized for Active Directory and GPO scenarios.

Active Directory and Group Policy are fundamental for a successful Presentation Server environment. Group Policy integration will bring major improvements to management experience, leveraging existing IT infrastructure and knowledge. The feedback we've received so far has been very positive, please let us know what you think!