Default servcienow user created during acc agent installation

[BasantChauhan]

Hi Servicenow ITOM Community,

Kindly help to address below points related to Agent client collector: 

• Need to reason out why default local user created by the name “ServiceNow” is not recommended to use for Agent installation/upgradation on windows systems
• Need to reason out why current ID used in Agent installation and upgradation is not supported in Linux servers

How to manage and automate the upgrade process of systems that have utilized the default servicenow user for installation process?

[Abbas_5]

Hello @BasantChauhan,

Please refer to this link below;

https://www.servicenow.com/docs/bundle/yokohama-it-operations-management/page/product/agent-client-c...

If it is helpful, please hit the thumbs up button and accept the correct solution by referring to this solution in future it will be helpful to them.

Thanks &  Regards,

Abbas Shaik

[AJ-TechTrek]

Hi @BasantChauhan ,

As per my Understanding, That might be helps you.

1. Why is using the default local user “ServiceNow” (created by ACC) not recommended for Agent installation / upgrade on Windows?
* The “ServiceNow” local user that ACC creates:
* Is a local user, not a domain user, so it lacks centralized management.
* Is limited in permissions; it often has only the minimal rights ACC needs to run, but may not have enough for initial installation or upgrades which often require admin privileges (e.g., writing to Program Files, setting services).
* Using this local account makes:
* Upgrade automation harder, since it can't access shared network resources (e.g., fileshares where upgrade packages are kept).
* Credential rotation and audit difficult: domain security teams prefer managing domain service accounts via Active Directory.

* Best practice:
 Use a dedicated domain service account with the right permissions to install & upgrade the

ACC agent, while still allowing the agent service itself to run under the lower-privilege local “ServiceNow” user.

2. Why is the current ID used for agent installation/upgradation not supported on Linux servers?
* On Linux, ACC expects:
* The installer is run by a user with root privileges (or via sudo).
* The agent usually installs under /opt/servicenow/ and needs to register a service.
* If you reuse the same non-root user (e.g., an ID that doesn't have sudo), installation fails because:
* It can’t register/start the agent service (systemd/init.d).
* It can’t write to privileged system paths.
* For Linux, recommended:
 Perform installation & upgrades using a privileged account (root or sudoer) that can create services and write to protected directories.

3. How to manage and automate upgrade of systems where the default “ServiceNow” user was used?
If you already deployed agents using the default local user:
* Identify those systems (use ACC dashboard: check agent service account).
* Plan upgrade:
* Create a proper domain account (Windows) or sudo-enabled user (Linux).
* Configure your automation tool (SCCM, Ansible, etc.) to:
* Stop the existing agent.
* Re-run installation using the new account.
* Ensure service is configured to run under the correct account going forward.
* Automation can be scripted:
* Windows: PowerShell script that stops service, installs MSI with correct account, restarts service.
* Linux: Ansible / shell script that stops service, reinstalls, fixes permissions.

Important:
Changing the agent service user after installation usually isn’t enough — better to reinstall or upgrade the agent properly to register under the correct user.

Please appreciate the efforts of community contributors by marking appropriate response as Mark my Answer Helpful or Accept Solution this may help other community users to follow correct solution in future.
 

Thank You
AJ - TechTrek with AJ - ITOM Trainer
LinkedIn:- https://www.linkedin.com/in/ajay-kumar-66a91385/
YouTube:- https://www.youtube.com/@learnitomwithaj
Topmate:- https://topmate.io/aj_techtrekwithaj (Connect for 1-1 Session)
ServiceNow Community MVP 2025