Looking for a way to manage ARS replication roles using powershell | Standalone < > Publisher < > Subscriber

Can you explain a bit more about WHY you want to do this - i.e. what's the end goal or what you do expect to be able to achieve?

I ask because tickling these roles within Active Roles itself is really not very meaningful as the real core engine behind this whole Publisher / Subscriber concept rests within SQL and modifying the role "labels" which is what Powershell is doing will only get you so far.

Thanks for the response.
We need to perform a annual disaster recovery exercise and as part of that we need to move both roles from one datacenter to another, test and revert to original state. So i was wondering if I could script that instead of having to manually switch roles from ARS mmc console.

Hi pramkris 

The below link give you details of the way you'd manually move the publisher role.

Active Roles 7.3.3 - Replication: Best Practices and Troubleshooting (oneidentity.com)

Hope this helps.

Hi Stu.Pollock 

That's more likely doing it using ARS mmc console and or in a force recovery scenario as stated.

I'm looking for a planned failover/ failback option of publisher and subscriber roles between two datacenters using powershell.

Hi pramkris ,

Could I ask a couple of questions if that's ok?

1) How are the failovers between data centre's handled? Is it just a manual and/or scripted process, or do you have special product in place like Site Recovery Manager?

2) Do you know what the rational was for choosing the Publisher Subscriber topology, over using something like SQL Always On or Clustering (etc)?

3) How big is the (on publisher and subscriber(s) SQL Servers:

a) Configuration Database

b) History Database

c) [on publisher] Distributor database size.

Hi Stu.Pollock 

1.  As of today, failover/ failback is manual. We have a custom web portal (used for trigger) and I plan to script the ARS failover/ failback process (if at all supported/ possible).

2.  Not sure really on that.... Been like this for a very long time. I wanted to test SQL Always On option but ran into some internal 'approved/ supported build' type issues.  I think I need to revisit that again now.

3.  They are about 1.5gb and 3gb in size respectively.

Thanks again.

Hi Stu.Pollock 

1.  As of today, failover/ failback is manual. We have a custom web portal (used for trigger) and I plan to script the ARS failover/ failback process (if at all supported/ possible).

2.  Not sure really on that.... Been like this for a very long time. I wanted to test SQL Always On option but ran into some internal 'approved/ supported build' type issues.  I think I need to revisit that again now.

3.  They are about 1.5gb and 3gb in size respectively.

Thanks again.