Author Archives trententtye

ConvertFrom-MCLI for PVS 7.6 POSH module

2016-04-06
/ /
in Blog
/

Martin Zugec made a POSH script to convert output from mcli.exe to a PowerShell object, but his script fails with the new PVS 7.6 POSH module.  From looking at his script he is trying to key on ‘spaces’ to set the properties of the objects.  MCLI.exe outputs the properties with spaces.  PVS 7.6 POSH module fails because it doesn’t format it’s output as spaces.

MCLI.EXE output:

POSH module output:

Notice the subtle difference? No spaces.

To get Martin’s original script working we need to change the script to look for another character we can key on. Fortunately(?) it *appears* that the PVS POSH module outputs properties to start with a lower case letter. If we modify his script here:

To this:

It now outputs properties correctly from the PVS POSH module:

The full modified script is here:

 

Read More

Citrix Provisioning Services – Updating VMWare Tools and Target Device software — with all native tools

2016-04-05
/ /
in Blog
/
  1. Prerequistes

Step
Detail
2 servers:
  1. Staging server with Windows 2008 R2 SP1
  2. VMWare machine configured identically to your PVS target devices (BLD server)
‘Windows Server Backup’ feature installed on the staging server
The Citrix utility ‘CVHDMOUNT.EXE’ is installed on the staging server
‘Backup’ space (approx. 100GB)
VMWare VMDK hard disk of a greater size than the PVS disk:
<

 

Copy and install required drivers on staging server

 

Step
Detail
From a Windows Server, browse to a server with Citrix Provisioning Services installed on it.

 

Copy the drivers folder and CVhdMount.exe to the server

 

Open the drivers folder, right-click on cfsdep2.inf and select “Install”

 

Open Device Manager, right-click the computer name and choose “Add Legacy Hardware…”
Select “Next”
Select “Install the hardware that I manually select from a list (Advanced)” and click “Next”
Click “Next”
Click “Have Disk…”
Click “Browse” and go to the “drivers” folder and select “cvhdbusp6.inf” and click “Open”
Click “OK”
Ensure “Citrix Virtual Hard Disk Enumerator PVS” is listed and click “Next”
Click “Finish”

 

Setup VMWare virtual disk

Step
Detail
Open the “VMWare vSphere Client”

 

Right-click on the server you want to do the cloning on and click ‘Edit Settings…’
Under the ‘Hardware’ tab, click ‘Add…’
Select ‘Hard Disk’ and click ‘Next’
Select ‘Create a new virtual disk’ and click ‘Next’

 

Set the ‘Disk Size’ to be greater than the size of the VHD file, select the ‘Disk Provisioning’ options you require, select the ‘Location’ you want to store the disk and remember where it is stored.  You will need this location soon.  Click ‘Next’
Click ‘Next’
Click ‘OK’
Format the disk and set it as active

 

  1. Clone VHD to VMDK

      1. Backup Citrix vDisk

Step
Detail
RDP into the staging server and mount the VHD file you want to update:
Cvhdmount.exe –p 1 \serversharevDisks-XenAppXenApp65Tn01.13.avhd

 

Open Disk Management and confirm your Citrix VHD is mounted and the new VMWare disk is present

 

Open ‘Windows Server Backup’
Click ‘Backup Once…’
Select ‘Different options’ then ‘Next’
Select ‘Custom’ than ‘Next’
Select ‘Add Items’
Select the PVS disk and click ‘OK’
Click ‘Next’
Select ‘Local drives’ and click ‘Next’
Select the ‘Backup Destination’ and click ‘Next’
Click ‘Backup’
Wait for the backup to complete
Click ‘Close’

 

      1. Recover backup to VMDK

Step
Detail
Click ‘Recover’
Select ‘This server’ and click ‘Next’
Click ‘Next’
Select ‘’Volumes’ and click ‘Next’
Select the checkbox beside the volume and choose the ‘VMDK’ for the destination volume and click ‘Next’
Click ‘Yes’
Click ‘Recover’
Wait for the Recovery to finish
Click ‘Close’

 

      1. Fix BCD file for VMDK

Step
Detail
Unmount the Citrix vDisk.  Cvhdmount -U 0
In the command prompt, switch to the ‘Destination’ drive and check the BCD file:

 

Notice there are 3 entries that need to be corrected.
Execute the following commands, substituting the ‘E:’ for the proper drive letter:

 

bcdedit /store bcd /set {bootmgr} device partition=E:
bcdedit /store bcd /set {default} device partition=E:
bcdedit /store bcd /set {default} osdevice partition=E:

 

Confirm the BCD file now contains the correct entries:

 

      1. Configure BLD Virtual Machine and attach the VMDK

Step
Detail
Open the vCenter console, select the staging server and ‘Right-click’ and select ‘Edit Settings…’
Select the VMDK file, note the path of the Disk File and click ‘Remove’
Under ‘Removal Options’ select ‘Remove form virtual machine’ and click ‘OK’
Select the associated BLD server of this vDisk and right-click and select ‘Edit Settings…’  In this example, the vDisk I am modifying is XenApp65Tn01 which is associated with BLD server WSCTXBLD351T
Click ‘Add…’
Select ‘Hard Disk’ and click ‘Next’
Select ‘Use an existing virtual disk’ and click ‘Next’
Select ‘Browse’
Navigate to the path noted earlier, select the disk and click ‘Open’
Click ‘Next’
Click ‘Next’
Click ‘Finish’
Click ‘OK’
      1. Disable CDROM attachment on bootup

Step
Detail
Select the associated BLD server of this vDisk and right-click and select ‘Edit Settings…’  In this example, the vDisk I am modifying is XenApp65Tn01 which is associated with BLD server WSCTXBLD351T
Select the ‘CD/DVD drive 1’ and ‘Uncheck’ the ‘Connect at power on’ and click OK

 

Start the VM and uninstall the target device software

Step
Detail
Right-click on the VM and select “Power > Power On”
Right-click on the VM and select “Open Console”
Login to the VM once it boots
Click “Start”
Click “Control Panel”
Click “Program and Features”
Click on the “Citrix Provisioning Services Target Device x64”
Right-click and choose “Uninstall”
Click “Yes”
Click “OK”
Wait for the uninstall to complete then restart the computer

 

Upgrade VMWare Tools

Step
Detail
Login to the VM once it boots
Browse to the VMWare Tools install and open ‘setup64.exe’

 

Select ‘Next’
Select ‘Custom’ and click ‘Next’
Ensure the ‘NSX’ options are set to ‘Entire feature will be unavailable’ and click ‘Next’
Select ‘Close the applications and attempt to restart them’ and click ‘OK’
Click ‘Finish’
Click ‘Yes’ to restart

 

Install new Citrix Provisioning Services Target Device software

 

Step
Detail
Login to the VM once it boots
Browse to the share that holds the updated software and open ‘PVS_Device_x64.exe’
Click ‘Install’
Click “Next”
Select ‘Acknowledged’ and click ‘Next’
Choose “I accept the terms in the license agreement” and click “Next”
Click “Next”
Click “Next”
Select ‘Complete’ and click ‘Next’
Click “Install”
Uncheck “Launch Imaging Wizard” and click “Finish”
Click “Yes” To restart the computer.
      1. Remove VMWare Disk from BLD server

Step
Detail
Right-click the VM and select ‘Edit Settings…’
Select the VMDK disk, note the ‘Disk File’ path and click ‘Remove’
Ensure ‘Remove from virtual machine’ is selected and click ‘OK’
Select the CD/DVD Drive and check the ‘Connect at power on’ box and click ‘OK’

 

  1. Clone VMDK to VHD

      1. Backup VMWare Disk

Step
Detail
Right-click on the staging server and select ‘Edit Settings…’
Select ‘Add…’
Select ‘Hard Disk’ and click ‘Next’
Select ‘Use an existing virtual disk’ and click ‘Next’
Click ‘Browse’ and select the disk you noted earlier
Click OK
Click ‘Next’
Click ‘Next’
Click ‘Finish’
Click ‘OK’
RDP into the staging server, browse the backup drive and delete the contents of ‘WindowsImageBackup’

 

Open Disk Management and confirm your VMDK is mounted

 

Right-click on the VMDK and select ‘Shrink Volume…’
Enter a number to shrink the partition so it is *smaller* then your Citrix VHD disk size

 

NOTE If you do NOT shrink the partition you will be unable to restore the partition to the smaller Citrix VHD file.
Confirm the shrink worked successfully
Open ‘Windows Server Backup’
Click ‘Backup Once…’
Select ‘Different options’ then ‘Next’
Select ‘Custom’ than ‘Next’
Select ‘Add Items’
Select the VMDK disk and click ‘OK’
Click ‘Next’
Select ‘Local drives’ and click ‘Next’
Select the ‘Backup Destination’ and click ‘Next’
Click ‘Backup’
Wait for the backup to complete
Click ‘Close’
Go to the vCenter console and Right-click on the staging server and select ‘Edit Settings…’
Select the VMDK used for updating VMWare Tools/Target Device software ‘’ and click ‘Remove’
Select ‘Remove from virtual machine and delete files from disk’

 

      1. Recover backup to VMDK

Step
Detail
RDP into the staging server and mount the VHD file you want to update:
Cvhdmount.exe –p 1 \serversharevDisks-XenAppXenApp65Tn01.13.avhd

 

Open ‘Windows Server Backup’
Click ‘Recover’
Select ‘This server’ and click ‘Next’
Click ‘Next’
Select ‘’Volumes’ and click ‘Next’
Select the checkbox beside the volume and choose the ‘Citrix vDisk’ for the destination volume and click ‘Next’
Click ‘Yes’
Click ‘Recover’
Wait for the Recovery to finish
Click ‘Close’

 

      1. Fix BCD file for PVS vDisk

Step
Detail
In the command prompt, switch to the ‘Destination’ drive and check the BCD file:

 

Notice there are 3 entries that need to be corrected.
Execute the following commands, substituting the ‘E:’ for the proper drive letter:

 

bcdedit /store bcd /set {bootmgr} device partition=E:
bcdedit /store bcd /set {default} device partition=E:
bcdedit /store bcd /set {default} osdevice partition=E:

 

Confirm the BCD file now contains the correct entries:

This process could be scripted to make it less manual, faster, and less error prone, but because of the frequency we actually do these type of updates, I have just created a manual document for now.

Read More

AppV5 – Package {GUID} version {GUID} failed configuration in folder ‘%packageinstallationroot% with error 0x4C40310C-0x12

2016-03-30
/ /
in Blog
/

We experienced this error on a package on one of our Citrix servers in the AppVClientAdmin event logs.  Attempting to procmon this error didn’t reveal anything substantial for what could be causing this issue.  I then tried my last post to enable AppV debug logs to see if we can see what’s going on.

Because this server was being used by other users the log generated a lot of noise.  I stopped the log as soon as I got the error message though, which meant the error should be at the end of the generated log.  Fortunately, you can search for the error message:

[2]06B0.2DE4::‎2016‎-‎03‎-‎30 09:41:30.817 [Microsoft-AppV-Client]Package {499ed340-c809-47dc-a533-2cdeab537e93} version {3589c28b-edb7-41d6-865d-e01c4fdd4318} failed configuration in folder ‘D:AppVDataPackageInstallationRoot’ with error 0x4C40310C-0x12. 

I suspect the first bit of hexadecimal code (06B0.2DE4) are probably an identifier for a thread or some such so I suspect if I search for just this code I can be shown all events that lead up to this error:

Looks like it.

The log up to the error:

With the error time code, I can compare what Procmon says is going on.  And procmon reports back the following (at exactly 09:41:30.815):

Procmon has the AppVClient.exe doing the following action “QuerySecurityFile” and it’s looking for “Information:Owner”.  So what is this the value of this property?

Hmmm…  This does not look correct to me.  From my experience, I think the current owner ends up being ‘SYSTEM’ because that’s the account the AppVClient.exe runs under when it creates this folder.  As a hunch, I looked at a system that is operating correctly and compared it’s Owner attribute:

Sure enough, on a working system the Owner is SYSTEM.  So I’ll attempt to modify the non-working system and retry adding the package:

Success!  So it appears this error “0x4C40310C-0x12″ is DIRECTLY related to the ownership attribute on your PackageInstallationRoot folder.  If it is anything but SYSTEM it looks like it fails.  I do not know why that attribute changed, but changing it back to SYSTEM resolves this error code.

Read More

AppV5 – The trouble with AppV5 logs (and a solution!)

2016-03-24
/ /
in Blog
/

AppV5 introduced to us a slew of logs that made troubleshooting more difficult than it should have been.

For instance, say you get an error message:

How do you start debugging this?  Well, you could start by trying to decipher the error message AppV has generated to a decimal value that you can then look at the first two digits to determine which ‘part’ of AppV generated the error and you can examine that specific log.  Sounds kind of ridiculous when you spell it out.

Another thing you could do is you could enable all logs just to be sure, but then you have to sift through the logs to find the time stamp that corresponds closest to the event that generated the message.  Sometimes it would be too far or close together or the debug logs generate so much information that your event viewer is just one big blob of ‘the exact same time’.

One of these could be the cause of my issue.  Going through them all is extremely cumbersome.

Of course this isn’t true that all these events are the same time, but it’s all event viewer can display.  If you view the XML of the event you can see there is more precise time stamps, but regardless, trying to compare each event with other logs is cumbersome and very difficult.

Is there a better way?

Yes!  There is!  And Microsoft has actually documented it here:
https://support.microsoft.com/en-us/kb/3037955

This is a powershell script that generates a ETL file on your desktop then converts it to a text format.  The script is:

What does the output look like?

First thing to notice is that it’s sorted chronologically, so if you can get a narrow time range to examine the error occurring it should be easier to spot.  Second thing is all event logs are added, and events themselves are included as they are generated.  So it should be easier to finding that specific component that causes the error.

If you are encountering AppV5 errors, this may be easier to help track down the error then trying to sift through the debug logs in event viewer.

Read More

AppV5 – Package fails to load with error 0x79100E100-0xC (Starring Procmon)

2016-03-17
/ /
in Blog
/

We were having an issue with a AppV5 package loading and we received the following error message:
Event ID 1008
Package {b8b01729-ed31-4d77-a859-dbd8b82a3372} version {e1d21ac7-84f0-4ab7-998f-e3258be91298} failed configuration in folder ‘D:AppVDataPackageInstallationRootB8B01729-ED31-4D77-A859-DBD8B82A3372E1D21AC7-84F0-4AB7-998F-E3258BE91298’ with error 0x79100E10-0xC.

This message is preceeded by this message:
Event ID 4009
machine script for event AddPackage with command line: ‘cmd.exe’ exited with failure error code: Incorrect function.. Because Rollback is set to true in the script definition, the current AppV Client operation was rolled back.

I started investigating.  The first thing I did was open a powershell window and tried to load the package via the command line:

I then looked at our DynamicDeployment XML file and examined the script it is trying to launch:

The script it’s trying to launch looks like this:

Since this is a Machine Script, I started a process monitor capture, executed my command, stopped the capture then used the “Process Tree”

and clicked on AppVClient.exe and clicked “Include Subtree”.

and used the “show process and thread activity”.  I filtered on ‘Detail’ ‘Begins with’ and set it for both Parent and Exit so I can look at the process path and exit codes:

 

The ‘exit code’ is ‘1’ (Exit Status: 1) which means an error occurred that caused the script to fail.  So now we dive into that script and see why it’s failing:

From looking at the script, it’s trying to create a new ‘mklink’ path.  If I try and run this command manually, I get the following:

So this is where the errorlevel (also exit code) is being set.  The last error level is 1 which becomes the exit code once the script runs ‘EXIT.

So, there are two methods I can think of to solve this problem.

1) I can set EXIT /B 0 to always set EXIT to report and error code of ‘0’.
2) Check to see if the path already exists and then EXIT

I chose to modify the script to exit if the path exists.  I changed it like so:

I cleared procmon, set it to trace again and attempted to run the add-appvclientpackage command again.

I selected ‘AppVClient.exe’ and clicked ‘Include Subtree’

This time we can see that the ‘AHS-ATOP.cmd’ script has an ‘Exit Status: 0’ which means it completed successfully.  But, the next script, ‘AHS-SoftWorksGroup-ScreenTestIII.cmd’ with the parameter ‘INSTALL’ fails with ‘Exit Status: 1’.  Again, we look into the script…

We can see it has the same flaw.  I then modified the script to add the same IF EXISTS check.  I then cleared procmon and reattempted to add the package.

Success!!!

Hurray!  The package loaded and the scripts ran correctly.

An alternative to all of this is I could have changed the ‘rollback’ to ‘false’ in the DeploymentConfig.xml file, but I would rather the package *not* load if the ‘INSTALL’ script fails for whatever reason.  This ensures an error is generated that needs to be dealt with rather than potentially having a half-working package.  These INSTALL scripts were simple enough that a simple directory check would suffice to ensure it’s working and that’s what I’ve done.

Read More

WSUS clients fail with WARNING: Exceeded max server round trips: 0x80244010

2016-03-14
/ / /

J C Hornbeck/Joe Tindale touched on this topic on a Microsoft blog post here.

In that post he touches on what’s actually happening:

Cause: The error, 0x80244010, means WU_E_PT_EXCEEDED_MAX_SERVER_TRIPS and happens when a client has exceeded the number of trips allowed to a WSUS server.  We have defined the maximum number of trips as 200 within code and it cannot reconfigured.  A “trip” to the server consist of the client going to the server and saying give me all updates within a certain scope.  The server will give the client a certain number of updates within this trip based on the size of the update metadata.  The server can send 200k worth of update metadata in a single trip so it’s possible that 10 small updates will fit in that single trip.  Other larger updates may require a single trip for each update if they exceed the 200k limit.  Due to the way Office updates are published you are more likely to see this error if you’re syncing Office updates since their metadata is typically larger in size.
I’ve bolded the more important information.  This is hardcoded and cannot be reconfigured.  This, to me, is a bit ridiculous that it can’t be reconfigured.
I have a WSUS client where we ‘reset’ the Windows Update client.  After resetting the client we were getting an error “WARNING: Exceeded max server round trips: 0x80244010”.  We would try multiple times but this error wouldn’t go away and prevented us from running Windows Update on this system.  So I started to investigate.  The first thing I did was finish reading that blog entry.  Hornbeck continues:
The client takes these new updates as they trickle down and inserts them into a small database to cache them for future use.  So during the first client synchronization with WSUS the client may get 75% of the available updates, put them into the database, and then fail at some point due to the number of max trips being exceeded.  The good news is the second synchronization cycle will not need to start from the beginning since the client has already cached 75% of the updates into its database.  The second cycle will pick up where it left off and most likely finish getting all the updates from the server.  There have been a few rare cases where a third scan cycle is needed but more often than not two is sufficient.
Again, I have bolded and underlined the important parts.
I started my investigation by trying to replicate the problem.  I started up Windows Update and ‘checked for updates’.
Ok, no problem.  So I checked again.
Well, Hornbeck/Tindale did say it may take a couple passes.  Let’s try again.
I’m getting worried now…  Let’s try a fourth time.
Hmmm…   At this point I wanted to better understand what Windows Update was doing.  I originally installed Wireshark to trace the conversation but it was difficult and time consuming to try and count the traffic back and forth to the WSUS server.  So I reverted my system and installed Fiddler2 on it.
From the video you can actually see the traffic from the WSUS server.  The request for the ‘Updates’ starts at item 3 and completes at 203.  Exactly 200 round trips.
Since my previous Windows Update attempts at the WSUS server failed after a few tries I thought I would trace the traffic with Fiddler for the multiple attempts.  My logic was I wanted to know if the traffic was ‘looping’; repeating itself and getting to the limit preventing updates.  Or, would each send/receive be unique and thus, simply, more is needed?
The first bit of the first run.  If the second run as identical or near identical traffic ‘packet sizes’ I would be concerned it’s looping…
I reset Fiddler and started the second run.  Completely different!
When I started the second run I was happy to see it was a completely different result.  I cleared Fiddler for a 3rd time ran the ‘Check for Updates’ until it timed out again, and cleared Fiddler again.  I then thought to just let Fiddler capture everything.  There really is no need to clear it each time.  I monitored the Fiddler output looking for loops or patterns.  The update check timed out a forth time (as before).  There was no looping I could see.
Finally, on the fifth run:
Updates!  We have updates!
In the end, when the Microsoft blog post was written (2008) there probably was only enough updates that two or three passes would go through all of them.  As time as gone on and more and more updates have been deployed to systems this hardcoded maximum is doing a huge disservice.  Our Windows 2008R2 SP1 systems require FIVE passes of clicking/waiting/clicking/waiting/etc.
A natural solution to this is to expose the “max server round trips” variable and allow it to be programmed by the organization according to their needs.  The present state of this issue is unnecessarily confusing and arbitrarily limited.
Read More

AppV5 – Sequencing Logibec eClinibase

2016-03-11
/ /
in Blog
/

I was given a new application to sequence:
Logibec’s eClinibase.

This application has some restrictions:
1) It has an updater that will pull down .exe’s
2) It won’t launch from a script in the bubble.  Example:
cmd.exe /appvve:%PACKAGEGUID%_%VERSIONGUID%
cd /d C:LogibeceClinibaseilgi11
eclinibase.exe

Will crash.

I’m going to address point 2) first because it’s weird and interesting.

Why does it crash?  Because, somehow, it breaks out of the bubble.  The reason it crashes is it looking for some registry keys that don’t exist outside the bubble and it explodes.  The keys it looks for are:

On a local install if I delete the environment keys that matchup to the folder we’re launching eClinibase from, I get the same error.  Since those keys don’t exist outside the bubble, we get the same error…  Which means it’s trying to look outside the bubble for some reason.  Powershell, however, works correctly but only if the exe is called directly:

However, we CAN get it to stay ‘in the bubble’ if we launch the eClinibase.exe with the /appvve: switch.

This is the first time I’ve ever encountered this where launching the application from a command prompt inside the AppV bubble fails, but it will work if you launch the exe with the /appvve: switch.

So that’s weird that we need to launch it specifically that way, but it appears to work so I guess that’s a limitation we have to roll with.

So how do we address point 1)?

I’ve used this technique before and it works here.  We will create a directory symlink to a network file share where the users will have full permission to update the application.  Since these updates occur ‘as needed’ the different environments may update at different times, this keeps them in sync across all of our Citrix servers since they will all point to the same location.

I add the mklink command the DynamicDeploymentConfig.xml:

And we are good to go!

Read More

The winlogon notification subscriber TermSrv failed a critical notification event.

2016-02-03
/ / /

When launching a Citrix application a user was getting a the ‘Citrix launch bar’ then, after a few seconds, it would immediately go away.  Checking the Application log in the event viewer displayed these entries:

The winlogon notification subscriber TermSrv failed a critical notification event. Event ID 6001
The winlogon notification subscriber Sens failed a notification event. Event ID 6004

The root cause?

A faulty path for the homedrive AD attribute:

See that ‘Connect’ H: To ‘Path’?  That was a bad path.

Removing the attribute or fixing it so that it pointed to a path that the user has access to and exists resolved our issue immediately.

Read More

Citrix Director 7.7 is giving me artifacts!

2016-01-19
/ / /

We are still in a pilot-preupgrade phase of Citrix Director 7.7 and found an issue where we were getting artifacts with IE11.  The artifacts manifested themselves like so:

This is wrong.
When the search box should look like this:
This is right.
This issue appears to be caused by a policy our organization uses to enable compatibility view for sites on the Local Intranet:
The Culprit
Citrix says the following about Director and ‘Compatibility View’:

Director does not support Internet Explorer compatibility mode. Please use the recommended browser settings. When you install Internet Explorer, accept the default to use the recommended security and compatibility settings. If you already installed the browser and chose not to use the recommended settings, go to Tools > Internet Options > Advanced > Reset and follow the instructions

Because we use a group policy to push this setting out, disabling it and re-enabling it on a site-per-site configuration isn’t acceptable.  There is an option to set the ‘zone assignment’ of our Citrix Director server to be on ‘Trusted Sites’ instead of ‘Local Intranet’ but this would be another policy that would have to be pushed out to the ~80,000 workstations we have.  Instead, there is another option.  We can edit the default.html file in the Citrix Director folder and add a line in thesection to tell IE to exclude this site from compatibility mode.  To execute this:
Edit the Default.html file (“C:inetpubwwwrootDirectordefault.html”) and add this line:

To the ‘head’ section.  Example:

Add the line around here
Delete your cache and now your website will work without issue.
Read More

Citrix Director 7.7 & XenApp 6.5

2016-01-15
/ / /

Citrix has ‘replaced’ Edgesight with a new tool called Citrix DesktopDirector. 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). Although vastly inferior to ControlUp, it is free.

But it’s not without poor documentation and its own tales of woe. We have Citrix DesktopDirector 2.1 currently live in our environment. Our environment is purely XenApp 6.5 (at the moment).

For version 2.1, logins are incredibly slow. Enumerating any sort of information on DesktopDirector is horribly slow. It’s just incredi-bad.

Enter Citrix Director 7.6 7.7; lots of promises to overcome the failings of the previous version.

First, installing Citrix Director 7.7 for XenApp 6.5:

1) Launch the AutoRun (AutoSelect.exe) installation file

2)
Select ‘Start’ for XenApp

3)
Select ‘Citrix Director

4)
Agree to the licensing agreement and click ‘Next

5)
Select ‘Next

6)
Without entering any information, select ‘Next

7)
Select ‘Next

8)
Select ‘Next’ for the firewall rules

9)
Select ‘Install

10)
Wait for the install to complete

11)
Open IIS Manager on the Director Server. Select the Director site under Default Web Site and double-click on ‘Application Settings

12)
Under ‘Actions’ click ‘Add

13)
For ‘Name’ enter ‘Service.AutoDiscoveryAddressesXA’ and for value put the IP of the local ZDC server

14)
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.

15) Reset IIS from the command line.

16)
On EACH XenApp server, install the Director WMI Provider (DirectorWMIProvider_x64.msi for 64bit OS’s and DirectorWMIProvider_x86.msi for 32bit OS’s). No reboot is needed, it takes effect immediately.

17) Enable WinRM on each XenApp server. In a command prompt run:
‘winrm qc’

18) Configure WinRM with the appropriate permissions:
ConfigRemoteMgmt.exe /configwinrmuser HEALTHYDesktopDirector.TST /all

**A NOTE ABOUT CONFIGREMOTEMGMT.EXE**

Ensure you use the latest version you can find. For XenApp/XenDesktop 7.7 the version that comes with it is:

It has been revised as time has gone on and numerous bug fixes have been implemented. We implemented a script to update our WinRM so all of our XenApp servers would have the user configured. We didn’t include checking, we just assumed if a group was added it would not be added again. 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. You see, ConfigRemoteMgmt.exe is also a front end to “C:\Windows\system32\winrm.cmd“. Here is the command it generates:

C:\Windows\system32\cmd.exe /c “”C:\Windows\system32\winrm.cmd” set winrm/config/service @{RootSDDL=”O:NSG:BAD:P(A;;GA;;;S-1-5-21-38857442-2693285798-3636612711-99999999)(A;;GA;;;BA)S:P(AU;FA;GA;;;WD)(AU;SA;GXGW;;;WD)”}”

The part I bolded is the GUID of the object you pass in the /configwinrmuser. The ConfigRemoteMgmt.exe takes your object and converts it to a GUID and then sets the SDDL using the native Windows tools. The bug in a pervious version of this tool is that it would add another GUID, even if one already existed. So in the buggy version the next command would be this:

And so on. Eventually, this causes WinRM to fail and it will just hang at this point:

To check your WinRM Root SDDL, execute this command:

If you have an output similar to this, then you have a problem:

Fortunately, it’s a super easy fix. If you run the command with a single GUID it all gets reset:

And now you can execute the ConfigRemoteMgmt.exe command again. The new version of ConfigRemoteMgmt.exe doesn’t seem to just ‘stack’ the new version on top.

/**A NOTE ABOUT CONFIGREMOTEMGMT.EXE**

Now that you have WinRM configured, Director installed, you login and it works. So you try with a HelpDesk account and it fails:

In order to trouble shoot this, we need to turn logging on for Director. To do so, go into IIS Manager Console, to the ‘Director‘ Site, and double click on Application Settings. Turn on the following “Log.” settings:

Now, create the folder you specified the log will be captured in and set the following permissions on it:

Note: The permissions are %COMPUTERNAME%IIS_USERS

Restart IIS and attempt to login again. You should get a log file generated with content. A failed login had this output:

And a succesful login had this output:

I highlighted the lines in the successful output that showed the command succeeding and the output from that. So why did this fail? The one account “adtest91” is setup as a ‘help desk’ style account and has ‘custom permissions’; essentially ‘View-only’ but with some categories removed altogether. Could this be permissions based? The odd thing is DesktopDirector 2.1 works without issue with this exact same configuration.

Fortunately, Citrix tries to make this easy to troubleshoot. I will login to the ZDC and start a Citrix PowerShell session with “adtest91” and run the command it supposedly fails on:

Well, at least it appears consistent. So, apparently, we need to get this command working. My first try at troubleshooting was to login to the AppCenter console, go to Administrators and get properties on this account, and change it’s ‘Privileges’ from Custom to Full:

When I attempted to login it worked! So it’s definitely a permission issue. I went back to Powershell and executed the same command:

Success!

So if the Powershell command specified in the log file works then ‘Director’ should work, and so far that is what it looks like. Now I wanted to narrow down *which* permission does this as we do not want our Help Desk to have full control over the farm. The, very obvious, first thing that stood out was:

Edit Zone Settings.” We are having issues enumerating Zones, perhaps this setting enables you to *read* zones? I enabled this setting and retested:

Success! And our ‘Help Desk’ account can now login to Director.

We don’t really want Help Desk to have the ability to ‘Edit’ Zones but I don’t see a ‘Read-only’ permission so we may have to live with it.

So now we’ve logged into Director and we enumerate an account but we get this message:

Cannot retrieve the data. Cannot find the referenced object. View Director server event logs for further information.

The IIS logging shows:

And the event log shows:

The requested data could not be found in the data ‘The virtual desktop via WinRM service reported an exception. See the event log for more information.’ (‘http://WSCTXZDC301T.healthy.bewell.ca:5985/wsman’).

User: ‘HEALTHYadtest91’

Console operation: ‘Retrieving running application details for IMA Session…’

Additional information:

‘Exception of type ‘Citrix.Dmc.Common.NotFoundException’ was thrown.’

When I got this message with my ‘Administrator’ account I installed the Director WMI Provider and it started working. But with this ‘limited’ user account I was getting an this error. Amazingly, this error goes away as soon as a user logs in to Citrix Director webpage, who would also be a local administrator on the Director server. After searching and searching and troubleshooting and scanning and trying various things to get this working, the only thing that would work was to grant our Director group admin privileges on the Director web server. I finally stumbled across another article that reaffirmed that the only solution is to have the users be local admins on the web server.

https://support.software.dell.com/kb/154066

To test WinRM the following command can be used:

winrm get winrm/config -r:%server%      — Non-administrator user gets access is denied making WinRM queries

This error, though, is only if you set Connector.WinRM.Identity as ‘User’ and those users are not Administrators.  The fix, is to put your users into a group and make them a local admin on the Director server.

Read More