What PS> string can be used to return the partner DC currently selected by each host listed under managed domains in ARS config?

I see a great deal of data under this node … I see the domains, and other details - just not a seeing a way to crack into the details on currently selected DC … along with current state/health info

Get-QADObject -SearchRoot "CN=<managed domain FQDN>,CN=Managed Domains,CN=Server Configuration,CN=Configuration"

I'm looking for this info to pro-actively switch hosts when my DirSync host becomes unresponsive to ARS.   The DC is still running - but not returning password unlock/reset info - the end users just sees the spinning-wheel-of-wait.
and I get a priority ticket....  There is too-long a window between the failure-to-communicate, and ARS switching to next available....
if I can use PS> to xpose the current value - and externally test the connection, then maybe I can use the same PS> path to trigger a change of the DirSync currently selected host value.

ideas? 

Parents Reply
  • For the domain DN you query, you will get back the host name of what Active Roles calls its current "operational DC" for that domain.  The AR server itself will be whatever one responds to your "-proxy" request.  I suppose you could direct that by doing:

    $ARSession = Connect-QADService -proxy -Service "myarservername"

    ...and then instead of referencing '-proxy', use -Connection $ARSession

Children
  • That's the ticket ... I loop through known good ARS hosts using connect-qadservice and run the query you provided.  
    Runs unexpectedly quicker than expected.  

    this is great - 

    now - any tricks up your sleve to validate relative health of the dirsync service for ARS ?  some ... ARS ping or hearbeat that ARS exposes might have increased latency?   for my next trick - I have to figure out that the otherwise 'healthy' DC is having issues responding to sync requests from ARS.  I understand SCOM has some threshold they can report on - but that service is far slower than the canaries that die the instant ARS makes my help desk wait.
    I want to proactively check and act on a growing response latency from that service to ARS.   Actually, I want ARS to do that internally - but it currently does not do that partner sync fast enough for the canaries I support.

    Thanks JQ!

  • In looping through your AR servers, did you actually see them talking to different DCs in the same managed domain?

    I don't quite follow your question:

    ...any tricks up your sleve to validate relative health of the dirsync service for ARS ? 

    Are you talking about ARSS?

  • Yes - we see ARS float between DC's in a site.

    We have 100 +/- DC's.

    We have two dedicated ARS DC's per site for the primary managed AD domain.  each site is honed to two DC's in the same geographic region of the country - think per timezone.   so, yes - ARS servers in EST are  honed to DC A or B in that TZ, Servers in CST are honed to DC C or D in that central timezone.

    We let ARS float between the two using 'any DC in the AD site' specific to their timezone  - however, when we need to reboot DC's post MS security patching, we explicitly point ARS to the one-DC-not-getting booted first so that ARS can continue to serve customers.  Then repoint ARS to the fresh-booted second DC in the site to maintain uninterrupted access.

    The issue we've seen, is that despite allowing ARS to alternate between the two DC's in the same dedicated ARS site (AD site), ARS doesn't detect that responsiveness is slow or stopped ... it just keeps waiting - and making the customer wait on password reset/unlock.  Maybe there is a timeout value ... maybe that timeout value is too long for our customers because we see high severity tickets internally when ARS 'sits and spins' waiting for the DC to respond to a password reset/unlock.

    All other managed domains, and web features continue to work - just not those that require service from the DC currently selected by ARS for dirsync in our primary domain.

    I want a way to determine if the AD dirsync service at the selected domain controller is lagging or slow, or hung despite showing 'running' in process explorer - so that I can tell ARS through your powershell command to switch dirsync partner DC's and then I can be alerted to address the issue with the other-dc in that site... without incurring the wrath of my peeps.