Migration problem from W2012 to W2022. Demote not possible

Copper Contributor

Hi everyone. I try to explain as best as possible my problem. I tried a side by side migration from a W2012 to a W2012 past week. It worked fine until I tried to demote the old W2012 server giving me an error like "unable to detect the other dc on the network". If I check on both server where are the fsmo roles installed, all of them are installed on the correct server (the new W2022) and both servers are capables to locate that information, but for some reason, the old one always tells me about the impossibility to demote. If I do a dcdiag from the oldone it's continue saying that he thinks is the master dc, but if I do dcdiag on the new W2022 it's says that he is the master dc. The advertising test on the W2022 tells that he recover information from W2012 on de "DcGetsDCName". One more thing I found is that in the W2022 the "SYSVOL" and the "NETLOGON" shared folders are not shared, so I really don't know that's going on. Can you give me some clarity on this? Ty!!!!

10 Replies

Please run;

Dcdiag /v /c /d /e /s:%computername% >C:\dcdiag.log (run on PDC emulator)
repadmin /showrepl >C:\repl.txt (run on **any** domain controller)
ipconfig /all > C:\%computername%.txt (run on **EVERY** domain controller)


Also check the domain controller System and Replication (DFS or FRS) event logs for errors since last boot. Post the Event Source and Event IDs of any found. (no evtx files)

then put `unzipped` text files up on OneDrive and share a link.    

    

 

@Dave Patrick 

 

Ty. Here you have the zip file with all the information you asked for

 

information_both_servers.zip

Cheers

 

 

Please do not zip the files.    

    

 

@Dave Patrick 

 

Sorry!! I missunderstand you 

 

Here it's is Information 

 

Cheers

On SERVIDOR add the server's own sttic ip address (192.168.1.5) listed for DNS, then do ipconfig /flushdns, ipconfig /registerdns, restart the netlogon service.

On SRVEMBASA add the server's own sttic ip address (192.168.1.4) listed for DNS, then do ipconfig /flushdns, ipconfig /registerdns, restart the netlogon service.      

  

I could not read much of the dcdiag but I'd check the System and DFS Replication are free of all errors since last boot. If not then post the Event Source and Event IDs of any found.    This one could also help.      

Troubleshoot missing SYSVOL and Netlogon shares for Distributed File System (DFS) Replication - Wind...     

    

 

   

 

 

@Dave Patrick 

 

Hi Dave

Following the stepS and restarting both servers now on old DC show this error on DFS event viewer (EVENT id 2213, SOURCE DFSR)

The DFS Replication service stopped replication on volume X:. This occurs when a DFSR JET database is not shut down cleanly and Auto Recovery is disabled. To resolve this issue, back up the files in the affected replicated folders, and then use the ResumeReplication WMI method to resume replication.

Recovery Steps
1. Back up the files in all replicated folders on the volume. Failure to do so may result in data loss due to unexpected conflict resolution during the recovery of the replicated folders.
2. To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:

 

 

My question is, about what is talking about when it say all replicated folders? what are those folders?

 

Sorry but I really don't know that 😞

 

I hope that after the backup and making the second step maybe the problem will gone

 

cheers

The \sysvol folder is a shared directory that stores the copy of the domain's public files such as logon scripts, computer and user policies that are shared for common access and replication throughout a domain.    

 

Okey, so just making a copy of that folder on both server, just in case, it's ok and I can proceed with step 2 ?

Cheers!

Hello, yes, backup the files as first step then follow the steps in document.     

      

 

Hi @Dave Patrick and sorry for terrible delay response. The customer was on christmas holidays and the office closed...

 

Well I finally solved the problem just making the powershell command suggested in event viewer talked in other commets (To resume the replication for this volume, use the WMI method ResumeReplication of the DfsrVolumeConfig class. For example, from an elevated command prompt, type the following command:) and after this, the old server retake 2 of the fsmo roles, not being pased to the new server. Transfering all of them once more time, ended correctly the process and let me demote the old server so, wonderful!!!

 

Thank you for your help and enjoy this new year !