Analysis of VDA registration mechanism in Citrix XenDesktop to DDC

Just cut to the chase, what is a VDA? What is a DDC or something like that I don't have to do too much introduction.

It is well known that if a user needs to use a virtual desktop, the virtual desktop must be deployed in the DDC's delivery group and the virtual desktop delivered to the user, and the virtual desktop is registered in the DDC. Among these, the VDA registration process to the DDC is more fastidious.

The VDA registration is also known as the DDC discovery process, which refers to the process by which Vdas find the DDC and establish communication with the DDC through a specific mechanism.

In Citrix's XenDesktop, VDA registration or DDC discovery is primarily registered in 3 types:

• Soft/hard Registration

• Registry Base Registration

• AD Base Registration

First, Soft/hard registration (Soft/hard registration) mechanism

The softregistration (soft registration) mechanism first appeared in the XenDesktop3.0 version, with only one purpose, which was to resolve the issue of delayed registration. So what does this delay mean? If the engineer who understands the xendesktop operating mechanism knows that the VDA starts the service after booting, first obtains the IP address, and then the VDA's service finds the DDC and initiates a registration request based on the appropriate configuration information. If the VDA has not been added to the delivery group at this time (formerly called the Desktop Group), then it is clear that the VDA is not able to be registered and rightly rejected by the DDC. But when we add this VDA to the delivery Group? The registration of the VDA to the DDC will obviously be accepted by the DDC at this time. However, there is a delay in the situation. Since the VDA is rejected for initiating a registration request to the DDC, the registration request is re-initiated to the DDC at a well-designed point in time. In XenDesktop 3.0 and previous versions, the default is 10 minutes, which is changed to 5 minutes at xendesktop4.x to 5.x. This process is undoubtedly the process of delay. These few minutes are something that we cannot make manual changes to, and only wait for the next time-point VDA to initiate a registration request to the DDC. Citrix in order to be registered in the process, in this step to speed up the registration of waiting time, so the development of integrated such a soft registration mechanism. This mechanism allows the DDC to accept the registration behavior from the VDA as long as the VDA finds the DDC through configuration information and establishes the communication before joining the VDA to the desktop group or delivery group, but this registration behavior does not include all of the registration behavior, only part of the registration operation is complete. For example, the VDA configuration is not sent (XML) or status monitoring does not start, this registration state does not allow the session to start or manage the VDA session. Reveals this mechanism:

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/7C/A6/wKiom1bU6bDisR1TAACivR6iI60722.png "title=" 1.png " alt= "Wkiom1bu6bdisr1taacivr6ii60722.png"/>

, we can see that 03 of the VDA's status in studio is not displayed, but in the details below, we will find that the status of the registration is registered in this column.

So what is the hard registration mechanism?

The incentive for the soft registration mechanism to the hard registration mechanism is that the VDA is added to the desktop group or to the delivery group.

This time we add 03 this VDA to the desktop group or to the delivery Group, when we view the VDA in studio, its display status becomes registered, this is when all the registration information is registered, Citrix will this soft registration to the hard registration process called hard registration, That is, all registration information has been fully registered to the meaning.

So we said, with this soft registration mechanism, you can save the VDA to register the DDC time, but in fact, the benefits are more than this, with this soft registration mechanism, you can avoid unnecessary network traffic, that is, the VDA when the DDC application registration is rejected by the DDC, If we keep the VDA from being added to the desktop group, the VDA will always send a registration request to the DDC on a regular basis. At the same time, before this mechanism, the VDA application registration to the DDC is rejected, it is in the event log to leave the error log records, the soft registration mechanism of course also avoid this problem.

Second, Registry Base registration (registry registration) mechanism

The registry registration mechanism is the default method that the VDA registers with the DDC by locating the DDC through a specific registry key value for the VDA. The key value of this registry is that the DDC's Fqdn,vda need to resolve the DDC IP address and communicate with it through the DNS service. This key value is the FQDN of the DDC that we filled out when we installed the VDA.

The specific path and key values of its registry are as follows:

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M01/7C/A6/wKiom1bU6dvylqxsAAA-Dm2MBZs322.png "title=" 1.png " Width= "655" height= "212" border= "0" hspace= "0" vspace= "0" style= "width:655px;height:212px;" alt= " Wkiom1bu6dvylqxsaaa-dm2mbzs322.png "/>

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/7C/A4/wKioL1bU6mGAQ5j9AABEa8Ird2E574.png "title=" 2.png " alt= "Wkiol1bu6mgaq5j9aabea8ird2e574.png"/>

There are 2 places in the registry for this registry key, and the 64 system may differ.

The process by which the VDA registers with the DDC through the registry registration mechanism is as follows:

1, when the virtual machine starts the power, obtains the IP address, the above Citrix Desktop Service service starts;

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M02/7C/A6/wKiom1bU6mPA-uz3AAA0cspzS60437.png "title=" 1.png " alt= "Wkiom1bu6mpa-uz3aaa0cspzs60437.png"/>

2. Citrix Desktop Service first finds the local registry Hklm\software\policies\citrix\virtualdesktopagent\listofddcs and Hklm\software\ Citrix\virtualdesktopagent\listofddcs, query the registry Listofddcs key to get the address of the DDC. If there is no DDC address or query in this registry key value, the service will find the address of the DDC in the [Vdadata] key in the C:\Personality.ini file in the local file system, and the value of ' Listofddcs '.

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M00/7C/A6/wKiom1bU6guhSjaTAAAefRArcc8383.png "title=" 1.png " alt= "Wkiom1bu6guhsjataaaefrarcc8383.png"/>

3, the VDA to the Listofddcs key value, the same time to the ad to verify that the DDC FQDN is legitimate, after verification, ad will be legitimate DDC corresponding SID returned to Vda,vda according to the test results of AD, the final can be used to register the DDC FQDN, if there are multiple legal values, Randomly selects one of the DDC and invokes its IRegistrar interface to initiate a registration request. Communication between the VDA and the DDC service through WCF. After the VDA initiates a request package that attempts to register, it times out if it does not receive a response packet from the DDC. The VDA chooses between 7 and 10 seconds after the timeout to initiate a new registration request and attempt to register.

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M02/7C/A4/wKioL1bU6uuBXdXEAACJLLYEfR0749.png "title=" 1.png " Width= "682" height= "177" border= "0" hspace= "0" vspace= "0" style= "WIDTH:682PX;HEIGHT:177PX;" alt= " Wkiol1bu6uubxdxeaacjllyefr0749.png "/>

4. After the DDC receives the VDA's registration request, it first verifies to the ad that the FQDN of the VDA is legitimate. After validation passes, AD returns the SID-corresponding SIDS to the DDC,DDC with the VDA machine to complete mutual trust. The DDC Brokerservice then accepts or rejects the registration request and returns the notification to the VDA.

5. If the VDA registration fails and then waits for a timeout, the VDA repeats the process indefinitely until the registration succeeds.

6, if the registration is successful, registration information (such as WIN7-POOLED01 and XD01 registration ) to update the point of arrival database.

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/7C/A4/wKioL1bU67XRUbXUAACd58Fo668838.png "title=" 1.png " Width= "653" height= "175" border= "0" hspace= "0" vspace= "0" style= "width:653px;height:175px;" alt= " Wkiol1bu67xrubxuaacd58fo668838.png "/>

7. Once the registration is complete, the VDA will receive a notification from the broker service registration success. The notification also includes a heartbeat value for maintaining the DDC connection to the VDA. (The default heartbeat value is 30 seconds)

8. After the VDA receives these notifications, it starts using the ' ping ' packet to the DDC to detect the connection heartbeat. The DDC will assume that the VDA is turned off if the DDC does not receive a ' ping ' packet from the VDA after 30 seconds, by keeping the heartbeat between the two sides to confirm that the other is alive.

9. The failure of the heartbeat means that the VDA is closed, and the DDC cancels the registration of the VDA and cleans up the information in the site database.

10. If the DDC fails, the DDC will not be able to reply to the VDA's ping package. The ' ping ' package is an API call that returns a value, so the return value will be present from each ping package on the ddc-> VDA. If the DDC is closed, the WCF framework will not function and its API calls will not work. In the case of a single DDC, such a scenario is sufficient to trigger the VDA to restart the entire registration process again. Because we need to build 2 DDC in the production environment to ensure high availability. Each VDA actually registers with the DDC to register only one of the DDC, and there is no case where a VDA simultaneously registers with 2 DDC. Therefore, in this case, the clustered DDC does not trigger the VDA to restart the entire registration process again, while on the second DDC the Vdas are in a soft-registration state, but the heartbeat between the DDC clusters detects the first DDC and shuts down, The live DDC will upgrade all of the VDA's soft registrations to hard-to-register, that is to take over the VDA, and I feel like these are working mechanisms similar to the two stored controllers?

11. If the VDA is not registered with the DDC for the first time, then the broker service of the DDC checks to the database whether the VDA belongs to the desktop group: The DDC checks if the VDA is owned by a desktop group belonging to its own site, and the database Returns query information. If it belongs to a desktop group or delivery group, the configuration is issued, the DDC is issued a policy configuration to the VDA, which includes configuration information such as site, delivery Group, etc. At the same time, the broker service update site under each DDC updates the virtual machine registration status to "ready".

Third, ad base registration (AD registration) mechanism

The ad enrollment mechanism differs from the local computer registry registration form, which differs from the relationship of the Working Group domain in Windows. To have the VDA use the AD registration mechanism to initiate a registration request to the DDC, we need to make the following configuration:

1. You must first run PS Scriptset-adcontrollerdiscovery on the DDC in the XD management site, the script on the installation path%programfiles%\citrix\broker\service\ Under the setupscripts. Use the Set-adcontrollerdiscovery script to identify the ad object using the ad DN (distinguished name). For example: Set-adcontrollerdiscovery–on–existingoudn "ou=xd56ddcs,dc=readiness, Dc=apac"

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M01/7C/A6/wKiom1bU6qKTKQa9AAAye15U2fg622.png "title=" 1.png " Width= "677" height= "145" border= "0" hspace= "0" vspace= "0" style= "width:677px;height:145px;" alt= " Wkiom1bu6qktkqa9aaaye15u2fg622.png "/>

1. The script creates ad objects (OU,SCP, etc.) that are required for all specified OUs in AD. Thus the SCP (Service connection point), each containing the information, including the DDC FQDN, which will be used by the VDA to discover the DDC. When you run the PS script, we need to restart all the DDC services so that the VDA Installation Wizard can discover the XD site.

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/7C/A6/wKiom1bU6siwH96KAAB2_Ya889w734.png "title=" 1.png " alt= "Wkiom1bu6siwh96kaab2_ya889w734.png"/>

650) this.width=650; "src=" Http://s3.51cto.com/wyfs02/M01/7C/A4/wKioL1bU60iSZBxxAAAaEal5XhY282.png "title=" 1.png " alt= "Wkiol1bu60iszbxxaaaaeal5xhy282.png"/>

1. Then run the VDA Setup Wizard, when choosing the DDC address, is now from AD, allowing you to select the XD site from the drop-down list.

650) this.width=650; "src=" Http://s5.51cto.com/wyfs02/M02/7C/A4/wKioL1bU61zAJ540AAGOjZNn_d8846.png "title=" 1.png " alt= "Wkiol1bu61zaj540aagojznn_d8846.png"/>

1. The wizard creates a Farmguid value in the VDA that is used to invoke the recognition xd site. The registry key-value path exists in the Hklm\software\citrix\virtualdesktopagent\farmguid

650) this.width=650; "src=" Http://s4.51cto.com/wyfs02/M00/7C/A4/wKioL1bU627zJYy8AADOQeBH2c4772.png "title=" 1.png " Width= "634" height= "178" border= "0" hspace= "0" vspace= "0" style= "width:634px;height:178px;" alt= " Wkiol1bu627zjyy8aadoqebh2c4772.png "/>

After using the above steps to establish an ad-based environment, the ad-based registration mechanism, the process by which the VDA registers with the DDC through the ad registration mechanism, is as follows:

1, when the virtual machine starts the power, obtains the IP address, the above Citrix Desktop Service service starts;

2. It finds local registry hklm\software\policies\citrix\virtualdesktopagent\farmguid and Hklm\software\citrix\virtualdesktopagent\ Farmguid to get information.

3. The VDA connects to the AD domain controller to verify that the Farmguid is valid and has a list of SCP (service connection points) that exist in the OU ad. The respective information contained in the SCP, including the FQDN with the DDC.

650) this.width=650; "src=" Http://s2.51cto.com/wyfs02/M00/7C/A6/wKiom1bU6xWRdZooAABMbhYAZcM609.png "title=" 1.png " alt= "Wkiom1bu6xwrdzooaabmbhyazcm609.png"/>

1. The VDA randomly chooses one from the list of DDC to initiate the registration. There is no difference between the subsequent procedure and the registry registration process I described above, so I will not be repeating it here.

Now, let's take a look at some of the key steps in the registration process

Service connection point (Serviceconnection Points) released, see Microsoft Official website for details:

http://msdn.microsoft.com/en-us/library/ms677638 (v=vs.85). aspx

The Active directory schema defines the ServiceConnectionPoint (SCP) object class to make it easy for a service to publish data for a particular service in the catalog. The client of the service uses data in the SCP to locate, connect, and validate an instance of the service.

More details about the SCP object:

http://msdn.microsoft.com/en-us/library/bb427286 (v=vs.85). aspx

VDA More instructions for registering a DDC cluster:

In XenDesktop 5.5 and later versions, virtual desktop proxies can be configured to register in a subset of the DDC and allow the DDC FQDN to be grouped by the Listofddcs registry value. The sessions between the two sets of DDC clusters are facilitated by another subset of the DDC (i.e., XML broker). For example, if a VDA should be registered as DDC1 or DDC2, which needs to be filled in the registry value, but DDC3 and DDC4 are XML brokers, the registry key value is so filled in hkey_local_machine\software\ WOW6432NODE\CITRIX\VIRTUALDESKTOPAGENT-REG_SZ: "Listofddcs" = "(DDC1.local.domain DDC2.local.domain) ( DDC3.local.domain DDC4.local.domain) "

In this configuration, the DDC in the first group is used for VDA registration, unless all DDC in the group is not available, then the VDA attempts to register to the second set of XML broker for use.

If the XML broker is in a different domain environment, listofsids can be used to specify the SID of the trusted XML broker and use a space-delimited list. If a DDC SID is added to Listofsids, all Xmlbroker SIDs must also be added to the list. For example, if you want to use Ddc.domaina to enlist, use DDC.DOMAINB as the XML BROKER,DDC. DomainA should be in Listofddcs, two DDC domain SID should be added to the listofsids Registry

(HKLM\SOFTWARE\WOW6432NODE\CITRIX\VIRTUALDESKTOPAGENTREG_SZ listofsids = "Sid space-delimited list of domains")

If you are interested in this, you can refer to http://support.citrix.com/article/CTX132536.

The end!

This article is from "I take fleeting chaos" blog, please be sure to keep this source http://tasnrh.blog.51cto.com/4141731/1746194

Analysis of VDA registration mechanism in Citrix XenDesktop to DDC