locked
Sign in address not found RRS feed

  • Question

  • We have been running OCS 2007 in a lab environment for a while with no issues. Have now installed OCS into a live environment and am starting to add test users but only some are able to log in.

     

    The error given is:

    "Cannot sign in to Communicator because this sign-in address was not found. Please verify the sign-in address and try again..."

     

    It is possible to predict which of these will fail from the fact that when you add these users to your contact list, some appear as "Offline" and others as "Presence Unknown". The users who give off the presence unknown status are the ones who will not be able log in when you attempt to do so.

     

    The only common factor I can find is that users who are members of administrative groups can log in and users who are not cannot. I obviously don't want to make all of my users domain administrators.

     

    This is purely a single domain setup and users that are able to log in can use all aspects of OCS - presence, telephony, messaging, conferencing etc etc so it has to be something REALLY simple.

     

    Please someone put me out of my misery.

     

     

    Thursday, February 7, 2008 4:14 PM

Answers

  • I've run into this issue a couple times, thankfully in the lab. I wouldn't say it's domain prep so much as replication. I would go through and ensure you don't have any AD replication issues. That said, if replication is A-OK, running domain prep again may resolve the problem (I've had it fail for no good reason once or twice).

     

    Alex

     

    Thursday, February 7, 2008 7:23 PM
  • Thank you both for your replies. Domain prep was not the answer, but it did point me in the right direction.

     

    It was partly down to replication...

     

    The problem was that the RTC groups are given specific access levels to the various containers in AD. The top level OU containing our users was not inheriting permissions from the parent. Now the RTC groups have permission, users are entered into the rtc(static) database which they were not previously and everyone can log in.

     

    Cheers guys
    Friday, February 8, 2008 12:07 PM

All replies

  •  

    I had the same error just this morning.  It was an issue with the Domain Prep.  All I did was rerun setup and it showed me a partal status on the AD prep step.
    Thursday, February 7, 2008 6:13 PM
  • I've run into this issue a couple times, thankfully in the lab. I wouldn't say it's domain prep so much as replication. I would go through and ensure you don't have any AD replication issues. That said, if replication is A-OK, running domain prep again may resolve the problem (I've had it fail for no good reason once or twice).

     

    Alex

     

    Thursday, February 7, 2008 7:23 PM
  • Thank you both for your replies. Domain prep was not the answer, but it did point me in the right direction.

     

    It was partly down to replication...

     

    The problem was that the RTC groups are given specific access levels to the various containers in AD. The top level OU containing our users was not inheriting permissions from the parent. Now the RTC groups have permission, users are entered into the rtc(static) database which they were not previously and everyone can log in.

     

    Cheers guys
    Friday, February 8, 2008 12:07 PM
  •  

    Can you tell me how you fixed the problems you listed?  Thanks.
    Thursday, May 15, 2008 11:36 PM