locked
Automatic Client Configuration RRS feed

  • Question

  • hi,

     

    one of your customer has only a external dns zone. the clients in internal network are connected to the external dns server. but the ocs 2007 server deployment was placed in internal network.

     

    customer want to have automatic client configuration and is short term not be able to setup a internal dns zone.

     

    is there a way to setup external / internal automatic client configuration on external dns zone?

     

    Thanks

    AB74

    Thursday, July 24, 2008 1:19 PM

All replies

  • Is the external DNS server an AD-Integrated system?  I'm a little unclear on how they could be running a Windows Domain and only have an external DNS server. I get the chills thinking about the security ramifications and replication<>firewall issues that setup would have.

     

    Can you provide some more details on the environment?  One way to go would be to use the same FQDN for the internal server and the Edge Access FQDN, but that may not be possible in some goofy AD deployment.

    Thursday, July 24, 2008 2:04 PM
    Moderator
  • hi jeff,

     

    the external dns server which hosts the zone are only implemented for mail and external web pages (example: @company1.com).

     

    the clients are located in AD domain (example: local.net) and has an e-mail address like (@company1.com). we set up a corparate policy that the e-mail address is equal to the sip-address.

     

    external we have the srv registered but for internal there is not way to do it? do you have the steps when communicator is trying to logon to OCS?

     

    is there a way to use the @company1.com external dns zone for internal and external automatic client configuration?

     

    Thanks

    AB74

     

     

    Thursday, July 24, 2008 2:38 PM
  • OK, that clears things up a bit.  You don't need to use SRV records for Automatic Configuration, if none exist then OC will fallback to standard A records, see my blog for more details:

    http://blogs.pointbridge.com/Blogs/schertz_jeff/Pages/Post.aspx?_ID=14

     

    I would just create sipinternal and sipexternal A records pointing to the Front-End and Edge Access FQDNs respectiviley, and that should work.  Or you could use a combination of SRV and A records to get the desired results, just configure them as you wish, paying attention to the order that they are resolved.

     

    Thursday, July 24, 2008 2:50 PM
    Moderator
  • hi,

     

    what will exactly happen when we register both of the srv's on external dns?

     

    example:

     

    1) internal srv points to sipinternal.company1.com

    2) external srv points to sipexternal.company1.com

     

    scenario:

     

    client is outside and can retrieve both of the srv's but one of the srv's can response for the service? what will happend in your described sequence?

     

  • sipinternal.domain.com
  • sip.domain.com
  • sipexternal.domain.com

     

    Thanks

    AB74

     

     

     

Thursday, July 24, 2008 3:06 PM
  • Taken straight from the OCS 2007 Resource Kit Book:

     

    Code Snippet

    Communicator can query for the following SRV records in it's search for an appropriate server:

     

    _sipinternaltls._tcp.contoso.com

    _sipinternal._tcp.contoso.com

    _sip._tls.contoso.com

     

    Failing these, it falls back to host (A) record queries:

     

    sipinternal.contoso.com (over TLS)

    sipinternal.contoso.com (over TCP)

    sipexternal.contoso.com (over TLS)

     

     

    Your clients will always receive the same DNS responses regardless of their location (internal/external) since there is only one source of name resolution.

     

    Here are two configuration options:

     

    (1) Define _sipinternaltls._tcp.domain.com for the Front-End (or internal pool) FQDN and _sip._tls.contoso.com for the Access Edge FQDN.

     

    (2) Or simply ditch the SRV records altogether, and define sipinternal.domain.com and sipexternal.domain.com DNS records instead.

    Thursday, July 24, 2008 3:38 PM
    Moderator
  • hi jeff,

     

    I have already tested the scenario and notized that the communicator did not fall back to A records!

     

    AB74

    Thursday, July 24, 2008 9:44 PM
  • Hi,

    You may want to double check the registry and / or any group policies that could be manually setting the external servername.

     

    I would also suggest installing netmon or some sniffer on your client and watching the DNS queries go out. If you can do that and report back which queries the client makes, that will help narrow down the problem.

     

    Regards,

    Matt

     

     

    Thursday, July 24, 2008 10:20 PM
  •  Jeff Schertz wrote:

    Your clients will always receive the same DNS responses regardless of their location (internal/external) since there is only one source of name resolution.

     

    Here are two configuration options:

     

    (1) Define _sipinternaltls._tcp.domain.com for the Front-End (or internal pool) FQDN and _sip._tls.contoso.com for the Access Edge FQDN.

     

    (2) Or simply ditch the SRV records altogether, and define sipinternal.domain.com and sipexternal.domain.com DNS records instead.




    Before login client never knows if it is external or internal. After login it gets one via header telling it that its a remote user.

    So it wont be able to filter which SRV or A record it shoulld query when login from outside the network.

    I am pretty much sure you dont have any solution using A record or the SRV record for automatic configuration.

    There is only one solution in this situation, n that is to use the Group Policy. Use Group Policy to define the external and internal OCS FQDN.


    Regards,
    R. Kinker
    MCSE 2003 (Messaging), MCTS - LCS 2005, MCTS - OCS 2007
    http://www.ocspedia.com
    http://www.itcentrics.com/LCS_Home.htm
    Friday, July 25, 2008 5:50 AM
  • So I tested my theory out in my lab and I was reminded what I discovered back when I originally wrote that blog; the failback only works if the name lookup fails, not the connection to the server.

     

    The idea is that the client can't know if it's internal or external and it checks for internal 'names' first, but the intended design is that while external the DNS lookup should fail.  But if the internal servername does resolve, which in your case it will from any location, then the client immediately attempts a connection to that server.  When the connection attempt fails the client errors out, and it not programmed to go back to the name lookup step.  It will take the first FQDN it is given via DNS and run with it.

     

    So you'll need to use manual configuration.  Aside from the fact that the client really should be running a split-DNS configuration Wink

    Friday, July 25, 2008 12:44 PM
    Moderator
  • hi jeff,

     

    thanks for your support and efforts testing the scenario to help use. we have decided to configure the clients manually which an internal dns zone is not available.

     

    thanks

    AB

     

    Monday, July 28, 2008 10:07 AM