Today something nice what can happen if you don't pay enough attention on that, what you are doing.
For the object cache we updated the superreader and superuser in one of our web applications. First we added the policies for the web application.
Secondly we executed the necessary PowerShell script for updating the properties for that specific web application.
BUT we had a typo in the username we did not recognise and suddenly our web shows the error message:
SORRY, SOMETHING WENT WRONG (indeed!)
English: The specified user or domain group was not found.
German: Der angegebene Benutzer oder die angegebene Domänengruppe wurde nicht gefunden
You can see that SharePoint is loading some parts of the masterpage and then suddenly this error occurs.
On new created site collections it does not occur until you activate the publishing features. If you disable the publishing features, this error remains.
The error message (if I would read this more cautious) indicates the origin of the error (marked bold and underlined):
xx/xx/2014 12:14:37.07 w3wp.exe (0x2264) 0x2378 SharePoint Foundation General 8sl1 High DelegateControl: Exception thrown while adding control 'Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapDataSource': Microsoft.SharePoint.SPException: Der angegebene Benutzer oder die angegebene Domänengruppe wurde nicht gefunden. ---> System.Security.Principal.IdentityNotMappedException: Some or all identity references could not be translated.
at System.Security.Principal.NTAccount.Translate(IdentityReferenceCollection sourceAccounts, Type targetType, Boolean forceSuccess)
at System.Security.Principal.NTAccount.Translate(Type targetType)
at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKeyClaim(IClaimsIdentity claimsIdentity, SPClaim loginClaim) --- End of inner exception stack trace ---
at Microsoft.SharePoint.AdministrationClaims.SPClaimProviderManager.GetProviderUserKeyClaim(IClaimsIdentity claimsIdentity, SPClaim loginClaim)
at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(IClaimsIdentity claimsIdentity, String encodedIdentityClaimSuffix)
at Microsoft.SharePoint.Administration.Claims.SPClaimProviderManager.GetProviderUserKey(String encodedIdentityClaimSuffix)
at Microsoft.SharePoint.Utilities.SPUtility.GetFullUserKeyFromFullName(String fullName)
at Microsoft.SharePoint.SPGlobal.CreateSPRequestAndSetIdentity(SPSite site, String name, Boolean bNotGlobalAdminCode, String strUrl, Boolean bNotAddToContext, Byte[] UserToken, SPAppPrincipalToken appPrincipalToken, String userName, Boolean bIgnoreTokenTimeout, Boolean bAsAnonymous)
at Microsoft.SharePointSPSite.get_Request()
at Microsoft.SharePoint.SPSite.OpenWeb(Guid gWebId, Int32 mondoHint)
at Microsoft.SharePoint.Publishing.CachedObjectFactory.OpenWebFromSuperUserSite(Guid webId)
at Microsoft.SharePoint.Publishing.CacheManager..ctor(SPSite site)
at Microsoft.SharePoint.Publishing.CacheManager.GetManager(SPSite site, Boolean useContextSite, Boolean allowContextSiteOptimization, Boolean refreshIfNoContext)
at Microsoft.SharePoint.Publishing.CachedAreaLookup.EnsureLookup(Boolean errorsAsExceptions)
at Microsoft.SharePoint.Publishing.CachedAreaLookup.GetCachedAreaOrException()
at Microsoft.SharePoint.Publishing.Navigation.TaxonomyNavigationCache.GetCachedWebInfo(CachedAreaLookup cachedAreaLookup)
at Microsoft.SharePoint.Publishing.Navigation.TaxonomyNavigationCache.GetWebNavigationSettings(CachedAreaLookup cachedArea, CachedAreaLookup& parentCachedArea, Exception& loadError)
at Microsoft.SharePoint.Publishing.Navigation.TaxonomyNavigation.GetEffectiveProviderSettingsList(CachedAreaLookup cachedArea, Boolean includeInheritedSettings)
at Microsoft.SharePoint.Publishing.Navigation.TaxonomyNavigation.GetEffectiveProviderSettings[T](CachedAreaLookup cachedArea, String siteMapProviderName, Boolean includeInheritedSettings, CachedAreaLookup& cachedAreaWithSettings)
at Microsoft.SharePoint.Publishing.Navigation.TaxonomyNavigation.GetEffectiveProviderSettings[T](SPWeb web, String siteMapProviderName, Boolean includeInheritedSettings)
at Microsoft.SharePoint.Publishing.Navigation.SwitchableSiteMapProvider.GetCurrentWrappedProvider() at Microsoft.SharePoint.Publishing.Navigation.SwitchableSiteMapProvider.get_RootNode()
at Microsoft.SharePoint.Publishing.Navigation.SwitchableDataSourceBehavior.AssignProperties(SiteMapProvider targetProvider)
at Microsoft.SharePoint.Publishing.Navigation.PortalSiteMapDataSource.OnInit(EventArgs e)
at System.Web.UI.Control.InitRecursive(Control namingContainer)
at System.Web.UI.Control.AddedControl(Control control, Int32 index)
at Microsoft.SharePoint.WebControls.DelegateControl.AddControlResilient(Control ctl) a2dcc69c-9d3f-d090-1565-39d609448356
After updating the web application with the correct superuser / superreader, everything works fine. Took some time to figure this out :)
Freitag, 31. Oktober 2014
Donnerstag, 2. Oktober 2014
Show all users of a site collection
If you want to see all users which are assigned to any SharePoint group then just go to "Site Settings" and "Group and People" and modify the URL in your browser,
It shows:
/_layouts/15/people.aspx?MembershipGroupId=7
change it to:
/_layouts/15/people.aspx?MembershipGroupId=0
Voila!
It shows:
/_layouts/15/people.aspx?MembershipGroupId=7
change it to:
/_layouts/15/people.aspx?MembershipGroupId=0
Voila!
Useful SharePoint links // and other stuff ... September 2014
Here are my current links I found in September 2014 and used somehow or are very interesting.
September 2014
The rest of my favorite links are here.
Mittwoch, 1. Oktober 2014
Unexpected behaviour of image search in SharePoint 2013
My customer has an environment with SPS2013 SP1, multiple Application Server and WFE.
We enabled search for images in image and document libraries.
Although we added the file extensions for images in search, did an IISRESET and reset of search services we had the issue hat every item in these libraries were identified as ASPX pages. After a look in the crawl logs we saw that every item was crawled by the display form and not as an image itself.
With a query tool we found out that for STS_ListItem_PictureLibrary, STS_ListItem_851 and STS_ListItem_DocumentLibrary the FileExtension was set to ASPX, FileType was empty and SecondaryFileExtension was jpg, png, gif.
We changed the managed property SecondaryFileExtension that it is searchable now.
We changed the custom refinement control (see previous post) and enhanced the template for mapping SecondayFileExtensions to FileTypes.
We changed Site Collection Result Types in Searchcenter Site Collection to point every content of our sources with SecondaryFileExtension jpg, png, gif to the Picture_Item Display Template.
Suddenly images were available including an image preview also in the hover window (again, have a look at the previous post, how to change the display templates for search items to reach this).
And suddenly again it was gone.
Weird, we found out, if you are doing a reindex on a library and starting an incremental or even full crawl, every item in this library will be crawled by the display form. If you are doing again (in our case) a full crawl, then suddenly images are crawled as images with their fileextension jpg, png, gif and everything works again.
Maybe an issue in SP1, can't imagine that this is a wanted feature. Weird!
Thanks to our technical staff and the many advices I got :)
Link to my previous post: http://sharepoint1080.blogspot.de/2014/09/problem-with-images-in-sharepoint-2013.html
Remarks:
I forgot to mention that also it seems to be a good idea, if images always have a title. Sometimes I had the feeling without a proper title the search result behaviour differs.
We enabled search for images in image and document libraries.
Although we added the file extensions for images in search, did an IISRESET and reset of search services we had the issue hat every item in these libraries were identified as ASPX pages. After a look in the crawl logs we saw that every item was crawled by the display form and not as an image itself.
With a query tool we found out that for STS_ListItem_PictureLibrary, STS_ListItem_851 and STS_ListItem_DocumentLibrary the FileExtension was set to ASPX, FileType was empty and SecondaryFileExtension was jpg, png, gif.
We changed the managed property SecondaryFileExtension that it is searchable now.
We changed the custom refinement control (see previous post) and enhanced the template for mapping SecondayFileExtensions to FileTypes.
We changed Site Collection Result Types in Searchcenter Site Collection to point every content of our sources with SecondaryFileExtension jpg, png, gif to the Picture_Item Display Template.
Suddenly images were available including an image preview also in the hover window (again, have a look at the previous post, how to change the display templates for search items to reach this).
And suddenly again it was gone.
Weird, we found out, if you are doing a reindex on a library and starting an incremental or even full crawl, every item in this library will be crawled by the display form. If you are doing again (in our case) a full crawl, then suddenly images are crawled as images with their fileextension jpg, png, gif and everything works again.
Maybe an issue in SP1, can't imagine that this is a wanted feature. Weird!
Thanks to our technical staff and the many advices I got :)
Link to my previous post: http://sharepoint1080.blogspot.de/2014/09/problem-with-images-in-sharepoint-2013.html
Remarks:
I forgot to mention that also it seems to be a good idea, if images always have a title. Sometimes I had the feeling without a proper title the search result behaviour differs.
Abonnieren
Posts (Atom)