Tuesday, August 28, 2012

How to manage XenApp 6.5 and XenDesktop 5.x using Desktop Director 2.1

Last time I wrote a blog and refer to blog by Dane Yong  http://blog.itvce.com/?p=408  for installing  DD which can integrate both XA and XD.  After that I tried following again and it never worked. There are several other blogs which says how to integrate XA6.5 and XD5.6 together. They also mention to use different ISO but here is what you need to do

  1. In this example we are using dedicated DD which does not have any other component.
  2. Mount XenDesktop 5.6 ISO image to the machine  and run Autorun.exe -> Install XenDesktop option -> deselect all options except Desktop Director
  3. On the bottom of the page where Desktop Director is selected, an input box will appear asking you to enter a controller in the XenDesktop site commence installation


     4.   Open Internet Explorer – open the Desktop Director site, confirm XenDesktop site is enumerated successfully

     5.      Run IIS Manager, open the Application Settings for the DesktopDirector folder. Add the

                Service.AutoDiscoveryAddressesXA option with relevant XA server


6.  Open Internet Explorer and log in to the Desktop Director site again. Confirm that XenDesktop is enumerated successfully

      on the main landing page and that searching for a user shows their XenApp sessions too


You can reach out incase you are not able to make it work :P

How to capture memory dump of Windows 2003 PVS Streamed VMs

Prep XenApp vm to enable COM port debugging.

1. Logon to XenApp vm and run “msconfig” from command line.

2. Select “Boot.ini” tab, then click “Advanced Options” button and check to enable the following checkbox and selected values.




3. Reboot server to take effect

Attach a Virtual Serial Port to VM

While the target XenApp vm is running on Xenserver console command line issue the following command to enable virtual COM port redirection to a separate machine running sockpipe tool and Windbg:

#xe vm-param-set uuid=<UUID of the VM> other-config:hvm_serial="tcp:<<IP-of-the-Windbg-machine>>:7001"  

(can use any open ports beside port 7001 on the machine running sockpipe/Windbg) .  This command can be run even if the VM is not running.

Configure Debug session

1. From sockpipe/windbg machine disable Windows firewall or 3rd party Anti-virus/firewall, etc.

2. Start sockpipe via command line (run in administrator mode for the command line if it’s Win7 or Win2K8), and run command “sockpipe mypipe 7001”

"mypipe" is name given to the pipe being used to connect to the VM. This needs to be  unique for all the Debug Session and so should be the port number.


Start Windbg and select “File > Kernel Debug” and enter the following on the first COM tab:

· Baud Rate=115200

· Port=\\.\pipe\mypipe

· Check the “Pipe” check box

· Click OK button


If the VM is running then reboot the XenApp VM so the virtual COM port of the VM will be redirected to sockpipe/windbg machine IP address. If the VM is not running, just start the VM

How to Capture

When XenApp vm experience hang or freeze, on Windbg machine select “Debug > Break” within Windbg to enter break point.  On bottom of Windbg you can type the command

“.dump /f c:\temp\fulldump.dmp” (or whatever location you have enough free disk space to hold the entire memorydump of same size as the vm’s physical memory)

Now wait for the full memory to copy out of the VM thru it’s virtual COM port.

Download Dump Configurator from CTX129575  

Download Sockpipe

Source : Based on input provided by my colleague Vipul Tripathi

Sunday, August 5, 2012

Provisioning Server error : No ARP Reply

Environment :  

XS= 6.0.2 with latest patch
PVS =6.1 HF1 running on Dell R720
Target=Windows 7 32 bit VM
Hardware = Dell R720  , NIC =BCM57712
Core Switch : Nexus5K

Problem description:When the target's  were booted   it use to contact the PVS server but while downloading image ARP use to time out. This use to happen with few machine say 3 out 5 machine.


Troubleshooting :

1.      Broke the bond , tested with Xenbridge/Open V Switch mode
2.    Finally put the virtual PVS and DHCP on same VLAN , all the target worked booted perfectly. This gave us thought that intra VLAN something is wrong. This translate into layer 3 issue . When target and PVS are on same VLAN , layer 3 act as a     layer 2 and just f/w the packets.
3.    We decided to test something else , used the working VM mac with non -working VM and voila. This gave us déjà vu that something messed at layer 3.
4.    Now Q was how do I separate Nexus 5K in the core and create my own layer 3 on Dell switch to test intra VLAN testing. Dell blade switch M8024 can also act as layer 3. We created layer 3 VLAN with different gateway. Now we moved our v PVS on this network. We also had to extend our DB and AD to this PVS as well ? So we added static route to one leg of PVS. Now streaming traffic was in separate VLAN and Target were in separate VLAN. One target boots it does intra VLAN communication to PVS . PVS intern fetch those info from DB /AD using backend connection. This way I eliminated layer 3 Nexus . Above setup can only be replicated on single host

CISCO troubleshooting:

1.    Core had VPC configured on their Active /Standby pair. We decided to shut down one leg and see if this works. To our surprise every thing work.
2.    We captured two set of trace one with VPC shut down and one without VPC shut down.

Here is what we see when VM's work : When ARP request received by CISCO core they does return back the MAC address of the targets image

But when it does not work then it does not broadcast the MAC .


Basically, depending on the hashing algorithm of the Dell switch, a packet may arrive at either the HSRP active or standby.  If the packets arrived on the HSRP standby, it would forward it over the peer-link towards the HSRP active which would then result in the ARP reply being broadcast . For other streams, the Dell switch would send the packet to the HSRP active which would result in a unidirectional reply and this works fine. This turned out to be KNOWN bug and CISCSO advised them upgrade their IOS to 5.0(3)N2(2).

As per bug Symptom:
ARP response from the Nexus 5000 is sent as a broadcast instead of a unicast. Some TCP/IP implementations on Network interface cards do not accept a broadcast ARP response and will not install an ARP entry in their ARP database. Such
clients will not be able to access network resources.

When the arp request is received on the HSRP standby switch and sent over the peer link to the HSRP active switch.

Once the IOS upgraded , this fixed this problem

How STA works for typical XenDesktop Deployment

This post is dedicated to my colleague who has done wonderful analysis of how STA works .Contents is not as it as because some of them are internal to Citrix.image

1. User clicks Desktop link "POOLDG-01" to request a remote desktop connection, actually is requesting an ICA file

2. WI asks XMLService for the "Address" of required VDA.

3. WI asks XMLServcie for the "LaunchRef".

4. WI asks XMLServcie for the "LogonTicket" using below XML protocol

5. WI sends request to standalone STA for another Ticket, AG uses it for session validation as well as identify the VDA

       it should proxy ICA for



6. WI now has all the information needed, then it returns back the new wrapped ICA file to client

7. wfica32.exe works on client side to parse the ICA file and connect to remote VDA thru AG: ag01.homa.com:443

8. AG checks with Standalone STA on the Ticket passed in to check if session is valid

9. AG uses the "ServerAddress" to connect VDA on, the LogonTicket then will be passed as a parameter LogonTicket=F41E843C8EC6F8C8055D679E545552

10. VDA asks DDCService to validate the Ticket, DDCService checks the Ticket information in IMA, redeems the Ticket, retrieved user's credential associated with Ticket

11. DDCService returns user's credential to VDA so that VDA could proceed with logon


For troubleshooting STA's issue :

1. How to Enable STA Logging on the STA Servers

2. The Status of the Secure Ticket Authority (STA) is Marked as DOWN for the Access Gateway Enterprise Edition Virtual Server