Application Identity Problem
Hi,
I have problems with NS 7.0. The password for the application identity had to be change and since then we are unable to use or access the console on regular basis
Tried: AeXConfig /svcid
Tried: SIM repair
Now we have limited access to the console because an account lockout on the application identity, we reset the account and we have access again until the account locks again
Doing some research I found the following text in the SMP Help
NS processing Setings
"If the application identity password fails, Notification Server is unable to access the CMDB. You cannot reset the application identity through the Symantec Management Console, as the console uses the same password to access Notification Server. You need to use the ASConfig utility to access the Web services directly and reset the application identity password using the appropriate command line."
I can´t find information about this ASConfig utility, someone has use it?
Any help will be greatly welcome.
Many Thanks in advance
Rubén
Comments
Is it enough to fix Windows services?
Is it enough to modify your Windows Services to use the new account, then reboot? If they can start the services and access the database, that might be enough.
ASConfig seems to be related to SQL, found in C:\Program Files\Microsoft SQL Server\90\Shared\ASConfig -- but my ASConfig folder is always empty.
Mike Clemson, Senior Systems Engineer
Intuitive Technology Group -- Symantec Platinum Partner
Thank you Mclemson!! well...
Thank you Mclemson!!
well... I had Change all the services to the new password, including the MSSQLSERVER service (BTW I use SQL 2005 on the same server) and still have lockout problems.
Run SIM repair again but now I get a "Repair Failed, Configuration Failed" error.
Contact support if in production
If this is in production, I'd contact support. I'm at a loss for next steps.
Mike Clemson, Senior Systems Engineer
Intuitive Technology Group -- Symantec Platinum Partner
I would investigate where the lockouts are coming from
Microsoft offeres a free tool to assist in this. It appears you have done your best in resetting the Altiris password. I think a script or something else is using the old password.
Jim Harings
HP Enterprise Services
1st Rule of Connect Club: Mark the post that helped you the most as a 'solution'. 2nd Rule of Connect Club:You must talk about Connect club.
Having same issue.
I'm having the same issue. The app identity was changed on the databases of several servers as part of the change. The reset appears to work for most things, but for task server doesn't appear to be working. Our PMImport has not run since the change.
Check in Services.msc, I think there's a couple of Services
that Task Server uses that run using the context of the App Identity and will need the password changing there.
PAC?
Do you have the Package Server package access credential set to use the old password by chance (maybe this has a new name in NS7)? Or maybe a test/dev server that is still up and running with the old password? Another thought would be a package that is set to run with the appID credentials and manually entered password.
Something else to try would be to create a new account (AltirisSvc2 or whatever) and use the AeXConfig utility to change the App ID to that. Be sure to grant all permissions the original account had to the DB, NS server, etc.
Thanks,
Kyle
Symantec Trusted Advisor
For Forum threads, please click "Mark as Solution" if answered.
For all content, please give a thumbs up if you agree with or support the post.
I had to run AeXConfig
I had to run AeXConfig /configureall to get things mostly working. What I found, however, is that all my Software Update Policies received the default target - not the filter I set up specifically for production after I ran the utility with the /configureall switch.
It also took software update policies in my test collections and put them into this default target - potentially putting patches out that had not been fully tested. Luckily the server was not yet in production and we are now going to v7.1. We didn't bother troubleshooting it further, as it happened the day before we made the decision to move to the newer version.
The command line also did not resolve the issue with Task Services.
Unfortunately when you have
Unfortunately when you have to run a configuration on a solution it causes the policies to be reset to their default settings. So any default policies you've modified for your needs will need to be updated again.
Rather..
Rather, I would just use it as a reminder to always Clone and never modify default policies, reports, or other cloneable items. On the flip side, if you do this, you may want to be cautious prior to version releases that could cause agent upgrades to occur -- disable all such policies prior to an upgrade. That's just one example.
Mike Clemson, Senior Systems Engineer
Intuitive Technology Group -- Symantec Platinum Partner
Would you like to reply?
Login or Register to post your comment.