SharePoint Configuration Errors: Where to Find Them and How to Fix Them
If you work with Microsoft SharePoint, you’ve likely come across the following error screen at some point in your career:
The error message is not particularly descriptive and in this example, I’ve only been given insight that a file is missing. If a client sends in a screenshot like this, it’s really not enough information for me to take action. So, I recommend asking the client to recreate the issue and this time to click on the ‘Technical Details’ link before taking the screenshot:
The important information under ‘Technical Details’ is the time of the error and the Correlation ID. Take note of both pieces of information, then log onto the server.
Now that you’ve logged onto the server, open the SharePoint 2013 Management Shell (this is PowerShell with the SharePoint Cmdlets loaded) and run the Merge-SPLogFile Cmdlet (https://technet.microsoft.com/en-CA/library/ff607721.aspx):
Merge-SPLogFile -Correlation “579c8c9d-da45-0078-a71b-cfacae7f593c” -path c:\error.txt
Once it is finished running, you will see an error.txt file on your C drive that contains all of the log entries related to this error. The file pulls from each server in the SharePoint farm, so there is no need to log into each server to look for more error messages. Additionally, there are a number of other options to use for narrowing down which logs are returned, including:
- Time frame
- Category / Area
- It doesn’t matter where your log files are stored, the Cmdlet handles that for you.
- If you didn’t log it, this Cmdlet won’t find it. Based on the severity of the error, you may need to temporarily increase the verbosity of the logging. Make sure your log settings are not left at high levels as this may affect performance. Logging is set up by going to central admin > monitoring > configure diagnostic logging.
- If you get the error “The term “Merge-SPLogFile is not recognized as the name of a cmdlet, function, script file, etc.…” you’ve probably forgot to load the SharePoint Cmdlets. Either load them manually or open the SharePoint 2013 Management Shell from the start menu.
- If you get an error screen and your Correlation Id is all zeros, look for the error in the Event Viewer.
When looking at the log file you’ve created for your error there could be a LOT of information that doesn’t make sense or seem to relate to the issue you’re seeing. Here is my advice when looking through these files:
- Look for lines that have a level of “unexpected”. The first “unexpected” line of logging usually contains the error message that is most relevant.
- If the unexpected error doesn’t make sense, try scrolling up, there may have been an error earlier in the page request processing that caused the unexpected error.
- Ignore these: “[Forced due to logging gap”
- Don’t forget to look to the “Category” column for clues
- Search for any details in the “Message” column that you don’t understand
- For this example, here’s mine:
Category – Runtime
Level – Unexpected
Message – System.IO.FileNotFoundException: The Web application at https://test.mydomain.com could not be found. Verify that you have typed the URL correctly. If the URL should be serving existing content, the system administrator may need to add a new request URL mapping to …
Ah ha! It couldn’t find my web application. I forgot that I had removed it previously, and so it turns out I wasn’t a missing file at all!
If you have been looking at Power BI, or are in the process of implementing it, one of the things you have undoubtedly questioned is whether you can surface your on-premise data in Power BI. The answer is that you can, and in this blog post, I’m going to walk through how that is done within the context of Power BI.
As consultants, we get opportunities to work with a variety of clients in different industries. We’re often advising and helping with new ideas and technology and it’s critical that we are up to date and aware of industry trends. Read more
To recap: The prerequisites install fine, SharePoint Setup runs, and then seemingly at the last step, it fails with:
osiserver.msi: “SharePoint Server 2013 encountered an error during setup”, Error Code 1603
Unsatisfied with the workarounds (read MSIBreak or the ORCA tool or changing the number of processors), and after having updated Windows with the latest patches, I called Microsoft and worked for weeks with their engineers at diagnosing the root issue of the problem, which for us was:
The SharePoint ArpWrite action (registering SharePoint 2013 as installed in the registry) attempted to access a missing registry key at HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer
So to resolve this, we wrote the following PowerShell script (run as Administrator):
New-Item -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer | Out-Null
$regProps = Get-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer
New-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer -Name logging -Value voicewarmup -PropertyType String | Out-Null
New-ItemProperty -Path HKLM:\SOFTWARE\Policies\Microsoft\Windows\Installer -Name debug -Value 3 -PropertyType DWord | Out-Null
And much to our shock, the installation succeeded!
Hopefully, this article can help anyone else out there with this problem until Microsoft publishes a fix or an updated installer.