locked
Automatic login issue RRS feed

  • Question

  • I have recently deployed OCS 2007 for our company. We wanted to use automatic login and we wanted to use our email address as our username/login address but the problem is we have a different domain name on our email address as to our inter AD domain, to say it we have a different domain name on out OCS server.

     

    For example

    our email address is myname@companyname.com and our internal domain is internaldomain.net thus making our server ocssername.internaldomain.net. plus the domain name companyname.com is hosted on our external domain so I cannot create a svr record _sipinternaltls._tcp.companyname.com on our internal DNS because it will create issues on our external DNS. and if we create a srv record on our external DNS a _sipinternaltls._tcp.companyname.com that points to ocsserver.internaldomain.net we are getting this error on the client communicator trying to login using automatic login:

     

    Event Type:       Error

    Event Source:    Communicator

    Event Category: None

    Event ID:           2

    Date:                4/21/2008

    Time:                4:16:38 PM

    User:                N/A

    Computer:         client

    Description:

    Communicator was unable to locate the login server.  The DNS SRV record that exist for domain companyname.com point to an invalid server ocsserver.internaldomain.net which is not trusted to provide support for the domain because the server's domain is not an exact match.

     

     Resolution:

     The network administrator will need to double-check the DNS SRV record configuration to make sure that the SRV record for the domain points to a server name that conforms to the DNS naming convention in the server deployment guide.

     

    For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

     

    If I configure the client communicator to log in settings to Manual and points it to the internal server and use tls it works fine but the problem is we want to use the AUTOMATIC Configuration for client/comunicator login. Is this possible?

     

    Thanks in advance for anybody who can and try to help

     

     

    Monday, April 21, 2008 9:09 PM

Answers

  •  

    We got the fix.

     

    What we did is we creted a new zone on our internal DNS. Since there is no easy way to create externaldomain.com zone on our internal DNS because it is being host on our external DNS (exept maybe by creating a split DNS) as explain further by Matt. The new zone we created is _tcp.externaldomaim.com and create a CNAME winocsservername that maps to the OCS server IP address and from that zone created the _sipinternaltls._tcp SRV record. But after creating this zone make sure you also update your certificate that has the new zones on its alternate subject name otherwise you will have a new issue which is a certificate issue.

     

    I'm just suprise microsoft did not include this on the documentation since we dont always expect that the email addresses would have the same name with the internal domain  

     

    Thank you every one for the help appriciate it very much. 

    Wednesday, April 23, 2008 8:17 PM

All replies

  • I too am having the same problem.

    Tuesday, April 22, 2008 8:45 PM
  • Hi,

    You will need to either:

     

    1) change your SIP accounts to match your e-mail addressess (recommended) - this is pretty easy to do and is non-invasive. You can go through the OCS configuration snap-in and add a sip domain that matches your SMTP domain. It doesn't matter what your internal AD name is, you can create a SIP domain within OCS that matches your external e-mail domain.

     

    2) you can just have your clients log in with username@internanaldomain.net. This will get them logging in automatically, but you will not see presence information in office apps or sharepoint etc. I don't recommend doing it this way, but just for kicks you could test it.

     

    Option 1 is defintely the way to go.

     

    Regards,

    Matt

     

     

    Tuesday, April 22, 2008 9:31 PM
  •  

    Hi


    Instead of making your SRV record point to A record in internaldomain.net domain, try to make your SRV record in companyname.com point to an A record created in companyname.com, this A filled directly with OCS server IP Address.

    Tuesday, April 22, 2008 9:34 PM
  •  

    Matt,

     

    number one was our current configuration automatic login looks ok but our problem was the Automatic Configuration of Communicator. This is our current setup but if we have Communicator setup its connection to Automatic configuration we are experiencing the error above. Setting up Manual configuration is works fine but we are trying to make the Automatic Configuration works so we dont have to set it manually and our users does not have to see the connections.

     

    number two works (this was my initial setup) but like you said there are some features that does not work and we dont want Public IM see's our usernames as username@internaldomain.net instead of our email addresses. What we need is to use our email address.

     

    Thanks

     

    Chris

     

    Wednesday, April 23, 2008 2:34 PM
  • It sounds like your issue now is down to DNS configuration I would think as NKV stated earlier in the thread

     

    You must configure internally on your internal DNS Servers your SMTP/Email/External domain name and then configure the relevant DNS records that are needed for the automatic configuration to work

     

    So for example, if you domain is ocs.com then you will need to have a zone in DNS called ocs.com and then within that create an SRV record which points either via TCP or TLS at your OCS Server (which can be ocsserver.internaldomain.net) on the relevant TCP or TLS port.

     

    It sounds lik eyou already have the right idea with DNS if it is working with your internal domain...

     

    hope this helps

     

    cheers

     

    Wednesday, April 23, 2008 2:47 PM
  • nkv,

     

    I'm going to try this, but our initial testing on this setup before is that we had the same error and we also have a certificate error since domain name does not match. I'll let you know what happens.

     

    Wednesday, April 23, 2008 2:47 PM
  • Hi Chris,

    ok - then yeah - as the others here have suggested, I would create an SRV on your internal DNS for your servername.

     

    Here's the trick, though: you need to already have a zone created in  internal DNS server for companyname.com (your external domain name).

     

    If you have that zone created in DNS, it's no biggie to just put an SRV record in there and point it to your internal OCS pool name.

     

    However, if you don't already have an internal DNS zone for "companyname.com" - you need to talk to your DNS guys about it. Because the minute you create that zone, anyone trying to browse to www.companyname.com will be looking to your internal DNS servers to resolve the name, and if you don't have an A record for www.companyname.com in your newly created zone, then people won't be able to reach www (or any external server for that matter) by DNS resolution.

     

    So you will definitely solve your problem by creating the SRV record on your internal DNS servers in a DNS zone called companyname.com, but you need to make sure that either:

    1) the zone already exists

    2) that it's ok with the DNS / AD people that you create a zone on the internal DNS servers & you have all the necessary A records in it.

     

    Regards,

    Matt

     

    Wednesday, April 23, 2008 5:23 PM
  •  

    We got the fix.

     

    What we did is we creted a new zone on our internal DNS. Since there is no easy way to create externaldomain.com zone on our internal DNS because it is being host on our external DNS (exept maybe by creating a split DNS) as explain further by Matt. The new zone we created is _tcp.externaldomaim.com and create a CNAME winocsservername that maps to the OCS server IP address and from that zone created the _sipinternaltls._tcp SRV record. But after creating this zone make sure you also update your certificate that has the new zones on its alternate subject name otherwise you will have a new issue which is a certificate issue.

     

    I'm just suprise microsoft did not include this on the documentation since we dont always expect that the email addresses would have the same name with the internal domain  

     

    Thank you every one for the help appriciate it very much. 

    Wednesday, April 23, 2008 8:17 PM
  • Silvrsrfr2 could you explain what you did in this fix a bit more clearly. I have had the exact same problem as you for months and I have just stumbled upon your fix. If you could explain the CNAME steps with an example I would appreciate it greatly.

     

    Thanks.

     

    Thursday, May 29, 2008 4:25 PM
  • For example: our external domain is external.com our internal domain is internal.com our email are setup myname@external.com our OCS 2007 server FQDN OCserver.internal.com

     

    What we did so I can configure our users to use our email address as their sign in address and also be able to set them up with automatic configuration we created on our internal DNS a zone with _tcp.external.com in it we created an Aliase (CNAME) OCserver which has the FQDN = OCserver._tcp.external.com and an (FQDN) for target host = OCserver.internal.com 

     

    In the _tcp.external.com zone we also created a SRV _sipinternaltls and a SRV _sipinternal that are both have this settings: Domain =  _tcp.external.com, Service = _sipinternaltls and _sipinternal as follows, Protocol = _tcp, Portnumber=5061, Host offering this service = OCserver._tcp.external.com

     

    our users end result setting: Sign in Address = myname@external.com, Username and Password = our windows domain username and password

     

     

    Hopes this help

    Thursday, May 29, 2008 9:05 PM
  • Yes that worked a treat. Thanks very much for your more detailed explanation. I've been trying to find this fix for 4 months. Cannot believe this is not documented properly by Microshaft somewhere as it must be a common scenario.

     

    Cheers

     

    Monday, June 2, 2008 11:59 AM