Configuration Wizard fails at the Database Configuration step with "The server has not found anything matching the requested URI" when using Azure AD Password authentication on a domain-joined SolarWinds Platform engine

7/2/2026 6:56 PM

7/9/2026 9:06 PM

When the Configuration Wizard runs on a SolarWinds Platform engine whose host is joined to a Windows Active Directory domain, and the database connection is set to Azure SQL with Active Directory Password authentication, the wizard fails at the Orion.ConfigureDatabase ("SolarWinds Platform Database") task. Because this is a hard-dependency task, its failure cancels the entire run and leaves the remaining tasks in a Pending state.

The account is entered and validated as a User Principal Name (UPN), for example user@example.com. However, when the wizard builds the final SQL connection string, the UPN is replaced with a Windows NetBIOS DOMAIN\user value, for example EXAMPLEDOMAIN\user. Azure AD Password authentication requires a UPN, so the token request fails and the database connection is never opened.

Symptoms and sample log entries (values such as host names, domains, accounts, IP addresses, and timestamps are generic and will differ in your environment):

• The connection string built by the wizard shows a DOMAIN\user value instead of the UPN:
  

  YYYY-MM-DD HH:MM:SS,000 [1] INFO  ConfigureDatabase - Built Connection String: data source=tcp:example-sql-server.database.windows.net;initial catalog=SolarWindsOrion;user id=EXAMPLEDOMAIN\user;encrypt=True;trustservercertificate=True;authentication="Active Directory Password"

• Earlier in the log, the impersonation/domain-resolution step reflects the host's Windows domain:
  

  YYYY-MM-DD HH:MM:SS,000 [1] INFO  ImpersonationContext - Now impersonating user user from domain EXAMPLEDOMAIN.

   

• The Azure AD (ADAL) token acquisition then fails, and the database task is marked failed:
  

  YYYY-MM-DD HH:MM:SS,000 [1] ERROR ConfigureDatabase - AdalException: The server has not found anything matching the requested URI (Uniform Resource Identifier).
  YYYY-MM-DD HH:MM:SS,000 [1] ERROR ExecutionEngine - Task Orion.ConfigureDatabase failed. Configuration Wizard has been canceled. Aborting...

For comparison, on an engine whose host is not joined to the Windows domain, the same account and authentication mode succeed because the UPN is preserved. In that case the built connection string shows the UPN (for example user id=user@example.com), the Azure AD token is issued, the database task completes, and the wizard finishes successfully. The failure is specific to engines running on domain-joined hosts.

Hybrid Cloud Observability

On a domain-joined machine, the Configuration Wizard attempts to resolve the supplied Azure AD UPN to a Windows NT account. On a domain-joined host this resolution replaces the original UPN with the corresponding DOMAIN\user account name. That DOMAIN\user value is then written into the SQL connection string that uses Active Directory Password authentication. Because Azure AD Password authentication requires a UPN (user@domain) and cannot use the DOMAIN\user format, the token request fails and the database connection cannot be established.

This condition typically requires all of the following:

• The engine host is joined to a Windows Active Directory domain.
• The database is Azure SQL and the connection uses Active Directory Password authentication.
• The account is a UPN whose Azure AD tenant differs from the host's Windows domain.

Note: the wizard re-translates the UPN to DOMAIN\user each time it builds the database connection string, so the condition recurs on every Configuration Wizard run performed while the host is domain-joined (including during upgrades).

The following workaround has been validated to allow the Configuration Wizard to complete:

1. Temporarily disjoin the engine host from the Windows Active Directory domain.
2. Run the Configuration Wizard and complete the database configuration (the Database Configuration step completes off-domain because the UPN is no longer translated to DOMAIN\user).
3. Rejoin the host to the Windows Active Directory domain.

Once the host is rejoined, the stored UPN / Azure AD Password connection continues to authenticate normally, and polling resumes as expected.

Because the disjoin/rejoin cycle affects Windows domain trust, plan for the following domain-side steps after rejoining (these are standard AD operations, independent of SolarWinds, and do not affect polling):

• Be prepared to repair the machine secure channel / trust relationship if domain logon or RDP fails after rejoin (for example, "the security database on the server does not have a computer account for this workstation trust relationship"). This is a standard AD trust repair and does not require re-running the Configuration Wizard.
• Reboot the host after rejoin so the network interface is re-registered in DNS and reclassified as domain-authenticated, which may otherwise block connectivity by host name.

Additional options that may unblock the wizard, depending on what your environment allows:

• Run the engine on a host that is not joined to a Windows AD domain.
• If supported by your Azure SQL configuration, use SQL Server authentication (a SQL login) instead of Azure AD Password authentication, which avoids the UPN translation path. This option is not available when the environment enforces Azure AD-only authentication.

Because the condition recurs on each domain-joined Configuration Wizard run, the workaround must be repeated whenever the wizard is run while the host is domain-joined, until the host is on a build that contains the permanent fix.

A permanent product fix is in progress. As the fix has not yet been released, monitor this article and the product Release Notes for the confirmed release version and availability.