SharePoint 2010 : Records Center : Site Hierarchy / Metadata Navigation missing

A real quickie for reference.

I was configuring the records center in SharePoint 2010 today and it took me a while to work out that in order to view the Site Hierarchy navigation panel which is so widely advertised on the left hand side of the page you need to activate the "Tree view".

Probably should have been obvious but hey, it wasn't at the time.

Site settings -> Tree view -> Enable Tree View

SharePoint 2013 : Installation at first glance

I just watched a video showing a 2013 install so thought I would share for those who havent had time to do one like me. The install went from clean server to providing a site collection.

Points as follows:

• Install procedure is essentially the same as 2010. Install pre-requisites -> Install SharePoint -> Run configuration wizard to create a new farm specifying  database access criteria ->  Specify port for central administration etc.
• A wizard fires as in 2010 which offers the automatic create of services (service apps).
• Central administration looks slightly different at first glance but a second look shows that things havent changed that much at all.
• The provisioning of a team site collection was the same. Create a web application -> Create a site collection by choosing a template. One thing that was different was that it looked like  you were able to choose a version of the template so 2013 or 2010 (not sure if 2007 was there) which was quite interesting.

All in all though the installation procedure seems to be the same.

Video is at : http://youtu.be/FC_mF23TlSg

Utilising the Content Type Hub within a document management solution

This post is intended to present one possible Document Management solution which utilises the Content Type Hub. The solution is based on a real world project for a client. The post is to outline the approach from a technical perspective and not to discuss requirements from a business perspective.

Background client information

• Intranet is based on SharePoint 2010.
• Intranet is stored in one site collection.
• Content Types are not currently utilsed for document management.

 Client requirements overview

1. Areas to create and manage documents are required throughout the organization.
2. Content needs to be searchable from with the intranet.
3. SharePoint is to provide a document management solution which over time replaced the current storage solution (a shared drive).
4. Content is expected to grow significantly over time so the solution should scale from a content storage size perspective.

Solution

The requirements above are high level but provide enough to outline the solution. This solution here outlines how each requirement was met.

Site templates

Business analysis determined that there were two main types of site which would cover the core document management needs of the business. Site templates were created for "Project" and "Programme" sites. Each of these site templates contained document libraries (and other asset library's) where documents could be stored.

Content types

Business analysis identified document content types and their respective metadata requirements. These content types were associated with the document libraries contained in sites created by the site templates.

Multiple site collections and databases (still one SharePoint web application)

The intranet existed in a single site collection which had a database associated with it. The Document Management and scalable solution requirements indicated that one database was unlikely to be sufficient going forward based on the maximum recommended database size.
The design decision was taken to create at least two new databases. One would store "Project" sites and the other would store "Programme" sites.

The decision was also made that "Projects" and "Programmes" would be stored in their own site collections. A "Project" site would thus be created from a template in the "Projects" site collection. Each site collection would have its own database which would take some of the pressure off the upper operational limit (splitting the documents across two databases instead of one). Whilst this was not the ideal scalable solution (because you could still bottle neck if the "projects" / "programmes" site collections grew too large) it was deemed suitable by the business.

As an aside, from a scalability perspective it would have been preferable to have each "Project" and "Programme" as its own site collection. This would have the added benefit of allowing administrators to add new databases as required to the web application. E.g. If there were six "Project" site collections in one database and the database was approaching an operational limit, a new database could be attached and new site collections could be created in this database. In addition, due to the site collection boundary it would be easy to move an existing site collection to a new database if once specific site collection was becoming too large.

The content type hub

One limitation of multiple site collection is that each site collection has a "Site Content Type Gallery". This means that adding a new or updating an existing content type is expensive. A manual task of configuration in each site collection or the creation of a script would be required to make any modifications. This is where the "Content Type Hub" comes in to play. This is a feature which is available at the site collection level which allows the site collection to "Publish" its content types to other site collections who are "Subscribed" to it. Ergo this provides a central location for storing content types to be utilised across multiple site collections. Any changes in the content type hub site are replicated in the other site collections (after a couple of timer jobs have run).

This effectively completes the solution and demonstrates one architecture using the Content Type Hub in SharePoint 2010.

Here is a handy diagram to confuse you all further.

SharePoint 2010 Service Packs and Cumulative Updates

A mental note to myself.

The latest SPs and CUs for SharePoint can be found on the Update Center for Microsoft Office, Office Servers, and Related Products page.

Hopefully this page is constantly updated by the boys and Microsoft to keep us all up to date.

SharePoint 2010 : Item has already been added. Key in dictionary: 'domain\account' Key being added: 'domain\account'

Scenario

The client was migrating from one domain to another. As such the servers in the their SharePoint farm would no longer sit on domainA, they would site on domain. There were many steps to this which I hope to outline in another blog post. A problem occurred when looking at service account migration.
The farm service account had been updated to “domainB\farm” using stsadm as had other service accounts.

Problem

The problem arose when we navigated to http://CentralAdmin/_admin/ManagedAccounts.aspx and http://intranetstg:1111/_admin/FarmCredentialManagement.aspx. In certain scenarios the following error would be displayed:

Item has already been added. Key in dictionary: 'domain\account' Key being added: 'domain\account'

There seemed to be multiple entries for the same account. This was confirmed by running PowerShell “Get-spmanagedaccount” to list them all. I attempted to delete the accounts using “Remove-spmanagedaccount” but the same error occurred

Solution explanation

I found a number of articles explaining ways to fix it but none of the worked for me.  The idea of re-installing the farm seemed over the top. I decided to configure the farm to only use one account throughout as a temporary measure. A new account was created and all components where a previous account had been set were configured to use the temporary account. This was set via http://centraladmin/_admin/FarmCredentialManagement.aspx. (The account for each component was noted so they could be reapplied once the troublesome accoutns were removed). Occasionally the error would occur again after applying but an IIS reset seemingly resolved this.  Once all the components (including farm account) were using the temporary account I could then view all the managed accounts again with PowerShell “Get-spmanagedaccount”. It was then just a matter of deleting all the managed accounts other than the temporary one with “Remove-spmanagedaccount”. It is worth noting here that after each delete an IISreset is required. SharePoint seems to get confused as to what accounts are still present and to which domain they belong to without this. Once only one account was left, new accounts were reregistered and applied to the relevant components via http://centraladmin/_admin/FarmCredentialManagement.aspx. Great.

Solution steps

1. Create new temporary domain account (domain\temp)
2. Set this account to be farm account with stsadm -o updatefarmcredentials -userlogin domain\temp -password temp.
3. Set all other components to use this account in http://centraladmin/_admin/FarmCredentialManagement.aspx (iis resets if error reoccurs)
4. List and remove accounts other that temp account with powershell ” Get-spmanagedaccount” and Remove-spmanagedaccount” (iis resets if error reoccurs – also watch for domain name changes after reset).
5. Recreate managed accounts and assign to relevant components again.
6. Tidy up permissions in SQL (temporary account is probably still hanging around which can be removed).
7. Relax with Coffee if before 4pm otherwise potentially have a beer.