Sign in
Microsoft.com
 
Microsoft
 
 
 

locked
autoconfiguration for server and method of connecting do not work, despite dns records being there... RRS feed

 > 

  • Question

  • Question
    Sign in to vote
    0
    Sign in to vote

     

    It simply wont connect unless we manually choose either TLS or TCP
    (either option seems to work)...

    The error is "Cannot sign in because the server is temporarily
    unavailable".

    When doing this manually, it seems either the direct ip or the dns
    name work fine..

    For SRV (local domain) records i have these two.. and i used nslookup
    to see if they show up on the clients..:

    _sipinternal (5060) serverb.domain.local  and _sipinternaltls (5061)
    serverb.domain.local

    Internally and externally i've been using TCP as the option, even
    though internall TLS will work.. I dont think i could get TLS to work
    externally, as the godaddy certificate wont work, if i choose to use
    TLS internally i dont think, as the SAN name wont match up.. and i
    dont think there is a workaround.

    Is TCP externally a bad idea?

    Thanks in advance.

    Tuesday, October 23, 2007 2:15 PM

All replies

  • Question
    Sign in to vote
    0
    Sign in to vote
     markm75c wrote:

     

    It simply wont connect unless we manually choose either TLS or TCP
    (either option seems to work)...

    The error is "Cannot sign in because the server is temporarily
    unavailable".

    When doing this manually, it seems either the direct ip or the dns
    name work fine..

    For SRV (local domain) records i have these two.. and i used nslookup
    to see if they show up on the clients..:

    _sipinternal (5060) serverb.domain.local  and _sipinternaltls (5061)
    serverb.domain.local

    Internally and externally i've been using TCP as the option, even
    though internall TLS will work.. I dont think i could get TLS to work
    externally, as the godaddy certificate wont work, if i choose to use
    TLS internally i dont think, as the SAN name wont match up.. and i
    dont think there is a workaround.

    Is TCP externally a bad idea?

    Thanks in advance.

     

    I did read somewhere that this can sometimes happen if the screen name used to login with, the domain.. is different than the server domain name..

    IE:  our users login with user@domain.com  while the server name is serverb.domain.local...

    Is there a way around this, if this is the case.. ie:  i dont want my users to have to sign in with user@domain.local... i prefer to keep the .com

    I guess i can just stick with GPO picking the method of connecting, but i was hoping to leave it to auto.

    Thanks

    Tuesday, October 23, 2007 2:20 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Hi,

     

    We have the same problem at my company, and the easiest solution we found was to use a GPO.

     

    There's no other way to tell the client to try another domain name.

     

    Friday, November 2, 2007 9:34 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Still no way?

    Monday, November 12, 2007 6:39 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    Make sure under the OCS Global properties that the @company.com is listed as the supported SIP domain and that company.local is not.

     

    Be sure that your internal DNS SRV record is set to _sipinternaltls._tcp.company.com (NOTcompany.local).  Same thing for the external DNS SRV.

    Thursday, November 29, 2007 6:24 PM
  • Question
    Sign in to vote
    0
    Sign in to vote

    You have to realize that automatic configuration queries DNS as noted above but the A record must be for the same domain as the SRV record which requires you populate the certificate with a SAN

     

    I edited this shortly after posting

    Edit -

    I put the wrong url reference in, apologies for any inconvenience, this is the post I wanted to share -

    http://blogs.technet.com/uc/archive/2006/09/06/454393.aspx

     

     

     

     

    Friday, November 30, 2007 7:51 PM