Content Types sent from the syndication hub across the enterprise are one of the biggest benefits of the syndication hub. It allows standadization across the enterprise, and a way to ensure that the entire enterprise has access to the same authorized content types. There is a catch though. If the content type is changed at the local level, it *can* then detach itself from its parent in the syndication hub. You will be able to tell this has happened when changes made at the syndication hub are no longer being accepted at the local level and you are seeing messages in the content publication log that say that there was a preimport check that failed because a particular column from the content type found a pre-exising column with the same name as a column needed by the content type.
Until now, the only resolution I had found for this was to delete any content in the corrupted library, then delete the corrupted content type. Then I could delete the corrupted site columns from the local site columns. Once all that was done, I could repush out the content type from the syndication hub. As you can imagine, this is not a great solution if there is live content on that site. So, I contacted MicroSoft. Their solution was to read a blog that discussed this very problem. Unfortunately, the solution was this very solution, and had been proposed by me. I was not very happy that the best they could do was give me my own solution. But, I followed my own advice, and sadly moved forward.
Then, I had another library get corrupted; actually, several. I don't know how they got corrupted, but this time, there was more than just a few live documents, but hundreds of thousands because we had already migrated content from 2007 to 2010. There was no considering deleting the content this time. I had to have a different solution. I spent some time with my largest coffee cup and my dog. We needed a fix and we needed it NOW. And then something came to me. Instead of trying to make the children accept changes maybe what I needed to do was change the parent to match the errant child.
If I changed the parents so that they were the same as the child, then all the content types would again be in sync. Then maybe if I changed it back at the syndication hub to the original parameters, they would all change back to the desired configuration together. It was worth a shot. After all, what could go wrong? The ones still connected would change, and then just change back. The ones not connected, if they didn't reconnect wouldn't be any MORE disconnnected. But, to cut to the chase, IT DID WORK. :)
It does take a few steps and quite a bit of patience, but let's face it, being patient is what is needed when you choose to work with Windoze in the first place. So, get your self a cup of java and settle in.
First, determine the list of sites on which the content type (ct) is broken. You will refer back to this later. Also, make a list of the values of the columns on the broken site(s). Hopefully, your sites are all broken in the same way. If not, you will be doing this in waves. Luckily for me, all my sites had the same set of fields broken in the same way (i.e. three fields were set to "optional" that were supposed to be "required") so this is what I will illustrate fixing.
Now that you have the list of broken sites and the list of the columns and the states that they are in, you are ready to fire up the Content Syndication Hub (CSH). Go to the CSH Site Settings->Content Types and select the ct in question. Write down the way the columns *should be* for the ct when it is in the fixed state. Save this configuration. You will need it later. Now change the values of the ct to match the *broken* content types as they are on the broken sites. Now "manage" the publishing for this content type and republish it.
Good, get another cup of java, and we will now go back to the broken sites. On each broken site, go to site settings->content type publishing and check the "Refresh all content types" box and click OK. This may take time depending on how many sites you need to visit. Once you are done, get another cup of java.
Now, it is time to fire up Central Administration. I hope you have administrative rights. Go to Monitoring->Timer Jobs->Review Job Definitions and then select Content Type Subscriber for the correct web application on which your sites are housed. If your site collections are on more than one web app, then you will need to run it on more than one subscriber job.
Make sure that you allow the job sufficient time to finish before moving on to the next step each time. I have found that the Content Type Subscriber job can take a long time, and sometimes it appears to stall for a very long time. So, you may need multiple cups of java to get through this. This is not the time to give up coffee! This is not the time to have a weak bladder. But, if you are patient, this can fix the issue where somehow the local ct has had the status (required, optional, hidden) changed.
I have not tried it in the case where the default value of a column has been changed locally in the list instead of by using the Column Default setting in the library settings, which is the only SAFE place to make that change. The only reason I have not testing this is because I don't have a case where I have a library broken in that way right now. Should that come up, I will certianly test it and report it back here.
Until now, the only resolution I had found for this was to delete any content in the corrupted library, then delete the corrupted content type. Then I could delete the corrupted site columns from the local site columns. Once all that was done, I could repush out the content type from the syndication hub. As you can imagine, this is not a great solution if there is live content on that site. So, I contacted MicroSoft. Their solution was to read a blog that discussed this very problem. Unfortunately, the solution was this very solution, and had been proposed by me. I was not very happy that the best they could do was give me my own solution. But, I followed my own advice, and sadly moved forward.
Then, I had another library get corrupted; actually, several. I don't know how they got corrupted, but this time, there was more than just a few live documents, but hundreds of thousands because we had already migrated content from 2007 to 2010. There was no considering deleting the content this time. I had to have a different solution. I spent some time with my largest coffee cup and my dog. We needed a fix and we needed it NOW. And then something came to me. Instead of trying to make the children accept changes maybe what I needed to do was change the parent to match the errant child.
If I changed the parents so that they were the same as the child, then all the content types would again be in sync. Then maybe if I changed it back at the syndication hub to the original parameters, they would all change back to the desired configuration together. It was worth a shot. After all, what could go wrong? The ones still connected would change, and then just change back. The ones not connected, if they didn't reconnect wouldn't be any MORE disconnnected. But, to cut to the chase, IT DID WORK. :)
It does take a few steps and quite a bit of patience, but let's face it, being patient is what is needed when you choose to work with Windoze in the first place. So, get your self a cup of java and settle in.
First, determine the list of sites on which the content type (ct) is broken. You will refer back to this later. Also, make a list of the values of the columns on the broken site(s). Hopefully, your sites are all broken in the same way. If not, you will be doing this in waves. Luckily for me, all my sites had the same set of fields broken in the same way (i.e. three fields were set to "optional" that were supposed to be "required") so this is what I will illustrate fixing.
Now that you have the list of broken sites and the list of the columns and the states that they are in, you are ready to fire up the Content Syndication Hub (CSH). Go to the CSH Site Settings->Content Types and select the ct in question. Write down the way the columns *should be* for the ct when it is in the fixed state. Save this configuration. You will need it later. Now change the values of the ct to match the *broken* content types as they are on the broken sites. Now "manage" the publishing for this content type and republish it.
Good, get another cup of java, and we will now go back to the broken sites. On each broken site, go to site settings->content type publishing and check the "Refresh all content types" box and click OK. This may take time depending on how many sites you need to visit. Once you are done, get another cup of java.
Now, it is time to fire up Central Administration. I hope you have administrative rights. Go to Monitoring->Timer Jobs->Review Job Definitions and then select Content Type Subscriber for the correct web application on which your sites are housed. If your site collections are on more than one web app, then you will need to run it on more than one subscriber job.
Make sure that you allow the job sufficient time to finish before moving on to the next step each time. I have found that the Content Type Subscriber job can take a long time, and sometimes it appears to stall for a very long time. So, you may need multiple cups of java to get through this. This is not the time to give up coffee! This is not the time to have a weak bladder. But, if you are patient, this can fix the issue where somehow the local ct has had the status (required, optional, hidden) changed.
I have not tried it in the case where the default value of a column has been changed locally in the list instead of by using the Column Default setting in the library settings, which is the only SAFE place to make that change. The only reason I have not testing this is because I don't have a case where I have a library broken in that way right now. Should that come up, I will certianly test it and report it back here.
No comments:
Post a Comment