Hello,
i am having 3 problems with restoring two DC's from production into my lab environment.
I would like to reach a situation where i, as STEP I, can restore the FSMO holder DC to a standalone running, functional state. It is ok if it runs standalone only for a week (TSL not exceeded). During that week, as STEP II, i will then restore the second DC.

Both DC are Server 2012R2 @ Forest,Domain FL "Windows Server 2008".
Both DC are in the same site, but in different subnets (connected via a transparent router).
Both DC are holding GC and DNS role.
Images from Production are taken via "wbadmin start backup /allcritical".
I will call these machines FSMO_DC and OTHER_DC here.

After restoring only FSMO_DC from Image, i *might* not be able do start dsa.msc (NAMING CONFIGURATION NOT ACCESSIBLE) until i set the BurFlags to D4 and restart the File Replication Service.
Now i can start dsa.msc, but creating new objects is refused with "Windows cannot create the object because the Directory Service was unable to allocate a relative identifier", so i am hitting KB822053 here.

To fix that, i restored OTHER_DC from image (which i wanted to avoid), went back to FSMO_DC and forced replication with repadmin SyncAll /Ade, resulting in a FSMO_DC accepting new objects.

Signing on to OTHER_DC and running repadmin SyncAll /Ade failes with "-2146893022: The target principal name is incorrect", hitting KB2090913.
running \\FSMO_DC on OTHER_DC failes, running \\OTHER_DC on FSMO_DC is ok.
running \\ip.of.FSMO_DC as well as running \\FSMO_DC.fully.quallified.domain on OTHER_DC is ok.
DNS on both machines is able to resolve both machines for a) short hostname and b) fqdn, forward and reverse.
I temporarily fixed that by adding an additional NIC to OTHER_DC wired to the same subnet as FSMO_DC is in. \\FSMO_DC is working now and replication started immideately at OTHER_DC.

I feel that there is a Netbios Name Service issue here and need help to understand how that works.
No LMHOST files or WINS Servers are used.
So why is FSMO_DC able to run \\OTHER_DC without problems, but \\FSMO_DC can not be resolved from OTHER_DC ?

Any idea to avoid all of that trouble and reach my goal of a standalone running FSMO_DC more easily ?

Hi,

Seems like that the domain DNS suffix is not appended on OTHER_DC, please ensure that Append primary and connection specific DNS suffixes option is selected from Advanced TCP/IP settings:

In addition, you may run IPconfig /all on OTHER_DC to check primary DNS suffix .

Best Regards,

Amy

Amy,

thank you very much for your reply, but as stated in my inital post:

"DNS on both machines is able to resolve both machines for a) short hostname and b) fqdn, forward and reverse."

DNS is working fine for all of the above 6 queries.

However, i rechecked that the referenced setting is configured.

As new information i would like to provide, that:

- calling "\\OTHER_DC" is working fine on OTHER_DC, where "\\FSMO_DC" is returning "The target principal name is incorrect".

- calling "\\FSMO_DC" as well as "\\OTHER_DC" on FSMO_DC is working fine, so that machine is OK.

- calling "nbtstat -c" on OTHER_DC returns no entries.

I still believe that to be a Netbios name service problem not a DNS problem.

Perhaps due to the different subnets broadcasts can not resolve the name.

I would like to understand why it starts to work after inital replication has been done.

As far as i understand, the following order in NBT resolution will be applied, but none should hit the szenario:

1. local cache (works in production, why?) (is empty in lab until replication)

2. LMHOSTS (does not exist)

3. WINS ( is neither existing nor configured)

4. For SERVER2000 and only if configured, DNS to NETBIOS (we are completely @ SERVER 2012R2)

5. BROADCASTS (these stop at subnet boundary, so they fail in that szenario).

So, why it works in production and in lab after initial replication (which includes DNS namespace) ?

Even purging the local cache with "NBTSTAT -R" does not break it - once established, resolution is stable.

• Edited by s_run 1 hour 3 minutes ago