locked
Cannot synchronize address book RRS feed

  • Question

  • Users are unable to retrieve their address book from the front end server. I ran a trace on the absserverhttphandler and it appears the user SID is unknown. Could it be I forgot some crucial provisioning in MPS? What could it be?

    Here is the tracelog for the domain admin in green, who is able to retrieve the address book. Below that the tracelog for a user that has been provisioned using MPS in red:


    TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(186))        [0]05F8.0C90::12/09/2008-15:34:03.660.0000246b

        ( 0090C5D0 )Request path: https://ocspool01.lab.local/Abs/Int/Handler/D-0b52-0b53.lsabs

     TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(207))        [0]05F8.0C90::12/09/2008-15:34:03.660.0000246c

        ( 0090C5D0 )Request file: D-0b52-0b53.lsabs

     TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(239))        [0]05F8.0C90::12/09/2008-15:34:03.660.0000246d

        ( 0090C5D0 )Request base directory: \\labocsfe01\ABS

     TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(263))        [0]05F8.0C90::12/09/2008-15:34:03.738.0000246e

        ( 0090C5D0 )Client Canonical Name: lab.local/Users/Administrator

     TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(269))        [0]05F8.0C90::12/09/2008-15:34:03.738.0000246f

        ( 0090C5D0 )Client ABS Folder: lab.local/Users

     TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(295))        [0]05F8.0C90::12/09/2008-15:34:03.738.00002470

        ( 0090C5D0 )Client request redirect path: \\labocsfe01\ABS\lab.local\Users\D-0b52-0b53.lsabs


    TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(186))        [0]05F8.0C90::12/09/2008-16:20:50.089.0000248f

        ( 0090C5D0 )Request path: https://ocspool01.lab.local/Abs/Int/Handler/F-0b53.lsabs

    TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(207))        [0]05F8.0C90::12/09/2008-16:20:50.089.00002490

        ( 0090C5D0 )Request file: F-0b53.lsabs

    TL_INFO (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(239))        [0]05F8.0C90::12/09/2008-16:20:50.089.00002491

        ( 0090C5D0 )Request base directory: \\labocsfe01\ABS

    TL_ERROR (TF_COMPONENT) ABServerHttpHandler (AbsHttpHandler.ProcessRequest:1381.idx(327))       [0]05F8.0C90::12/09/2008-16:20:50.089.00002492

        ( 0090C5D0 )Return 500 to client. ProcessRequest Exception:\nSystem.ApplicationException: User or contact object not found for SID: S-1-5-21-1750494654-4240407801-2677618340-1265

       at Microsoft.Rtc.ABServer.ADUtils.LookupUserOrContactDn(WindowsIdentity identity)

       at Microsoft.Rtc.ABServer.ADUtils.LookupUserOrContactCanonicalName(WindowsIdentity identity)

       at Microsoft.Rtc.ABServer.AbsHttpHandler.ProcessRequest(HttpContext context)



    Monday, December 15, 2008 1:50 PM

Answers

  • Finally, after contacting Microsoft, this problem has been solved. It appears in a hosted OCS setup the RTCComponentService account needs to be a member of the "Window-based Hosting Service Accounts" security group. This group has access to the hosting ou's.

    As far as I know this is not documented, at least not in the deployment guide.
    • Marked as answer by ®win Tuesday, January 6, 2009 1:41 PM
    Tuesday, January 6, 2009 1:41 PM

All replies

  • Can you download the file by going to https://ocspool01.lab.local/Abs/Int/Handler/F-0b53.lsabs?

    Make sure you do this from a different Server / Workstation than the OCS Server.

    What errors do you get on the Screen "Service Unavailable"?

    --geoff




    Monday, December 29, 2008 12:32 AM
  • If I authenticate using domain admin credentials, I can download the file. But when I authenticate using other users credentials I just get an empty browser window in IE (and the error in the tracing tool).

    If I understand the resolving mechanism right, absserverhandler tries to determine the path from where it should serve the correct address book files by trying to get the authenticating users canonical name.

    The path under \\labocsfe01\ABS is identical to the path to the user in the AD. For example the address book files for the user testuser@company.com are located in \\labocsfe01\ABS\lab.local\Hosting\Company\lab.company.com

    The canonical name for this user in the AD is: lab.local/Hosting/Company/lab.company.com/testuser@lab.company.com
    Monday, December 29, 2008 12:49 AM
  • Sounds to be either a permission issue in IIS or a permission issue on the File Shares.  What are the permissions set to on the File Shares "ABS"?

    --geoff
    Monday, December 29, 2008 12:51 AM
  • Permissions on the share ABS:
    Authenticated users: Read
    Everyone: Read
    RTCHSUniversalServices: Read/Change
    RTCUniversalGuestAccessGroup: Read
    RTCUniversalServerAdmins: Read/Change

    Security Settings for the site in IIS:
    Enable anonymous access enabled
    everything else disabled
    Monday, December 29, 2008 1:06 AM
  • The share permissions look correct.  the Security permissions should be as follows:

    Administrators, Creator Owner, System, Users - Inherited Permissions
    Authenticated Users Read & Execute, List Folder Contents, Read
    RTCHSUniversalServices Modify, Read & Execute, List Folder Contents, Read, Write
    RTCUniversalGuestAccessGroup Read & Execute, List Folder Contents, Read
    RTCUniversalServerAdmins Modify, Read & Execute, List Folder Contents, Read, Write

    In IIS - Authenticated should be turned on for the Default WebSite, but Integrated should be on for the Virtual Directories.

    Can you verify?

    --geoff

    Monday, December 29, 2008 1:14 AM
  • The security permissions are exactly as you say.

    In IIS the permissions on all virtual directories are currently set to enable access to anonymous access. This could be because I have been fiddling with it.

    Should anonymous access be disabled for all these virtual directories and integrated enabled? And for the directories under Ext and Int as well?

    I have now set the virtual directory Abs to integrated security only, but still get the same error in the tracelog.
    Monday, December 29, 2008 1:32 AM
  • Ok sounds like IIS is the issue then.  We go thru all of the permissions, but what I find easiest at this point is to uninstall Web Conf, Web Comp, IIS.  Then reinstall IIS and relaunch the OCS installer.  It will discover that Web Comp and Web Conf is missing and reinstall.  It will setup all of the required permissions in IIS.  This usually only takes about 15 minutes. 

    Is OCS the only program using IIS?  Was CWA installed on this server at any point?  If so remove it. 

    Is this OCS Standard or Enterprise?

    --geoff
    Monday, December 29, 2008 1:36 AM
  • Thanks for taking the time Geoff. I will try your suggestion to reinstall those components.

    OCS is the only program using IIS on this machine and CWA is also installed on this machine, it is using a different website and IP though. Could the CWA install still be the cause of my problems?

    I'm using enterprise by the way.
    Monday, December 29, 2008 1:40 AM
  • In OCS 2007, CWA is not supported on the same server as Web Components.  So then in your case I would also uninstall CWA.  Then reinstall everything else except for CWA.  Test and it should work.  Then if you must reinstall CWA.  I have gotten CWA to work on a Web Components server before on a different IP, but usually is not fun.

    The easiest is to keep CWA off the Web Components server if possible.  But in most cases CWA has always broken Web Components.  But millage may very - haha.

    --geoff
    Monday, December 29, 2008 1:43 AM
  • I forgot to mention - make sure you deactivate the roles before uninstalling.
    Monday, December 29, 2008 2:06 AM
  • Ok, I uninstalled then reinstalled IIS, Web Conf and Web Comp as you suggested but am still getting the same results (and error in trace). I saw you post about deactivating the roles too late however... Is this a showstopper? If so, how do I deactivate the roles? Sounds to me this can't make the permissions on IIS invalid.
    Monday, December 29, 2008 2:15 AM
  • When you uninstalled it should have prompted you about deactivating?  I assume you did not?  So the steps should have been:

    Deactivate: CWA, Web Conf, Web Comp
    Uninstall CWA, Web Conf, Web Comp, IIS
    Reinstall IIS, Web Conf, Web Comp

    I assume you did not deactivate, but was CWA uninstalled?  We might need to go into ADSIEDIT to clean up some Attributes.

    --geoff
    Monday, December 29, 2008 2:18 AM
  • If uninstalling prompted to deactivate, I will have done it. Can't remember seeing it though. I didn't deactivate in the OCS console (found it) previous to uninstall however.

    CWA was uninstalled as well (and not reinstalled), I should have mentioned that in my previous post.


    Monday, December 29, 2008 2:23 AM
  • Ok lets check something first.  Are you familar with ADSIEDIT?  If so go to the following location:

    DN:CN=Trusted WebComponentsServers,CN=RTC Service,CN=Microsoft,CN=System,DC=domain,DC=com

    Domain, com would be your root domain.

    I am curious how may containers are under this CN.

    --geoff

    Monday, December 29, 2008 2:29 AM
  • There is only one container under this CN
    Monday, December 29, 2008 2:32 AM
  • Ok then we should be in good shape.  When you are trying to access this URL are you doing it from the OCS Server?  If you are try from another server or workstation.

    There is Loopback check in IIS that will fail if you are trying this from the server.

    --geoff
    Monday, December 29, 2008 2:34 AM
  • I tried it from a server in a different domain as well as the PDC, both give the same results.
    Monday, December 29, 2008 2:37 AM
  • Ok you are testing with the same user when failing?  Can you create a different user or try any domain user.  They do not have to be enabled for OCS to download this file.
    Monday, December 29, 2008 2:38 AM
  • Tried with 5 different users, only users located in lab.local/Users container seem to be able to download the file. All others cause the error.

    Other users are all in the lab.local/Hosting/Company container
    Monday, December 29, 2008 2:44 AM
  •  Yea I started looking at the Client request redirect path in my Lab.  Mine shows very simple:  \\2k3ocs07\ocabs\d-0b55-0b56.dabs

    I need to understand more in your enviroment to go further.  Looks like it is working, just not for users in certain OU's.

    Are the OU's labled with hosting/company or is the nesting you are showing me?



    Monday, December 29, 2008 2:50 AM
  • It's the nesting. The complete path to a user would be:

    lab.local/Hosting/Company/lab.company.nl/testuser@lab.company.nl (copied from object description of user properties)
    Monday, December 29, 2008 2:53 AM
  • I have not tested from Nested OU's.  I will try and replicate this tomorrow and let you know my findings.

    --geoff
    Monday, December 29, 2008 5:27 AM
  • Also let me understand - this is a different domain?  I assume the sip uri for this user is testuser@lab.company.nl.  Has this domain been preped by OCS?  I assume this a different domain in the Forest?

    --geoff
    Monday, December 29, 2008 5:31 AM
  • The AD contains only one domain (lab.local). The sip uri is identical to the username in this case and is indeed testuser@lab.company.nl. The win2k compatible name is lab\testuser_la

    Please let me know if you need more info.
    Monday, December 29, 2008 7:26 AM
  • Ok so if you were to login with this username you would use.

    lab\testuser@labcompany.nl

    If this is the case this could be issue.  Try creating another user in the same OU but just like testuser.

    --geoff
    Monday, December 29, 2008 3:35 PM
  • I created two new users in the same OU (lab.company.nl) with pre-win2000 names LAB\testuser5 and LAB\testuser6

    The standard logon names are
    testuser5@lab.company.nl (when creating a user in that OU, I was able to choose from @lab.local and @lab.company.nl)
    testuser6@lab.local

    I'm still getting the same error for both accounts. Tried https://ocspool01.lab.local/Abs/Int/Handler/F-0b53.lsabs and logging in with the full logon names and with the pre-win2000 names.

    Also created a testuser directly in the Hosting OU. Same error.

    Created a testuser in the default lab.local/Users OU and was able to download the ab file.



    Monday, December 29, 2008 6:20 PM
  • Ok I have done some testing with your setup.

    I created an account with the name of orogers@test.net.  But you can see from an LDP dump the userPrincipalName is orogers@test.net@mylab.nc and the sAMAccountName is orogers_te.

    If I give it a sip uri of orogers@test.net - that will not match.  So if I try to download the file, I can authenticate 2 ways.

    orogers@test.net@mylab.nc or mylab\orogers_te

    Downloading the file using one of the 2 formats listed above should allow you to download the file. 

    For your SIP URI are you using sip:orogers@test.net@mylab.nc or sip:orogers@test.net?

    --geoff
    Monday, December 29, 2008 6:21 PM
  • Geoff I'm sorry I might have been unclear. My user principal names don't have two '@' in them. testuser's userPrincipalName is just testuser@lab.company.nl and sAMAccountName is testuser_la

    The sip uri belonging to this user is identical to its userPrincipalNameand so testuser@lab.company.nl

    Did you try creating a user in a different OU? For example under Hosting?
    Monday, December 29, 2008 6:29 PM
  • Ok I just set up the same OU path

    mylab.nc/Hosting/Company/lab.company.nl/testuser@lab.company.nl

    SamAccount of testuser_la

    I was able to login using mylab\testuser_la

    Make sure you not blocking inheritance on Group Policy Tab of your OU's.

    --geoff
    Monday, December 29, 2008 6:29 PM
  • Well if that is the case, then test it they I have shown and I bet it works.  So you have created another AD domain?  If you are able to select what domain they belong to when creating the AD account - then that domain needs to be prepped by OCS.

    --geoff
    Monday, December 29, 2008 6:32 PM
  • lab.company.nl is not another domain, it's a businessorganisation created with MPS (CreateBusinessOrganization.xml). The AD still only contains one domain (DC=lab,DC=local)

    Authenticating is possible with either testuser@lab.company.nl or with LAB\testuser_la
    For testuser6@lab.local authenticating is possible with either testuser6@lab.local or with LAB\testuser6_la


    Monday, December 29, 2008 6:45 PM
  • I am not familar with MPS, but this might get you were you need to be - http://technet.microsoft.com/en-us/library/cc501473.aspx
    Monday, December 29, 2008 6:52 PM
  • Just took a quick look at this - I see where it talks about MPS.  Our group does not support MPS or hosted OCS, and I have not tested it.  I will read thru it and see if anything stands out to me.
    Monday, December 29, 2008 6:55 PM
  • I'm familiar with the deployment guide. I used HMC_4.5_Help.chm as a guide, which has building a hosted OCS environment as a chapter.

    From the moment this error occurred I had the feeling I missed a step in provisioning somewhere, but can't figure out where.
    Monday, December 29, 2008 7:04 PM
  • Thinking this might be a permissions issue on the Hosting OU. What account is being used by abshttphandler to query the AD for the users canonical name?
    Tuesday, January 6, 2009 10:50 AM
  • Ok I think I can confirm this is the problem. I gave everyone read rights on the Hosting and child containers and now it works! Ofcourse this is no solution, so I still need to find out what the permissions should be and why they haven't been set in the first place.
    Tuesday, January 6, 2009 11:13 AM
  • Finally, after contacting Microsoft, this problem has been solved. It appears in a hosted OCS setup the RTCComponentService account needs to be a member of the "Window-based Hosting Service Accounts" security group. This group has access to the hosting ou's.

    As far as I know this is not documented, at least not in the deployment guide.
    • Marked as answer by ®win Tuesday, January 6, 2009 1:41 PM
    Tuesday, January 6, 2009 1:41 PM