Sunday, July 08, 2012

Coming soon :

Blogs that are in the making:
- Importing 42.000 files / 300 GB of data into SharePoint; automatically mapping the data to the Managed Metadata.

- Using Report Server & SharePoint to automate the invoice process.

SharePoint 2010: Creating personal content streams

One of my customers asked me for a way to let there employees "subscribe" to content sources so that they would only see news and events that are interesting for them personally.

I explained the customer "audiences" that can be used for these purpose but unfortunately their Active Directory isn't that well populated.

The "content sources" consist of interest areas that needed to be centrally managed (Term Store); this way we can ensure that both the "subscribers" and the "publishers" are using the same content source.

First off I started creating the term-set to hold the "content sources" in the Term Store.
Company Taxonomy
Interest Areas

Next, I configured the user profile service configuration in SharePoint 2010;
- Central Administration : Manage Service Applications
- Either manage (highlight the row and click 'manage' on the top) or create a new User Profile Service Application and then manage it:

- Under people, there is a link "Manage User Properties", this is the location where we can add the new "ContentSource" property. Employees will be able to manage the selection of this "Content Source" them selves.
- On the top of the page there is a link to create a "New Property"
- We can give the property a name etc.
- The property type (depending on your solution) will either be a single (single value) or string (multi value)
- When selecting multi value, please be sure to use the Semicolon separator, this will ensure the filter webpart to be able to work with the multiple values.
- Next up, we'll be able to select the Term Set from the Term Store we created in step 1.

Creating the content holder.
The content holder can be a library or a list where we will add a column (either on the list or document library or content type) that references the same "Interest Areas" term-set we created in step 1.
This will allow the "publishers of content" to select the interest area for the content.

Filtering the content based on the current logged in users' profile selection.
To accomplish this we create 2 web-parts on a page.
The first web-part will be linked to the content holder created in Step3; obviously we can link using a specific view that filters maybe on publication date etc.; Creating multiple content filters.

Next, we'll add the "Current User Filter" Web-Part To the page.
This filter will apply an extra filter to this list, filtering the content based on the current user selected interest areas.
• Note: The configuration of the 'Current User Filter' Web-Part will only be shown when you edit the "List View" Web-Part; this is a bit confusing.

Configuring the "Current User Filter" Web-Part is easy:
After adding the Web-Part to the page hover over the little drop down arrow on the top right and follow the drop-down path down to filter it's data to the list-view Web-Part:

After a few seconds the configuration pops up:

• Note: this will only happen in Internet Explorer; I tried Chrome to do this, doesn't work out of the box.

In this configuration menu you can select the property from the user profile properties that we linked to the Term Store "Interest Areas" term-set.
Clicking finish will instantly filter down our "List View" Web Part.

To configure additional options:

Choose "Edit Web Part"
You can re-configure the field to be provided to the List View Web-Part:

That's it; the page now automatically filters down items from the list that the current user has "Subscribed to".
The current user obviously can change these values by going to his "My Site" and click on "Edit Profile":

There the user will be provided with a normal "Select From Term-Set" input box:

Great solution, giving the users control on what they see on SharePoint !

Saturday, July 07, 2012

SharePoint 2010 Content Type Publishing (HUB) problems

While implementing the content type hub (a Managed Metadata Services (MMS) production) at a client to day, I ran into trouble.
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.

The environment:
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.

The preparation:
- 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 result:
- 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 problem:
- 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.

Update: 16-10-2013
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:
24-10-2013 ^^ I managed to get this done ! Thanks to a sneaky way of deleting the HUBuri from the wrong Service Application (no, Set-SPWebServiceApplication -HubUri = "" doesn't work as explained here:

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:
Although this is a HUGE step in the right collection, it still uses the wrong Managed Metadata Service (MMS and not HUBService, even though it now says that MMS has no hub defined...) #SIGH !

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 !!"