XenDesktopSetupWizard запускаем с правами не DomainAdminа

XDSetupWizard запущенный под юзером с правами Domain User(прав DomainAdmin нет) но полными правами на Citrix OU (даже owner) завершается аварийно без предупреждения на этапе работы с AD.

Если разрешим запись лога через файл настроек C:\Program Files\Citrix\XenDesktop Setup Wizard\SetupToolApplication.exe.config, то в логе увидим:

INF:(8/14/2009 11:22:22 AM):Target device New6 successfully added to domain.

…

INF:(8/14/2009 11:22:22 AM):Making Directory entry for LDAP://CN=New6,OU=Citrix,DC=testlab,DC=ctx

ERR:(8/14/2009 11:22:23 AM):Error setting properties on AD computer account

Message = System.UnauthorizedAccessException

General access denied error

…

at Citrix.ManagementAPI.Infrastructure.AD.ADManager.SetPropertiesOnDirEntry(String compAccName, String compOuPath, String compLocation, Boolean provisioned)

Если разрешим directory access audit в политиках контроллера домена и разрешим аудит отказов на нашем Citrix OU в АД то чз EventViewer зафиксируем:

Event Type: Failure Audit

Event Source: Security

Event Category: Directory Service Access

Event ID: 566

Object Operation:

Object Server: DS

Operation Type: Object Access

Object Type: computer

Object Name: CN=New6,OU=Citrix,DC=testlab,DC=ctx

...

Accesses: Write Property

Properties:

...

Additional Info:

Additional Info2:

Access Mask: 0x20

Т.е. не хватает прав на запись атрибутов. Дело в том, что АД имеет специальный флаг у атрибутов объектов, которые могут скрывать их для чтения всеми, кроме DomainAdmins, это своего рода фильтр в дополнение к стандартному механизму прав на чтение. Описано сдесь:

http://support.microsoft.com/kb/922836

http://blogs.dirteam.com/blogs/tomek/archive/2005/11/21/confidential-bit.aspx

Это явный косяк XDSetupWizard, поытка читать/писать confidential attribute и не перехватывать неуспех попытки чз exeptions. Решить проблему можно следующим образом:

1. На КД запустить Ldp.exe tool и обязательно только из Windows Server 2003 R2 диска Active Directory Application Mode (папка CMPNENTS\R2\PACKAGES\ADAM\I386\ADAM). Другой lpd не годится.

2.Connection-Connect-localhost

3.Bind - под аккаунтом Domain Admin

4. View-Tree. В Tree найти свою Citrix OU - правый клик - Advanced- Security Descriptor

5.бязательно отметить SACL

6.нажимаем AddACE

7.пишем имя нашего обрезанного админа CitrixOU, в примере - adminvdi

8. отмечаем все дополнительные маски доступа

9. Ok и Update

Перезапускаем визард. 100% заработает) Удачи!

XenDesktopSetupWizard 3.0 не может получить список vDiskов с PVS5.1

Привет все.
Может случиться такой косяк, что XenDesktopSetupWizard 3.0 не может получить список vDiskов с PVS5.1 и выдает на этом этапе ошибку недоступности сайтов PVS.

Это случается потому, что по умолчанию PVS5.1 настроен на TCP порт 54321, а XenDesktopSetupWizard 3.0 по умолчанию обращается к порту 8000. Нужно менять одно из двух. Проще всего сменить настройки PVS через Provisioning Services Configuration Vizard.

Кроме этого, надо тогда правильно настроить потом и Provisioning Services Console на порт 8000.

Удачи!

настоящая причина неработоспособности 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.
Успехов!