Domain Extension Restrictions and Warnings

What to be aware of when launching a domain extension

Craig Medland avatar
Written by Craig Medland
Updated over a week ago

When deploying a domain extension, one of the requirements is connectivity to the on-prem environment either through a vpn or an interconnect with Google. If you're setting up a single region extension and don't have an interconnect already setup, then you will need to create a vpn between sites. You can find an article on how to do that here.
However, if you need to setup multiple sites (regions) for redundancy or any other reason, then please be aware that when creating the VPN you will need to set up the VPN using IKEv2. This is because IKEv1 does not support multiple IP ranges per traffic selector.

The domain administrator account that is required by our system when extending an existing AD must be member of Domain admins, Enterprise admins and Schema admins groups.
โ€‹
Another item to keep an eye out for when extending a domain is the on-prem DNS servers. If you've had DNS or AD servers which have been decommissioned in the past, please make sure that all traces of those servers are removed from your DNS servers. If there are any stale records of an old DNS or directory servers in DNS, then there is a chance that when the domain controllers are being spun up in the Google cloud, that when trying to connect to the domain the servers may resolve the domain name to a none existent server(s).

When the itopia software is extending a domain, the software also creates AD sites, replication subnets and site links. The software uses a pre-determined naming convention so having an issue with any existing sites should be very rare, the replication subnets are not as rare. During the deployment process you can use the pre-defined subnets Google creates for cloud deployments or you can also set your own subnets for each region. This is where there may be problems with the replication subnet naming. If you've had multiple sites in the past and have setup other replication sites and subnets, please make sure that the subnets being used for the cloud deployment are not that same. Or if the old replication subnets are not longer being used then please delete them so there aren't any conflicts during the deployment process.

If you are extending a domain with a Windows Server 2003 or 2003 r2 domain controller please migrate to DFSR replication of the SYSVOL before performing the deployment. FRS is deprecated and does not work on Server 2016 and newer domains. You will also need to raise the forest functional level of the domain to at least 2008. How to migrate from FRS to DFSR can be found here.

Did this answer your question?