In order to trouble shoot this, we need to turn logging on for Director. So you try with a HelpDesk account and it fails: ![]() ![]() Now that you have WinRM configured, Director installed, you login and it works. The new version of ConfigRemoteMgmt.exe doesn't seem to just 'stack' the new version on top. If you run the command with a single GUID it all gets reset:Ĭ:\Windows\system32\cmd.exe /c ""C:\Windows\system32\winrm.cmd" set winrm/config/service now you can execute the ConfigRemoteMgmt.exe command again. If you have an output similar to this, then you have a problem:įortunately, it's a super easy fix. "C:\Windows\system32\winrm.cmd" get winrm/config/service To check your WinRM Root SDDL, execute this command: Eventually, this causes WinRM to fail and it will just hang at this point: The bug in a pervious version of this tool is that it would add another GUID, even if one already existed. The ConfigRemoteMgmt.exe takes your object and converts it to a GUID and then sets the SDDL using the native Windows tools. The part I bolded is the GUID of the object you pass in the /configwinrmuser. You see, ConfigRemoteMgmt.exe is also a front end to " C:\Windows\system32\winrm.cmd". With an older version of ConfigRemoteMgmt.exe this was an incorrect assumption and our WinRM SDDL became so large that the command line that ConfigRemoteMgmt.exe generates for winrm.cmd breaks the command line. We didn't include checking, we just assumed if a group was added it would not be added again. We implemented a script to update our WinRM so all of our XenApp servers would have the user configured. It has been revised as time has gone on and numerous bug fixes have been implemented. ![]() For XenApp/XenDesktop 7.7 the version that comes with it is: In a command prompt run:ġ8) Configure WinRM with the appropriate permissions:ĬonfigRemoteMgmt.exe /configwinrmuser HEALTHY\DesktopDirector.TST /allĮnsure you use the latest version you can find. No reboot is needed, it takes effect immediately.ġ7) Enable WinRM on each XenApp server. On EACH XenApp server, install the Director WMI Provider (DirectorWMIProvider_圆4.msi for 64bit OS's and DirectorWMIProvider_x86.msi for 32bit OS's). If you are not setting up certificates on the server for SSL, you can disable the SSL verification by changing the UI.EnableSslCheck to false. Select the Director site under Default Web Site and double-click on ‘ Application Settings’įor ‘ Name’ enter ‘ Service.AutoDiscoveryAddressesXA’ and for value put the IP of the local ZDC server Without entering any information, select ‘ Next’ It's just incredi-bad.Įnter Citrix Director 7.6 7.7 lots of promises to overcome the failings of the previous version.įirst, installing Citrix Director 7.7 for XenApp 6.5:ġ) Launch the AutoRun (AutoSelect.exe) installation fileĪgree to the licensing agreement and click ‘ Next’ Enumerating any sort of information on DesktopDirector is horribly slow. Our environment is purely XenApp 6.5 (at the moment).įor version 2.1, logins are incredibly slow. We have Citrix DesktopDirector 2.1 currently live in our environment. ![]() Although vastly inferior to ControlUp, it is free.īut it's not without poor documentation and its own tales of woe. It's a monitoring tool that provides help desk or other type of technicians with data on what's going on in user sessions (when referring to XenApp). Citrix has 'replaced' Edgesight with a new tool called Citrix DesktopDirector.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |