Tuesday, December 20, 2016

SharePoint 2013: An unrecognized HTTP response was received when attempting to crawl this item

I got this error message:
The start address http://somesite cannot be crawled.
Context: Application 'Search_Service_Application', Catalog 'Portal_Content'
Details:
An unrecognized HTTP response was received when attempting to crawl this item. Verify whether the item can be accessed using your browser.   (0x80041204)
  
The start address https://somesite cannot be crawled.
Context: Application 'Search_Service_Application', Catalog 'Portal_Content'
Details:
Item not crawled due to one of the following reasons: Preventive crawl rule; Specified content source hops/depth exceeded; URL has query string parameter; Required protocol handler not found; Preventive robots directive. (0x80040d07)

After recreating the search and different changes to the content sources and the typical missing permissions, the customer basically got stuck with this broken search. After taking a look at the settings and the web.config I found this:
<httpProtocol>
<customHeaders>
<add name="X-Content-Type-Options" value="nosniff" />
<add name="X-MS-InvokeApp" value="1; RequireReadOnly" />
</customHeaders>
</httpProtocol>

What does this do?
1. <add name="X-Content-Type-Options" value="nosniff" />
Every file will bring a MIME type with it, which can differ from the specified MIME type. Internet Explorer can check the files, if the files should be handled different and choose a different application or handling of the file. But this will also lead to a security issue, for example: you upload a modified JPEG with a script included, this JPEG could possibly start to run the code if handled the wrong way. Basically the script will get detected and because the MIME type detected by IE is different from the specified MIME type, IE will start to run the script.

2. <add name="X-MS-InvokeApp" value="1; RequireReadOnly" />
With InvokeApp the Internet Explorer can start an application (like Office) and hand over the URL to the application. The file only open in a read only state with "RequireReadOnly" set in this line.

It is fine to remove those lines if you are not running an external website in your SharePoint environment. As soon as you allow anonymous access, you should put those lines back in. But those lines will also create some issues with the search. Removing them fixed my issues.

Saturday, October 22, 2016

Windows Container: Create local user on microsoft/nanoserver

Last time I showed you on how to download Windows Container images, this time we will work with one of the containers!
First of all download the microsoft/nanoserver image: docker pull microsoft/nanoserver
Now run the image: docker run -it microsoft/nanoserver cmd
The command "cmd" will open a cmd box on your container. To add users open Powershell by running powershell.exe in this container cmd windows.
And now we can add new users by using this command:
Finally add the user to the Administrators group:
For verification, run this script:

Friday, October 21, 2016

Windows Container: hard links not supported with legacy writer

I got this error
How to fix this?
1. Stop the Docker service with Stop-Service docker
2. Remove the local file of docker (f.ex. C:\Program Files\docker)
3. Download and unpack docker again:
Invoke-WebRequest "https://master.dockerproject.org/windows/amd64/docker-1.13.0-dev.zip" -OutFile "$env:TEMP\docker-1.13.0-dev.zip" -UseBasicParsing
4. Unpack the files again:
Expand-Archive -Path "$env:TEMP\docker-1.13.0-dev.zip" -DestinationPath $env:ProgramFiles
5. Start the docker service again with Start-Service docker

You should be able to download images again!

Wednesday, October 12, 2016

SharePoint: Move the Central Administration

This is an easy one:

Run the SP configuration wizard on the new server (DEV02W2K3) and recreate the Central Administration site.
1. Select "Do not disconnect from the configuration database"
2. Select "Advanced Settings"
3. Select "Use this machine to host the web site"
Finish the config wizard run and your are golden. Your CA should have been moved to a new server.

Tuesday, October 4, 2016

SharePoint 2013: Search Usage Analytics threw an exception

A customer showed me a couple of errors from his ULS log:
UsageAnalyticsTimerJob-12417730-3f25-49fb-846b-e40d49878aad : Usage Analytics has not completed successfully the last 1497 hours.
UsageAnalyticsTimerJob-12417730-3f25-49fb-846b-e40d49878aad : Previous execution of the analysis failed (consecutive failed runs: 6).
UsageAnalyticsTimerJob-12417730-3f25-49fb-846b-e40d49878aad : Search Analytics has not completed for 63 days. Last completed at: 08/02/2016 00:10:04.
UsageAnalyticsTimerJob-12417730-3f25-49fb-846b-e40d49878aad : Failed to start Usage Analysis.
The Execute method of job definition Microsoft.Office.Server.Search.Analytics.UsageAnalyticsJobDefinition (ID 1a74d33a-370e-4dae-a19c-d798e435495b) threw an exception. More information is included below. An update conflict has occurred, and you must re-try this action. The object UsageAnalyticsJobDefinition Name=Usage Analytics Timer Job for Search Application GUID was updated by Domain\User, in the OWSTIMER (xxxx) process, on machine SERVERNAME. View the tracing log for more information about the conflict.
Update conlfict? That's an easy one, right? Just run the Config Wizard. Right?
No. I tried running the Wizard and ran into this error:
Failed to provision the SharePoint Central Administration Web Application. An exception of type Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException was thrown. Additional exception information: An update conflict has occurred, and you must re-try this action. The object SPWebConfigFileChanges Name=WebConfigChanges - GUID was updated by Domain\User, in the powershell (xxxx) process, on machine SERVERNAME. View the tracing log for more information about the conflict. Microsoft.SharePoint.Administration.SPUpdatedConcurrencyException: An update conflict has occurred, and you must re-try this action. The object SPWebConfigFileChanges Name=WebConfigChanges - GUID was updated by Domain\User, in the powershell (xxxx) process, on machine SERVERNAME. View the tracing log for more information about the conflict.
Than maybe I could simply start the service manually and check on the Config Wizard later? Well, that didn't work either, same issues as before. So what was wrong? I was able to crawl and I was able to search for items, but analytics kept on bugging me.
Good ol' Windows was the cause of all this commotion. Something went wrong with the file system cache! I cleared the cache and the system started to work again, without those annoying errors.

1. Stop the SharePoint Timer Job on all the SharePoint Servers.
2. Go to this directory: %ALLUSERSPROFILE%\Microsoft\SharePoint\Config\
There can be multiple folders here, you will need the one with the Cache.ini file in it
3. Backup the Cache.ini
4. Remove all files except the Cache.ini
5. Open the Cache.ini and remove the content of that file
6. Start the SharePoint Timer Job again.

Please keep in mind, that you will have to do this on all SharePoint Servers. Ideally repeat those steps on every server while the Timer Job is deactivated.