Andy Dawson's Blog

The blog of Andy dawson

Setting SharePoint 2013 User Profile Service Application Permissions Using PowerShell

My last post about the SharePoint 2013 MySite Newsfeed and required additional permissions on the User Profile Service Application dealt with adding the required permissions to the UPSA using the SharePoint 2013 GUI. Alternatively, you can add the required permissions using PowerShell:

#Grab a reference to the User Profile Service Application $serviceapp = Get-SPServiceApplication | where {$_.DisplayName -eq "User Profile Service Application"} #Return the SPObjectSecurity object for the Service Application $security = Get-SPServiceApplication $serviceapp | Get-SPServiceApplicationSecurity #Setup our claim provider $claimprovider = (Get-SPClaimProvider System).ClaimProvider #Specify the required principal $principal = New-SPClaimsPrincipal "Domain\UPSAppAccount" -IdentityType WindowsSamAccountName #Grant the required permissions on the Service Application Grant-SPObjectSecurity -Identity $security -Principal $principal -Rights "Full Control" Set-SPServiceApplicationSecurity $serviceapp -ObjectSecurity $security

Using PowerShell allows us to add this part of the configuration to a script rather than having a manual step to perform once the PowerShell has completed (as we all know, these additional manual steps tend to get forgotten).

SharePoint 2013 MySite Newsfeed displays "There was a problem retrieving the latest activity. Please try again later"

This is an issue that we've been bumping up against and have seen a number of other users seeing the same problem with SharePoint 2013 implementations.

When looking at the 'Everyone' tab on a user's MySite, the following message is displayed:

There was a problem retrieving the latest activity. Please try again later.

and the following entries appear in the SharePoint logs:

Failure retrieving application ID for User Profile Application Proxy 'User Profile Service Proxy': Microsoft.Office.Server.UserProfiles.UserProfileApplicationNotAvailableException: UserProfileApplicationNotAvailableException_Logging :: UserProfileApplicationProxy.ApplicationProperties ProfilePropertyCache does not have c2d5c86f-e928-4abf-b353-a8ab7809766c     at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_ApplicationProperties()     at Microsoft.Office.Server.Administration.UserProfileApplicationProxy.get_AppID()           0e49dc9b-d278-1089-b021-6e2138766eae

SPMicrofeedFeedCacheService.GetUserProfile() - UserProfileApplicationProxy not available     0e49dc9b-d278-1089-b021-6e2138766eae

To correct this issue, complete the following steps:

  1. Log onto the SharePoint 2013 Central Administration site as a farm administrator
  2. Navigate to 'Manage Service Applications'
  3. Highlight the User Profile Service Application
  4. Click the 'Permissions' ribbon toolbar button:
    UPSA permissions
  5. Add the account that is used to run the User Profile Service Application and give it full control:
    UPSA connection permissions
  6. Click OK

At this point it is usual to see the following displayed in the 'Everyone' tab of the user's MySite:

Were still collecting the latest news. You may see more if you try again a little later.

It's worth checking the SharePoint logs at this point to see what additional errors may be reported (note that you will see 'We're still collecting the latest news' if no users have posted anything, so create a post to ensure that you have something waiting in the queue). In my case, I saw the following:

System.Data.SqlClient.SqlException (0x80131904): Cannot open database "SP_Content_MySite" requested by the login. The login failed.  Login failed for user 'Domain\UPSApp'.

This can be solved by completing the following steps:

  1. Open the SharePoint 2013 Management Shell by right-clicking and choosing 'run as administrator'
  2. Issue the following PowerShell commands
    $wa = Get-SPWebApplication http://<MySiteURL>
    $wa.GrantAccessToProcessIdentity("domain\UPSApp")

At this point, the newsfeed should be up and running successfully:

Functional everyone newsfeed

Hiding a Default SharePoint 2010 Content Type Field

Extending some of the default content types available in SharePoint 2010 can result in unwanted fields being shown. An example is extending the 'Event' default content type, which has three fields attached which you don't seem to be able to edit:

Unwanted event fields

In particular, many users would like to remove the Workspace field from calendar entries:

Workspace field

Some users resort to editing the new/edit/view forms to remove the fields that are not wanted, however there is an easier way!

Using the following PowerShell, an unwanted field can be hidden so that it does not appear in the new/edit/view forms:

1 # Get a reference to the web we are using 2 $web = Get-SPWeb https://intranet.domain.com/site 3 4 # Get a reference to the list to which the content type is attached 5 $list = $web.Lists["Holiday Calendar"] 6 7 # Return a list of the fields 8 $fields = $list.fields 9 10 # Select the field we wish to hide 11 $field = $fields | where {$_.internalname -eq "WorkspaceLink"} 12 13 # Show the current 'hidden' status of the field 14 $field.Hidden 15 16 # Set the field to hidden (note that 'CanToggleHidden' must be true to allow this) 17 $field.Hidden = $true 18 19 # Update the field 20 $field.Update()

Creating a new holiday event on the calendar, the field allowing a user to create a workspace is now hidden:

New item form without workspace field

SharePoint 2010 Service Application Communication Scheme

The default communication scheme for many of the SharePoint 2010 Service Applications is ‘http’ (i.e. unsecured). This can be changed easily in the GUI by selecting the service application and clicking the ‘publish’ ribbon button:

Service Application publish ribbon toolbar button

It should however be noted that a number of Service Application communication schemes run by default over https and cannot be modified, these are:

  • Application Discovery and Load Balancer Service Application
  • Search Administration Web Service
  • Secure Store Service Application
  • Security Token Service Application

The communication scheme of a few Service Applications cannot be inspected using the GUI (and the publish ribbon button remains greyed out when they are selected):

  • SharePoint Server ASP.NET Session State Service
  • SharePoint Session State Service Application
  • WSS_UsageApplication

Modifying the communication scheme of all of the Service Applications can be time consuming and can be error prone, especially when using SharePoint 2010 Enterprise and the Office Web Applications with all of the Service Applications available configured for use. With this in mind, the following PowerShell will change the communication scheme of all of the Service Applications where it is possible to do so to https:

1 # This script sets the communication scheme of all Service Applications to be https instead of http 2 # Note that the communication scheme for a number of Service Applications cannot be changed 3 4 # Grab a list of the Farm's Service Applications 5 $ServiceApps = Get-SpServiceApplication | Sort-Object TypeName 6 7 # Iterate through the Service Applications 8 foreach ($ServiceApp in $ServiceApps) 9 { 10 if (($ServiceApp.TypeName -ne "Application Discovery and Load Balancer Service Application") ` 11 -and ($ServiceApp.TypeName -ne "Search Administration Web Service Application") ` 12 -and ($ServiceApp.TypeName -ne "Security Token Service Application") ` 13 -and ($ServiceApp.TypeName -ne "Secure Store Service Application") ` 14 -and ($ServiceApp.TypeName -ne "SharePoint Server ASP.NET Session State Service") ` 15 -and ($ServiceApp.TypeName -ne "State Service") ` 16 -and ($ServiceApp.TypeName -ne "Usage and Health Data Collection Service Application")) 17 { 18 # We can modify the communication scheme 19 Write-Host "Current communication shceme for" $ServiceApp.DisplayName ":" $ServiceApp.DefaultEndpoint.Name 20 if (($ServiceApp.DefaultEndpoint.Name -eq "https") -or ($ServiceApp.DefaultEndpoint.Name -eq "secure")) 21 { 22 Write-Host "Service Application already using https, skipping" -ForegroundColor Red 23 } else { 24 # Change the communication scheme to https 25 26 27 if ($ServiceApp.TypeName -eq "PowerPoint Service Application") { 28 # PowerPoint Service Application has "fast" instead of "http" and "secure" instead of "https" 29 $SAEhttps = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "secure"} 30 } else { 31 $SAEhttps = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "https"} 32 } 33 Write-Host "Setting Service Application communication scheme to https" -ForegroundColor Green 34 $ServiceApp.DefaultEndpoint = $SAEhttps 35 $ServiceApp.Update() 36 } 37 Write-Host "`n" 38 } 39 }

To reverse these changes, and set the communication scheme of all Service Applications for which it is possible to modify the communication scheme, the following PowerShell can be used:

1 # This script sets the communication scheme of all Service Applications to be http instead of https 2 # Note that the communication scheme for a number of Service Applications cannot be changed 3 4 # Grab a list of the Farm's Service Applications 5 $ServiceApps = Get-SpServiceApplication | Sort-Object TypeName 6 7 # Iterate through the Service Applications 8 foreach ($ServiceApp in $ServiceApps) 9 { 10 if (($ServiceApp.TypeName -ne "Application Discovery and Load Balancer Service Application") ` 11 -and ($ServiceApp.TypeName -ne "Search Administration Web Service Application") ` 12 -and ($ServiceApp.TypeName -ne "Security Token Service Application") ` 13 -and ($ServiceApp.TypeName -ne "Secure Store Service Application") ` 14 -and ($ServiceApp.TypeName -ne "SharePoint Server ASP.NET Session State Service") ` 15 -and ($ServiceApp.TypeName -ne "State Service") ` 16 -and ($ServiceApp.TypeName -ne "Usage and Health Data Collection Service Application")) 17 { 18 # We can modify the communication scheme 19 Write-Host "Current communication shceme for" $ServiceApp.DisplayName ":" $ServiceApp.DefaultEndpoint.Name 20 if (($ServiceApp.DefaultEndpoint.Name -eq "http") -or ($ServiceApp.DefaultEndpoint.Name -eq "") -or ($ServiceApp.DefaultEndpoint.Name -eq "fast")) 21 { 22 Write-Host "Service Application already using http, skipping" -ForegroundColor Red 23 } else { 24 # Change the communication scheme to https 25 if ($ServiceApp.TypeName -eq "Visio Graphics Service Application") 26 { 27 # Visio Graphics Service Application has "" instead of "http" (equivalent to "default" in the GUI) 28 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq ""} 29 } elseif ($ServiceApp.TypeName -eq "PowerPoint Service Application") { 30 # PowerPoint Service Application has "fast" instead of "http" and "secure" instead of "https" 31 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "fast"} 32 } else { 33 $SAEhttp = $ServiceApp | Get-SPServiceApplicationEndpoint | where {$_.DisplayName -eq "http"} 34 } 35 Write-Host "Setting Service Application communication scheme to http" -ForegroundColor Green 36 $ServiceApp.DefaultEndpoint = $SAEhttp 37 $ServiceApp.Update() 38 } 39 Write-Host "`n" 40 } 41 }

Note that an IISRESET will be required on all servers in the farm once either of the above PowerShell scripts has been run to complete the modification of the communication scheme.

Renaming the Managed Metadata Service Application Database

On the face of it, renaming the Managed Metadata Service Application database in SharePoint should be a fairly simple matter. There’s a test box for the database name in the properties of the Service Application and changing the name shown changes the database name. There are however one or two issues with changing the database name this way…

The image below shows a minimally configured Managed Metadata Service Application instance (some sample data has been added):

Sample Managed Metadata Service Application

The database name can be easily changed by editing the properties of the Service Application and editing the name of the database:

Sample Managed Metadata Service Application Properties

The first of the issues experienced is that SharePoint now knows about two Managed Metadata Service Application databases. Checking the database list within the ‘review database status’ area of the ‘upgrade and migration’ section of Central Administration (a good place to get a complete list of the databases associated with a SharePoint 2010 farm) shows two Managed Metadata Service Application databases:

SharePoint believes that it has two Managed Metadata Service Application databases

In addition, if the old database is deleted (using SQL Management Studio), the message ‘Not Responding’ will be shown against the database in the list (and errors will be shown in the event viewer of the machine hosting the Managed Metadata Service):

Managed Metadata Service Application database showing 'Not Responding'

This is logical as SharePoint understands that there is a database associated with the farm that has been deleted.

The real problems have, however, only just started!

Looking at the Managed Metadata Service Application now shows the following:

Empty Managed Metadata Service Application

In other words, although the database associated with the Service Application has been changed, the data contained within the original database has not been migrated. SharePoint has simply created a new Service Application database and associated that with the Service Application. If the database is renamed before any data has been added to the Service Application, this is not an issue, you’ll simply have to add administrators and data as you would normally. You’ll also have to remove the original database using the following PowerShell:

  1. Get-SPDatabase
    Note the GUID of the original Managed Metadata Service Application database
  2. $OldDB = Get-SPDatabase <GUID of the original database>
  3. $OldDB.Delete()

 

To correct the issues shown above after renaming the database, assuming that the original database is still available, there are a couple of potential routes to take:

  1. Perform steps similar to those outlined in the blog post ‘Renaming the PerformancePoint Service Application database in SharePoint 2010’ – I’d suggest the ‘backup and restore’ procedure from this blog post. Also note that the PowerShell command you’ll need to assign the newly renamed database to the Service Application is Set-SPMetadataServiceApplication <Identity> –DatabaseName <New DB Name>
  2. Temporarily reattach the original database to the Service Application and export the data from it, before reattaching the new database and importing the data into it.

 

The PowerShell you’ll need to achieve the latter of the the above methods is:

  1. Set the Service Application to use the original database:
    Set-SPMetadataServiceApplication "<friendly name of the Managed Metadata Service Application" -databasename <original DB name>
  2. Issue an IISRESET on all servers in the farm
  3. Export the Managed Metadata Service Application information:
    Export-SPMetadataWebServicePartitionData -identity <URL of the Web Application associated with the Service Application> -ServiceProxy “friendly name of the Service Application Proxy” -path <path and filename of the backup file to be used>.cab
  4. Set the Service Application to use the new database:
    Set-SPMetadataServiceApplication "<Friendly name of the Managed Metadata Service Application" -databasename <new DB name>
  5. Issue an IISRESET on all servers in the farm
  6. Import the Managed Metadata Service Application information:
    Import-SPMetadataWebServicePartitionData -identity <URL of the Web Application associated with the Service Application> -serviceproxy "friendly name of the Service Application Proxy" -path <path and filename of the backup file to be used>.cab –OverwriteExisting

 

Note that using this method retains the original data in completeness, therefore all of the list associations with the Managed Metadata Service Application should continue to function without needing to be reconnected.

You can then delete the original database using the PowerShell commands detailed previously.

Publishing Access Services Database to SharePoint 2010 gives ‘&lt;URL&gt; did not respond…’

While building a portion of our demo SharePoint 2010 farm, I encountered an error when publishing an Access 2010 database to a SharePoint 2010 Access Services site.

The error which was shown was ‘<URL> did not respond. Either the server does not exist, Microsoft Access Services are not enabled on the server, or the server is using an older version of Microsoft Access Services which is not compatible with Access 2010’:

Access Services Publish Error

After checking that the Access Services farm and web application features were enabled, and that the enterprise features were enabled on the site collection to which I was attempting to publish the Access database (all were fine), I looked in the server application logs on the WFE servers in the demo farm, and on one of the farm servers saw the error ‘There is no default Access Services Application Proxy’:

Event Viewer Error

Checking the Service Application Associations (Central Administration –> Application Management –> Configure service application associations) showed that the Access Database Service proxy was not associated with the default proxy group:

Proxy Associations

After adding the Access Database Service proxy to the default group, publishing the Access database to SharePoint proceeded without a hitch.

In our case, the proxy not being associated with the default proxy group was due to us using PowerShell to configure the Access Service Application. If you do the same, check whether the proxy has been associated with the default group (or whatever proxy group you want it associated with).

Error during SharePoint 2010 Upgrade “Minimal master page failed to provision: could not find master page gallery”

During a recent SharePoint upgrade using the database attach method, I saw the following recorded in the upgrade error log:

[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: SPSite Url=http://intranet.domain.com
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: Minimal master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: SPSite Url=http://intranet.domain.com
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: V4 master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: SPSite Url=http://intranet.domain.com

Further information was provided in the upgrade log that accompanies the error log:

[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Setting UIVersion metadata on existing default master page
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Provisioning minimal master page in site: Site1
Site Url: http://intranet.domain.com/Site1
[Powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: Minimal master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Provisioning V4 master page in site: Site1
Site Url: http://intranet.domain.com/Site1
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: V4 master page failed to provision: could not find master page gallery.
[powershell] [PerWebUpgradeAction (4.0.10.0)] [INFO] [13/04/2011 15:55:48]: Setting UIVersion metadata on existing default master page
[powershell] [PerWebUpgradeAction (4.0.10.0)] [WARNING] [13/04/2011 15:55:48]: Could not find master page gallery. Metadata on default.master not set.

The farm in question was originally a SharePoint 2003 farm that had been in-place upgraded to SharePoint 2007. The site recorded in the upgrade error log had been created in SharePoint 2003, but had not had its template selected at the time of original creation, allowing the first site user to pick the template to use. Critically however, this had never been done.

Once the database upgrade had been completed, navigating to the site gave me the expected screen to allow me to select the site template to use. Picking a template and clicking OK however produced a ‘file not found’ error.

The moral of the story seems to be ensure that any sites created without selecting a site template should either be completed, or deleted before the upgrade process starts. Note that you can still delete a site that has been upgraded to 2010 in the above state using PowerShell. Detection of sites such as these in SharePoint 2007 is straightforward using stsadm –o enumallwebs – any site that doesn’t have a template shown against it is in this state.

Renaming the PerformancePoint Service Application database in SharePoint 2010

When creating the PerformancePoint Service Application, there is no way to control the name of the database that is created, not even when using PowerShell to create the Service Application. The database that gets created is in the form

<Service Application Name>_GUID

which for some reason a good many DBAs are not too keen on!

The database can however be renamed by following these steps:

  • Stop the PerformancePoint service on all SharePoint servers in the farm that are running the service using the ‘services on servers’ area of Central Administration:
    Stopping the PerformancePoint Service
  • Rename the database and log file – there are two ways of completing this; I prefer the second option of the two outlined below as it completely renames all of the references to the database, but it is a more involved process:
    1. Open SQL Server Management Studio on the SQL Server for the farm.
      Select the PerformancePoint Service Application database and then click again to allow renaming:
      Rename PerformancePoint DB in GUI
      Rename the database to match the naming convention you wish to use for farm databases. Note that this only renames the database friendly name as shown in SQL Server Management Studio and not the file names or the logical database and log file names.
    2. Alternatively:
      Open SQL Server Management Studio on the SQL Server for the farm.
      If you wish to, you can change the recovery mode of the PerformancePoint database to ‘simple’; this saves having to backup and restore a log file as well as the database file.
      Backup the PerformancePoint database created during the Service Application creation process.
      Restore the PerformancePoint database from the backup completed to a new database name which matches the naming convention you wish to use for farm databases. Note that the default naming convention for the log files on restore appends ‘_1’ to the database name to form the log file name; you may wish to change this to ‘_log’ to match the other log files that the database server hosts. The backup and restore will change the filenames used for the databases and the display name shown in SQL Server Management Studio, but not the logical database names. To change the logical database names, first find the logical names of the database and log for the database you wish to change; you can find this information either by taking note of the original database name when it was created, or from the ‘files’ section of the database properties screen within SQL Server Management Studio:
      Database Logical Names
      Execute the following two SQL queries:

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical database name>", NEWNAME="<new PerformancePoint database name>")

      ALTER DATABASE <new PerformancePoint database name> MODIFY FILE (NAME="<original logical log file name>", NEWNAME="<new PerformancePoint database name>_log")

      If you changed the database recovery mode to ‘simple’, change it back to ‘full’.
  • On one of the SharePoint servers in the farm, open an instance of the SharePoint 2010 Management Shell, ensuring that it is run as administrator and issue the following PowerShell Commands:

    $newdatabasename = "<new PerformancePoint database name>"
    Set-SPPerformancePointServiceApplication -Identity "<name of the PerformancePoint Service Application>" -SettingsDatabase $newdatabasename
  • Restart the PerformancePoint service on the servers in the farm it was running on originally.
  • Delete the original PerformancePoint database that was created during the Service Application creation from SQL Server Management Studio.

Microsoft SharePoint Conference 2009: Day 2

A few highlights from today’s talks:

  • With SharePoint 2010, we no longer have a Shared Service Provider (SSP), instead we now have service application instead. All of the applications benefit from an internal load balancing scheme (fault tolerant round robin load balancing), meaning that as long as you start a service application on more than one server, you’re better protected from failure.  Oh, and yes, that goes for indexing as well!
  • The Service Application framework is extensible; this means you can write your own services to be hosted by SharePoint. These will, in turn, benefit from the internal load balancing scheme mentioned above.  Yes, you can also use a hardware load balancer and from what I gathered, even write your own load balancer!
  • All of your Service Application management can be done from PowerShell – if you don’t know PowerShell, now is going to be a very good time to learn…  If you want to have a look at the available applets, try the following in PowerShell:
    get-SPServiceApplication
    this will return the list of available commandlets.
  • You will be able to add delegated administrators for specific Service Applications. These delegated administrators will have their view of the Central Administration site trimmed to only those items they should see.
  • Claims based auth looks very interesting, and can be extended to allow 3rd party applications to provide additional claims.
  • SharePoint Designer 2010 rocks!