A couple of days ago, a fellow colleague was setting up a VM with SQL and then Microsoft Dynamics or that was the plan. The VM was relatively clean with only Windows updates installed, AV, and a couple of small footprint utilities. The VM was staged and then a snapshot created of the VM in a clean state before loading SQL and Microsoft Dynamics.
Upon installing Microsoft SQL server, he kept seeing the error in the setup Bootstrap log concerning two errors:
- There was an error generating the XML document. Error code 0x84B10001
- the computer must be trusted for delegation sql setup error
The Windows 2012 R2 server was joined to the domain and everything looked good. After receiving the error above, different versions of SQL were tried to rule out SQL 2014 – SQL 2008, 2012, etc. A quick Google and none of the issues that others had reported as possible causes for these errors in our case did not make sense. UAC was left enabled on the box. However, there was a unique set of circumstances with the environment this server was being built in. The infrastructure contained two Windows Domains. Users login to one domain and then servers, workstations are being joined to another domain.
The user that was getting the issue logging into the domain was using the User domain account which was part of local administrators to login to the box before running the SQL install. Also, the box had a snapshot restored on it AFTER it was joined to the domain, which all of us have seen monkey with a domain joined workstation when you rollback a snapshot due to Kerberos tickets, time, etc.
As it turns out we were dealing with a couple of different but coincidental issues. The first time my coworker ran the SQL install, he was logged in as his domain account and not the administrator account that the box was built with in the native machine domain. He received the errors mentioned above.
Then the server had the snapshot rolled back to a clean state. No matter which user tried the install, it still bombed with the above errors about delegation and XML document.
In our case the resolution came in a two step approach. First, we rolled the snapshot back on the server to the clean point in time. Then we disjoined the domain and rejoined the domain to make sure everything was good from a machine account/domain perspective. Finally, we logged into the native machine domain as the administrator and ran the install and the install worked fine!
If you are seeing these errors above, be sure to check out your environment. Are there multiple domains? Are users and machine accounts in different domains? Has the server been rolled back to a previous snapshot if it is a virtual server? All of these factors can lead to the error messages i the Setup Bootstrap log above and cause the SQL installation to fail.