Doug on SharePoint

Stuff on SharePoint and other things.

Another Content Deployment Problem:

Wow just when I thought we had our content deployment jobs fixed….

I worked another content deployment problem, this time I have the error!

Group cannot be found. at Microsoft.SharePoint.SPGroup.InitMember() at Microsoft.SharePoint.SPGroup..ctor(SPWeb web, ISecurableObject scope, SPUser user, String GroupName, Object[,] arrGroupsData, UInt32 index, Int32 iByParamId, SPGroupCollectionType groupCollectionType) at Microsoft.SharePoint.SPGroupCollection.get_Item(String name) at Microsoft.SharePoint.Deployment.RoleAssignmentXImport.UpdateAssignment(ImportStreamingContext context, SPWeb web, ISecurableObject obj, Boolean bAdd, String strUser, String strGroup, String strRole) at Microsoft.SharePoint.Deployment.RoleAssignmentXImport.ProcessElement(ImportStreamingContext context, XmlReader xr, SqlSession session) at Microsoft.SharePoint.Deployment.SqlImport.Run() at Microsoft.SharePoint.Deployment.SecurityObjectSerializer.SetObjectData(Object obj, SerializationInfo info, StreamingContext context, ISurrogateSelector selector) at Microsoft.SharePoint.Deployment.XmlFormatter.ParseObjectDirect(Object objParent, Type objectType) at Microsoft.SharePoint.Deployment.XmlFormatter.DeserializeObject(Type objectType, Boolean isChildObject, DeploymentObject envelope) at Microsoft.SharePoint.Deployment.XmlFormatter.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ObjectSerializer.Deserialize(Stream serializationStream) at Microsoft.SharePoint.Deployment.ImportObjectManager.ProcessObject(XmlReader xmlReader) at Microsoft.SharePoint.Deployment.SPImport.DeserializeObjects() at Microsoft.SharePoint.Deployment.SPImport.Run()</code>

Huh…What Group?

Let me give you a little bit of background on the environment. Content is being deployed to an externally facing server and consists of news & stuff and an area that is behind an FBA login. The path is set with the following: Deploy User Names is not checked and the Security Information is set to Role Definitions Only (not groups?). The main site is anonymous and the sites behind FBA have inheritance broken (more on that later).

On the source, a document lib had its inheritance broken and all of the groups removed, they didn’t want any publishers putting anything in there…(This is what was causing the job to have the error, more in a minute)

Still, what group?

First place to start is checking the content deployment logs….once it happens it will continue until you find that group…

You probably don’t have the ULS logging turned up for Content Deployment so you will need to do that…Once you have it turned up, run the job that is failing. It will error, check the logs…You should be able to find the error and a line or two above that error you should be able to find the site that that is causing that error. It will say something like not being able to get the group information.

Let’s talk about how inheritance is working with regards to content deployment (remember I am not pushing security, just Role Definitions – not groups?). When inheritance is broken, by default all of the group/security information remains on the site, we have all seen this. When the job is run, I expected to see the inheritance broken with all of the source groups still the same – not the case. What happened was inheritance was broken and all security information was removed – I need to check if some hotfix or SP2 changes this behavior and I will update.

Next…look at the site that is having the problem and compare the source and destination group information. Wait, the job removed all of the groups from the destination and the source groups were removed already….ok they are the same! Yes, they look the same but remember we have another variable, the changes that content deployment is trying to push to the destination.

Still haven’t figured out what group?

In figuring out what group, I inherited on both the source and destination and started comparing the two….

HA! In this case, there were some (3) SharePoint groups that were on the source and not the destination, so with that said all I did was add the groups on the destination at the same level (site collection for me) and ran the deployment job. Success!

Next the inheritance was broken on the inside and ran the job Success! – lastly I deleted the groups on the source and ran the job – SUCCESS!

That fixed it….

I will research why some of the groups were there and not others….remember, Role Definitions Only is not supposed to push the groups but some are pushed and some are not. I will update with what I find.

Recap:

  1. Turn up logging for Content Deployment
  2. Run the failed job
  3. Check the ULS logs for the error and determine what site is having the problem
  4. Start looking for differences in the groups
  5. Add the groups that are not on the destination that are on the source
  6. Run the job and hope you have found everything.
  7. If not wash, rinse, repeat…
Advertisements

07/18/2009 Posted by | Content Deployment | , | 2 Comments

Duplicate Content Type Error during Content Deployment Job

Had a problem the other day with content deployment.  Everything was running fine then the deployment jobs started failing with an error that started out with “Duplicate content type ‘Page'” ( I wish I had the entire message but the logs have rolled over since we have fixed it).  This content type was of the type ‘Page’ but it could be any of your content types.

Huh?

It turns out that the content deployment jobs don’t delete the content types from the document library on the destination if they have been removed from the source. In practice if you remove them from the source site and don’t ever use them, having them on the destination isn’t really a big deal….however, if you choose to put the content type back into the document library, then you have a problem. The content deploy job attempts to push the added content type and because it already exists, it is a duplicate the the job fails.

The error message doesn’t point you to the right document lib nor does it even point you to the right site. The best thing to do is to turn on auditing of content types in the site collection audit settings on the source.

If it happens again you will be able to see the site that it happened in…in this case there are a good 12 or so sites that are being deployed and by chance the auditing was turned on so we could see where the problem was happening (otherwise, you can remove the sites and add them back in one by one until the problem occurs again).

So how do you work around it? (no not 64bit)

All you need to do is delete the content type from the document lib on the destination and run your content deployment  job again, it should be successful.

Note: You should not be able to delete the content type if it is being referenced in the doc lib.

Prevention is another story.  Education of the user base and limiting the number of users that can perform this function is about the only way to prevent it…but now that you know how to fix it, you should be able to minimize the downtime of your content deployments.

07/17/2009 Posted by | Content Deployment | , | 1 Comment