Issue / Symptoms
Fuzzy / phonetic name searching is not working in people search in SharePoint 2013. For example, if you search for my name as “myree” (which is how it sounds), you would not get my profile as a result.
Here is a good reference on finding if your farm is having this issue (however the fix suggested is no longer the recommended solution): https://blogs.msdn.microsoft.com/ronalg/2015/02/25/sharepoint-2013-fuzzy-and-phonetic-people-search-dont-appear-to-be-working/
How to Reproduce the Issue
- Turn up logging level by running the following command (do this on non-prod or off hours)
- Open ULS log viewer and create a filter on “EN_EN.mdl” OR “fuzzy”
- Browse to the people search page and enter a name
- You will see entries similar to the following if your farm has this problem
On Query Server:
10/25/2016 13:07:45.13 NodeRunnerQuery2-936ea3ce-afa6- (0x0C0C) 0x270C Search Fuzzy Name Search ajyfa Unexpected CCANameProjector : Exception:Exception : Access to the path ‘E:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\CanonicalResources\ProjectionModels\EN_EN.mdl’ is denied. encountered while attempting to load the Projection Model Catalog E:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\CanonicalResources\ProjectionModels\EN_EN.mdl for Language : en encountered while attempting to load the projection model. 3af3b09d-aa93-906f-2913-467b8e5e0f93
On Crawl Server:
CCANameProjector : Exception:Exception : Access to the path ‘E:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\CanonicalResources\ProjectionModels\EN_EN.mdl’ is denied. encountered while attempting to load the Projection Model Catalog E:\Program Files\Microsoft Office Servers\15.0\Data\Office Server\CanonicalResources\ProjectionModels\EN_EN.mdl for Language : en encountered while attempting to load the projection model.
CCAMetadataProducer : Fuzzy metadata generation failed to load resource for language: en.
CCAMetadataProducer : Fuzzy metadata generation failed for the current record. Check logs for more details.
- Remember to turn log levels back down!
If you watch the search index directory using procmon while running searches or profile crawls, you will see the access denied messages.
This is a known bug in SharePoint 2013. It has been there since RTM. The good news is that it is finally fixed in the July 2016 CU for SharePoint 2013. This happens in scenarios when you run in the recommended way of having a separate service account (domain account) for the service service. Under this condition, the service account does not have the permissions that the code requires. The fix in the July CU changes the code so that read only access is all that is required on the search index directory.
Upgrade your farm to at least the July 2016 CU. Once this fix has been applied, you will likely need to wait 1 day for all of the indexing / processing to take place before fuzzy / phonetic searches start working.
After waiting a day, test this out using the SharePoint Search Query Tool. Make sure you have nicknames and Phonetic enabled as shown below:
If you can’t upgrade your farm for whatever reason, a temporary workaround would be to add your search service account to WSS_ADMIN_WPG local security group. This change would require a reboot (or a service restart).
After running a web test, you see an error such as this:
Could not read result repository: Unknown transaction id in results: XX.
Will display the runtime result instead of the repository result.
You also get a similar error when you try to load historical results from the “Open and Managed Load Test Results” screen. In my case, I am running Visual Studio 2015 with Update 3. The controller and agents are 2013 with update 5.
Solution / Workaround
In this case, the workaround is to update your load test “Run Settings” to include a “Cool-down Duration”. This can set by:
- Open the load test file
- Click on the run settings section (the active one)
- In the properties window, set the “Cool-down Duration” to at least 1 minute:
We have some really long running queries in our SSRS SharePoint integrated mode environment. After a few minutes of processing, we would see the following error:
Sys.WebForms.PageRequestManagerServerErrorException: An unknown error occurred while processing the request on the server. The status code returned from the server was: 12019
Interestingly, this issue only occurs when using IE. In Chrome, the report keeps running and works fine.
In our environment, we have an F5 BigIP as the load balancer in front of SharePoint. All we needed to do was set the Idle Timeout to 3600 (default was 300) on the TCP profile for the virtual server.
In other load balancing solutions, there are likely similar settings.
A bug in the .net framework causes SQL Server Reporting Services (SSRS) reports to “lose” their parameter values when paging through the report when to stay on a page for longer than 1 minute.
When you click the next page button, you will be presented with the parameter prompt again:
- You have a multi-page report in SSRS in SharePoint that includes required parameters
- If you sit on a page of the report for more than 1 minute, you are re-prompted for parameter values and must re-run the report
This is a known problem in the .NET framework. Please reference the following KB: https://support.microsoft.com/en-us/kb/2996566
MSFT does not have the download link published, so you will need to contact support to be sent the hotfix. As of this writing, this hotfix has not been included in any public patches or updates.
I came across this issue while running SQL Server Reporting Services 2014 (SSRS) in SharePoint integrated mode in SharePoint 2013. As part of the SSRS integrated mode installation, you get a feature that enables a library template called “Report Document Library”. If you use this template, you are unable to create folders using the web interface. Using the “New Folder” option in the web interface results in the following error:
The aspx_debug attribute on the page directive is not allowed in this page.
The “Report Document Library” feature has been deprecated and should not be used. This library template comes from these feature files:
\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES\ReportsAndDataListTemplates\ReportDocumentLibrary
The SharePoint group removed this from the product in SharePoint 2013, but it gets added back in when you install SSRS integrated mode.
So, when creating libraries, stay away from both of these:
This recommendation is confirmed through Microsoft support.
Use the standard “Document Library” template to create your libraries for SSRS reports. Once you have the document library, simply add the needed SSRS content types to the library to enable all of the same functionality.
- Browse to the library settings page
- Click on Advanced Settings. Then enable Allow management of content types
- Back to the library settings page, then add the SSRS content types as needed
- The SSRS content types are in the group called “SQL Server Reporting Services Content Types”
If you already have report document libraries setup, the best way (without a 3rd party migration tool) to move these into a regular document library is to:
- Rename the path of the existing library using SharePoint Designer 2013 (e.g. LibraryName_OLD)
- Create the new library using the “Document Library” template using the original name so that user’s links don’t break, then enable the SSRS content types as shown above
- Move the existing content into the new library using the Content and Structure feature (Gear -> Site Settings -> Content and Structure). NOTE: If you do this, you will need to reconfigure any shared data connections settings on the reports!!
Alternatively, if you have a library already setup and you can’t migrate to a standard document library, you can create new folders using Windows Explorer:
- Browse to the library
- On the library tab, click Open with Explorer
- Create folder as needed in Windows Explorer
I ran into an issue where in one of my site collections, I was no longer able to change the composed look or “Change the Look” in SharePoint 2013. After selecting a composed look, the following error would be presented:
Cannot complete this action. Please try again.
The ULS logs did not contain much useful information either:
08/14/2015 08:09:13.47 w3wp.exe (0x15E8) 0x3118 SharePoint Foundation General 8kh7 High Cannot complete this action. Please try again. 0ee8239d-e4c1-9060-8a21-d1416cc5bdef
08/14/2015 08:09:13.47 w3wp.exe (0x15E8) 0x3118 SharePoint Foundation General ai1wu Medium System.Runtime.InteropServices.COMException: Cannot complete this action. Please try again., StackTrace: at Microsoft.SharePoint.SPWeb.InitWebPublic() at Microsoft.SharePoint.SPWeb.get_AlternateUILcids() at …
Because I has some strange issues trying to restore a web from the recycle bin earlier in the day, I decided to check to see if there were any orphan items in the content database. Sure enough, there was an orphaned web and that was causing the “Change the Look” issue throughout the site collection.
The first step is to check to see if this applies in your environment.
- Get the content database name
Get-SPSite <SiteCollectionURL> | FL *Database*
- Check for orphaned items
$ContentDB = Get-SPContentDatabase <ContentDBNameFromStepAbove>
The above method will output XML that contains each of the orphaned items in the content database.
If you do have orphaned items, take a full backup of your SQL database. Then proceed with the following:
- Run the Repair method against the content database
- Confirm there are no longer any orphaned items by reviewing the XML output from the prior step
- Try to apply the composed look to one of the webs in the site collection
Here is the MSDN page that outlines the repair method.
I created a simple SharePoint Designer 2013 workflow. The workflow only has a couple activities – sending and email and copying the document to another library. When the workflow reached the copy document step, it would constantly pause and you would see and error such as the following on the workflow status page:
Activity in progress
Retrying last request. Next attempt scheduled in less than one minute. Details of last request: HTTP BadRequest to https://myserver.fqdn/sites/teamsite/_vti_bin/client.svc/web/getfilebyserverrelativeurl(‘/sites/teamsite/FormLibraryName/FormInstanceName_2015_06_01_12_00_00.xml’)/CopyTo(strNewUrl=’/sites/teamsite/SecondLibraryName/FormInstanceName_2015_06_01_12_00_00.xml’,%20bOverWrite=’false’) Correlation Id: 62600f9d-24c3-9060-8a21-d4689f426f96 Instance Id: 11915cf9-2e82-49ae-ae04-3e93dcef731c
The reason that this happens is that the URL that is being requested to get data via the client API (client.csv) is longer than the default IIS setting of 260 characters. The part that is in bold above is the request that the workflow is making, which in this case is 281 characters. Microsoft should update the default settings in IIS for the ISAPI virtual directory, but lucky for us, they don’t.
Update the web.config file in the ISAPI virtual directory on each of your SharePoint servers:
C:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\ISAPI\web.config
<httpRuntime maxUrlLength=”4096″ />
Here is what it should look like:
By putting this in the ISAPI virtual directory’s web.config, the change will apply to all SharePoint web applications. You could put this in the web application’s web.config, but that is a lot of extra work. It would also then make the max URL length change for all pages in the web app, not just the ISAPI services.