Da Windows Server SBS2003 a Windows Server 2012 Foundation
Questo video molto ben fatto ci guida passo passo verso la migrazione da un Server con Windows Server 2003 ad un 2012. Si è rivelato utilissimo anche nel mio caso in cui dovevo migrare un Windows Server SBS2003 (anche se ero consapevole che avrei perso tutta la gestione del Server Exchange integrata in SBS).
In ogni caso, anche applicando tutti i passaggi descritti purtroppo la replica non funzionava correttamente, non mi erano state creare e condivise le cartelle SYSVOL e NETLOGON sul nuovo server (anche se il passaggio dei ruoli risultava effettuato correttamente.
Se anche a voi capitasse di avere problemi con le repliche tra i due server in calce allego le istruzioni per forzare la replica in modo autoritativo. Per questo ringrazio il Forum di Microsoft Technet, attraverso il quale, che in breve tempo, si viene a capo di grandissima parte delle problematiche Server side
Authoritative FRS restore
Use authoritative restores only as a final option, such as in the case of directory collisions.
For example, you may require an authoritative restore if you must recover an FRS replica set where replication has completely stopped and requires a rebuild from scratch.
The following list of requirements must be met when before you perform an authoritative FRS restore:
- The FRS service must be disabled on all downstream partners (direct and transitive) for the reinitialized replica sets before you restart the FRS service when the authoritative restore has been configured to occur.
- Events 13553 and 13516 have been logged in the FRS event log. These events indicate that the membership to the replica set has been established on the computer that is configured for the authoritative restore.
- The computer that is configured for the authoritative restore is configured to be authoritative for all the data that you want to replicate to replica set members. This is not the case if you are performing a join on an empty directory. For more information, click the following article number to view the article in the Microsoft Knowledge Base:
266679 Pre-staging the File Replication service replicated files on SYSVOL and Distributed file system shares for optimal synchronization
- All other partners in the replica set must be reinitialized with a nonauthoritative restore.
To complete an authoritative restore, stop the FRS service, configure the BurFlags registry key, and then restart the FRS service. To do so:
- Click Start, and then click Run.
- In the Open box, type cmd and then press ENTER.
- In the Command box, type net stop ntfrs.
- Click Start, and then click Run.
- In the Open box, type regedit and then press ENTER.
- Locate the following subkey in the registry:
HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\NtFrs\Parameters\Backup/Restore\Process at Startup
- In the right pane, double click BurFlags.
- In the Edit DWORD Value dialog box, type D4 and then click OK.
- Quit Registry Editor, and then switch to the Command box.
- In the Command box, type net start ntfrs.
- Quit the Command box.
When the FRS service is restarted, the following actions occur:
- The value for the BurFlags registry key is set back to 0.
- An event 13566 is logged to signal that an authoritative restore is started.
- Files in the reinitialized FRS replicated directories remain unchanged and become authoritative on direct replication. Additionally, the files become indirect replication partners through transitive replication.
- The FRS database is rebuilt based on current file inventory.
- When the process is complete, an event 13516 is logged to signal that FRS is operational. If the event is not logged, there is a problem with the FRS configuration.
Considerations before you configure authoritative or nonauthoritative restores of FRS members
If you configure an FRS member to complete an authoritative or nonauthoritative restore by using the
registry subkey, you do not resolve the issues that initially caused the replication problem. If you cannot determine the cause of the replication difficulties, the members will typically revert back to the problematic situation as replication continues.
A detailed breakdown on FRS interdependencies is beyond the scope of this article, but your troubleshooting should include the following actions:
- Verify that Active Directory replication is successful. Resolve Active Directory replication issues before you perform additional FRS troubleshooting. Use the Repadmin /showreps command to verify that Active Directory replication is occurring successfully. The Repadmin.exe tool is located in the Support\Tools folder on the Windows 2000 CD-ROM.
- Verify that inbound and outbound Active Directory replication occurs between all domain controllers that host SYSVOL replica sets and between all domain controllers that host computer accounts for servers that participate in DFS replica sets.
- Verify that FRS member objects, subscriber objects and connection objects exist in the Active Directory for all the computers that participate in FRS replication.
- Verify that inbound and outbound connection objects exist for all domain controllers in the domain for SYSVOL replica sets.
- Verify that all the members of DFS replica sets have at least inbound connection objects in a topology to avoid islands of replication.
- Review the FRS and SYSTEM event logs on direct replication partners that are having difficulty.
- Review the FRS debug logs in the %SYSTEMROOT%\DEBUG\NTFRS_*.LOG between the direct replication partners that are having replication problems.
For more information about how to troubleshoot, click the following article number to view the article in the Microsoft Knowledge Base: