I get this one regularly at work now when one of servers crash. It seems that their logon session remains connected and won't reset. There are plenty of solutions out there, but none worked for me until I found this one - so simple!
Run command prompt on the relevant server the user is having an issue with, and use the 'query process winlogon.exe'
This will show you all the winlogon processes on the server.
Find the one process without a SESSIONNAME (i.e. the only blank entry).
Make a note of the PID associated with that process.
Run Task Manager and click View menu > Select Columns... and choose PID (at the very top).
Now you can sort the list by PID number and find the winlogon process with the PID you are looking for.
Kill the winlogon process and Hey Presto, the user can now log in!
Hope this helps, took me a while to find!
Wednesday, June 20, 2012
Tuesday, April 3, 2012
Citrix... Again!
Halfway through Monday morning I get a note to say one of our users cannot access any Citrix published applications on one of our Citrix Servers (XenApp on Windows 2008). All other applications are fine, but anything on our second application server just gives the generic 'loading' message. As the day progresses, anyone else that tries to log on or create new sessions (key words: New Sessions) gets the 'loading' message. All users with open sessions are fine, programs keep working and they can be as productive as they choose.
We decide to cut our losses and bounce the server - in the past this has meant a 5 minute outage for everyone but after this all users can get onto the system. This time round however, the system won't remotely reboot. It sits there halfway through the reboot process and becomes completely unresponsive. Luckily we have a colleague down at the remote site with the server and it is forced to shut down and reboot. This does not make it happy! Over the next few hours it has to be repeatedly forced to shutdown until eventually it seems to catch up with itself and goes down gracefully. Luckily it comes back up too!
At this point, we also discovered issues with Terminal Server on the application server - it would not show any TS details and when it did load (which was infrequently) it would not show any license servers at all. We decided to reinstall TS on this server. This went without too much of a hitch but did not fix the Citrix issues.
Citrix was now showing the '*published application* failed to start' error. Little info on the web regarding this, so we ended up doing the following to register all the dll files in the webem folder in the system32 folder:
cmd> CD c:\windows\system32\webem
>for %s IN (*.dll) DO regsvr32 /s %s
Followed by:
>winmgmt /resetrepository
This allowed all the terminal server services to come back online and for us to examine and confirm that this at least was back online.
Finally, we had to make some amendments to the Registry - running regedit we found that the following key was missing some info:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon
the AppSetup key was showing UsrLogon.cmd
but needed to show:
CtxHide.exe UsrLogon.cmd,cmstart.exe
Once these changes had been made, Citrix was back up and running again! Now to do some clean-up routines and find out what exactly went wrong in the first place!
We decide to cut our losses and bounce the server - in the past this has meant a 5 minute outage for everyone but after this all users can get onto the system. This time round however, the system won't remotely reboot. It sits there halfway through the reboot process and becomes completely unresponsive. Luckily we have a colleague down at the remote site with the server and it is forced to shut down and reboot. This does not make it happy! Over the next few hours it has to be repeatedly forced to shutdown until eventually it seems to catch up with itself and goes down gracefully. Luckily it comes back up too!
At this point, we also discovered issues with Terminal Server on the application server - it would not show any TS details and when it did load (which was infrequently) it would not show any license servers at all. We decided to reinstall TS on this server. This went without too much of a hitch but did not fix the Citrix issues.
Citrix was now showing the '*published application* failed to start' error. Little info on the web regarding this, so we ended up doing the following to register all the dll files in the webem folder in the system32 folder:
cmd> CD c:\windows\system32\webem
>for %s IN (*.dll) DO regsvr32 /s %s
Followed by:
>winmgmt /resetrepository
This allowed all the terminal server services to come back online and for us to examine and confirm that this at least was back online.
Finally, we had to make some amendments to the Registry - running regedit we found that the following key was missing some info:
HKLM\Software\Microsoft\WindowsNT\CurrentVersion\WinLogon
the AppSetup key was showing UsrLogon.cmd
but needed to show:
CtxHide.exe UsrLogon.cmd,cmstart.exe
Once these changes had been made, Citrix was back up and running again! Now to do some clean-up routines and find out what exactly went wrong in the first place!
Wednesday, March 28, 2012
DNS Corrupt
Today I came into work to find that none of our users could access their mailboxes. On inspection, I managed to isolate the problem as a DNS issue. When I looked at the Standard Primary DNS Zone on our Domain Controller I was shown a nice big red cross and "The DNS server encountered a problem while attempting to load the zone. The transfer of zone data from the master server failed."Most forums on the Internet give lots of info on secondary zones and how to reconfigure them to reload from the primary zone - in this case the error was with the Standard Primary Zone and as such, no reloading was possible! For some reason, the zone wasn't set up as an Active Directory Integrated (ADI) zone and as such there was no backup of the zone in AD. As soon as I get a chance, this will be rectified and the zone will become an ADI Zone!
In the meantime - how do we go about solving this problem? I looked in the system32\dns folder and opened the domain.local file to see that it was completely empty - this is where our problem is. If the zone is not ADI, this text file is where all the DNS information is stored. There should also be a Backup folder in here, with a copy of all the files. In my case there was a fully populated domain.local file which I was able to copy back into the system32\dns folder and replace the empty domain.local file. A quick restart of the DNS Server service on the server and Hey Presto! DNS is back up and running!
The Exchange server also required a reboot to bring all the services back up and allow all staff members to access the mailboxes once again.
Moral of the story: Make sure your DNS Zone is ADI and backup the system32\dns folder daily!
In the meantime - how do we go about solving this problem? I looked in the system32\dns folder and opened the domain.local file to see that it was completely empty - this is where our problem is. If the zone is not ADI, this text file is where all the DNS information is stored. There should also be a Backup folder in here, with a copy of all the files. In my case there was a fully populated domain.local file which I was able to copy back into the system32\dns folder and replace the empty domain.local file. A quick restart of the DNS Server service on the server and Hey Presto! DNS is back up and running!
The Exchange server also required a reboot to bring all the services back up and allow all staff members to access the mailboxes once again.
Moral of the story: Make sure your DNS Zone is ADI and backup the system32\dns folder daily!
Subscribe to:
Posts (Atom)