Deployment Solution

I've been chasing down an issue that we're seeing with x64 aclient processes becoming more and more unresponsive. Even the admin gui is susceptable to this.

I believe I've tracked it down to an issue with the way that the aclient and aclntusr processes interact through the registry.

When you login to a server, the aclntusr process is started under your context, and creates a registry entry : HKLM\SOFTWARE\Altiris\AClntUsr\Users\<userid>\Port with a TCP port that the aclntusr process is listening on (bound to localhost I think).

The aclient process polls this area on a regular basis, and connects to any TCP ports specified, to talk to the aclntusr processes.

When the user logs off, the entry is deleted from HKLM\SOFTWARE\Altiris\AClntUsr\Users and aclient no longer tries to talk to that particular aclntusr.


HOWEVER....

Under x64 windows, the aclntusr process is still a 32bit app, and actually writes to HKLM\SOFTWARE\Wow6432Node\Altiris\AClntUsr\Users\<userid>\Port which is then 'registry reflected' to the HKLM\SOFTWARE\Altiris\AClntUsr\Users area.

When the user logs off, the deletekey is only applied to the HKLM\SOFTWARE\Wow6432Node\Altiris\AClntUsr\Users area and not to the HKLM\SOFTWARE\Altiris\AClntUsr\Users area, leaving orphaned entries there, which aclient continues to try and connect to, and appears to hang while doing so.

Turning on debug logging for the aclient shows many entries like this:
[04/24/08 15:15:07.378] CInteractiveUserService::SendDataToHiddenApp(): Thread 1 returned error 10061.
[04/24/08 15:15:07.393] CInteractiveUserService::SendDataToHiddenApp(): Thread 2 returned error 10061.
[04/24/08 15:15:07.425] CInteractiveUserService::SendDataToHiddenApp(): Thread 3 returned error 10061.
[04/24/08 15:15:07.440] CInteractiveUserService::SendDataToHiddenApp(): Thread 5 returned error 10061.
[04/24/08 15:15:07.472] CInteractiveUserService::SendDataToHiddenApp(): Thread 6 returned error 10061.

TCP error 10061 is a connection refused, which is due to nothing listening on that port.

Has anyone else seen this, is it a known bug, is it fixed in Altiris 6.9? I've been trying to find any similar posts but not found anything here or on altirigos.

I've just talked this through with one of our Citrix guys, who's a bit more used to dealing with registry updates and shadow keys, and we think that rather than any "registry reflection" going on, it's the aclntusr that's writing both keys, but only deleting one of them.

Well we've now had confirmation that this is an issue in 6.8SP1 6.8SP2 and 6.9

The recommendation we've been given is to use the DAgent for Windows Server 2003 x64, but I thought that wasn't officially supported, and the DAgent seems to run jobs in the background rather than in foreground on the console, so if an error pops up, you can't see it :-(

I see the same exact issue. As a work around, after our scripts run, we add:

net stop aclient & net start aclient

It's a work around, but it works. Has Altiris fixed the issue or assigned a KB article to it?

They recommended disabling the aclntusr process with reference to this KB article:

https://kb.altiris.com/article.asp?article=37661&p=1

Seems to do the trick for us, you just lose the display of logged in users on the Deployment Console. I've not seen a KB article relating to the fault itself though.

Thanks for the info. I opened up a case with HP to get this resolved. I'll post up their results.

HI
Any moore info regarding this matter?
Is there a new client?
/Sten