To remove user from site collection use the following url.MembershipGroupId=0 will return all the users list.
Executed the following script and noticed the following error
The context has expired and can no longer be used.
#TokenTimeout value before
.TokenTimeout = (
#TokenTimeout value after
#WindowsTokenLifetime value before
.WindowsTokenLifetime = (
#WindowsTokenLifetime value after
#FormsTokenLifetime value before
.FormsTokenLifetime = (
#FormsTokenLifetime value after
#LogonTokenCacheExpirationWindow value before
#DO NOT SET LogonTokenCacheExpirationWindow LARGER THAN WindowsTokenLifetime
.LogonTokenCacheExpirationWindow = (
#LogonTokenCacheExpirationWindow value after
Script source – https://www.vioreliftode.com/index.php/active-directory-security-groups-and-sharepoint-claims-based-authentication
To fix this issue
run IISRESET on web front end server
Other possible causes could be
I tried to update the site logo of the SharePoint portal by updating the CSS file but it still cached the old CSS file. I tried appending version number to the CSS file but still it showed the old image.
I ran the following powershell script which ‘busted’ the JS and CSS cached file and updated with latest file.
$webApp = Get-SPWebApplication "<WebApplicationURL>" [Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp) Write-Host "Flushed the BLOB cache for:" $webApp
For some reason the blob cache was out of sync with content database and this script helped me to update the cache. It seems restoring the content database will cause BLOB sync issue as mentioned in Technet article.
When you search for text in people search… for example., a location the “People expertise search” result blocks is displayed at the top of search results followed people results… to deactivate this result block go to Site collection settings -> Search -> Query Rules.
From result source drop down select “Local People results”.
Select people expertise search and select “Make inactive” from the drop down.
I have a web application with 3 content databases and I tried to move site collection between database using the Move-SPSite and got the following error…
Move-SPSite : The databases need to be on the same database server in order to combine them.
To troubleshoot this issue, I ran the following command to check the database server name. This command lists all the content databases used by this webapplication.
Get-SPContentDatabase -webapplication http://portal.contoso.local
Id : 8f9611d3-0c46-477b-95ee-e0898f87e023
Name : SP_MySite
WebApplication : SPWebApplication Name=Portal
Server : SP_SQL
CurrentSiteCount : 230
Id : 05dffa47-4218-4387-bf74-0ad519df55d0
Name : SP_Portal
WebApplication : SPWebApplication Name=Portal
Server : TSTDB
CurrentSiteCount : 201
It seems the issue mentioned above is caused by value in the Server field. One database is using alias name “SP_SQL” and another database is using the database server name. The Move-SPSite command thinks its two different database server…
Any fix for this issue ???
To resolve this issue I removed the content database that uses server name instead of alias name via central admin. Then I ran the following command to attach the database with alias name.
Mount-SPContentDatabase SP_Portal -DatabaseServer SP_SQL -WebApplication http://portal.contoso.local
Another important thing to notice is if I add the content database via central admin instead of PowerShell script and browse the site you get “web page not found” error… so it’s recommended to use PowerShell.
It’s also a good practice to flush blob cache after restoring the content database. From Technet,
after you restore a content database, the BLOB cache will be out of sync with the content. To correct that situation, you must flush the BLOB cache
$webApp = Get-SPWebApplication “<WebApplicationURL>” [Microsoft.SharePoint.Publishing.PublishingCache]::FlushBlobCache($webApp) Write-Host “Flushed the BLOB cache for:” $webApp
The SharePoint 2013 Search crawl log had the following error for word documents. It turns out that if the word document is empty then Search logs this error in crawl log.
SharePoint returned an empty response
I got the following error when I try to crawl the content using the default zone (in content sources – Local SharePoint Sites)
The URL of the item could not be resolved. The repository might be unavailable, or the crawler proxy settings are not configured. To configure the crawler proxy settings, use Search Administration page
The AAM is configured as below
default zone : http://portal.contoso.local
Intranet zone : http://portal
In the search administration -> content sources “Local SharePoint sites” the start address was configured with url http:portal and sps3:http://portal… yuck…
As per the article references below it’s always best practice to crawl the default zone. I noticed the following issues if search content sources is not configured to use default zone.
- “Search this site” will return empty results
- Document library in-place search (find a file) will return empty results
- Usage report (popularity trends) will return zero views
When I changed the content sources to use the default zone I noticed the above mentioned error. The full crawl finished in < 20 seconds. When I referred the crawl log the above error was logged.
To fix this issue add
IP Address of the Web front end in hosts file in (all) application servers.