kschroeder

JDS300:
This is probably because you have the client agents set to use the Agent Connectivity Credentials (ACC) and it is set to "Use application identity" for accessing packages. So your clients haven't retrieved the new password yet (still using the old cached one) and are locking the account out when they try to access packages on the package servers. To fix it:

1. Configuration > Altiris Agent > AA Configuration > Global Altiris Agent Settings
2. Click the Authentication tab
3. Change from "Use application identity" to "Use specified credentials" and put in a low-rights service account/password.

You'll still have to wait for all your clients to get the new configuration, but once that goes through you should be OK.

__________________
Kyle Schroeder
Symantec Trusted Advisor (TA)
(Yeah, at the other site)

JDS300

Let me try that. That can be any account? How will the clients get checked in though if the account is locked?

kschroeder

Well, as long as the Altiris service is running on the NS they can check in. That of course may require temporarily changing the NS AppId so that the service can be started due to the account being locked out (if it isn't already).

For an ongoing password change, setup 2 service accounts. When it is time to change the password for the in-use one, also change it for the secondary one, then update the ACC to use the 2nd account. Once all the clients have updated configuration, you can reset the account for the first one too. Then when you have to change the 2nd account, do the same process.

This is an old SMS trick, because SMS had to run the SMS Agent using credentials (or something like that; not sure how that worked on Win95 boxes).

__________________
Kyle Schroeder
Symantec Trusted Advisor (TA)
(Yeah, at the other site)

JDS300

I deleted my machine from NS to test it after the password change, and so far it hasn't called in to the NS yet.

JDS300

These errors are now showing up in the LogViewer. Sorry for hi-jacking the thread, but I was hoping this would be much, much easier.

Log File Name: C:\Program Files\Altiris\Notification Server\Logs\a.log
Priority: 2
Date: 8/24/2006 11:54:00 AM
Tick Count: 463001968
Host Name: HQDS1
Process: AeXNSAgent.exe (1760)
Thread ID: 1796
Module: AeXNetComms.dll
Source: CoNetworkTransport(116)
Description: HTTP Request Failed: No connection could be made because the target machine actively refused it. (-2147014835)


Log File Name: C:\Program Files\Altiris\Notification Server\Logs\a.log
Priority: 2
Date: 8/24/2006 11:54:00 AM
Tick Count: 463001968
Host Name: HQDS1
Process: AeXNSAgent.exe (1760)
Thread ID: 1796
Module: AeXNetComms.dll
Source: AeXNetworkTransport
Description: Get 'http://HQDS1.monroe.com:81/Altiris/NS/Agent/GetClientPolicies.aspx?xml=<Request configVersion="2"><WrkstaGuid>HQDS1</WrkstaGuid></Request>&compress=1&hash=3e995d60-4785-4207-600c-582d5b57dc84' failed: HTTP Request Failed: No connection could be made because the target machine actively refused it. (-2147014835)

JDS300

So how long does what need to wait before everything just start working again?

None of our clients are checking in. Can we just change the password back or use a new App Identity?

Nick

Question
How can the Notification Server application Id be changed?

Or if the NS application Id account password was changed how can the NS easily be reconfigured to accept this change?

Answer
1. Close the console

2. Go to the \notification server\bin directory and run aexconfig /? and see the options.

3. Use the option /svcid which requires user: and password:
Note: Make sure to put the user in as <domain or computer name[if local])\account name and then the password
Example: AeXConfig /svcid user:gemini9\administrator password:pw .

4. Then go to the console and it should go right in without the setup wizard.

Note: The password is typed into the console and displayed on the screen so secure the screen and then close the command window when the process is done. All of the NS handling of the password is encrypted as the NS log entry below shows
[Jan 31 15:36:06 I AeXConfig being run with command line: /svcid user:gemini9\administrator password:******* Altiris.NS.AeXConfig.Main AltirisNativeHelper.dll AeXConfig.exe (3032) 2648 ]

__________________
Scire potentia est (knowledge is power)

JDS300

Is this the same end result that rerunning the NSSetup.aspx produces?

Nick

Yes

__________________
Scire potentia est (knowledge is power)

JDS300

So if I ran the NSSetup.aspx and nothing is working. Can we revert back to the old password or setup a new App Id?

How do the clients know what App Id to use? Are they required to check in before using the new App Id?

Nick

Should be able to revert or setup a new App ID.

I believe the clients will become aware of the new App ID setting when they run their next configuration request cycle.

__________________
Scire potentia est (knowledge is power)

JDS300

Thats the problem I seem to be running into, that the clients arent requesting anything.

So if the old app id is being locked, it's going to refuse to allow them to connect because of the account being locked they won't be able to pull the new config. At least if I understand correctly.

So I guess now, we'd have to revert back to the old ID and password? Apply a new App ID and then in a couple days change the Old ID's password?

JDS300

Changed the old App ID password back and everything is happy again. Now we're going to just change the app id all together, but how do we know when all of the clients are using the new id instead of the old?