Hi,
I recently had to configure the PDCe server in a forest to sync with an external time source. The time source was on a Cisco Nexus switch. For some reason the PDC server was not liking the NTP server - it was refusing to sync. PDC running Windows Server 2008 R2 SP1.
I was getting the local CMOS time..
w32tm /query /status
Leap Indicator: 0(no warning)
Stratum: 1 (primary reference - syncd by radio clock)
Precision: -6 (15.625ms per tick)
Root Delay: 0.0000000s
Root Dispersion: 10.0000000s
ReferenceId: 0x4C4F434C (source name: "LOCL")
Last Successful Sync Time: 11/05/2016 15:07:25
Source: Local CMOS Clock
Poll Interval: 6 (64s)
This drove me CRAZY for two weeks or so. After trying EVERY single possible fix on the forums, I came across this: https://support.microsoft.com/en-us/kb/875424
Time synchronization may not succeed when you try to synchronize with a non-Windows NTP server in Windows Server 2003
This problem may occur when your computer sends synchronization requests by using symmetric active mode. By default, Windows Server 2003 domain controllers are configured as time servers and use symmetric active mode to send synchronization requests. Some NTP servers that do not run Windows respond only to requests that use client mode.
As it turns out, that was my issue. I was able to see in wireshark that the server was indeed requesting a symmetric sync.
Applied the fix suggested in the article of appending the 0x8 to the NTP server and it's all ticking along just fine now.
Let's all sync our clocks now!
Wednesday, May 11, 2016
Monday, March 30, 2015
The one with the 'Right Click - New' menu
Ahoy !
So you've deployed a mandatory profile solution with your XenApp infrastructure. You were quite eager to see it working so you created the mandatory profile before deploying all your applications on the system used to create the profile. The profile works fine but your users have reported a snag: when they right click on the desktop or inside a folder to select New - and then a file type to create a blank document, not all the 'expected' file types are listed. As soon as they exit the menu and do this process again, all the file types are displayed. So the second time it works...why is that?
To save yourself the grief of troubleshooting you'd probably decide to re-create the mandatory profile so you can 'recapture all file types'. It is not a bad option and it will give you what you want.
Not wanting to do that I set to understand what happens.
When you right click and select New, your computer will read a registry value located under your user hive with all file types recorded for your profile. At the same time it will scan the registry for all registered file types (under Classes Root) and for those that a flag to integrate with the New menu exists will write them to your user hive. It will however display only the file types recorded on your user hive. As at this stage we only have what's captured in the mandatory profile...we get nothing relevant:
The next time you access the menu the process repeats but this time your value has the updated data. That's why the second time you get to see all file types.
The method I decided to use to fix my problem was to mount the mandatory profile hive and change the registry entry. The entry is a Multi-String value and what you have to do is to list the extension you want displayed: .txt for example. Keep the entries one per row.
Having RES Workspace manager on top of the mandatory profile I decided to take this fix one step further and configured a user's settings capture policy so that when the user logs off the registry key is saved to the user's RES profile and restored at the next logon. This will help in the future should the servers get new applications delivered to them that interact with the Shell New menu.
The registry location is :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew
The value is called Classes and as previously said it's a Multi-String Value.
Don't remove the value from the hive. Yes - it will be generated the first time the user accesses the menu but they'll also get this:
So you've deployed a mandatory profile solution with your XenApp infrastructure. You were quite eager to see it working so you created the mandatory profile before deploying all your applications on the system used to create the profile. The profile works fine but your users have reported a snag: when they right click on the desktop or inside a folder to select New - and then a file type to create a blank document, not all the 'expected' file types are listed. As soon as they exit the menu and do this process again, all the file types are displayed. So the second time it works...why is that?
To save yourself the grief of troubleshooting you'd probably decide to re-create the mandatory profile so you can 'recapture all file types'. It is not a bad option and it will give you what you want.
Not wanting to do that I set to understand what happens.
When you right click and select New, your computer will read a registry value located under your user hive with all file types recorded for your profile. At the same time it will scan the registry for all registered file types (under Classes Root) and for those that a flag to integrate with the New menu exists will write them to your user hive. It will however display only the file types recorded on your user hive. As at this stage we only have what's captured in the mandatory profile...we get nothing relevant:
The next time you access the menu the process repeats but this time your value has the updated data. That's why the second time you get to see all file types.
The method I decided to use to fix my problem was to mount the mandatory profile hive and change the registry entry. The entry is a Multi-String value and what you have to do is to list the extension you want displayed: .txt for example. Keep the entries one per row.
Having RES Workspace manager on top of the mandatory profile I decided to take this fix one step further and configured a user's settings capture policy so that when the user logs off the registry key is saved to the user's RES profile and restored at the next logon. This will help in the future should the servers get new applications delivered to them that interact with the Shell New menu.
The registry location is :
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Discardable\PostSetup\ShellNew
The value is called Classes and as previously said it's a Multi-String Value.
Don't remove the value from the hive. Yes - it will be generated the first time the user accesses the menu but they'll also get this:
Monday, December 8, 2014
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 !
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 !
Tuesday, October 28, 2014
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.
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.
Monday, June 16, 2014
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.
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.
Saturday, January 11, 2014
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:
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>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false" />
</runtime>
</configuration>
...but you probably saw the above lines of config more times than needed.
Problem fixed.
Tuesday, March 19, 2013
The one where Discovery fails
Hi there,
Ever had one of those issues when you know it was not triggered by recent changes because there were none and you look around and you actually can't find any recent changes? Let me tell you - you need to look harder. There's always someone changing something, next to you, without you actually knowing it. I heard the answer "Nothing has changed" so many times so far that I think it's safe to say...I don't trust people anymore when it comes to this.
Back to our issue. We had a XenApp 6 farm (under Citrix PVS) that all of a sudden it decided not to perform discovery. There are nearly a dozen servers with one data collector. Basic error message:
Error occurred when using {server} in the discovery. On double clicking the message the following was being shown: An unexpected error occurred. Check that the server name is correct, that the server is on, that Citrix Presentation Server is installed on this server, and that the Citrix MFCOM Service is running.
The usual suspects: IMA and MFCOM. You got to love them.
After running all the sanity checks, everything seemed in place. IMA started, MFCOM started, LHC recreated. Farm was functioning properly, people could connect and there were no relevant errors in Event Logs. We even tried un and re / gistering MFCOM - no luck.
I started thinking of creepier scenarios - someone has made a joke and removed all Citrix admins from the farm (you get the same error message when you're not an admin). I used DSView to check there are still admins listed - there were. Time to pull out the big guns - CDFControl.
So I ran CDF Control with only Access Management Console category selected (AMC..nice memories huh?) and performed a discovery. Here's the output:
*the picture was cropped to show only the relevant data.
Aha - a server entry in the farm is causing problems. I bet dscheck will show more details.
Finished data store validation.
I created a backup of the SQL Database holding the Citrix Datastore and then executed the same command as above with the /Clean switch, to fix the problems. For confirmation I ran dscheck again. There was still and error present so I ran dscheck /clean again. The second error was cleared the second time and I was able to run discovery.
To finish the story I started with - the server causing problems was a recently created test server booted from a new test vdisk (completely rebuilt). So the answer to the question: What recent changes were in the environment should have been: tested a new vdisk in the production farm.
Happy Citrixing.
Ever had one of those issues when you know it was not triggered by recent changes because there were none and you look around and you actually can't find any recent changes? Let me tell you - you need to look harder. There's always someone changing something, next to you, without you actually knowing it. I heard the answer "Nothing has changed" so many times so far that I think it's safe to say...I don't trust people anymore when it comes to this.
Back to our issue. We had a XenApp 6 farm (under Citrix PVS) that all of a sudden it decided not to perform discovery. There are nearly a dozen servers with one data collector. Basic error message:
Error occurred when using {server} in the discovery. On double clicking the message the following was being shown: An unexpected error occurred. Check that the server name is correct, that the server is on, that Citrix Presentation Server is installed on this server, and that the Citrix MFCOM Service is running.
The usual suspects: IMA and MFCOM. You got to love them.
After running all the sanity checks, everything seemed in place. IMA started, MFCOM started, LHC recreated. Farm was functioning properly, people could connect and there were no relevant errors in Event Logs. We even tried un and re / gistering MFCOM - no luck.
I started thinking of creepier scenarios - someone has made a joke and removed all Citrix admins from the farm (you get the same error message when you're not an admin). I used DSView to check there are still admins listed - there were. Time to pull out the big guns - CDFControl.
So I ran CDF Control with only Access Management Console category selected (AMC..nice memories huh?) and performed a discovery. Here's the output:
*the picture was cropped to show only the relevant data.
Aha - a server entry in the farm is causing problems. I bet dscheck will show more details.
C:\Users\user>dscheck
Data Store Validation Utility. Version: 6.23
Server Consistency Check: The Citrix XenApp record with HostName
{server} at
DN 00001CAE may be invalid. The Load Manager for Citrix XenApp entry was not found.
DN 00001CAE may be invalid. The Load Manager for Citrix XenApp entry was not found.
Finished data store validation.
I created a backup of the SQL Database holding the Citrix Datastore and then executed the same command as above with the /Clean switch, to fix the problems. For confirmation I ran dscheck again. There was still and error present so I ran dscheck /clean again. The second error was cleared the second time and I was able to run discovery.
To finish the story I started with - the server causing problems was a recently created test server booted from a new test vdisk (completely rebuilt). So the answer to the question: What recent changes were in the environment should have been: tested a new vdisk in the production farm.
Happy Citrixing.
Subscribe to:
Posts (Atom)