2

I just (almost) finished our upgrade to Sitecore 9 (from 8-something) and completed the XConnect setup (just SIF as you would with a normal install). The installation (on a dev server environment) went fine, everything seemed to be running but after finally enabling the XDB on the (upgraded) site and testing it we get lots of errors in the logs (of both xconnect and website) saying:

[Error] An error occurred while communicating with the SQL Server System.Data.SqlClient.SqlException (0x80131904): Could not obtain information about Windows NT group/user '..\..', error code 0x5.

Which is probably true, as I don't want my sql database to know about my domain user. I see the logs with my account as well as with one of my colleagues. Weird thing is that I have been on the site after enabling xdb, but my colleague hasn't. He did visit the site a few days ago, but xdb was still disabled then.

I think I'm missing something - probably something silly.. but can't figure out what. I did check the connectionstrings obviously, and they are ok (using a sql user and pwd).

Improve this question
3
  • What does the connection strings look like? (feel free to obfuscate any sensitive info)
    – Pete Navarra ♦
    Dec 14, 2017 at 14:07
  • Are you getting these errors in the Sitecore logs or the xConnect logs?
    – LonghornTaco
    Dec 14, 2017 at 14:14
  • Errors are (were) in both logs. I assume xConnect is passing the error through to the site..
    – Gatogordo
    Dec 14, 2017 at 15:59

1 Answer 1

Reset to default
1

I managed to fix the issue and it was something rather silly indeed. The connectionstrings were perfectly fine (so I'm not going to post them - when obfuscating they look exactly like the ones in a clean SC9 setup).

For the upgrade, I restored database backups from our 8.x site on SQL2012 and restored them on a SQL2016. Those databases were "upgraded" and during the whole upgrade process we had to deploy 2 extra databases (dacpac's). The other databases were installed by SIF when installing xconnect.

The problem was that when restoring/deploying the databases, the owner of the database was set to the currrent user (being our domain user as it's only a dev environment and we didn't take the effort to login with an admin sql user). Not sure which database was causing the troubles but after switching the db owner to a sql admin user everything worked.

So, lesson learned:

Use a (dedicated) sql admin user when restoring/deploying the databases for an upgrade

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.