Sql-server – Do I need a domain controller for multiple PCs accessing the same SQL server db? How to configure it

This is not definitive proof but just my opinion based on what I learned from a PluralSight course Paul Randal did on wait stats.

PREMEPTIVE waits are indicative that SQL Server Operating System (SQLOS) has to change a thread to preemptive mode to handle something outside of SQL Server, at the OS level.

Now as you have already determined this types of waits are not documented much at all. There are a few you can see documented in BOL under the sys.dm_os_wait_stats DMV but it is not extensive. In most cases the calls being made to the OS are via Windows API calls. So what I ended up learning from the course is that if you take off the PREMEPTIVE portion of the PREEMPTIVE_REENLIST you end up with the name of the possible API being used: REENLIST. So if you take that and start searching around on the web you can try and deduce what it means.

So my deducing would be that I came across this MSDN article on IResrouceManager::Reenlist there are also other MSDN articles on similar named methods that all discuss a TransactionManager. It is not the content that catches my eye but the section of MSDN where this article is located: DTC Interfaces. So you don't specify this level of setup for your server but I would make a hunch that you are using distributed transactions. This can come from making remote calls to other instances/databases or if you are working on a clustered instance. If you actually read a statement from the MS DTC Service, although it is from SQL Server 2000 you might catch the key word that caught my eye:

One or more servers running SQL Server can then be instructed to enlist in the distributed transaction and coordinate the proper completion of the transaction with MS DTC

Just my opinion...

Run this on your current instance:

select
    'CREATE LOGIN ['+p.name+'] FROM WINDOWS;'
from sys.server_principals as p
where type in ('U','G')

Take it's output and run it on the new instance. Those AD accounts will now have logins on both instances. (This is a good opportunity to audit your access and ensure all those users really are needed.)

Backup your databases (a proper SQL Server backup, not a copy of mdf and ldf files) and restore these to the new instance. You may have to get creative with the restores if the drive names have changed. If there are a lot of DBs some RESTORE FILELISTONLY and a script will save much time.

Finally, on each DB, script an ALTER USER to reconcile LOGINS to USERS. This can be meta-scripted as above.

Test connections to the new instance. Update the applications' connection strings. Take the old DBs offline and, after a few days, tidy away the old server.