Client Management Suite

Hello,

I just upgraded our Altiris infrastructure during the weekend.

From CMS 7.5HFx to 8.0HF1 and during the night, the identity account started to lock pretty badly.

 

To help, I wrote a little powershell to unlock it until I find the solution. The script is currently unlocking every 1 second.

We have 115 PS and about 19000 clients.

 

I did not change the account password or anything.

 

I know that the agent and plug-ins deployment is still in progress when I look the database.

Anyone has a clue?

 

Regards.

 

RJ

 

Check out this article. It contains some links for troubleshooting account lockout.

https://support.symantec.com/en_US/article.HOWTO10951.html

 

1. Is there any useful information in "Altiris Log Viewer" on CMS Server, regarding to database connections retries, etc and AppIdentity locks due this?
2. You AppIdentity is used somewhere else? For example in some "Client task" or in "Global Agent Settings"? Maybe someone changed wrong password there and now it causes locking of this account?

 

For a while the recommended way to change the service account ("App identity") password was to create a duplicate account with identical rights and then change the account via the console. If you do this and the new account starts locking you know you have a problem with the system, if the old account keeps locking out you know it's been used somewhere else. Here's the process: http://www.symantec.com/docs/TECH194254

Hello,

thank you all for your replies.

I know that I did not give lots of informations.

The account is locking less often now. I think that the old agents still in the field are locking the account for some reason.

The agents are upgrading slowly anyway. The EventQueue is geting more events that it can process.

We changed a few settings and the EventQueue decreasing slowly.

I found that the Task Server service on the NS was giving a lot of errors in the log and at first I changed the service logon to the AppIdentity account for a while. When I reverted the service back to Local System, it started to do better.

Using a powershell script, I could see that the locking was coming from clients. It seams that more the clients are upgraded less locks occurs.

We did not change the AppIdentity password. The password is the same as it was since the first installation with Altiris 6.0 ten years ago.

RJ

Do you have an identity account whose username is a local credential as well as a domain credential? If you do when you log-in under the local account, group policy processing I think will apply and your local account will try to authenticate to the domain. This can cause these types of lockout.

This issue often appears on upgrade simply because of the recent changes in SIM which force you now to login to the server under the identity account.

Any new development or resolution? I am seeing this in 2 environments as well.

Hello,

sorry for the delay, we were very busy trying to get ready for Patch Management monthly process.

We openned a ticket at Symantec.

Regarding lock accounts, we still have clients that locks the account but much less. I dont't know if it occures only once for each but we saw that once the client is restarded, it upgrades and stop locking.

The agent and plug-ins deployment is almost completed that is why it locks less often. It locked 9 times yesterday.

What was found with Symantec, was that some storedprocs were locking tables and EventQueue inbox processing was not working properly. It was taking alomost 30 seconds to process only one light Basic Inventory NSE.

The 20000 clients were flooding the queues, inventories were not procesed, agent deployment was doing very slowly. Some code was changed in a storedproc by Symantec and it finally started to process. We spent almost a week and a half to figure out where it was blocking.

I have been told that a fix will be included in a future HF release.

For locks, I don't know exactly where is the problem.

RJ

I have also encountered this lockout issue with two customers.
To my understanding it has something to do with the upgrades of the plug-ins.

One of the customers gathers account lockout events from the domain controllers in their monitoring tool.
This made it very easy for me to locate which client computer actually locked the service account.
Each time the offending computer was still running with a 7.6 agent but one of the plug-ins (mostly deployment solution plugin) was already upgraded to version 8 .
Therefore I decided to modify the resource target for each of the plug-in upgrade policies (inventory, software management, software update, deployment solution, ...) and I added an additional exclude in - filter  - Windows Computers Requiring Symantec Management Agent Upgrade.
This ensures that the Management Agent gets upgraded first before upgrading the plug-ins.

After this change the lockout no longer occurred.

Good find, a bit odd though because previous upgrades usually used to enforce the base Symantec Management Agent being upgraded first in exactly this way.

Thank you LCode,

You putted your finger right on the problem.

I can see some clients that have Software Management Solution Agent 8.0.2225.0 over Altiris Agent 7.5.

I hope that this will be fixed in future releases.

 

RJ