Question:

I am working on a project to decommission an old SBS 2008 server and migrate all its roles and functions to a new Server 2012 R2 server. Eventually, I will also add a Server 2022 server to the network. However, I have encountered a DNS issue that worries me. When I run nslookup for _gc._tcp.dc._msdcs.example.local, I get a non-existent domain error. This suggests that the DNS records for the Global Catalog server are missing or corrupted in the AD domain. I am hesitant to demote the SBS 2008 server until I resolve this issue.

I would appreciate your advice on the following topics:

• How serious is the DNS issue and how can I fix it? Should I manually create the DNS entry or look for other causes?
• What are the best practices for decommissioning the SBS 2008 server and removing it from the domain? Are there any SBS-specific steps I should take?
• How can I ensure a smooth transition from FRS to DFSR for SYSVOL replication? Are there any potential problems or tips I should know, given the different server versions in my network?
• How can I prepare for the integration of the Server 2022 server into the existing domain? Are there any compatibility or configuration issues I should be aware of?

I would greatly value your input, experience, and resources as I go through this process. My main goal is to minimize the impact on the network and services. I want to be proactive and avoid any possible complications.

Thank

you for your help and expertise.”

Answer:

How to Decommission an SBS 2008 Server and Migrate to Server 2012 R2 and Server 2022

If you are planning to retire an old SBS 2008 server and move its roles and functions to a new Server 2012 R2 server, you might encounter some challenges and issues along the way. In this article, I will share some tips and best practices on how to decommission the SBS 2008 server and migrate to Server 2012 R2 and Server 2022 smoothly and successfully.

One of the common issues that you might face during the migration process is a DNS issue related to the Global Catalog server. When you run nslookup for _gc._tcp.dc._msdcs.example.local, you might get a non-existent domain error, indicating that the DNS records for the Global Catalog server are missing or corrupted in the AD domain.

This is a serious issue that should be fixed before demoting the SBS 2008 server, as it can affect the functionality and stability of the AD domain and the services that rely on it. The Global Catalog server is responsible for storing and providing information about the objects in the entire forest, such as users, groups, computers, and printers. It also enables cross-domain logons and searches, and supports operations such as Exchange and DFS.

There are several possible causes and solutions for this issue, depending on your environment and configuration. Here are some of the common ones:

• Check the DNS server settings on the SBS 2008 and the Server 2012 R2 servers. Make sure that they are both pointing to the correct DNS servers, preferably themselves as the primary DNS server and each other as the secondary DNS server. Also, make sure that they are both using the same DNS suffix and domain name.
• Check the DNS zones and records on the DNS servers. Make sure that the _msdcs.example.local zone is present and contains the correct records for the Global Catalog server. You can use the dnscmd command to verify and update the records. For example, to register the Global Catalog server in the _msdcs.example.local zone, you can run the following command on the Server 2012 R2 server:

“`dnscmd /recordadd _msdcs.example.local _gc._tcp.dc SRV 0 100 3268 Server2012R2.example.local“`

• Check the Global Catalog server role on the Server 2012 R2 server. Make sure that the Server 2012 R2 server is configured as a Global Catalog server and that it has replicated the Global Catalog data from the SBS 2008 server. You can use the Active Directory Sites and Services console to verify and enable the Global Catalog server role. You can also use the repadmin command to check the replication status and force a replication if needed. For example, to force a replication of the Global Catalog partition from the SBS 2008 server to the Server 2012 R2 server, you can run the following command on the Server 2012 R2 server:

“`repadmin /replicate Server2012R2 SBS2008 DC=ForestDnsZones,DC=example,DC=local“`

• Check the firewall settings on the SBS 2008 and the Server 2012 R2 servers. Make sure that the firewall is not blocking the communication and the ports required for the Global Catalog server and the DNS server. The default ports for the Global Catalog server are 3268 (TCP) and 3269 (TCP/SSL), and the default ports for the DNS server are 53 (TCP and UDP).

The Decommissioning Best Practices

Once you have resolved the DNS issue, you can proceed with the decommissioning of the SBS 2008 server and the removal of it from the domain. However, there are some specific steps and considerations that you should take into account, especially for the SBS 2008 server, which has some unique features and limitations compared to the standard Server editions.

Here are some of the best practices for decommissioning the SBS 2008 server:

• Transfer all the FSMO roles to the Server 2012 R2 server. The SBS 2008 server must hold all the FSMO roles in the domain, otherwise it will shut down after 21 days. Therefore, before demoting the SBS 2008 server, you need to transfer all the FSMO roles to the Server 2012 R2 server, which will become the new domain controller. You can use the ntdsutil command or the Active Directory Users and Computers console to transfer the FSMO roles.
• Migrate all the SBS-specific services and data to the Server 2012 R2 server or another server. The SBS 2008 server provides some additional services and features that are not available in the standard Server editions, such as Exchange, SharePoint, Remote Web Workplace, and WSUS. You need to migrate these services and data to the Server 2012 R2 server or another server, depending on your needs and preferences. You can use the SBS Migration Preparation Tool or the specific migration guides for each service to perform the migration.
• Uninstall the SBS components from the SBS 2008 server. After migrating the SBS-specific services and data, you need to uninstall the SBS components from the SBS 2008 server, such as the SBS Console, the SBS Manager, and the SBS Licensing. You can use the Programs and Features control panel or the SBS Uninstall Tool to uninstall the SBS components.
• Demote the SBS 2008 server and remove it from the domain. Finally, you need to demote the SBS 2008 server and remove it from the domain, using the dcpromo command or the Active Directory Domain Services Installation Wizard. This will remove the AD domain controller role from the SBS 2008 server and delete its metadata from the domain. You can then disconnect the SBS 2008 server from the network and retire it.

The FRS to DFSR Transition

Another important step that you should take during the migration process is to transition from FRS to DFSR for SYSVOL replication. SYSVOL is a shared folder that stores the domain policies and scripts, and it is replicated among all the domain controllers in the domain. FRS is the legacy replication method that was used in Windows Server 2003 and earlier versions, while DFSR is the newer and more efficient replication method that was introduced in Windows Server 2008 and later versions.

By default, the SBS 2008 server uses FRS for SYSVOL replication, while the Server 2012 R2 and the Server 2022 servers use DFSR for SYSVOL replication. However, you can upgrade the SBS 2008 server to use DFSR for SYSVOL replication, and then migrate the entire domain to use DFSR for SYSVOL replication. This will improve the performance, reliability, and scalability of the SYSVOL replication, and also enable the integration of the Server 2022 server into the domain.

Here are some of the common steps and tips for the FRS to DFSR transition:

• Prepare the domain for the FRS to DFSR transition. Before you can migrate the domain to use DFSR for SYSVOL replication, you need to prepare the domain by raising the domain and forest functional levels to Windows Server 2008 or higher, and by ensuring that all the domain controllers are healthy and synchronized. You can use the Active Directory Domains and Trusts console to raise the domain and forest functional levels, and the dcdiag and repadmin commands to check the domain controller health and synchronization.
• Upgrade the SBS 2008 server to use DFSR for SYSVOL replication. After preparing the domain, you need to upgrade the SBS 2008 server to use DFSR for SYSVOL replication, using the dfsrmig command or the DFS Management console. This will create a new SYSVOL_DFSR folder on the SBS 2008 server and start replicating the SYSVOL data from the FRS to the DFSR folder. You can monitor the progress and status of the upgrade using the dfsrmig command or the DFS Replication event log.
• Migrate the domain to use DFSR for SYSVOL replication. Once the SBS 2008 server has completed the upgrade to use DFSR for SYSVOL replication, you can migrate the entire domain to use DFSR for SYSVOL replication, using the dfsrmig command or the DFS Management console. This will switch the domain controllers to use the SYSVOL_DFSR folder as the authoritative source of the SYSVOL data, and stop using the FRS for SYSVOL replication. You can monitor the progress and status of the migration using the dfsrmig command or the DFS Replication event log.
• Clean up the FRS data and settings from the domain. After the domain has successfully migrated to use DFSR for SYSVOL replication, you can clean up the FRS data and settings from the domain, using the dfsrmig command or the DFS Management console. This will delete the old SYSVOL folder and the FRS metadata from the domain controllers, and free up the disk space and resources. You can also uninstall the FRS service from the domain controllers, using the Programs and Features control panel or the sc command.

The Server 2022 Integration

The

final step that you should take during the migration process is to integrate the Server 2022 server into the existing domain.