Cannot use SharePoint feature to deploy content types using content type hub functionality when using XML elements

*** Update 11/05/11 ***
Over the last few weeks I have been contacted regarding this post and had contradicting reports that you are in fact able to create a feature to deploy content types to a content hub without the need for the feature to be enabled on each subscribing site collection.
My original issue experienced was also replicated by others once I’d posted this issue so this seems a strange one as since both of us are unable to recreate the issue.
Upon retesting the issue I can confirm that you are able to deploy a feature to a content type hub without the need to enable the feature on subscribing site collections.
Thanks to Chakkaradeep Chandran for following up on this and feeding back his findings.
*** Original Post ***
I’ve recently stumbled across a restriction of using the content type hub in SharePoint 2010 and I am a little surprised by its behaviour. From a quick search around there was very little discussing this so thought I’d post a blog on my findings.
So the plan was to leverage the new content type publishing feature in SharePoint 2010 alongside programmatically deploying site columns and content types using a feature to simplify deployments. Admins and developers of MOSS 2007 will recall that to deploy content types to multiple site collections easily required a feature creating with the necessary customisations. A downside to this was that every time you needed to update the content type you had to redeploy the feature with the updates.
An assumption on my part with the new SharePoint 2010 hub was that when you create a feature to deploy content types all you needed to do was to enable that feature on the content type hub and publish this out to subscribing site collections. Unfortunately it doesn't seem to work this way as subscribing site collections do not receive the published content types and looking at the error log on the receiving site collection states that it it requires the custom content type feature to be enabled which defeats the object as we will be back to the MOSS 2007 scenario mentioned above.
So some thoughts around options available to use to deploy content types to the content hub for successful publishing:

• Raise it with Microsoft
• Create a PowerShell script that can receive a maintainable XML input file to update the content types on the hub.
• Not sure if this is possible but if the feature could be enabled on the subscribing site collection and have a dependency on the ‘Content Type Hub’ feature before deploying the content types.

Thanks to Chris O’Brien for confirming this for me on Twitter. As always I welcome your comments / feedback / findings on this.
*** Update 30/11/2010 ***
After posting my blog entry a great SharePoint community member Nick Hadlee posted a comment with his initial thoughts / frustrations and kindly shared further finding’s based on a quick test he carried out.
So to explain further the way the feature I described above was deployed was using an XML file which requires no code.
Nick pointed out that if you created a code based deployment of the content types using a feature receiver this works. This is effectively the same as using the UI to enter content types / columns.
So to conclude there is a workaround to deploy content types using a feature however this requires coding rather than the XML format.
I did have a thought around enabling the feature on all site collections and then seeing if any updates from the Hub were published however I’m sure this will get messy in the long run as updates and changes are applied.
Credit to Nick Hadlee for his input and also my client who I’m currently working with who has helped in investigating this.
*** Update 10/01/2011 ***
Nick Hadlee has thankfully posted his workaround which can be found here. Again thanks Nick for following this up and hope its useful.

Video and Audio option not available on Ribbon for SharePoint 2010 site

If you’ve created a team site and want to add video’s to your site with Wiki page feature active as the homepage (add text directly to the page you are editing without the need for a web part). You will notice the Video option is not available on the Ribbon.

To enable adding video and audio on the page simply enable the publishing feature at site and site collection level and when you re-edit the page you will notice that the Video and Audio option is available. 

Hope that saves you some time.

[Updated] Side effects of attaching additional SharePoint 2010 servers to the farm using PowerShell

Over the last few weeks I have been implementing various SharePoint environments for clients such as PoC’s, Dev, Pilots to name a few. All these environments have been single server farm deployments which I have found the community autospinstaller PowerShell script useful in configuring the majority of the install.

Now the challenge comes when you want to add additional servers to the farm. Initially the version of the installer script used had an issue where the logic for joining the farm worked but for some reason did not enable relevant features / services (osearch), I later discovered this when trying to add the query role to the new addition to the farm only to find that I could not select the server from the drop down in the UI.

After resolving this issue the new server did appear in the drop down but this is where I hit another issue and this is where I am currently at but read on for my findings and workaround.

So at the stage when I’m trying to assign the query role to the additional server in the farm using PowerShell the script just hangs, likewise if I try to assign the role via Central Admin I experience the same behaviour.

After many a roll back of VM snapshots I found the unlikely issue to be related to joining the farm using PowerShell. All PowerShell commands have been executed as per the TechNet article: http://technet.microsoft.com/en-us/library/cc262839.aspx#section6 and THE SERVER WILL JOIN THE FARM SUCCESSFULLY! Yes that's correct the server will join the farm with no errors. This is why it took so long to diagnose the farm attach as the problem as it didn't fail!

So how did I find this out? I simply added the server using PSConfig (The grey wizard as its known) and assigned the query role via Central Admin and all worked fine.

I have raised this issue with Microsoft and after a week and a half they have managed to experience the same issue. I’m currently working on the issue with them however in the meantime I would suggest adding the additional servers to the farm using PSConfig and then running PowerShell scripts again.

Users of the script may have not come across this issue yet as SharePoint 2010 RTM is only just over six months old and most environments being deployed are in preparation for a production 2010 build and those who have SharePoint 2010 in production may have built the server via the UI. Development environments may also have relaxed security even if a multi-server farm has been installed where the install account may have been a domain admin which may bypass these issues (be happy to hear your experiences on this).

As well as failing to assign search roles to additional servers, another issue I have discovered is deploying solutions. Deploying solutions to the new servers hangs and fails to deploy successfully.

Background to my environment:

• Windows 2008 R2, SQL 2008 R2.
• A specific install account was used to create the farm (not the Farm account)
• The install account is NOT a domain admin
• The install account is only admin on the local SharePoint servers
• The farm account is not local admin or domain admin on SharePoint / SQL / AD servers
• AD is on a separate server
• SQL service account is running under a separate account to any of the SharePoint services
• The search account is a dedicated search account (and so is the service application pool account (separate to the service account))

I will update my blog with progress. Credit also goes to my colleague James Brennan for assisting with this issue.

*** Update 17/12/2010 ***

After weeks of emailing back and forth with Microsoft Support I have now had confirmation that a hotfix will be created to address the issue, no timescales for the fix have been provided at this stage.

*** Update 23/03/2011 - Workaround ***

Contrary to the update on 17/12/2010 I have now received confirmation of a workaround to the issue.

The resolution is really simple. Basically after following the steps to add an additional server to the farm from the TechNet website http://technet.microsoft.com/en-us/library/cc262839.aspx#section6 there is a step missing where the SharePoint 2010 Timer (Job) (and Possibly the Admin Job) windows services require starting manually.

Once you start the service and wait a short time you should then successfully be able to assign server roles to the new addition to the SharePoint farm.

Next steps are that I have requested that this additional step to start the SharePoint 2010 Timer service is added to the TechNet article (http://technet.microsoft.com/en-us/library/cc262839.aspx#section6).

More information

Another symptom experienced when attaching new SharePoint servers to the farm is that when you try and assign the query role via the user interface you receive the following error:

‘The path must point to a fixed, NTFS drive whose root directory exists’

I also stumbled across a blog by Abdul where he has a different solution to resolving this using Repair-SPManagedAccountDeployment.which I’m guessing also starts the Timer service along the way.

Adding search scopes to site collections in SharePoint 2010

In MOSS 2007 you were able to hover over the search drop down and take you to the option to add new SSP defined scopes to your site collection. In SharePoint 2010 they’ve removed the hyperlink from the group.

SharePoint 2010 search scopes are configured in pretty much the same way as in MOSS 2007, the only difference being the SSP has now become a Service Application although the Admin UI is the same.

Once you’ve created your scope in the Service Application as you did in MOSS 2007 navigate to the search scopes settings in the site collection and instead of clicking on the name of the group click on ‘Display Groups’ (circled in blue above) and this will then give you the link to the group to administer the scopes you want to add.

Not sure why this has changed as it simply adds more clicks to achieve the same result, perhaps this is an issue with the style that has not been picked up yet?

Published Content Types not replicated to subscribing SharePoint 2010 blank site template site collection

I discovered an issue which was documented in a blog by Wictor Wilen regarding using a blank site template and fell into this trap myself as there seems no point turning on lights on a site collection that will only be used as a content type hub (Turning on lights would allow anyone to think it was somewhere to put content right?).

As I’d already created the site collection with a blank site I wanted to understand what exact feature was missing.

So the problem is that if you create a subscribing site collection blank root site then published content types aren't replicated to the newly created blank site collection. I’d made sure all the timer jobs related to the content hub we’re run but no luck.

I stumbled across a post which didn't specifically relate to the issue to but I had a feeling I was in the right place.

The feature is called TaxonomyFieldAdded and by querying a blank site you will notice this is not enabled whereas on a Team Site it is.

So I enabled the feature by running the following command from PowerShell:

Enable-SPFeature -Url "<enter url here>" -Identity "73EF14B1-13A9-416b-A9B5-ECECA2B0604C"

Almost instantly the published content types appeared in the blank site collection.

Why after I enable the Document ID Service Feature do I not see Document ID's on my documents?

I got caught out when enabling the Document ID service for SharePoint 2010 trying to understand why instantly after enabling the feature my documents did not have unique ID's so I thought I'd write a quick blog on how to do this.

Navigate to the site collection that you require the Document ID Service to run on and activate the Site Collection Feature as shown below.

Again from Site Collection Administration navigate to Document ID settings as highlighted in red below:

From this section you can provide a predefined document ID naming prefix to suit.

If you have existing documents in the documents in the site collection there is also the option to reset all the document ID's with the new naming prefix.

So at this stage you would assume that the document ID's are there when you visit a document center after enabling the

settings above? Wrong! Although this feature has been activated the process of assigning the ID's to documents has not yet been run and this is carried out via a SharePoint Timer Job.

Navigate from Central Admin to monitoring then click Review Job Definitions.

From the list here make sure the correct web application is selected in the top right.

Then run the Document ID enable/disable job. This basically propagates changes to content types across all sites after the Document ID feature has been reconfigured.

Once this Timer Job has run (depending on how many content types you have created should not take long) you then need to run the Document ID assignment job which will assign document ID's to all items in that specific Site Collections.