locked
After running Migrate User, content deployment messes up user properties RRS feed

  • Question

  • Hello,

    We are right in the middle of changing from several domains into one.  For the SharePoint portion of this we have been running stsasm -o migrateuser to migrate users from their old domains to the new one.  Also, all but one of our sites receive content deployment.  If content deployment is set to deploy all content then it messes up random attributes for some random users at the sites that receive content deployment.  For example, somone's display name might change from "John Doe" to domain\jdoe.  In some really bad cases "John Doe"s display name might change to their managers account name.  Also, e-mail addresses sometimes get cleared.  I can tell that content deployment is the cause of this because fields can be fixed, but then mess up again when content deployment runs.

    - We run stsadm migrateuser at all sites, remotely (pstools)
    - Only properties in the user list at the top of the site collection get messed up, not the SSP.
    - The problems occur only when content deployment is set to deploy all content.
    - I think deploying only new or changed content (incremental) works because accounts don't get deployed unless something changes (makes sense)
    - Olnly a few users get messed up, not all of them
    - I have checked for anything different about the AD accounts, such as a \ in a field or something.  Special characters do not seem to have any correlation.

    Please let me know if you have any ideas.

    -Eric

    Thursday, May 26, 2011 9:39 PM

All replies

  • Hi,

     

    According to your description, "John Doe"s display name might change to their managers account name, in my opinion, it  may be deploy partial content without exporting the parent items.

    When deploying with retaining the object identity (as you can do with content deployment in the central admin) it is not possible to reparent items. Deployment with retaining the object identity requires that the identity of the object is the same on the destination server and the identity is defined by Id, Name and by the Url.

    So the parent of each deployed object has to exist on the destination server in order to successfully import the package on the destination server. We have seen that customers are trying to export a specific subtree of the site without exporting the parents. E.g. only a specific variation label without the variation root.

    If the parent of the exported objects does not exist on the importing site then the item cannot be imported and the deployment will fail.

     

    Best Regards
    David Hu
    • Marked as answer by Emir Liu Thursday, June 2, 2011 1:40 AM
    • Unmarked as answer by Eric Sammann Thursday, June 2, 2011 3:36 PM
    Monday, May 30, 2011 1:47 AM
  • Thank you for the reply David.

    Unfortunately I don't think your reply is the correct answer in this case.  We have been using content deployment for over a year now without this problem.  We use it as more of a multi-site (geographic) deployment scenario instead of dev -> staging -> production scenario.  This is supposed to be a supported configuration.  The problem only started happening after we migrated to a new domain.  Also, the parent of the object should exist at each site that is having this problem.  We deploy only the top site and a couple sub-sites.  Since we deploy the top level site we are not trying to reparent any sites.  The user information list only exists at the top level of the site collection, so the site exists with the same GUID, and the user list exists with the same GUID at each site (the parents to the user records).

    The user records do not have the same ID.  These items have never had the same ID though, and things were fine prior to the domain change so I don't see this as being an issue.  You said "If the parent of the exported objects does not exist on the importing site then the item cannot be imported and the deployment will fail."  The parents do exist, and content deployment does not fail.  The problem is that about 10% of the users get messed up attributes.  About 1% get really messed up, where the display name belongs to someone else.

    Thanks,

    Eric

    Thursday, June 2, 2011 4:36 PM