SharePoint Online Content Type Hub Publishing Issues

We use the SharePoint Online Content Type Hub extensively as the central location to create, manage and distribute content types throughout our SharePoint Online tenant. We recently saw an issue with the distribution of one of the content types defined in the Content Type Hub which had a specific PowerPoint template assigned to it.

The content type in question had been updated with a revised template and republished, however when we tried to create a new presentation from the content type in SharePoint Online, the older template was still being served. I spent quite a long time testing a variety of PowerPoint template files of varying content and sizes with the content type (upload a new template to the content type in the Content Type Hub –> republish the content type –> wait for distribution to the site collections –> test; a process that can take some time when the content type is being distributed correctly) with no progress at all. It didn’t seem to matter what template file I uploaded to the content type, nothing seemed to be distributed. I even tried a blank Word template, and even that didn’t get distributed. Eventually I raised a Microsoft support case to help resolve the issue.

As the content type used managed metadata columns and I’d made a minor change to those, I tested with content types created using the same columns but a different template file and one using no managed metadata columns, but with what appeared to be the problematic template file uploaded. Only the example with the problematic template file was affected, but in the same way that we’d seen with the original content type, it didn’t matter what template file we uploaded afterwards, the content type and revised template were not distributed. The template we were using was obviously the issue, however it seemed to break distribution of any content type it was uploaded to from then on.

SharePoint content type templates are held in a folder structure in the root of site collections as follows:

_cts/<content type name>/<template file name>

This is true for both the Content Type Hub where the content types are distributed from, and the destination site collections.

Examining this location in the Content Type Hub (initially using PowerShell, but also using the SharePoint Client Browser), showed the following:

SPCB exploration of cts folder

As can be seen, all of the template files that have been uploaded to the content type were still present! Uploading a new template file does not appear therefore to delete the previous file that was associated with the content type. If one of the uploaded files causes issues distributing the content type, even though it may not be associated with the content type anymore, it continues to cause issues simply by being present in the folder for the content type. For example the following PowerShell retrieves the template filename and URL associated with the content type:

Get-PnPContentType -Identity “Black Marble Presentation” | select DocumentTemplate,DocumentTemplateUrl

In our case, this demonstrated that the template that was causing the issue was not associated with the content type, except by its existence in the folder for the content type in _cts.

The following PowerShell could therefore be used to remove the extraneous template files from the content type folder in the Content Type Hub site collection:

Remove-PnPFile –SiteRelativeUrl “_cts/Black Marble Presentation/<template file name>”

Using the above PowerShell I removed all of the unused template files and then republished the content type with a simple blank Word template initially to test whether the content type was distributed successfully. Once that was shown to be successful I uploaded a revised PowerPoint template file and republished the content type. The revised template was also successfully distributed.

Correcting Legacy Microsoft Teams Settings

I recently noticed that some of the Microsoft Teams that we had in use exhibited different behaviour to others that had been created more recently. ‘Recently’ (for varying definitions of ‘recent’) created Teams allowed users to edit and delete their messages, whereas a few older Teams did not. The older Teams were all created very early during our rollout of Teams, when Microsoft Teams itself was relatively new.

Checking the Teams messaging policies showed that the correct settings were in place to allow users to edit and delete their messages:

Messaging policy settings

It appeared that these settings were not however being applied for the legacy Teams. Checking in the individual Team settings showed that these were overriding the global settings applied:

Individual Team settings

Note also that in the above screen shot, the ‘Owners can delete all messages’ setting was also unchecked, although this turned out to be the only Team for which this was the case.

I could go through each Team individually and manually check the Team settings, however PowerShell allows us to perform the same actions quickly. The following PowerShell checks for the user Team settings being mis-configured and corrects the settings:


$teams = Get-Team | where {$_.AllowUserDeleteMessages -eq $False -OR $_.AllowUserEditMessages -eq $False}

foreach ($t in $teams) {
     Set-Team -DisplayName $t.DisplayName -GroupId $t.GroupId -AllowUserEditMessages $True -AllowUserDeleteMessages $True

For the other mis-configured setting mentioned, use ‘AllowOwnerDeleteMessages’ as the search criteria.

Deploying Files to the Logged-In User’s Profile Using Configuration Manager

I’ve had a number of cases where it would have been useful to be able to deploy files to a logged-in user’s profile on Windows using Configuration Manager (SCCM), but due to the context in which the ‘installation’ runs (i.e. the local system), using parameters such as %AppData% in a batch file doesn’t work, and this has always been an issue.

We recently wanted to push some custom backgrounds out to Microsoft Teams and I thought I’d spend a while trying to solve this issue. The following may not be the most elegant solution, but it seems to work reliably for me!

  1. We’re going to use PowerShell to detect the presence of a file. Copy the following into a file for the moment; we’ll need this PowerShell snippet shortly:
    Function CurrentUser {
         $LoggedInUser = get-wmiobject win32_computersystem | select username
         $LoggedInUser = [string]$LoggedInUser
         $LoggedInUser = $LoggedInUser.split(“=”)
         $LoggedInUser = $LoggedInUser[1]
         $LoggedInUser = $LoggedInUser.split(“}”)
         $LoggedInUser = $LoggedInUser[0]
         $LoggedInUser = $LoggedInUser.split(“\”)
         $LoggedInUser = $LoggedInUser[1]
         Return $LoggedInUser

  2. $user = CurrentUser

    start-sleep 30

    $AppPath = “C:\Users\” + $user + “\AppData\Roaming\Microsoft\Teams\Backgrounds\Uploads\CustomBackground.png”
    If (Test-Path $AppPath) {
         Write-Host “The application is installed”

    We need the sleep function in the file as the detection runs pretty quickly after the deployment and we want to be sure that the file(s) we’re going to copy are in place before attempting to perform the detection. This script extracts the username (including domain) of the currently logged in user, then separates the actual username from the returned value allowing this to be inserted into the path for detecting the file.

  3. Create a PowerShell file similar to the detection script to perform the file deployment:
    Function CurrentUser {
         $LoggedInUser = get-wmiobject win32_computersystem | select username
         $LoggedInUser = [string]$LoggedInUser
         $LoggedInUser = $LoggedInUser.split(“=”)
         $LoggedInUser = $LoggedInUser[1]
         $LoggedInUser = $LoggedInUser.split(“}”)
         $LoggedInUser = $LoggedInUser[0]
         $LoggedInUser = $LoggedInUser.split(“\”)
         $LoggedInUser = $LoggedInUser[1]
         Return $LoggedInUser

  4. $user = CurrentUser

    $AppPath = “C:\Users\” + $user + “\AppData\Roaming\Microsoft\Teams\Backgrounds\Uploads\”
    cp “.\Backgrounds\*.png” -Destination $AppPath -Confirm:$false –Force

    I saved mine as ‘Deploy-TeamsBackgrounds.ps1’. This script uses the same logic as the detection script, above, to determine the username and allows us to use this in the path to copy the file(s) to.

  5. Create a batch file to call the PowerShell file that does the actual file deployment:
    Powershell -NoProfile -ExecutionPolicy Bypass -file %~dp0Deploy-TeamsBackgrounds.ps1

    I saved this as ‘Deploy-TeamsBackgrounds.bat’. This batch file runs PowerShell and passes in the filename of the scripts used to deploy the files to the user’s profile location. Ensure that the batch file and the deployment PowerShell script are in the same location somewhere suitable for SCCM to use as the application source (usually a share on the SCCM server). I then have a folder called ‘Backgrounds’ in the same location that contains the actual image files to be copied.

  6. Create a new application in Configuration Manager selecting ‘Manually specify the application information’:
    Then enter information on the name, publisher and version of the application:
    Add any required information for the Software Center entry:
    Click ‘Add’ to add a deployment type:
    and select ‘Script installer’ from the drop-down. This will automatically select the ‘Manually specify the deployment type information’ option:
    Provide a name for the deployment type:
    Specify the location that contains the files created earlier and the batch file as the command used to install the content:
    For the detection method, select ‘Use a custom script to detect the presence of this deployment type, the click the ‘Edit…’ button:
    Select PowerShell from the Script type drop-down and then paste the detection script generated earlier:
    and click OK to close the script editor window.
    Define the user experience:
    Note that I saw a warning shown at this point.
    Define any requirements (e.g. only deploy on Windows 10) and dependencies, then click through to generate the application.
  7. Distribute the content, then configure a deployment. I used the ‘All Staff’ user collection to deploy to.

Once the application appears in the Software Center, an end-user can click to install the custom backgrounds and the ‘application’ is downloaded to the Configuration Manager cache, then the batch file is triggered, which in turn executes the PowerShell script to copy the custom background images to the correct location in the user’s profile. The detection script then runs and detects the presence of the specified file.

Configuring PowerChute Network Shutdown on Server Core

Everyone installing Hyper-V servers is installing them as Server Core servers, right? Smile

I recently hit an issue configuring APC’s PowerChute Network Shutdown (PCNS) software on a Server Core installation of Windows Server 1809 (the most recent release of the semi-annual channel) whereby while the installation appeared to complete successfully, I could not communicate with the service to configure it post-installation.

After a little digging, it turned out that the installer had created the firewall rule exemptions for to wrong profile (i.e. public rather than domain). The solution was to run the following PowerShell to update the profile for the PCNS firewall rules to match the network profile the server was operating on:

Get-NetFirewallRule | where {$_.DisplayName -like “PCNS*”} | Set-NetFirewallRule -Profile Domain

Once the firewall rules were updated, communication was restored and configuration could be completed from a browser running on another machine.

Test-SPContentDatabase False Positive

I was recently performing a SharePoint 2013 to 2016 farm upgrade and noticed an interesting issue when performing tests on content databases to be migrated to the new system.

As part of the migration of a content database, it’s usual to perform a ‘Test-SPContentDatabase’ operation against each database before attaching it to the web application. On the farm that I was migrating, I got mixed responses to the operation, with some databases passing the check successfully and others giving the following error:

PS C:\> Test-SPContentDatabase SharePoint_Content_Share_Site1

Category        : Configuration
Error           : False
UpgradeBlocking : False
Message         : The [Share WebSite] web application is configured with
claims authentication mode however the content database you
are trying to attach is intended to be used against a
windows classic authentication mode.
Remedy          : There is an inconsistency between the authentication mode of
target web application and the source web application.
Ensure that the authentication mode setting in upgraded web
application is the same as what you had in previous
SharePoint 2010 web application. Refer to the link″ for more
Locations       :

This was interesting as all of the databases were attached to the same content web application, and had been created on the current system (I.e. not migrated to it from an earlier version of SharePoint) and therefore should all have been in claims authentication mode. Of note also is the reference to SharePoint 2010 in the error message, I guess the cmdlet hasn’t been updated in a while…

After a bit of digging, it turned out that the databases that threw the error when tested had all been created and some initial configuration applied, but nothing more. Looking into the configuration, there were no users granted permissions to the site (except for the default admin user accounts that had been added as the primary and secondary site collection administrators when the site collection had been created), but an Active Directory group had also been given site collection administrator permissions.

A quick peek at the UserInfo table for the database concerned revealed the following (the screen shot below is from a test system used to replicate the issue):

UserInfo Table

The tp_Login entry highlighted corresponds to the Active Directory group that had been added as a site collection administrator.

Looking at Trevor Seward’s blog post ‘Test-SPContentDatabase Classic to Claims Conversion’ blog post showed what was happening. When the Test-SPContentDatabase cmdlet runs, it’s looking for the first entry in the UserInfo table that matches the following rule:

  • tp_IsActive = 1 AND
  • tp_SiteAdmin = 1 AND
  • tp_Deleted = 0 AND
  • tp_Login not LIKE ‘I:%’

In our case, having an Active Directory Group assigned as a site collection administrator matched this set of rules exactly, therefore the query returned a result and hence the message was being displayed, even though the database was indeed configured for claims authentication rather than classic mode authentication.

For the organisation concerned, having an Active Directory domain configured as the site collection administrator for some of their site collections makes sense, so they’ll likely experience the same message next time they upgrade. Obviously in this case it was a false positive and could safely be ignored, and indeed attaching the databases that threw the error to a 2016 web application didn’t generate any issues.

Steps to reproduce:

  1. Create a new content database (to keep everything we’re going to test out of the way).
  2. Create a new site collection in the new database adding site collection administrators as normal.
  3. Add a domain group to the list of site collection administrators.
  4. Run the Test-SPContentDatabase cmdlet against the new database.

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>

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 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.