Menu
Find below my Desktop Director RES AM Runbook. Once you import the Building Blocks you will be able to have Desktop Director 2.1 up and running within 15 minutes.
Thanks to Kees Baggerman for testing this for me.
Download res_am_runbook_desktop_director
The Runbook complete the following tasks
Add IIS Role and all required Role Services to a server
Install Desktop Director 2.0, 2.1, & 2.1.1 (x86 or x64)
Configure XenApp and XenDesktop controllers, SSL, timeout, and subsystem model
Enable Dashboard View for helpdesk group on XD Controllers
Configure WinRM on VDI Team or Template (x86 or x64)
Install WinRM hotfix on XenApp
Configure WinRM on XenApp Team
Configure group with PVD Reset permission on VDI
All required software included so you do not need to download anything else.
Below is a screenshot of the Jobs in the Runbook.
And here are the parameters. In most instances you can use the same group for a lot of the parameters (E.G HelpdeskGroup, WinRMSecurityGroup) . Some environments require granular control, this is why I have split them out.
If you are only using XenDesktop or only using XenApp enter a zero (0) in the ….Team parameter of the component you are not using; this will cause the Runbook to skip that job. RES Automation Manager does not allow you to leave blank parameters that define who a job will run on, this is why you must enter a zero (0). Other paramaters can just be left blank.
E.G If you are only using XenApp enter a zero (0) in VDITeam and XenDesktopControllerTeam.
I have explained each parameter in the Runbook but I will outline their functions below for clarity.
DesktopDirectorSSLCheck – Setting to Off will prevent Desktop Director from checking for an SSL certificate and prevent an error on the logon screen. If you are using an SSL cert set this to on
DesktopDirectorTimeOut – Sets the time in minutes that the Desktop Director website will time-out due to inactivity.
WinRM Model Type – Trusted subsystem model uses the Desktop Director server AD computer account to connect to the end points, Impersonation Model uses the AD user account currently logged on to the Desktop Director website to connect to the end points.
DesktopDirectorServers – This is the server or servers on which IIS role will be added and the Desktop Director components and website will be installed.
XenAppController – Enter the hostname of the XenApp controller that Desktop Director will talk to. Only one controller per farm can be used
Domain – The domain in which your user accounts reside. This is used to permission Desktop Director functions
HelpdeskGroup – The group that is permissioned with Helpdesk role in XenDesktop and will be given the Desktop Director dashboard view.
VDITeam – If you are using Existing VDI model enter the team name of your VDIs, if you are using pooled desktops enter the hostname of your VDI master template
XenAppTeam – Enter the name of the team containing your XenApp session-host servers. The Desktop Director HDX hotfix will be installed and WinRM configured on these servers
WinRMSecurityGroup – This is the group used to connect to the endpoints to collect HDX information via WinRM. Place either your user accounts or Desktop Director server computer accounts in an AD group and specify the group in this parameter See WinRM Model Type
PvDResetGroup – This group will be configured with rights to reset Personal vDisks on the VDAs.
DesktopDirectorHelpdeskDashBoard – Enable or disable the dashboard view for XenDesktop helpdesk administrators
XenDesktopControllerTeam – Enter the name of the team containing your XenDesktop controllers. The PowerShell command to enable dashboard view for XenDesktop helpdesk administrators will be executed on these servers (if you choose for it to be enabled)
XenDesktopController – Enter the hostname of the XenDesktop controller that Desktop Director will talk to. Only one controller per farm can be used
Please leave any comments below.
If you are only using XenDesktop or only using XenApp then place a zero (0) in the paramters that are required for the component you are not using. I had to do it this way due to the limitations of RES AM requiring paramaters that define who a job will run on not be left blank . Placing a zero (0) in the paramter causes the job to be skipped and not fail the Runbook.