NetBackup 11 Install Fails With Domain Accounts

A NetBackup 11 Windows installation that says the web service account does not exist should be checked against NetBackup's web server account requirements before Active Directory itself is blamed. For Windows, the account and group must exist in the form NetBackup expects, the user must belong to the web service group, and the account needs the effective “Log on as a service” right on the primary server.

A recent installation case involved Windows Server 2019 joined to Active Directory. The administrator wanted to use a domain account and reported an error saying the account did not exist or a user in the group did not exist on the primary server. DNS worked and a Group Policy supposedly granted “Log on as a service,” yet installation still failed. That combination makes local effective configuration more important than assumptions about the domain.

Does a domain-joined NetBackup server require a domain web service account?

A domain-joined server does not automatically require a domain account for NetBackup's web service. Veritas documents a local account and local group as the normal Windows example, with nbwebsvc as the default local user and nbwebgrp as the default local group.

The important exception is clustering. Veritas states that domain accounts must be used for clustered environments on Windows. That distinction should be made before troubleshooting begins. A standalone Windows primary server that happens to be a member of an Active Directory domain is not the same architecture as a clustered NetBackup primary server.

If the server is standalone, testing with the documented local account pattern can establish whether the installer and local permissions are healthy. If the server is clustered, use the required domain-account design and verify it consistently on every participating node.

Do not choose the account type because “domain feels more enterprise.” Choose it because the deployment architecture and security policy require it.

What does NetBackup require from the web service account?

NetBackup requires a low-privilege account for its primary server web service, and Veritas explicitly warns against giving that user administrator privileges. The default local names are nbwebsvc for the user and nbwebgrp for the group, although the names can be changed.

On Windows, the documented setup creates the user, creates the local group, makes the user a member of that group, and grants the user the “Log on as a service” right. Veritas says primary server installation fails if those requirements are not met.

There is also a small detail that can ruin an otherwise correct domain design: the Windows web service username is limited to 20 characters. Long descriptive service-account names are common in Active Directory. Count the actual account name before spending time on DNS and policy debugging.

The account is supposed to be constrained. Turning it into a local administrator to get past setup defeats the security model and can hide the permission that was actually missing.

Why can Group Policy say the right is granted while setup still fails?

Group Policy can describe the intended right while the effective local state on the NetBackup server still differs. The installation case included exactly this tension: the administrator said the domain account had “Log on as a service” through Group Policy, while commenters kept pushing them to verify the actual local security assignment.

Check the effective user rights on the primary server after Group Policy has applied. Confirm that the relevant policy is not being overwritten by another GPO with higher precedence. Check whether the right is granted directly to the account or through a group, and verify that the account's current token actually contains that group membership.

Also check the opposite policy. Windows can explicitly deny service logon. A deny right wins over an allow right. If enterprise hardening policy adds service accounts or broad groups to a deny list, the NetBackup account can look correct in one GPO and still be unusable.

The point is not that Group Policy is unreliable. The point is that the installer experiences the server's effective security state, not the administrator's intended policy design.

How should nbwebgrp be checked with a domain account?

The account used by the web service must be recognized as a member of the web service group NetBackup is using. The default local group name is nbwebgrp, but custom names are possible, so verify the exact group passed to the installer.

On a standalone Windows server, inspect local group membership directly. If a domain account is used, confirm that the domain identity appears in the local group and resolves correctly from the server. Do not rely on the fact that the account exists in Active Directory. NetBackup needs the relationship between the user and the configured web service group to be valid on the primary server.

If the error says a user in the group does not exist on the primary server, simplify the test. Remove stale or misspelled members from the group. Confirm there is only the intended identity. Verify the domain controller can resolve the account and that the server's secure channel to the domain is healthy.

Then rerun the prerequisite check or installer. One clean account and one clean group provide much better evidence than a group filled with inherited test identities.

What else should be verified before reinstalling?

Before reinstalling, verify the account name length, password, account status, group membership, effective “Log on as a service” right, and whether the deployment is clustered. Also confirm the account is not disabled, expired, locked, or restricted from logging on to the primary server by an Active Directory workstation rule.

Use the exact account format the installer expects. If one screen uses DOMAIN\\user and another validation step resolves a UPN, keep the identity consistent and verify how NetBackup records it. DNS success only proves the server can resolve hosts. It does not prove a service account can be resolved, authenticated, or granted local rights.

If a previous failed installation created partial local users or groups, inspect them before another attempt. Do not keep layering new accounts over stale state without understanding which one the installer is using.

This is similar to recovery troubleshooting in general. The Proxmox backup comparison deals with a different platform, but it reinforces a useful habit: separate the control-plane prerequisite from the data-protection function before changing the whole system.

Should you test with a local account?

On a nonclustered Windows primary server, a local account can be a useful diagnostic because Veritas documents that setup directly. If the documented local nbwebsvc and nbwebgrp pattern succeeds, the installer is capable of completing and the domain-account path deserves closer scrutiny.

That does not mean a local account should automatically become the final production design. Security policy may require centrally managed service identities. The test simply divides the problem.

On a clustered Windows deployment, do not use this shortcut because Veritas says domain accounts are required. Troubleshoot the domain account correctly across all nodes instead.

Once the installation succeeds, record how the account is managed, where its rights come from, how password changes are handled, and which monitoring will detect service-logon failures. A service account is a lifecycle dependency, not a one-time installer field.

The same principle applies to backup repositories described in the Proxmox Backup Server guide. Credentials, encryption keys, and management identities have to survive normal maintenance as well as initial setup.

What would I do with the Windows Server 2019 failure?

I would first identify whether the primary server is actually clustered. If it is standalone, I would test the exact documented local-account pattern to prove the installer path. If it is clustered, I would stay with a domain account and validate it on every node.

Next I would count the username characters, inspect nbwebgrp membership locally, verify the account's effective service-logon right, check for a deny right, and confirm the account is enabled and allowed to authenticate to the server. I would not accept “the GPO contains the setting” as the final verification.

Only after those checks would I reinstall or change broader NetBackup components. The original error is about identity and group recognition. Treat it that way until evidence points elsewhere.

The safest fix is the one that leaves the web service running with the limited privileges NetBackup designed for it. If the only configuration that works is an administrator account, the problem has been bypassed, not solved.