locked
Question about multiple pools and automatic client redirection RRS feed

  • Question

  • I'm looking at the following option when deploying a Standard Server and/or Enterprise Pool:
    You must designate one (and only one) Enterprise pool or Standard Edition Server to authenticate and redirect client sign-in requests.

    So in our situation, we will have two Enterprise Pools.  Each Server handles its own DNS and is not replicated with the other location.  So we can easily have an SRV record in each location so users will use that SRV record within their own location. 

    But in reading that you must designate only one, will this work what I wrote in the last paragraph?  And if not, what happens in a site resiliency situation where I have to change the SRV record to point to the other pool so clients can still automatically log on?  It seems like this won't work since you must only select one of your pools to authenticate and redirect client logon requests when creating Pools.
    Wednesday, July 30, 2008 1:28 AM

All replies

  • The text that you referenced is a little misleading.  I believe what they are trying to communicate is that you cannot have multiple SRV records for the same SIP domain.  The reality is that each and every front end server has the native functionality to authenticate and route users to their OCS pool.  Deploying SRV records to each location as you referenced is completely fine and will work the way you expect.

     

    Wednesday, July 30, 2008 2:19 PM
    Moderator
  •  Mike Stacy wrote:
    The text that you referenced is a little misleading.  I believe what they are trying to communicate is that you cannot have multiple SRV records for the same SIP domain.  The reality is that each and every front end server has the native functionality to authenticate and route users to their OCS pool.  Deploying SRV records to each location as you referenced is completely fine and will work the way you expect.

     



    Mike, thanks a ton.  Do you know where there is this limitation on one SRV record per SIP domain?  Why can't we have multiple SRV records so we load balance the traffic across multiple Pools?
    Wednesday, July 30, 2008 2:45 PM
  • If the point is to load balance, then I would recommend implementing multiple Front End servers and Access Edge servers (using NLB), rather then implementing multiple pools.  You can do this in a multiple site configuration with a properly routed LAN/WAN environment. 

     

    In response to your question about multiple SRV records:  If you plan to use automatic sign in, you will create an SRV record like this: _sip._tls.<domainname>.com that points to your access edge server and port 443.  This limits your ability to create multiple SRV records if you are going to use automatic sign in, because this is the record that OCS looks for from outside your LAN to connect to your OCS environment.

    Wednesday, July 30, 2008 3:07 PM
  • We are using two pools because one location is in Asia and one is in the US.  Both locations will have pools behind F5s and we'll have Edge Servers in both locations with the Access Edge in the US with a possible standby in Asia.

    So I do know all about the redundancy and load balance mechanisms in OCS.

    My question still stands.  Why is there a limitation on only having 1 SRV record per SIP domain.  Why can't we have multiple SRV records?  Is this some issue with Communicator having issues when hitting multiple SRV records for its SIP domain?
    Wednesday, July 30, 2008 3:41 PM
  • Hi,

    If you have 2 different pools, one is Asia one in the US, then you will have US users homed to the US pool and Asia users homed to the Asia pool. If the US pool goes down, you will not be able to have them "fail over" to the Asia pool - the Asia pool will have no trace of the US users. Pools don't replicate the user database. Users only live on one pool or the other. So in this case, you can't load-balance between pools; there is no such thing.

     

    Now on to your question about SRV records... if you are looking to use the same SIP domain for both pools (company.com) and you have the DNS zone company.com in both US and Asia, you could create 1 SRV record in the US company.com zone that points to the US pool, and 1 SRV record in Asia that points to the Asia pool. But for this to work though, you'd need to make sure that each region has its own (not replicated) company.com zone.

     

    And then the ultimate answer to your question is: If you put multiple SRV records in the same zone, pointing at different pools, your US users may be directed to the Asia pool and the Asia pool won't have any record of that US user (and vice-versa).

     

    Regards,

    Matt

     

     

    Wednesday, July 30, 2008 5:26 PM
  •  mmcgille wrote:

    And then the ultimate answer to your question is: If you put multiple SRV records in the same zone, pointing at different pools, your US users may be directed to the Asia pool and the Asia pool won't have any record of that US user (and vice-versa).

     

    Regards,

    Matt

     

     



    Matt, thanks for the response.  But the part I quoted I don't see how that's true.  Front End Servers and Standard Servers know how to route users to their pool..  So if we used our AD name as our SIP name, that DNS instance is replicated throughout the environment.  This means that we would have 1 SRV record pointing to that 1 pool and that 1 pool will re-direct users.  So I don't really understand why in your example you say the Asia pool won't have any record of that US User.  Sure it should.  It should see it in AD and route the user to their correct pool as internal pools support re-direction.

    This is why I'm wondering why multiple SRV records aren't supported since Front End Servers and Standard Servers can re-direct users to their pool.  If you have multiple SRV records, it'd seem as it'd just load balance between multiple Front End Servers and Standard Servers but since those Servers will route you, why should having more than one SRV record matter?

    Maybe I'm not following you.

    But really, there needs to be more documentation on the whole:
    "You must designate one (and only one) Enterprise pool or Standard Edition Server to authenticate and redirect client sign-in requests."
    Wednesday, July 30, 2008 5:37 PM
  • Regarding mulitple SRV records in the same DNS domain, the OCS 2007 Planning Guide (and the Standard Edition Deployment Guide) has a note about that:

     

    Important

    Only a single pool or Standard Edition Server can be designated to distribute sign-in requests. Create only one SRV record for the designated server or pool. Do NOT create this SRV record for additional internal servers or pools.


    I remember reading somewhere that if there are multiple records the clients will also choose one of them based on some criteria that I can't recall.

     

    Wednesday, July 30, 2008 5:39 PM
    Moderator
  •  Jeff Schertz wrote:

    Regarding mulitple SRV records in the same DNS domain, the OCS 2007 Planning Guide (and the Standard Edition Deployment Guide) has a note about that:

     

    Important

    Only a single pool or Standard Edition Server can be designated to distribute sign-in requests. Create only one SRV record for the designated server or pool. Do NOT create this SRV record for additional internal servers or pools.


    I remember reading somewhere that if there are multiple records the clients will also choose one of them based on some criteria that I can't recall.

     



    So you are confirming my though about the issue lying in Communicator and not OCS.  Thanks Jeff.

    Well, I start my deployment in a couple weeks.  SIP domain will be different than AD domain, and I'm going to try different methods.  Using the AD domain for SIP, using the separate zone for SIP domain (which the DNS zones won't be replicating) and write out some information on my findings.
    Wednesday, July 30, 2008 5:43 PM