Showing results for 
Search instead for 
Do you mean 
Community Home Request Access Read Blogs Share Your Ideas Search Community View My Settings
Reply
Highlighted
Bronze Super Contributor
Posts: 146
Registered: ‎04-01-2009
Accepted Solution

login failed: unspecified error.... Citrix Xenapp 6

Hi,

 

We have a rather annoying problem. We are running 7.5.4 LAN as a published application on a 4 server Xenapp 6 Citrix farm.

 

We are using windows authentication for the SLX login. Sometimes the users can launch SLX and are logged right into SLX without problems. Other times, the same users will instead get a SLX login prompt, and when they enter their credentials, will get the  "Database login failed: Unspecified Error" message.  Sometimes, if the user cancels here and tries a second, third, or fourth time, they get logged right in. Sometimes they will try for 45 minutes to an hour and continue to be denied access to SLX. 

 

Checkng the Citrix Server the user is connected to, we find that it happens regardless of the Citrix server they happen to be connected to when they log into Citrix.

 

Checking the data connection for the session when they are prompted to login, after selecting the SLX server from the dropdown, when I click the database dropdown, it is empty.   From a cmd prompt at the users own PC, they can ping the SLX server with no problems.

 

Seems kind of random.  Any thoughts?


Thanks

Highlighted
Bronze Super Contributor
Posts: 146
Registered: ‎04-01-2009

Re: login failed: unspecified error.... Citrix Xenapp 6

BTW, I've been through the KB article on this error, but none of the solutions helped.

Highlighted
Bronze Super Contributor
Posts: 146
Registered: ‎04-01-2009

Re: login failed: unspecified error.... Citrix Xenapp 6

Well, we *seem* to have fixed the symptom to this issue. As summed up by our BP....

 

"Although we couldn't’t pinpoint a specific user or Citrix server as causing issues, we did see an error message in the Event Viewer pretty frequently:

 

http://community.sagesaleslogix.com/t5/Customer-Experience/SLXKeepLoggedInThread/td-p/1132/page/2

 

From this thread and others we saw that there may be references in the registry to the old SalesLogix server. We found references on each Citrix server to the old connection under HKLM\Software\Wow6432Node\SalesLogix\CUD\ADOLogin. I’m not sure what CUD\ADOLogin is for, as I only saw it referenced in the Implementation Guide and Upgrade guides for 7.2. We removed these keys, then corrected the keys under HKLM\Software\Wow6432Node\Microsoft\Windows NT\Current Version\Terminal Server\Install\Software\SalesLogix\ADOLogin, as these were different across each of the four Citrix servers.

 

Each user’s roaming profile was deleted and recreated in case anyone still had a data link in their registry user hive pointing to the old server.  "

 

Yes, during the upgrade, the data links were all recreated. 

 

So what would happen is that a user would attempt to log in using AD authentication and their roaming profile would provide data link settings that pointed to the old server / environment.  At that point, the SLXSystem service would just kind of say, "Let me think about that......forever...", and wouldn't crash, shutdown, or throw any hissy fits... it would just hang, appearing to be running.  Then as subsequent users tried to log in, and happened to hit the same Citrix server, they wouldn't be able to because SLXSystem was out to lunch. Eventually, they'd usually be connected to a different server that had SLXSystem running as it should. 

 

The Symptom was that users couldn't get logged in. To me, the immediate issue was that one user providing bad data link credentials could hose the SLXSystem service for all other users. The root issue is really that SLXSystem does not shut itself down, restart, or provide any meaningful event logs when specific events affect it. (The events listed in the event logs are actually from subsequent users' attempted logins....).  SLXSystem is touted as a self-recovering service... I don't see it.

 

 We have the same issue with the Sync Service. It will appear to be running when in fact it is hung. Our IT group has this odd idea that they shouldn't have to constantly go check services and restart them just to be sure they are not hung.