I’ve been working on a large SharePoint 2010 rollout and learning quite a bit about managing the farm using PowerShell. I’ve never been much of a console junkie – we have _Graphical_ User Interfaces for a reason, right? But, it’s always good to have an extra tool in the belt, so when one of my Web Front Ends was refusing to serve up a site, and the SharePoint log was being less than helpful, I came up with some PS to compare it to a working server and was able to fix my problem.
The error I was seeing was that a certain site returned a ‘404 file not found’ error browsing to the root of one of the sites, but only from one web front-end. By putting an entry in my host file and trying the 3 web front-ends, I isolated the server. Looking in the logs, even with verbose logging, only revealed an ‘Unknown SPRequest error occurred’.
The next step, then, was to compare the failing server with a working one. If you aren’t familiar with SharePoint’s architecture – it manages copying supporting files between multiple servers for failover, scale, and redundancy. If you aren’t familiar with SharePoint’s headaches, that process is apparently harder than it sounds, and occasionally, files will be missing from servers. The end result is that requests that hit one server may fail, while requests to another succeed.
I’m sure there are utilities I could have used to do this, but after a little sleuthing, I came up with the following PowerShell to compare the default sharepoint folders on the two servers:
$prod01 = dir 'C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14' -recurse | ?{$_.mode -match "d"}
$prod02 = dir '\\spprod02\c$\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14' -recurse | ?{$_.mode -match "d"}
Compare-Object $prod01 $prod02
This stores the directory listing, containing only folders, of one server in one variable, and of the second server in another variable. Compare-Object then compares the two, and spits out the results. In my case- a feature that had failed to deploy to the second server. Redeploying fixed the issue, and immediately the ‘404 file not found’ error went away.
