What was calculated to be done in an hour took me 8 !
Summary: Re-publishing the updated HUB-content type didn't update the subscriber versions of this content type.
4 Web applications with each one Site Collection:
- 1) Content Hub Web app: Hub.[customer-domain]
- 2) Main intranet portal: Portal.[customer-domain]
- 3) Main ECM location: ECM.[customer-domain]
- 4) Sub company collaboration site: subcompany.[customer-domain]
The term-store is already implemented (MMS application service running); the ECM location already has 1 site Content Type configured (ECMct) with some Managed Metadata lookup fields (one of them is 'security') to this term-store.
- a) Configured a HUB web application (1) and enabled the 'Content Type Syndication' site-collection feature.
- b) Configured the MMS service application:
- Enabled the connection to the HUB web app (1)
- Under permissions, added the APP-Pool accounts
- c) Configured a site Content Type (HUBct) in the (1) Site Collection
- Published the Content Type
- d) Ran the "Content Type" & "Content Type Subscriber" timer jobs from central admin
- To prevent the default 15 minute & 1 hour wait time
- The in the hub created Content Type (HUBct) was published to all Site Collections, yeah ! Looked great; unfortunately I forgot one field in the HUBct :(
No problem, let's just add the field "security" to HUBct and re-publish the Content Type. After I did this the problem started.
- The updated HUBct (with the 'security' field wasn't pushed trough to the subscriber site collections. I tried:
- Re-publish again (running the Timer Jobs afterwards each time); no results
- Un-Publish the HUBct and then delete it in Site Collection (3)
After a while I checked the other site collections and there the updated HUBct was pushed trough; It was just Site Collection (3) that didn't get the update.
Using the 'Published Content Type' link in the Site Settings - Site Collection Settings menu I opened the 'Content Type Syndication log' where there was an error:
The HUBct content type with it's updated field 'security' was giving an error because of the already existing (local) site column 'security'.
So I deleted the security column from the HUBct and re-created 'Isecurity'; Re-published but whatever I tried, no update in Site Collection (3);
No updates in the subscribing site collections.
Eventually I added another Managed Metadata Service (MMS2);
Via Central Admin, Manage Web Application ->'Service Connections' I connected the new MMS2 service to both Web Applications (1) & (3), making it the default MMS for the Content HUB web application (1).
Now I re-published the HUBct and it is available in site collection (3) !
I still need to have 2 MMS services connected to this site collection because it's already using the term-store from the original MMS.
To prevent confusion I added a Term-Group to the new created MMS2 and called it 'DO NOT USE AS TERM-STORE; FOR CONTENT TYPE HUB USE ONLY'.
Other things to think about:
In a desperate attempt to get the subscribing site collection to receive the published content type I deleted the previously published HUBct on the subscribing site collection. This was not possible at first because there were still items in my document library which were using this content type. After deleting them from both the site recycle-bin AND the site-collection recycle-bin it was possible to delete the local copy of this content type.
You still need to change the 'read-only' status of the published content type to 'no' in the Site-Content type's 'advanced settings' menu before you can delete it.
Now, more than a year later, I run in a problem with these 2 MMS services.. Some site collections decided to get their content types from the wrong MMS.. don't ask me how this is possible, it's very annoying though.. Especially when I just updated a content type and now 1 site-collection doesn't receive the update because it's connected to the wrong MMS... see sample picture below:
Yes, I did execute the evil query to get rid of the HUBuri in the wrong MMS.. yes it seems to have fixed the problem a little bit:
Schema that shows the configuration in detail (and problem):
It seems that the old site collections (all under the same web-app) are still "connected" to the old publishing location and failing to connect to the new one. Resulting in the error:
Content type 'IDocument' has been published from service application 'Managed Metadata Service' and 'HUBService'. 'Managed Metadata Service' was used.
Where would this connection be defined... on (local) content-type level ? Site Collection Level ?
It's not from top-down since all the MMS service applications ARE correctly configured and new site collections work perfectly..
Update: 24-10-2013, resolved !
Thanks to some ideas from @AlistairPugin I first tried to remove & re-add the HUBservice to the ProxyGroup. This didn't work, even after a full farm-reboot (same error).
Then I tried removing the 'Managed Metadata Service' from the ProxyGroup (Custom), re-published the content type, hoping it wouldn't choose this wrong service application since it didn't have a association in the ProxyGroup anymore.. That worked ! Of course, all the Managed Metadata fields in the newly published content type were not working (nicely grayed out) because it still needs the Managed Metadata Service Service Application to resolve the term-store items ! Just adding the Managed Metadata Service Service application back to the ProxyGroup and that issue was also fixed :)
Even better, it seems it's now fixed 'forever' as new publication tests not seem to cause any errors ! Somehow the adding and removing helped fixing the correct relation from Site Collection to the [default] ProxyGroup-Service Application.
Now... even though the new version of the content type is published to the site collection, the document libraries are still using the old one... Like @AlistairPugin says.."Never a dull moment mate !!"