none
Communicator 2007 R1 R2 - Roaming Profile RRS feed

  • Question

  • Guys,

    I manage a huge enterprice and as consecuense our GALCONTACTS.DB is 50mb [compress Full file 12 mb], in addition the majority of my users use ROAMING PROFILE.  The network bandwidth is being affected by the download of Full file each time the user with roaming profile log on to the workstation as you know local setting are not save to the server and even if we set up the roaming profile to save the local setting to the server the users are complaining of slowness at log on in the workstations.  No matter if the roaming profile is configured to save the local setting or not, roaming profile is causing a big issue with Communicator because Communicator save or store the GALCONTACTS.DB in the Local Setting under the user profile.

    This is my proposal:  Why you don't create a registry key, GPO setting or GUI option in Communicator to allow the Administrator to save/store the GALCONTACTDS.DB out side the USER PROFILE.  THINK ABOUT IT!!!!  Having the option to choose will be AWESOME, If we choose to save/store the GALCONTACTS.DB for example C:\Program Files\Communicator per sample all users that log on to the workstation will have access to the file and it only need to be download it once.  Does not matter if is a local user profile or roaming profile both can share the same file.   This will be A HUGEEEE IMPROVEMENT TO THE NETWORK!!!

    We should have two option: use local setting to same GalContacts or save it else where ...Admin will choose where base on registry key, GPO or GUI in Communicator that way we cover all bases.

    Did you guys in MICROSOFT use ROAMING PROFILE, I GUESS NOT!!!!   Otherwise you will notice this obious problem with big enterprise.

    But don't worry the solution is simple ...create a registry key to save/store galcontact.db OUTSIDE the user profile local settings folder.

    Can you create a new version of Communicator 2007 R1 or R2 with this option? Yes, piece of cake!!
    Can you take this proposal to the developer of Communicator 2007 R1 or R2?

    I will like to see this option to resolve my network performance issue, pass this proposal to right person.

    Thanks, PRJUANL
    VB 2005 \ C# 2005
    Tuesday, March 16, 2010 2:43 AM

All replies

  • Hi
    Per my known, Sure, the OC client must download the addressbook into loacal, and then could search for the contact using the local galcontac.db.
    But if you use one account log in on one computer/device, you do not need to download the full addressbook again when you log in on the same computer/device next time except some update.
    If you log in on different computer/device, you need to download the full addressbook into your own profile.
    In my opinion, it like exchange account, a new profile will be built on the machine when you log in the same account on, the different is that the outllok could serach the contact online without download them into local.
    I think it is by design by MS OCS.
    I would also get more information from MS PT about your suggestion.

    Best regards!
    gavin 
    Thursday, March 18, 2010 7:38 AM
    Moderator
  • Hi

    I have to say that it is by design.

    Regards!
    gavin

    Monday, March 29, 2010 3:02 AM
    Moderator
  • Hi

    I have to say that it is by design.

    Regards!
    gavin

    Monday, March 29, 2010 3:02 AM
    Moderator
  • Hi Gavin-Zhang,

    My concern is not users with LOCAL PROFILE, is with users configured with ROAMING PROFILE.  The normal download behavior is to download the full file once and deltas files after that the cycle repeat each month.

    Now like I explained in my previous post since the GALCONTACTS.DB is saved under the Local Settings Directory and the content of the Local Settings Directory are NOT save to the server by default this is causing the GalContacts.db to be deleted each time the users with roaming profile log off and download a new full file each time a roaming profile user log on.

    What I'm asking Microsoft is to provide a way to save the GALCONTACTS.DB out of the Local Settings Directory.  By doing this we will increase the Network Performance tremendously since the users with ROAMING PROFILE will no longer need to download the full file each time they log on.

    Are you understanding my concern?

    Please before reply learn/study how ROAMING PROFILE works and where GALCONTACTS.DB is saved.

    Remember the mayority of my users are configured with ROAMING PROFILES.


    Thanks, PRJUANL


    VB 2005 \ C# 2005
    Thursday, April 1, 2010 1:02 AM
  • I think I am experiencing this issue in a Citrix based environment.

    The issue as I see it for the customer is that when they login to MOC it takes 10 minutes before they can actually get any contact name effectively resolved. If they type in the correct full SIP name then they can go ahead and use that, but that's skipping any form of address book look up function. As they are using Citrix there logon sessions get torn down all the time hence they never get the galcontacts.db cached for nay length of time. I assume most folks deployments don't experience this issue as they don't use roaming profiles so don't see the delay daily, just once when they install and first logon to MOC.

    My first question is it normal behaviour for galcontacts.db to take 10 minutes to download? This is a fairly small organisation of 1300 contacts so the the address book is less than 1MB so the actual download is trivialhnece this shouldn't be network related issue. Is there something else that holds up the ABS download such as a timer that can be adjusted?

    If there is no workaround, has anybody had any success with using folder redirection for roaming profiles so that the galcontacts.db is stored in a set location and no reload should be required?

    Alternatively, as a kludge perhaps a script could be run to download the latest galcontacts.db directly rather than waiting for MOC to do this, I'm sure that would cover the 10 minute window then?

    Jed

    Sunday, April 4, 2010 7:22 AM
  • prjuanl,

    Did you get an answer to your question for this?

    Thanks

    Wednesday, March 21, 2012 1:00 PM