F5 VIP for administration service port 15172

I have only ever seen VIPs setup to virtualize connectivity to the AR web UI - never to the service itself.

The thing is that programmatic connections to the service leverage the AD-published service connection point to "find" available services.  I don't know if you could publish your VIP "host" in that list.  (It's not something that would be "supported")

We've done this and i don't recall any special F5 configurations.  When you issue the connect command, you do need to add the -SERVICE <vip name>

Is it possible your F5 is configured to forward any/any?

After talking it over here we pretty much gave up on the idea when the ports documentation was updated to include the high ports:

Active Roles Administration Service:

• 15172 (HTTPS) TCP Inbound
• All high ports (1024-65535) on port 15172
  • Client machines randomly select high ports to use for outgoing traffic on port 15172 to access the Active Roles Administration Service.

Similar to JohnnyQuest , I've only ever seen a NLB in front of the AR WI, not the service, and from what I remember, Load Balancers aren't support.

Usually if the introduction of a Load Balancer is transparent to the interface (Web, Admin Service etc), is shouldn't be an issue.

For example with the Web Interface, as log as the Load Balancer is configured with persistent/sticky sessions, you should be ok. There might also be a required to configure some SPN's and/or trusted for delegation (Kerberos Constrained Delegation) settings

I suspect your issue is similar(ish), but more specifically relating to authentication, as your going to be attempting to access the service using some token, which there is no account (machine for the VIP) to decrypt the TGT. 

You couple of things (I'd suggest in a term environment)

Create a computer account in AD using the VIP,

if that doesn't work, try configuring Kerberos constrained delegation. That however you'd need to do yourself (but this might help Enabling Kerberos Constrained Delegation for a stand-alone Web Interface instance (4336757) (oneidentity.com)_

A question occurred to me:  Is your Web UI installed on your Admin Servers?

Hi - i am guessing you want to add resilience for your Active Roles instance and be able to reference multiple AR servers with one connection string? 

Have you considered using multiple DNS cname entries - 1 for each of the servers you want to connect to?  We present a subset of our servers like this and it seems suitable for our usages.

No. We have the Web standalone. We do Kerberos Constrained delegation for the self-service interface. 

Yes, resilience, but more for consistency. We'd like to give our admins one VIP they can use to connect to ARS to run the quest cmdlets. Right now we give them the actual server names. So when an upgrade happens scripts across the lands start breaking (we are a large org). 

We are probably going to go the DNS round robin route.

related question - Johnny Quest and crew, when using the powershell commandlets with "-proxy" instead of "-connection"

- how is '-proxy' selecting an ARS service to direct the activity to? 

I've tested 'connect-qadservice -proxy' without specifying the primary and secondary hosts using '-service' ... just to try - and it randomly picks one, or that's what I thought.
is that a smart selection process ( like least simultaneous connections in use ) - or just first returned from its internal  service connection point lookup?
                                                     

UPDATE: I tested setting $ARSESSION  equal to 'connect-qadservice -proxy'  - several times in a row over time  - and saw that the ARS service connected to as a result of the command changed up several times.  The commonality was - they were up and available at the time the command was run.