SharePoint Site Collection Administrators with PowerShell

Suppose you want to delete a user from Site Collection Administrator but not deal with the Owner and Secondary Owner properties business…

Mind you, even if you like to ignore ownership properties, there still needs to be at least one site collection administrator.

$site = Get-SPSite http://sharepointsite/sites/MySiteCollection
$RemoveThisGuyAccount = "DOMAIN\BadSiteAdmin"
$AllSiteAdmins = $site.RootWeb.SiteAdministrators
$RemoveThisGuy = $AllSiteAdmins | where {$_.UserLogin -eq $RemoveThisGuyAccount}
$RemoveThisGuy.IsSiteAdmin = $false
$RemoveThisGuy.Update()

New-SPTrustedRootAuthority New-SPTrustedServiceTokenIssuer The name exceeds the maximum allowed length

I received this error on a PowerShell script for cmdlets New-SPTrustedRootAuthority and New-SPTrustedServiceTokenIssuer

The name exceeds the maximum allowed length.
    + CategoryInfo          : InvalidData:(Microsoft.Share...viceTokenIssuer:SPCmdletNewTrustedServiceTokenIssuer) [New-SPTrustedServiceTokenIssuer], ArgumentException
    + FullyQualifiedErrorId : Microsoft.SharePoint.PowerShell.SPCmdletNewTrustedServiceTokenIssuer

This actually has nothing at all to do with lengths of anything, but is caused when the Service Token Issuer certificate is not paired with a Trusted Root Authority.

In a scripted environment build, the commands were similar to below (names changed to protect the innocent).

(On the Providing Farm)
New-SPTrustedRootAuthority $consumingRootCert -Certificate $trustCert
New-SPTrustedServiceTokenIssuer $consumingSTSCert -Certificate $stsCert

The commands use the first parameter as an identifier for SharePoint. The value of the parameter MUST be the same for the two certificates coming from the same environment. For example,

New-SPTrustedRootAuthority "ConsumingFarmCertificates" -Certificate $trustCert
New-SPTrustedServiceTokenIssuer "ConsumingFarmCertificates" -Certificate $stsCert

If anyone comes across this post as a result of meeting this error and can’t interpret my advice, let me know by posting a reply and I’ll see where I can improve the explanation.

SharePoint Enterprise Search – crawling Last Modified By

I was investigating why SharePoint search results were not including the refiner for Last Modified By when I came across this information.

SharePoint Enterprise Search requires certain settings in order to crawl data for Last Modified By and add to the search index.

Firstly you need a managed property – there is a default managed property called ModifiedBy but you can make your own if you wish. From the Enterprise Search Administration page, navigate to the Metadata Properties page.

The Metadata Properties page shows all managed properties for the Enterprise Search service application.

The managed property needs to be mapped to the crawled property “Office:8(Text)”. The crawled property needs to have ticked tickbox for “Include valies for this property in the search index”.

If anyone can tell me how Office:8(Text) happens to map to the “Last Modified By” attribute of an Office document, it would be much appreciated. In fact, a prize to go out to the first who can find TechNet documentation on what all the Office crawled properties are.

Finally don’t forget to run a crawl before seeing this in search results.

The PowerShell script equivalent of the above is as follows:

$searchApp = Get-SPEnterpriseSearchServiceApplication
$manangedProperty = Get-SPEnterpriseSearchMetadataManagedProperty -SearchApplication $searchApp -Identity "ModifiedBy"
$crawledProperty = Get-SPEnterpriseSearchMetadataCrawledProperty -SearchApplication $searchApp -Name "8" -Category "Office" -PropSet "f29f85e0-4ff9-1068-ab91-08002b27b3d9"
$crawledProperty.IsMappedToContents = $true
$crawledProperty.Update()
New-SPEnterpriseSearchMetadataMapping -SearchApplication $searchApp -ManagedProperty $managedProperty -CrawledProperty $crawledProperty

Suppress PowerShell output

I wanted to suppress the output of PowerShell on deploying a new SharePoint farm, particularly when executing Install-SPFeature -AllExistingFeatures

The simple solution was to pipe the output to the Out-Null object

Install-SPFeature -AllExistingFeatures | Out-Null

This SharePoint farm currently has pending upgrades using New-SPConfigurationDatabase

Scenario

Creating a new SharePoint 2010 farm with PowerShell cmdlet New-SPConfigurationDatabase on a virtual machine that contain SharePoint and Office Web Applications (OWA) binaries.

Error

New-SPConfigurationDatabase : This SharePoint farm currently has pending upgrades. The cmdlet New-SPConfigurationDatabase cannot be executed until the upgrade is completed.

Resolution

Execute PSConfig as below
psconfig -cmd upgrade -inplace b2b -wait –force

Explanation

The installation of the Office Web Application binaries sets certain registry entries that trick the system to believing the system is in the middle of an upgrade when running New-SPConfigurationDatabase.

Thanks to Maxime’s solution blog at http://blogs.msdn.com/b/maximeb/archive/2010/10/13/this-sharepoint-farm-has-pending-upgrades-error-when-running-new-spconfigurationdatabase-for-a-new-sharepoint-2010-installation.aspx

SharePoint Enterprise Search – scripted PowerShell build

In the PowerShell script build for SharePoint 2010, references to the different components (query servers, component servers, administration component) should NOT be FQDN.

I wonder if this means

• Enterprise Search is restricted to being scaled out within a single domain
• PowerShell scripted builds need to be executed in the context of the same domain as the servers

Set-SPEnterpriseSearchAdministrationComponent -SearchApplication $searchApp -SearchServiceInstance $serverName
New-SPEnterpriseSearchCrawlComponent -SearchApplication $searchApp -CrawlTopology $crawlTopology -SearchServiceInstance $serverName -CrawlDatabase $crawlDB
New-SPEnterpriseSearchQueryComponent -IndexPartition $partition -QueryTopology $queryTopology -SearchServiceInstance $serverName

POSTSCRIPT: I found that the URI for publishing farms also does not contain FQDN server names. That is, the publishing URL is
https://appServer:32844/Topology/topology.svc
and not
https://appServer.domain.net:32844/Topology/topology.svc

Managing User Profile Service Application Permissions in a Claims Based Authentication Environment With Powershell

The User Profile Service Application provides default permissions so that all NTLM authenticated users can create a personal site and use other features.

The script below removes the access to create personal site for All Authenticated Users. Credit to Aaron Saikovski for providing.

$upaproxy = Get-SPServiceApplicationProxy | Where-Object {$_.DisplayName -eq "User Profile Service Application Proxy"}
$upasecurity = Get-SPProfileServiceApplicationSecurity -ProfileServiceApplicationProxy $upaproxy
$authuser = New-SPClaimsPrincipal -Identity 'c:0(.s|true' -IdentityType EncodedClaim
Revoke-SPObjectSecurity -Identity $upasecurity -Principal $authuser -Rights "Create Personal Site"
Set-SPProfileServiceApplicationSecurity -Identity $upasecurity -ProfileServiceApplicationProxy $upaproxy