Identifying a SiteID from the SSP Content SiteSync table RRS feed

  • Question

  • I am trying to track down a problem I am having with user profiles in the SSP not being synched in the way I expected in site collections.

    I have seen recommended a number of times to check to see if the Moving flag is set to true . I ran SELECT * FROM SiteSynch WHERE Moving = '1' and got 2 records returned.

    Then I did an stsadm -o enumallwebs

    against each of the sharepoint content databases, and could not find the SiteId in the SiteSynch records associated with any sites.

    Is there a way for me to identify the specific site URLs still having the Moving flag set to 1?

    Wednesday, January 30, 2013 2:34 PM

All replies

  • Hi,

    What behavior are youexpecting and have you tried using stsadm -o sync???

    stsadm -o sync {-ExcludeWebApps <web applications> | -SyncTiming <schedule(M/H/D:value)> | -SweepTiming <schedule(M/H/D:value)> | -ListOldDatabases <days> | -DeleteOldDatabases <days>}

    Reference: http://technet.microsoft.com/en-us/library/cc263196.aspx & http://blogs.msdn.com/b/spblog/archive/2009/06/18/stsadm-part-1.aspx


    EX: stsadm -o sync listolddatabases 0


    Check it out, there are a few that have not synched since 8/11/08, 7/25/08, and 12/10/08.

    Note: command lists the databases that have not synchronized with the SSP in zero days.


    EX: stsadm -o sync deleteolddatabases 1



    >> This will delete synch records for all the content DBs that have not synched in the last 1 day.


     Now as you can see we only show DBs that have synched with the SSP today.


    M:<# of minutes>

    H:<# of hours>

    Set back to default (h:1) when done testing.

    EX: stsadm -o sync -synctiming m:5


    Note: This is useful for testing synch problems. You can set the synch schedule to every 5 minutes instead of every 1 hour.


    Ivan Sanders My LinkedIn , My Blog, @iasanders, BI in SP2013, SP2013 Content Packs.

    Monday, July 1, 2013 3:42 AM
  • Re: what behavior am I experiencing

    We see the following behavior. The information in a user's profile record is mostly kept in sync with the site collection user list.

    However, there are times in our organziation in which a user's login changes - they change names, they change departments, etc.

    When that happens, all of the user's information - except the account field - is updated. However, in a recent example, when the user moved from abc53 to abc57, the account stayed abc53, but the login name within the site collection user list did change.

    This causes problems when code retrieves user info from an infopath, it causes problems when the user tries to check out a document and make changes, etc.

    I have worked with stsadm and the sync commands and those do not seem to be relevant. The syncing is working - but the one field does not change.

    Monday, July 1, 2013 4:44 PM
  • Dear,

    If sites are unaffected from preparetomove –undo? Please also check MovingDeleted="1"

    Please note that there is no other way to get rid of the MovingDeleted mark in the SiteSynch table. Because SharePoint will not try to synch the site with this GUID anymore. The only way to fix it is as below:

    1. Use stsadm -o backup -url “site url” -filename “file name for the backup” command to back up the site collection.
    2. Delete the site collection.
    3. Use stsadm -o restore -url “site url” - filename “file name for the backup” command to restore the site collection. It will generate a new GUID for the site collection so that the new one can be synched.

    Let me know if this help,

    Friday, October 11, 2013 6:30 PM
  • thank you for the suggestion. As I have mentioned above, the sync is, for the most part, working.

    The issue that we are having occurs when a user's account name changes. When this happens, the actual user profile is updated as expected.

    Interestingly enough, even though the account name seems to be a key, after the change, the sync between user profiles and site collection user lists appears to occur, syncing everything EXCEPT for the key.

    The user's department numbers, or names, etc. show updated. However, the account name remains the same.

    The problem is that retaining the old account name key results in various MOSS SP 2007 problems; occasional problems with document sign ins, problems when infopath attempts to retrieve user information via the sharepoint web service, etc.

    We can manually delete the user from the site collection user list, then re-add them to the site. We are trying to keep up now with manually performing this process. It would be so much better if the system just updated that field itself so we didn't have to.

    Tuesday, October 29, 2013 11:59 AM