настоящая причина неработоспособности XenDesktop VDAgentа

Если Вы устанавливали VDI-инфраструктуру XenDesktop, то наверняка сталкивались с проблемой, когда VDAgent не регистрируется на Desktop Delivery Controllerе. И Вы пробовали все варианты, описанные в статье CTX117248 .Вариантов там немного, IP-стек, DNS, UID фермы в реестре виртуального десктопа, синхронизация времени. Эти причины быстро выявляются и убираются, более того, возникновение этих причин маловероятно в принципе, если все делаешь по шагам инструкции.
Главный, и главное - недокументированный косяк в том, что Provisioning Server управляет аккаунтами таргет_девайсов(они же вируал_десктопы) в Active Directory, и если , введя темплейтный вируал_десктоп в домен, используя private_mode виртуального диска ( а как же иначе это сделать), Вы вдруг обнаруживаете, что вируал_десктоп перестал входить в домен из-за ошибки
Event ID: 4
Source: Kerbeors
Type: Error
"The kerberos client received a KRB_AP_ERR_MODIFIED error from the server host/myserver.domain.com. This indicates that the password used to encrypt the kerberos service ticket is different than that on the target server. Commonly, this is due to identically named machine accounts in the target realm (domain.com), and the client realm. Please contact your system administrator."
это следствие того, что вируал_десктоп имеет 2(два) CSID в AD, соответствующие его имени. Лечится эта ситуация просто. Нужно УДАЛИТЬ(не СБРОСИТЬ) аккаунт вируал_десктопа в AD и затем воссоздать его же через ProvisioningServicesConsole правым кликом на таргет_девайсе. Таргет_девайс после перезагрузки залогинется в домене, а вируал_десктоп 100% зарегистрится на DDC.
Успехов!