SureBackup for AD upgrade

[matteu]

Hello,

I need to help a customer to build a surebackup job to test AD upgrade to 2022.

He is AD2012 now and my job is :
Create a surebackup environment (2 domain controller + 1 app server + 1 DB server)
Upgrade his 2 Domain controler from 2012 to 2022
He can test his application works with 2022.

He will have to build the lab again and again for each app on his environment (and upgrade 2012 -> 2022 each time).
I know how to use surebackup job for basic task.

I suppose I need to map an IP (stating mapping) here to access the isolated environment from the production to be able to do some task like upgrade and test from a remote desktop connection or I can only use the vmware console ?
Is there a way to manage the upgrade 2012 - 2022 easely or he will need to upgrade 2012 -> 2022 everytime he wants to rebuild the lab ?

If my memory is good, he can ask a lab from Enterprise manager right ?

Thanks for your advices

[Andreas Neufert]

Hi Matteu,

thanks for the request.

Access of the lab.
If Lab users PCs are in the same network as the B&R server and the Virtual Lab appliance, then you can set some dymanic routes to the Masquerade Networks to access the labs that you have started. Otherwise you can use as well the Universal Restore client on these machines where you can ask for labs in combination with the approval process in the Enterprise Manager. This client will set these routes automatically.

Other option is to set the routes static in your router, you need to do this specifically if your PCs are not part of the same network as the Virtual lab appliance.

Overall in theory you can use custom scripting with the SureBackup jobs. Create an application group for each scenario that you test and let the script execute then the upgrade. But I think it will have some side effects and it will take some time until it works correctly. Maybe you need to use 2 SureBackup jobs with 2 different application groups... One for the AD and when you have completed the upgrade you start the second one.

Maybe add some additional host resources and start the whole environment and do the upgrade testing only once? Remember you can cap the memory usage of all servers in the Veeam wizards as you do not have any client connecting to the lab. Then perform once the upgrade while you monitor if the other applications work well. This would catch maybe as well some side effects between the applications?

There is as well the Veeam Disaster Recovery Orchestrator, that has a enhanced scripting and testing engine that can help you to automate things further.

[matteu]

Hello,

Thank you for your answer.

If I understand correctly what you mean, I need to do this :


I create 1 virtual lab with static mapping
I create 1 application group with both DC (I need to upgrade them from 2012R2 to 2022 each time I launch the job)
I create 1 application group per application I need to test with 2022

I think I have several issues here :

-I can't have both application group start with 1 sure backup job.
-If I use 2 differents jobs, I can't use the same virtual lab

=> I suppose I need to create as much application group I have as application with : 2 DC + APP + SQL

[Andreas Neufert]

Thought about it deeper and as well asked some collegues. Each Virtual Lab can only host one active SureBackup Job (with an application group for lab VMs).

I would do the following:
1) Create one or multiple Virtual Labs (you can have multiples with the same IP Setup).
2) Make a plan on how you want to automate the upgrade of the AD in the lab (scripting).
3) Create an application group that include the DCs and the first scenario that you want to test (BDD1,APP1 in your example).
4) Create a SureBackup job, select the first virtual lab first applciation group that you want to test.
5) Repeat step 4 potentially for the same virtual lab but different application group (you can run only one test scenario in parallel) or use multiple Virtual Labs.

Idea is to start an environment with the old AD version and the application server (check that everything runs fine in the lab). Then you kick start the upgrade of the AD in the lab. This allows you to monitor as well how the application react to this as it would be similar to the real life scenario in production. You can boot systems as well for additional testing.
If you do it this way it would reduce complexity a lot in case of lab handling.

The labs could be started as well with the Universal Restore wizard and your teams could ask for labs and book specific timeslots if this would be helpful.

[matteu]

Thanks for tour answer.
This is what i was thinking about for 1 or several vlab and 1 app group per scénario.

To connect to the lab I need people to use vmware console or static ip (but I need to add ip route on PC client right ?)

Universal restore is with enterprise manager right ?

The easiest Way is to use surebackup job and check don t remove the lab at the end of test.

[Andreas Neufert]

The easiest Way is to use surebackup job and check don t remove the lab at the end of test.
Yes

Universal restore is with enterprise manager right ?
Yes, if you have the Enterprise Plus Licensing (or VUL) then this feature is available.
The universal restore client can be found on the B&R ISO.
It connect to Enterprise Manager and request the lab. The Admin will get an mail and can approve this lab.
https://helpcenter.veeam.com/docs/backu ... ml?ver=110
I would just use the Universal Restore Client instead of requesting the lab in the enterprise manager. The benefit is that the routing is set automatically at the system that hosts the client.

Overall access to the VMs can be done by RDP/SSH while leveraging the Masquerade Subnet IPs if the temporary routes are in place.

[matteu]

Thanks for your answer

Interesting for the automatic routing !

What I don't understand is : How my client computer can access DC in lab production and production at the same time ? It will not be possible right ?

[Andreas Neufert]

You create in the VLAB wizard additional VMware networks.
Each production VM will get a network card connected to this vlab network.
THe VM in the lab will have same IP as within production and the same Gateway setting.

In the lab you bind to the lab internal interfaces the GW addresses and you can enable routing within the virtual lab between multiple networks (checkbox to enable).

So within the lab you can communicate between subnets.


To be able to access the lab networks from the outside you define a Masquerade subnet.
The idea is that you communicate from the outside of the lab with these Masquerade IP subnet only and the virtual lab appliance translate it into the lab internal requests.
This works only from outside of the lab to the inside of the lab.

Example
Subnet
10.0.0.1
255.255.255.0

Masquerade Subnet
11.0.0.1
255.255.255.0

Virtual lab Appliance
production LAN1: 10.0.0.4
virtual lab LAN1: 10.0.0.254

FirstServer in production/lab
10.0.0.1
255.255.255.0
GW 10.0.0.254

So if the server started in the lab want to access something outside of his subnet it will automatically ask the GW address which is the virtual lab appliance. It blocks communication outside of the lab but you can enable routing between subnets within the lab.


When you set temporary the following route on the Veeam Server (we do this automatically when the surbackup job runs) or at any Client within 10.0.0.0 subent in production, you will be able to access the lab over the masquerade address.

Temproary route:
11.0.0.0
255.255.255.0
Target IP 10.0.0.4

If the Veeam Server or the Client tries to access for exampel 11.0.0.1 it will check route and go to 10.0.0.4 which is the vritual lab appliance production IP. The lab appliance will replace target IP in the packages from 11.0.0.1 into 10.0.0.1 and forward the package to the lab.
The answer goes back to the virtual lab internal address (as it is the gateway address) and it will translate back the answer into the production network). It is similar to NAT and IP forwarding combination.

[matteu]

Thanks again for the good description

I learn a lot here !

I need to test with the universal client restore to avoid create route on my computer !

Something more I don't understand correctly. My customer has arround 25 port group on vmware. How can I manage it with virtual lab ? Maximum is 9 .
If my understand is good, I need to specify all my port group on the network section and make them routable to be able to use script right ?

I don't understand how can I use linked job with 200 vm and 15 differents port group for example with 1 sure backup job because of this limitation.

[Andreas Neufert]

Hi Matteu,

this is not possible based on limitation of VMware that can manage only up to 9 networks. We have planned to do some workarounds in later versions, but today you can only work with 9 networks in the lab.

You need to split things accordingly and build multiple labs where you test specific subnets only.

[matteu]

Hi,

Unfortunately it's not easy to spread VM accross different job when you work with tag ^^.
I think I will just avoid "custom" test for other network and just keep them for critical workload. They should not be in more than 9 different portgroup.