Sep 14 2021 12:46 PM
Sep 14 2021 12:46 PM
The full error I'm getting:
SSPI handshake failed with error code 0x80090311, state 14 while establishing a connection with integrated security; the connection has been closed. Reason: AcceptSecurityContext failed. The Windows error code indicates the cause of failure. No authority could be contacted for authentication.
I was configuring a new server as a 2019 Domain Controller to replace a 2008 R2 one. In addition I have two other DC's for a total of 3. All in different sites.
One with all FSMO roles which is what is referred to as PDC back in the day running 2012 R2. The other running Windows Server 2019 and now the new one that I mentioned above that replaced the 2008 R2 also running 2019.
The problem I ran into is that I forgot to raise the domain functional level from 2008 R2 to 2012 R2 before I demoted it. Once that happened I started to receive errors from a couple of servers regarding the SSPI handshake and after researching this, I found that it's most likely or I can honestly say it's probably close to 100% that what I did caused this error.
So, I took the same server and brought it back to 2008 R2 Domain Controller status but what's weird is that even prior to completing this task, the errors seemed to stop...but accessing some of our applications didn't work until I fully brought it back.
My goal is to raise the domain functional level to 2012 R2 then test to make sure that the new DC in that site works for authentication of the SQL and application servers running there. I was wondering if shutting down the 2008 R2 DC temporarily and monitoring to make sure no errors are thrown is a good way to make sure my environment is ready to demote the 2008 R2 DC once and for all?
I appreciate any help I can get and thanks in advance!
Sep 14 2021 12:55 PM
The two prerequisites to introducing the first 2019 domain controller are that domain functional level needs to be 2008 or higher and older sysvol FRS replication needs to have been migrated to DFSR
I'd suggest removing the new 2019, make sure prerequisites have been met, then use dcdiag / repadmin tools to verify health correcting all errors found before starting any operations. Then stand up the new 2019, patch it fully, license it, join existing domain, add active directory domain services, promote it also making it a GC (recommended), transfer FSMO roles over (optional), transfer pdc emulator role (optional), use dcdiag / repadmin tools to again verify health, when all is good you can move on to next one
Sep 14 2021 01:31 PM
Sep 14 2021 01:35 PM
If the prerequisites have not been met then there is no choice but to remove the 2019 domain controllers. Perform cleanup if needed.
Then check health is 100% and if so you can start again.
Sep 14 2021 01:35 PM
Sep 14 2021 01:57 PM
Sep 14 2021 02:00 PM
Three right? Please run;
Dcdiag /v /c /d /e /s:%computername% >C:\dcdiag.log
repadmin /showrepl >C:\repl.txt
ipconfig /all > C:\dc1.txt
ipconfig /all > C:\dc2.txt
ipconfig /all > C:\dc3.txt
then put unzipped text files up on OneDrive and share a link.
Sep 14 2021 02:38 PM - edited Sep 14 2021 02:40 PM
Run these commands on each DC? Also, these results will show 4 DC's since the 2008 R2 DC is currently running but it's the one that I want to eventually remove which will leave me with the other 3...thanks.
Sep 14 2021 02:45 PM
Run first two on any healthy DC, if there are four then include a file for the fourth as well.
Sep 14 2021 02:57 PM
Sep 14 2021 03:01 PM - edited Sep 14 2021 03:03 PM
You can just post a link here, or send me a message
Sep 14 2021 03:04 PM
Sep 14 2021 03:06 PM - edited Sep 14 2021 03:06 PM
The files should be harmless but message me the link if you like.
Sep 14 2021 03:42 PMSolution
- ACEPDC7 is DHCP assigned which is a no-no for a domain controller. After assigning a static address I'd do ipconfig /flushdns, ipconfig /registerdns, restart the netlogon service.
- ACEPDC4 is DHCP assigned which is a no-no for a domain controller. After assigning a static address I'd do ipconfig /flushdns, ipconfig /registerdns, restart the netlogon service.
- ACEPDC5 -> ACEPDC4 5012 errors
- ACEPDC6 event logs cannot be queried because of RPC, so I'd check the logs for possible errors
- ACEPDC7 event logs cannot be queried because of RPC, so I'd check the logs for possible errors
- ACEPDC4 has replication problems. I'd check the event logs for error details (may be related to DHCP assignment)
(please don't forget to mark helpful replies)
Sep 14 2021 03:58 PM
Sep 14 2021 04:08 PM
Ok, then as long as the ip address is not changing on those two it should be Ok, but the other issues need to be cleared up specifically the system and dfs replication event logs should be clear of errors on all four. If problems persist after cleaning up event logs put up a new set of files to look at.
Sep 14 2021 04:22 PM
You're welcome. Another tip: the system and dfs event logs prior to last boot are of no use to me so when I'm building a new one I like to clear out the logs just prior to reboot so a quick look I don't need to decide if an error was before or after last boot. Another reason to clear is dcdiag will query the last 24 hours so something that shows there may have been before last boot and no longer a problem.