The one with RES Workspace Manager and Citrix Receiver SSO

Hi there,


Quick one for you. If you're deploying RES Workspace Manager 2014 to clients that have Citrix Receiver installed and you find that after the installation of the RES agent SSON for Citrix Receiver stops working then ensure Active Setup is not disabled in RES.



If the friendly Receiver login box prompts you for credentials:

Then head into RES and make sure Active Setup is still enabled:

Remove the user profile from the computer & log back in again and it should work. 

If after doing this you see that it takes a long time for Citrix Receiver to login and display applications in Start Menu, then you can run this command to force Receiver to update faster. It doesn't seem to take effect if the command is set under a Registry Run key. The only ways to make it work right after the login is to run it via RES like below or to run another command via RES : runonce.exe /ShellAlternateStartup (google this for more details). I went with the Receiver login & poll command.

Happy Citrixing.
Here's to a lousy Christmas and a crappy New Year !

The one with the 30 second delay

So you're troubleshooting a delay issue? Here's one that I came across today.

I'm at a customer setting up few things. One of the task is to make sure users can login from the thin client solution into Citrix published desktops. We're going to use ThinKiosk on top of the OS. The chosen OS is Windows Embedded 8.1 Industry (WES 8). The OS gets deployed part of an SCCM task sequence. Part of the same task sequence we install ThinKiosk and apply a write filter to prevent any changes to the C drive from sticking (the build in Windows write filter via the Embedded Lockdown Manager). Everything works fine except that there's a 30 second delay between pressing CTRL ALT DEL and getting the username and password prompt.

After much troubleshooting a colleague found the solution posted on the Microsoft support forums. Exclude the folder c:\windows\ccm\logs from the write filter. That'll fix the issue.

The one with the Network Profile

Hi there,

It's been a while since I posted something. I blame my employer for keeping me busy :)

So I'm on this project for few days where I have to build some physical servers, install the OS on them, patch them to the switches, etc.
Part of the build requires setting up a DC and joining the other servers to the domain. Done and dusted in no time. After joining the servers to the domain I moved from using the KVM in the datacenter to managing the servers remotely. Not that before it wasn't possible but I usually do things in one shot: set IP & join to the domain.

To my surprise I wasn't able to RDP to the boxes. The firewall in Windows was turned on so I said to check if the rule to allow RDP is on. It was on but only for Domain and Private networks. I checked the Network profile I was on and what do you know - I was on a Public Network profile. That is not right - it should've been Domain  Network profile.

After some more digging around to understand how the Network profile is set I fired up Process Monitor (When in doubt run process monitor :) ) to have a look at the network traffic. I used Wireshark at the same time but in this case it's easier to spot the problem in Process Monitor.

I noticed that after plugging the network cable in the server, Windows (2012 R2) was starting to identify the network type. It does this by by opening a connection to the domain controller on port 389 and performing some queries (I will not go into details).

As seen below - there are plenty of UDP send packets but no response:

I plugged the DC and a client into another switch (a 5 port - 10 year old one) and the network type was set to Domain right away. The only thing that could create such a problem is if for some reason the switch doesn't start forwarding packets right after the cable is plugged in. Aha - spanning tree protocol...:) What Windows does is that it tries to identify the network right away without actually knowing if the switch/switch port is in a state to process/forward packets.
After a chat with the networking admin and changing the ports' spanning tree state to "portfast" the problem went away. Now I can see replies to the outgoing packets and the network profile is set to the correct one. This means the firewall profile Windows is using is also the correct one.

The one with the slow first logon

Hi there,

I just came across this old entry which never got published...so here it is.

I want to share something with you, something that recently happened to me while deploying a XenApp 6.5 environment; might spare you some valuable time.

As said, I'm deploying at the moment a XenApp 6.5 farm and was presented with a frustrating issue: after a server restart, the first logon via ICA (RDP and console were always fine) was slower than normal. By slower than normal I mean that there was a delay of 30 to 40 seconds during logon. This was visible in both provisioned servers and normal non-provisioned servers. The farm is 6.5 HRP3.
After this first logon/logoff via ICA subsequent logins were fine - loading in the expected amount of time. This was happening to both published applications and published desktops.

Here's a print screen of where the hang was and what was visible on the screen during the hang:

 

To spare you the trouble of reading a long story I'm going to cut to the chase. Running a Process Monitor trace on the first login showed that some Edgesight components where trying to perform what I believe is a CRL check against some servers in Akamai. As the customer has a proxy with authentication the access was failing.

 

The fix came to me when I found a Citrix article explaining how to fix an issue with an Edgesight service. I told myself then that if the trick works for that particular service it should work for the other Edgesight executables - the ones that were giving me a headache.

So what I ended up doing was to create a file called SemsService.exe.config under the folder c:\Program Files (x86)\Citrix\Euem\Service.

A similar file called rscorsvc.exe.config was created under the folder c:\Program Files (x86)\Citrix\System Monitoring\Agent\Core

Both files contain the following text:

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false" />
</runtime>
</configuration>

 

...but you probably saw the above lines of config more times than needed.

 

Problem fixed.