NearPoint SQL Server Authentication vs. Windows Authentication

While helping a customer resolve an issue with their Nearpoint eDiscovery installation this morning, I learned that Autonomy recommends against configuring NearPoint to use same-named SQL logins and domain accounts. Apparently this can somehow confuse NearPoint when it tries to apply certain updates to the SQL databases. Autonomy recommends either using the SQL ‘sa’ account (always a bad idea) or creating/renaming the existing same-named SQL login account so that it no loner matches the NearPoint service account (the domain account). After making this change, you also need to run the dbreconfig.ps1 PowerShell script to update the DB user accounts on the master node. Prior to running that script, you also need to explicitly grant the SQL login dbo rights to the NearPoint databases under the User Mapping section of the login properties.

The following is a quote from an Autonomy support engineer regarding this issue:

Not all Stored Procedures (SPs) that NearPoint runs need to connect using SQL Authentication, however NearPoint needs to connect to the databases and run certain SPs using SQL Authentication. From what I know, most of these are during upgrades and rollup installs. If the DBuser account is named the same as any NT account, NearPoint’s attempt to connect will default to Windows Authentication and will fail. There’s certain changes to the databases that need to be done as a db owner using SQL Authentication.

This could explain why you’ve had apparently so many problems with upgrades and rollup installs in the past.

Leave a Reply

Your email address will not be published. Required fields are marked *