Skip Ribbon Commands
Skip to main content

Quick Launch
Home > Blog
The ramblings of a generic SharePoint Consultant Developer
March 13
Content Type Syndication Hub – Technical Overview
by  System Account  on 13/03/2012 14:14

In its most basic sense the Content Type Syndication Hub (CTSH) provides a mechanism for centralising control of content types across multiple site collections and web applications.

It does this by "Promoting" one designated site collection to become the Content Type Syndication Hub (CTSH). Any subsequent content types added to this "Promoted" site collection will be published out to all other "Consuming" site collections.

The CTSH is part of the Managed Metadata Service application and as such any site collection or web application that uses this service application will also consume content types from the CTSH.

You can only have one CTSH per Managed Meta Data Service Application and once set it cannot be changed. If you want to move the CTSH after inception then you must create/use a brand new Metadata Service Application.

However a web application may consume content types from more than one CTSH by subscribing to multiple metadata services. In the case of any conflicts the Default Managed Metadata Service Web app will win (that is to say the content type on the default will be the version pushed to the consuming site collection).

Content Type Syndication Hub – Known Limitations

Non supported column types – Custom Fields and external data columns are not supported in syndicated content types. They can be added to the original content type on the hub, but the column will not be pushed out.

Workflows – Workflows are NOT supported with syndicated content types, although once deployed workflows can be attached to them in normal fashion, but after every republish the association will be dropped and has to be re-established.

To configure the Content Type Syndication Hub

The initial Configuration of the CTSH is relatively straight forward and should be the first element checked when trouble shooting.

Step 1 - Provision the CTSH in the managed metadata service

  • In central admin, go to Managed Service Applications
  • Focus (not select) the managed metadata Service
  • Enter the URL that is going to be the CTSH
  • Focus (not select) the Managed Metadata service Proxy
  • Choose the desired options

Step 2 -Enable the Service on the site

  • Go to the proposed CTSH site
  • Enable the CTSH Feature at the site collection level

Step 3 - Run the timer Jobs

  • Run the Content Hub Timer job (More on this later)
  • Run the Content Subscriber Timer Job (More on this later)

Content Hub Job – Runs every 15 minutes by default – Gathers up all content types that have been set to publish for the first time or republish

Content Type Subscriber Job – Runs at 59 minutes past the hour by default – (One of these jobs exist per web app) This job runs and completed an update check per content type as well as pushing "Consuming" any new content type

Sealed and unsealed content types

When a content type is "Consumed" by a site collection that content type becomes "Sealed" – which in essence means read only. This prevents the end user altering the content type and making the Hub unstable.

If the Content Type is retraced (Unpublished) then the site collection will not receive any more updates for that content type but the content type will be set to the site scope and will become "Un sealed". End users will then be able to edit this content type as it is site specific.

This is to ensure that the removal of content types from a hub does not lose any associated data.

Removing a Content Type from a Site completely

As mentioned above the use of unsealed content types has its advantages, but if you are looking to remove the content type completely from the site then you will need to go through a more hands on process.

First of all you must remove all instances of the content types from any lists or document libraries in the site/site collection. Once this has been done this you can delete the content type from the site collection Gallery.

As you can imagine with multiple content types, libraries and sites this process can take some time. The Powershell code below can be ran against your site collection to help find all documents (and their libraries) where a specific content type is used – which should aid your search considerably.

 

#add-pssnapin Microsoft.sharepoint.powershell

 

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint") > $null

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint.Publishing") > $null

 

$url = "http://SITECOLLECTIONURLGOESHERE"

$site = new-object Microsoft.SharePoint.SPSite ($url)

$contenttype = $site.rootweb.contenttypes["Document"] # Change this to represent the desired CT

ForEach ($web in $site.AllWebs)

{

ForEach ($list in $web.Lists)

{

if ($list.BaseTemplate -eq "DocumentLibrary")

{

ForEach ($item in $list.Items)

{

If ($item.ContentType.Name -eq $contenttype.Name)

{

"DocURL:"+" /" + $item.Url + " CT: " + $item.ContentType.Name

}

}

}

}

}

 

Common Errors

Newly published Content Types not appearing in site collections

This is by far the most common of all errors with the CTSH and it can be caused by a number of reasons. Trouble shooting steps for this error should be to review all configuration settings and then test syndication to the effected site using the subscriber job for that web application only.

In the first instance check that the issue is reproducing in PPE and if possible rectify there first and confirm any repro steps

After this check the Content Type Syndication hub error log:

Next check the log Content type publishing log for specific publishing errors

These steps should outline the exact nature of the fault and allow you to troubleshoot further.

If the logs are showing clear then use the following steps to confirm syndication is operating correctly:

  • Check CTSH settings in Central Admin (as outlined in the screenshots in Section 1 above)
  • Ensure you can surface the CTSH site collection
  • Make sure that content types in the CTSH are set to publish
  • Check currently running Jobs in Central Admin - this will show if any long running subscriber jobs are present

If you are still having issues then the creation of a test content type may be necessary but make sure you gain customer approval before deploying it.

  • Create a CTSH Content Type
  • Set the Content Type to Publish
  • Run the Content Subscriber job for that web application – alternatively wait till 59 minutes past the hour when the job will run as scheduled.

If the test content type syndicates correctly you have confirmed that the CTSH is operating as expected and the fault lies with the Content Type itself.

Columns missing from Syndicated Content Types

The CTSH does not support Custom Fields and external data columns but it WILL publish the rest of the content type. This can lead to the customer reporting columns are missing. In this instance there is nothing that can be done until the offending columns are removed from the content type at the CTSH level.

Content not syndicating to blank site

You may get a customer call about content types not be syndicated and on checking you cannot find the Content Publishing Hyperlink. This is more than likely because the site has been created using the blank site template.

By default the blank site does not have the taxonomy feature enabled and this cannot be enabled through the interface. To enable the feature use either of the following methods:

 

Via powershell

Enable-SPFeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C -URL <SiteCollectionURL>

 

Via STSADM

activatefeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C -url http://<server> -force

 

 

 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
February 09
Web Analytics Overview – How Web Analytics Work
by  System Account  on 09/02/2012 21:53

Web analytics has always been one of those grey areas that has a lot of articles written about it that cover elements of the service in some form or fashion but I have failed to find a definitive guide that illustrates the exact web analytics process step by step. This type of guide is invaluable when trying to troubleshoot any web analytics issues. Essentially, if you know "How" it works you can find out "Why" it is broken…

So I've decided to throw together a brief PowerPoint that details (via animation) how the web analytics service works in a step by step manner.

This should give other sharepointers the knowledge to troubleshoot web analytics issues with relative ease – or at least understand which phase of the analytics process their issue is occurring.

Just click the link below and go through the presentation which shouldn't take more than three minutes.

Hope you like it J

Web Analytics Overview Presentation:

http://www.sp2010blog.com/Blog/_layouts/PowerPointFrame.aspx?PowerPointView=SlideShowView&d=F48a9b326c7274f7387a85c98e03da16dma8b53ea548454f9387b42155e55ef0a2mac3ee315468f4a3e9c98fbd13116b7fdm

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
January 22
UPA Persistent Stuck on Starting Issue
by  System Account  on 22/01/2012 16:32

The UPA Stuck on Starting journey – a trip into FIM hell!

There are many great articles that list various steps to clear "stuck on starting" in FIM – including the defacto bible of Stuck on Starting by Spence Harber:

http://www.harbar.net/articles/sp2010ups2.aspx

However in certain circumstances the usual steps of clearing this issue don't always work.

Recently I had an issue where an OOTB SharePoint 2010 farm (No service packs or CUs applied) had un-provisioned itself.

When trying to re-provision, the one off timer job that does this did not materialise and I was left in a state of "Stuck on Starting" but with no timer job, all services stopped and the application online. This became very frustrating and no matter what I tried I could not get rid of the "Starting" state.

To rectify this I used the following method in this order:

Customer was using OOTB sharepoint config – with a named SQL instance so by default the service would not re-provision until the June CU or a hot fix was applied (see here for error details)– in this case the customer was not ready to go to sp1 so the hotfixes had to be applied:

After this is noticed the "Starting" was still persistent in mange services on server and when trying to start the FIM services manually - I got a slew of errors - Eventids: 22, 3, 26, 2, 3 :

Running though the normal steps to clear this issue did not remediate it. Im going to list the steps here for brevity as in most cases they would of worked:

  • Stop User profile service and User profile sync service on ALL SharePoint servers in the farm
  • Clear timer config cache by following the "resolution" documented at http://support.microsoft.com/kb/939308
  • Deleted the Pending timer job related to the UPA sync service provisioning using Central administration->Monitoring->check job status
  • Confirmed that the security token service has only windows and anonymous enabled ( from IIS manager->SharePoint web services->Security token service->Authentication (under IIS))
  • On the SharePoint server access the registry editor and confirm that the information related to FIM ( database servername , sync DB name etc ) are properly populated, if found wrong , back up the registry key and edit the values to reflect the right information.
  • HKLM\system\currentcontrolset001\services\FIMservice
  • HKLM\system\currentcontrolset002\services\FIMservice
  • HKLM\system\currentcontrolset\services\FIMservice
  • Delete all FIM related certificates from certificate store ( for account and system) . Make sure that no FIM related certificate is listed in any folders when looked at certificate manager.
  • From Central administration->Application management->Manage service application, Make sure the User profile service application and its proxy are started, If found stopped, its always recommended to recreate them taking necessary backups (mysites)
  • Start User profile service on the machine where you would like to start the User profile sync service (use central administration console)
  • Once the service is started, try starting the User profile sync service from the central administration site

So as you can see there were quite a few steps without success.

If you use the Get/Stop SPService instance you will be able to see the state SP thinks the UPA service is in. In this case there were 3 three UPA services, 2 of them stopped, but one of the them was "Stuck" in provisioning!

In the SP2010 command shell use the following command to list them:

get-SPServiceInstance | where {$_.TypeName -like "*User*"}

If you see an instance that is "Provisioning" you will need to stop it as it is this that is causing the issue:

Stop-SPServiceInstance -identity <GUID>

They should all now be disabled:

Success! You should note now that the service should be registered as stopped in the interface:

For good measure at this point I turned Verbose logging on for UPA (don't forget to turn it off when you're done). I then started ULS viewer and filtered category on "User Profiles" which helps to track the actual provisioning process so you can view errors as they occur.

Start User Profile Service through the interface as normal

You should be able to watch the process provisioning in its entirety (usually takes around 15 minutes)

Success!

I then went and recreated and my synchronisation connections and performed a full sync

Hope you find this useful!

 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
December 21
Error deploying administration application pool credentials
by  System Account  on 21/12/2011 13:03

​When trying to change administrative credentials using the manage accounts interface in SharePoint 2010 I often come across this error:

 

Error deploying administration application pool credentials. Another deployment may be active. An object of the type Microsoft.SharePoint.Administration.SPAdminAppPoolCredentialDeploymentJobDefinition named "job-admin-apppool-change" already exists under the parent Microsoft.SharePoint.Administration.SPTimerService named "SPTimerV4".  Rename your object or delete the existing object.

 

When the managed accounts tab section is used to change the password it creates a timer job "job-admin-apppool-change" and if this is half way or has been corrupted (like its been half way through and system reboot occurred) then the job “Sticks” and this can manifest itself as the error above.

The best and quickest way of rectifying this I have found is to delete the job and try again.

Use the following PowerShell to delete the job:

 

$tj = Get-SPTimerJob -Identity "job-admin-apppool-change"

$TJ.Delete()

 

Now try reset your password again using the managed accounts link and you should be successful

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
September 12
User Display Name Set to Domain\Username – SharePoint 2010
by  System Account  on 12/09/2011 16:41

In truth this error can be caused by a number of factors and there is not just one answer. The best way to approach this error is by working through all the possible reasons this could be happening and eliminating each step. This way you will get to the root cause and (ultimately fix) any underlying issues you have with your UPA/ContentDB synchronisation process.

To trouble shoot this issue properly we need to understand what is actually going on and what may be causing the issue – so here goes:

The Theory bit…

When dealing with user profiles it's very easy to get mislead with all the terminology and the path of what actually happens during the site logon process. So this next bit is intended to help clarify the process and hopefully lead us closer to a permanent fix.

When a user authenticates against a site it uses the information in the content database for that Site Collection. This information is kept in the userInfo table and is synchronised with the central User Profile Store by two Sync Jobs:

  • User Profile to SharePoint Full Synchronisation (hourly by default)
  • User Profile to SharePoint Quick Synchronisation (every 5 minutes by default)

The key to these jobs are in the names – which is also why they are routinely misunderstood. Most people think these are the normal full and incremental Active Directory jobs for the user profile application and with the dubious titles it is easy to understand why!

In reality these jobs take information FROM the User Profile Store to the SHAREPOINT content databases throughout the day and they are responsible for refreshing the information in those content databases with the information stored in the User Profile Store.

The incremental job is designed to run every five minutes and only synchronises users that have been set to active since the last synchronisation, whereas the full synchronisation job synchronises all the users' details in the content DB. The idea behind these jobs is to ensure that when a user logs on for the first time that they have to wait for the least amount of time possible before there details are updated (if the incremental job doesn't get you within five minutes the hourly quick job will J )

So when a site collection is setup for the first time in its shiny new DB the userInfo table lists who has, and hasn't got access to the site but until that person hits the site for the first time, the isActive flag for the user is set to zero.

The isActive flag is used by these two jobs to define whether or not the information for a user should be synchronised. So when a user hits the site for the first time, it sets this flag to 1 and the next quick or incremental job will pick this up and synchronise the information accordingly.

This means that when a user logs on for the first time the isActive flag is set to 1, but the information about the user will not be present – hence the display name is not set in this content database – and therefore the user account display name will be set to their user account name which is Domain\UserName.

Once the Full or Incremental jobs pick up the change (i.e. it sees that the user now has a 1 value for isActive) they sync the user's data from the User Profile Store (including the ever important display name) and et viola! On refresh the users display name is changed from Domain\UserName to Display Name (as well as making all the other profile information available like phone number etc.)

So from reviewing this process above and confirming the symptoms we can start to rectify any errors.

Defining the Symptoms – (Potential causes for User Showing as Domain Username)

The way to do this is to ask two simple questions which can go a long way to tracing down the exact source of the error:

  1. If the user logs on to a different site collection (in a different ContentDB) does this still happen?

    This will help you define if the error is localised to the current site collection DB or is spanned across multiple Site Collection DBs. This will help us ascertain whether or not the full and incremental synchronisation jobs are working/running and if the issue is localised to one DB or is farm wide

  2. Is the user set as active in the current site?

    This will tell us if the current site collection is expecting to have the information for the user. If the user has never logged onto the site or has been set to inactive (i.e. they haven't logged on for 30 days – which by default sets isActive back to zero) then they want have their Display Name set until the next Full or incremental job is ran, and then further to this if the jobs have been ran but the user has not been synced we can start to look elsewhere.

The following scripts lists the details of the userInfo Table sorted with the isActive Flag and login and title listed first to help you quickly determine if the user is active or not.

USE [NAME_OF_YOUR_CONTENT_DB_GOES_HERE]

GO

SELECT TOP 10 [tp_SiteID]

,[tp_ID]

,[tp_IsActive]

,[tp_Login]

,[tp_Title]

,[tp_Email]

,[tp_DomainGroup]

,[tp_SystemID]

,[tp_Deleted]

,[tp_SiteAdmin]

,[tp_Notes]

,[tp_Token]

,[tp_ExternalToken]

,[tp_ExternalTokenLastUpdated]

,[tp_Locale]

,[tp_CalendarType]

,[tp_AdjustHijriDays]

,[tp_TimeZone]

,[tp_Time24]

,[tp_AltCalendarType]

,[tp_CalendarViewOptions]

,[tp_WorkDays]

,[tp_WorkDayStartHour]

,[tp_WorkDayEndHour]

,[tp_Mobile]

,[tp_Flags]

FROM [NAME_OF_YOUR_CONTENT_DB_GOES_HERE].[dbo].[UserInfo]

The result should look like this:

How to resolve the issue

The information you have gained from applying the above logic should be pointing you in the right direction by now so here is a list of fix's that can be applied to help rectify the issue

Confirm the users AD account is legitimate and not locked

First and foremost make sure the user is active in AD. It may seem a little obvious but checking it may save you a lot of time – needless to say a user being disabled in AD will not be able to log on to the site.

Confirm the user is an active user of the site

As mentioned above, look at the userInfo table for the site collection DB for the site in questions and see if the user's isActive flag is set. From here you can also see all the other profile information that is available and this will be a good indication of whether or not the account is being synchronised.

Remove and Re-add the user in the site collection

Sometime the user's details may become stale. If you check the contentdb and they are set to active and the jobs are running fine and this issue is related to just one user then deleting and re-adding the user in quick succession will refresh the user data as it does another full import from ad for that user. Once the Full or Incremental jobs pick up the users change status they will synchronise the information again. Don't forget to make a note of the user's security group membership beforehand and add them back in once the operation is complete.

Checking the last time ContentDBs were synchronised

You can check the last time the content DBs were synchronised by using the following STSADM commands. The –listolddatabases command lists all databases that have not been synchronised longer then the day value that you provide. So in this example it lists all DBs that have not been synchronised in the last day:

stsadm -o sync -listolddatabases 0

If you subsequently use the –deleteolddatabases command this will delete the records in the userInfo table in the ContentDBs older than the day value given which means that on the next Full or Incremental sync the table will be totally repopulated. In this case any records not synchronised within the last day will be deleted and repopulated – THE DATABASES WILL NOT BE DELETED! Only the corresponding records in the table:

stsadm -o sync -deleteolddatabases 0

The language used in this command can come across as quite destructive but in all fairness it's essentially triggering a re-sync.

Sync the individual user from AD

You may come across occasions where individual accounts have not been synchronised and removing them and re-adding them from the site collection may not be acceptable.

n.b. This could be for a number of reasons but is most likely to involve the membership of lots of permission groups- so re-adding them to each might be a more labour intensive task than you are willing to undertake

In this scenario you can use the Set-SPUser –syncfromad command which essentially synchronises the user's information table record with the contents of Active Directory. The script below does this for a specific user in one site collection:

add-pssnapin microsoft.sharepoint.powershell

Set-SPUser -identity http://Siteyouwantsync/my -SyncFromAD

This may be the less destructive option for your scenario but please be warned that when the next full or incremental profile sync with AD should trigger an overwrite of this information. This shouldn't be a problem as you've synchronised the user with AD using this command anyway J

Sync All Users from AD

Like the above scenario you may have to re-sync all users in one particular site collection rather than just one user. In this scenario removing each user from the site collection would not be practical and you may have good reasons for not running the Full or Incremental sync jobs. This script iterates through the site collection in question and synchronises each user in turn with AD.

add-pssnapin microsoft.sharepoint.powershell

Get-SPUser -Web http://SiteToSync/my

Get-SPUser -Web http://SiteToSync/my | ForEach-Object {Set-SPUser -identity $_.name -web http://SiteToSync/my -SyncFromAD}

Once again these commands will be overwritten by the profile store information when the next full AD synchronisation takes place.

If in doubt - check FIM!

If by this stage you are still struggling with this issue then you may be having trouble with UPA/FIM and you may need to investigate your full user profile synchronisation and setup. In this scenario I'd refer you to rather brilliant set of blogs by Spencer Harbar at:

http://harbar.net/

Paying particular attention to:

http://www.harbar.net/articles/sp2010ups.aspx

The main point from here will be to check the FIM interface and do a MetaVerse search for your problem user – this will help determine the state of the user and indeed the last time the user's attributes were synchronised with AD.

The FIM client can be found here:

Systemdrive:\Program Files\Microsoft Office Servers\14.0\Synchronization Service\UIShell\miisclient.exe

 

One Final Word of Caution…

In this post I've covered two highly contentious and volatile areas, namely:

  • Connecting to SharePoint contentDBs
  • Connecting to the FIM interface

Whilst connecting to these clients and viewing information will not harm your installation you must be aware that ANY changes to ANY SharePoint information contained within SharePoint databases is unsupported and any changes made in the FIM interface are also unsupported – so please, ensure you only use these methods to view information to aid troubleshooting and not as an actual troubleshoot tool! Sermon over… J

Hope someone finds this useful – feel free to send feedback via the comments form on the right hand side.

Permanent Link to Post | Email Post Link | Number of Comments 1 Comment(s)
May 07
.WebTemplateID issues –.WebTemplateID doesn’t report what you’d think
by  Heath GrovesNo presence information  on 07/05/2011 13:48

Whilst in the midst of creating the new move site PowerShell script (http://movesites.codeplex.com) I needed to find out the template id of a site that has been created.  For instance:

Site A was made last year and we need to move it – to do this we need to:
·         Export all the content from site A (to a folder somewhere as a .cmp file )
·         Find out the original site template used to create site A
·         Create a new site based on the original template
·         Import all the site content from the exported (.cmp) file
 

So as you can imagine all the above looked pretty routine for a site move – until I started to investigate the WebTemplateID property.

It would appear that this property returns the web template ID of the very FIRST template that was used to create the site, so if a site has been built on a template from previous and not from scratch then it will report the initial template id and not the current template id.

So why all the fuss?

Well, basically in the early days of SharePoint creation even Microsoft used this method to create their templates.  For instance they created a blank site (STS#1) which would have the initial template ID of 1 and then (rightly so to save effort) they made the team site (STS#0) based on the blank template, but yep you’ve guessed it – the underlying WebTemplateID remained as 1… This is also the case for document workspace (STS#2) which was also based on the blank template and thus has the same initial template ID of 1.

If we list all the templates from the site collections we can see the template ID issue.  To display all the templates use this code (lovingly pilfered from the excellent http://get-spscripts.com):

function Get-SPWebTemplateWithId

{

    $templates = Get-SPWebTemplate | Sort-Object "Name"

    $templates | ForEach-Object {

        $templateValues = @{

            "Title" = $_.Title

            "Name" = $_.Name

            "ID" = $_.ID

            "Custom" = $_.Custom

            "LocaleId" = $_.LocaleId

        }

        New-Object PSObject -Property $templateValues | Select @("Name","Title","LocaleId","Custom","ID")

    }

}

Get-SPWebTemplateWithId | Format-Table

This gives us the output of:

PSTemplate1.png

These are all the default templates and the IDs associated with them – you can clearly see that the template names are individual BUT the web template IDs (in the end column) are grouped in to the original templates that were used to create them.

This screenshot shows the groupings of the initial template IDs:

PSTemplate2Grouped.png

To illustrate the issue even further I created a TEAM Site at http://sp2010blog.com/export and then ran this snippet against it:
 
$web = Get-SPWeb http://sp2010blog.com/export
write-host "Web Template:" $web.WebTemplate " | Web Template ID:" $web.WebTemplateId
$web.Dispose()
 
This returns the values of:
Web Template: STS  | Web Template ID: 1
 
It’s clearly using the underlying site template value for a blank site…
 
….Still – why all the fuss? Can’t you just use the Template Name?
 
Well yes and no – if you are altering the script manually you can change the name manually but if you want to automate the process using a GUI for ease of use then you need to call the template ID programmatically and hence the problem… as calling the name only provides the first portion of the name (up to the #) and requires a separate call to get the id – so in essence it has to be built up, but can’t if the wrong id is reported.
 
The whole point of my the new move sites script is to provide a PowerShell, GUI driven script that can quickly and easily move a site from one location to another without having to edit code all the time – and more importantly do it for free rather than having to purchase very expensive third party products!
So far I haven’t been able to come up with an answer to this conundrum so anyone with any type of info or answer is more than welcome to post using the form on the right.  The Move site scripts uses a drop down and link to this site for the end user to select the relevant template manually, but that is still a no go if you don’t know the source template…
 
One ray of sunshine however is that when you try to import a site into a newly created site made from a different template it bombs out and tells you which template you should be using in the first place which means the original template details are in there… somewhere… so if anyone has any ideas please get posting! J
​

 

Permanent Link to Post | Email Post Link | Number of Comments 1 Comment(s)
May 05
SharePoint 2010 Site Template IDs - Used in the Move Site Script
by  Heath GrovesNo presence information  on 05/05/2011 13:45

Below is the list of the default site templates used in a SharePoint 2010 install. 

Template ID Description Template ID Description
STS#0     Team Site BICenterSite#0     Business Intelligence Center
STS#1     Blank Site SPS#0     SharePoint Portal Server Site
STS#2     Document Workspace SPSPERS#0     SharePoint Portal Server PS
MPS#0     Basic Meeting Workspace SPSMSITE#0     Personalization Site
MPS#1     Blank Meeting Workspace SPSTOC#0     Contents area Template
MPS#2     Decision Meeting Workspace SPSTOPIC#0     Topic area template
MPS#3     Social Meeting Workspace SPSNEWS#0     News Site
MPS#4     Multipage Meeting Workspace CMSPUBLISHING#0     Publishing Site
WIKI#0     Wiki Site BLANKINTERNET#0     Publishing Site
BLOG#0     Blog BLANKINTERNET#1     Press Releases Site
SGS#0     Group Work Site BLANKINTERNET#2     Publishing Site with Workflow
TENANTADMIN#0     Tenant Admin Site SPSNHOME#0     News Site
ACCSRV#0     Access Services Site SPSSITES#0     Site Directory
ACCSRV#1     Assets Web Database SPSCOMMU#0     Community area template
ACCSRV#3     Charitable Contributions Web DB SPSREPORTCENTER#0     Report Center
ACCSRV#4     Contacts Web Database SPSPORTAL#0     Collaboration Portal
ACCSRV#6     Issues Web Database SRCHCEN#0     Enterprise Search Center
ACCSRV#5     Projects Web Database PROFILES#0     Profiles
BDR#0     Document Center BLANKINTERNETCONTAINER#0     Publishing Portal
OFFILE#0     (obsolete) Records Center SPSMSITEHOST#0     My Site Host
OFFILE#1     Records Center ENTERWIKI#0     Enterprise Wiki
OSRV#0     Shared Services Administration Site SRCHCENTERLITE#0     Basic Search Center
PowerPivot#0     PowerPivot Site SRCHCENTERLITE#1     Basic Search Center
PowerPointBroadcast#0     PowerPoint Broadcast Site SRCHCENTERFAST#0     FAST Search Center
PPSMASite#0     PerformancePoint visprus#0     Visio Process Repository

 

This page is used in the move site powershell script so it can dynamically updated for continual use​

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 26
SharePoint 2010 change user display name (Particularly MySite shows domainname\username)
by  Heath GrovesNo presence information  on 26/04/2011 13:55
I’ve come across this error a few times now.  Basically new users have their display name shown with the Netbios name for the network in front of it.  Generally once the user has created a MySite (i.e. they click the My Content link which actually creates the MySite site collection) it generally resolves itself after the next full sync.
 
However in some cases it does not, so I’ve written a little PowerShell script that gathers all the users that have logged onto a SharePoint site and forces a sync with AD – which in turn fixes the error.
 
Here’s the script:
 
add-pssnapin microsoft.sharepoint.powershell
Get-SPUser -Web http://mysite/my
Get-SPUser -Web http://mysite/my | ForEach-Object {Set-SPUser -identity $_.name -web http://mysite/my -SyncFromAD}
 
As always you use it at your own risk, but it’s worked fine for me so far… Happy hunting! J
​

 

***** MAJOR UPDATE *****

Please use this blog post for this issue:

​http://www.sp2010blog.com/Blog/Lists/Posts/Post.aspx?ID=50

It explains the theory behind the error in question 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 20
The required feature is not enabled for this column type managed metadata
by  Heath GrovesNo presence information  on 20/04/2011 10:33

 

This sometimes occurs when you try to use the meta data service on a separate web application or site collection that reside in a separate DB.  Basically you have to enable the feature using STSADM for it register/work with your current managed meta Data service.
 
As a secondary error - you may notice that when using the content type syndication hub, the content type publishing option is not displayed on separate site collections and web applications (specifically anything resident in a different DB to the main Content Type Hub) - activating this feature also rectifies this situation.
 
On your Central Admin/Indexer machine run the following stsadm script
 

For example STSADM -o activatefeature -id 73EF14B1-13A9-416b-A9B5-ECECA2B0604C –url http://intranet/sc -force.

Hope somebody finds this useful! :)​

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
April 14
SharePoint 2010 Timer Service Stuck Stopping – Usually on a SQL Box
by  Heath GrovesNo presence information  on 14/04/2011 15:31

 

Error
 
Health Analyser states that one or more servers is not responding and on investigation you try to restart the SPTimerV4 service and at that point it sticks in the “Stopping” mode
 
Fix
 
Open Task Manager, Go to Services and find the SPTimerV4 Service - this will be in the stopping state
 
Right click the service select Go To Process, this will switch to the process screen and should highlight OWSTIMER.EXE - if you can't see this make sure the Show Processes from all users is ticked and that display it regardless of the account it is running with, Right Click OWSTIMER.EXE and select End Process.
 
The SharePoint 2010 Timer service should now be showing as Stopped, right click the service and select Start and you should be good to go!
 
Just in case you need to try and stop and start the timer service from the command line you can also try these:
 
SharePoint 2010: net stop
 
SPTimerV4 net start SPTimerV4
 
I’ve found that this issue happens more on SQL boxes and the main reason for correcting it is that deploying .wsps won’t complete unless the timer service on all machines is running correctly.
​

 

Permanent Link to Post | Email Post Link | Number of Comments 0 Comment(s)
1 - 10Next
Alert Me Alert Me
 Photos
Untitled 1
Blog Author/Owner Heath Groves (Click for Profile)
Why not follow me on:
  Follow Heath Groves on Twitter