DSA Replication Error During AWS Server Migration - Login failed for user (28000: 18,456)

1

Hi everyone,

We are currently in the process of migrating our Primary BigFix server to AWS and have run into a replication block. I wanted to share our scenario, the errors we are seeing, and our proposed fix to see if the community agrees with our approach.

The Scenario Our DSA (Distributed Server Architecture) environment is configured to use NT Authentication with domain computer groups for inter-server communication.

The Issue During the setup and configuration process of the newly migrated PDC server in AWS, database replication began failing. The BigFix Administration console shows a <connect...> expected status, but the Last Replication Status displays an ongoing login failure.

The Logs Reviewing the GatherDB.log on the primary server, we see the following repeating errors:

Fri, 03 Jul 2026 10:43:54 +0000 -- 2088 -- Replication connection attempt failed for server '[Replica_Server_DNS]\BIGFIX2D,1999': Database Error: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Login failed for user '[DOMAIN]\[New_AWS_Server_Name]$'. (28000: 18,456)

Fri, 03 Jul 2026 10:48:55 +0000 -- 22280 -- Replication connection attempt failed for server '[Replica_Server_DNS]\BIGFIX2D,1999': Database Error: [Microsoft][ODBC Driver 17 for SQL Server][SQL Server]Login failed for user '[DOMAIN]\[New_AWS_Server_Name]$'. (28000: 18,456)

Root Cause Analysis The $ at the end of the username indicates that the BigFix services are attempting to authenticate to the secondary SQL Server using the new AWS server's Windows Machine Account. Because this is a new server instance, it appears its machine account has not yet been granted the necessary login permissions on the replica SQL Server.

The Proposed Solution To resolve this and unblock the migration, our plan is to align the target SQL Server with the BigFix DSA NT Authentication requirements by doing the following:

  1. Verify AD Group: Ensure the new server's machine account is added to the Global Security Group used for BigFix replication in Active Directory (and reboot the server to update its credentials).

  2. SQL Login: On the replica SQL Server, open SSMS and create a Windows Authentication login for either the specific machine account ([DOMAIN]\[New_AWS_Server_Name]$) or the Global Security Group.

  3. Database Mapping: Set the Default Database for this login to BFEnterprise.

  4. Permissions: Grant the login the sysadmin Server Role, OR map it to the db_owner role on both the BFEnterprise and master databases.

Feedback Request Before we finalize these changes with our DBA team, can anyone confirm if this is the correct approach? If you have successfully navigated a similar AWS migration in a DSA environment, are there any other recommended solutions or best practices we should consider instead?

Thanks in advance for any insights!

2

Have you looked into this page - Installing Additional Windows Servers (DSA)

the following is mentioned:

  • Each DSA Server must have its own SQL Server database engine, either local or remote. Ensure that each server uses the same SQL Server version. Do not use the same database engine to store the databases of two different DSA servers. Each DSA Server must be able to access its own database engine and also the database engines of the other DSA Servers.
  • Use the same authentication method to access all the SQL Server database engines, either Windows authentication or SQL Server authentication. If you chose the Windows authentication method, use the same domain user to access all your database engines. If you chose the SQL Server authentication method, use the same user name and password. Ensure that your database user has sysadmin privileges on all database engines.