Firewall – Secondary DPM server and access to protection agents at primary server

firewallnetworkingscdpmsystem-center

Disclaimer: This is not an ideal setup. In a perfect world we would have a direct two-way VPN between our site and the remote site. My task is to enlighten the consequences of running a System Center installation at a remote site with management and backup from our local site without the use of a VPN link between these.

Using System Center 2012 R2 Data Protection Manager I want this setup:

| * 1-* Servers protected by DPM_1
| * A Primary DPM server, DPM_1, protecting the servers above
|
|--- Remote firewall, all Inbound and Outbound traffic must be explicitly set
|
| The Internet
|
|--- Our firewall. (Almost) all outbound traffic is allowed, inbound must be configured
|
| * A Secondary DPM Server, DPM_2, protecting DPM_1 and it's replicas.

Now, DPM_2 is intended for disaster recovery as Azure Offsite backup is not an option at that site. I need to find out how the Firewall must be set up.

Now, I know that from DPM_2 I will install a Remote Agent on DPM_1, thus inheriting the firewall requirements for protecting a Windows Server.

For which scenarios does the firewall need additional configuration to allow DPM_2 to act as intended ?

Scenario 1: DPM_1 is running as normal. DPM_2 protects DPM_1 and replicas on DPM_1

Scenario 2: Sysadmin at remote site has a bad day and spills coffe on DPM_1, putting it temporary out of business. We use "Switch protection" to let DPM_2 be the Primary DPM Server for the protected computers at the remote site.

Scenario 3: One of the protected computers break down at the remote site while DPM_1 is out of business so we need to perform a recovery from DPM_2

Scenario 4: Oh, you, sysadmin…. while cleaning the coffee spill from DPM_1 something went bad and now DPM_1 is permanently out of business. We need to perform a bare metal recovery of DPM_1 from DPM_2.

Best Answer

After some discovery and reading my conclusion is that you must be a very brave man to attempt this and this setup should be avoided at all circumstances (we did)

Related Topic