Author : Ingmar Verheij

I’ve built a lab to run some tests on Citrix XenApp. Since this is a lab environment I do not have enough resources to create dedicated machines for each role. Therefore I found it justified to create a virtualized domain controller (dc001.domain.local) with multiple roles and multi-homed (Boooohhh, I know). The machine is not only a domain controller but also has the DNS and DHCP role.

The following network interfaces are present on dc001.domain.local:

  • Local Area Connection 1 : 192.168.1.1/24
  • Local Area Connection 2:  192.168.2.1/24

The Citrix XenApp server is a dedicated physical machine with a single network interface:

  • Local Area Connection 1 : 192.168.1.2/24

After creating a published desktop I’ve tried to connect from a machine in the 192.168.1.0/24 subnet. The session keeps waiting with the message ‘Please wait for the Local Session Manager’.

Please wait for the local Session ManagerSince I am the local session manager around here, this annoyed me.

I took me a while to find the problem. I’ve installed all recommended Citrix and Microsoft hotfixes but that did not solve the problem. Eventually Process Monitor (SysInternals) send me in the right direction.

Process Monitor

The LogonUI kept on (re)connecting to the domain controller while the status message remain the same.

A quick peek with ping (did I mention I Love Ping?) showed the problem. The domain controller resolved to the wrong IP address and could therefore not be reached (the XenApp server is in the 192.168.1.0/24 subnet)

Ping

The problem is caused by the multi-homed domain controller (which is a bad-practice btw). Since all network interfaces by default gets registered on the DNS server, there is a chance the IP address resolved is on a different subnet.

Register this connections addresses in DNSThe solution to the problem is (as always) fairly easy. Either don’t use a multi-homed domain controller, since this is a bad practice, or prevent the network interface to register on the DNS server.

This can be achieved by disabling the checkbox ‘Register this connection’s addresses in DNS’ on the Advanced TCP/IP Settings of the network interface.

If the checkbox is enabled after you disable it, hotfix KB2554859 is required.

OR, you can issue the netsh command with the parameter skipassource=true as Remko Weijnen recently blogged.

If you do not have access to the domain controller, or unable to appy hotfixes, or you want to do it in a completely different way… You can also add the domain controller to the hosts file which can be found in the location %windir%\system32\drivers\etc\hosts

hosts file

To check if the changes have worked you can issue the ping command again to verify if the name resolution of the domain controller works.

Ping dc001.domain.local - after

If you now make a connection to the Citrix XenApp server, the connection will successfully be made (or at least it did on my lab).

Logon screen

6 Reacties

  1. Thank you so much, I’m now 100% sure that you helped me solve a problem that Citrix Support has yet to help me with for over 2 months. while my Domain Controller is not Dual homed, it does have 2 NICs. One is for the network the other for iSCSI SAN. Event though it doesn’t have the check mark checked to update DNS it still does every hour on the hour. Once I delete this entry and flush DNS. My applications work.

  2. Hi Ingmar,

    I have a situation, where A new Xenapp6.5 farm does not allow published applications to be launched. It pauses for a few seconds waiting for the local session manager and disappears.

    Do you have any suggestions to persue?

    1. Hi Ravi,

      I have no easy answer on that. I would check the event log first to see if there are events that give a good hint.
      Also try to logon via RDP to see if that works.

      Ingmar

  3. Hi, Please install below for windows 2012 server gets “Please wait for the Local Session Manager” to avoid the error,

    server manager –> Add Roles and features –> next–> Remote desktop services installation –> quick start –> next –> session-based desktp deployment –> follow the installation restart would require and login with RDP it works.

    Regards,

    Udesh.

Geef een reactie

Het e-mailadres wordt niet gepubliceerd. Vereiste velden zijn gemarkeerd met *

Deze site gebruikt Akismet om spam te verminderen. Bekijk hoe je reactie-gegevens worden verwerkt.

nl_NLNederlands