Surebackup Job and DC sandbox

[Stabz]

Hello,

I 'm trying to create a Sandbox with the virtual lab solution, but I have a problem with my Domain controller.

The surebackup jobs starts correctly,and all the tests have the status "succes".

But when I try to acces to the "group policy management console" on the DC I obtain the following message:
"The specified domain controller could not be contacted. This affects all sites in the console for the following forest."

This domain controler isn't my primary domain controler. I tryed to create an user and obtained the message' The directory service was unable to allocate a relative identifier'

Any suggestion, I have to test some GPOs and I don't want to do this on my production environnement.

[Mgamerz]

Does your sandbox contain your domain controller in it? It ideally would be part of the application group, as far as I am aware.

[foggy]

Hi Philippe, if you want to make SureBackup VM accessible from production network, you need to configure static IP mapping rules.

[Stabz]

Hi,

I ll give you some details .

I did:
* A virtuallab
* An application group with two vms, one of my DC and a files server. I specified for the DC the roles DNS ,DC (Authoritative restore) and Global Catalog.
* A Surebackup Job

I run the Surebackup Job ,I'm waiting that the status is at 99%. Every tests are success,

I have access to my Sandboxing vms from the VBR server or from my production network, I worked with my network team for that.

But once connected on the sandbox DC, I have the message mentionned in my first post when I try to do some modifications. The server seems to be a little bit lost.
Is there more actions to do after a restoration of a DC even if it's a surebackup job?

[foggy]

I have access to my Sandboxing vms from the VBR server or from my production network, I worked with my network team for that.

How did you configure that? Through static mapping in SureBackup job?

[Stabz]

Hello,

IP informations:
VBR server: 172.30.250.100
Virtual lab: 172.30.250.102
Production DC: 172.30.252.1
Masquerading DC: 172.32.252.1

From the VBR the static route is automatically added so the access to the masquerading ip works.

From my computer the network team added on your firewall a static route:
Destination 172.32.252.0/24 (masquerading) -> Gateway 172.30.250.102 (Virtual lab)

And allow my computer to access to the ip range 172.32.252.0/24.

[foggy]

Any chance this post is related to your case?

[Stabz]

I tried to follow the kb https://www.veeam.com/kb2119 mentionned in the post.
unfortunately I have the same problem.

But in my comprehension in a surebackup job everything was made automatically.

I opened a case # 03106962

[foggy]

I mostly meant the article from Microsoft mentioned there that says that this behavior is expected in case the DC is not primary, as far as I can get.