SharePoint 2010/Server 2012 R2: Config Wizard Fails with Error “Value Does Not Fall Within The Expected Range”

Ran into an interesting installation error – SharePoint was failing to create the Configuration Database..or so it appeared. Running New-SPConfigurationDatabase and running the SharePoint Products Configuration Wizard were both failing with the error “Value does not fall within expected range.” We were able to track down this issue in the ULS Logs and noticed all sorts of IIS-related errors:

Creating new application pool ‘SecurityTokenServiceApplicationPool’.

Adding DOMAIN\spfarmacct to local group IIS_WPG.

Adding DOMAIN\spfarmacct to local group WSS_WPG.

Adding DOMAIN\spfarmacct to local group PerformanceMonitorUsers.

Attempting to give SE_ASSIGNPRIMARYTOKEN_NAME privilege to application pool user DOMAIN\spfarmacct

Attempting to give SE_INCREASE_QUOTA_NAME privilege to application pool user DOMAIN\spfarmacct

An exception occurred while committing IIS configuration changes: Value does not fall within the expected range.

Unable to unprovision metabase object IIS://localhost/w3svc/AppPools/SharePoint Central Administration v4: System.Runtime.InteropServices.COMException (0x80070003): The system cannot find the path specified.

at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)

at System.DirectoryServices.DirectoryEntry.Bind()

at System.DirectoryServices.DirectoryEntry.get_AdsObject()

at System.DirectoryServices.DirectoryEntry.DeleteTree()

at Microsoft.SharePoint.Administration.SPMetabaseObject.Unprovision()

Removing the Web Server (IIS) Role Service and letting the prerequisite installer configure IIS was the ticket to get “past” the SharePoint Products Configuration Wizard. It looked like something was up with the client’s Windows Server 2012 R2 image which caused IIS to get a little out of whack. Some other items to watch out for in this configuration (SP10/Svr 2012 R2):

image

SharePoint 2010 – Office Web Apps Cache Expiration

I was doing some browsing around a SharePoitn 2010/Office Web Apps-Enabled farm the other day and noticed something interesting that I thought I’d share. By default when you setup Office Web Apps in SharePoint 2010 the cache expiration does not get set in the web app’s property bag.

I started by checking the web app cache URL’s propery bag items. As you can see there is nothing related to cache expiration:

After this I went ahead and set the max size/cache expiration for the Office Web Apps cache URL and then checked the property bag items:

Notice the waccacheexpirationperiod entry now!

 

-AJB

KB2775511 – Blowing up my Usage Data Import Timer Job

This issue is described here: http://support.microsoft.com/kb/2916922 

This patch (along with  KB2682011 or KB2882822) could cause the Usage Data Import timer job to not import the .Usage files into the Usage Logging Database. When this timer job runs you will notice the following in the ULS logs:

OWSTIMER.EXE (0x51A0) 0x59E4 SharePoint Foundation Usage Infrastructure a5rv High Failed to delete usage log file ‘E:\Logs\ServerName-20130701-2117.usage’ after data import. Exception: System.IO.IOException: The process cannot access the file because it is being used by another process. at System.IO.__Error.WinIOError(Int32 errorCode, String maybeFullPath) at System.IO.FileInfo.MoveTo(String destFileName) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.MoveFileOrDirectory(FileSystemInfo fi, String newPath) at Microsoft.SharePoint.Administration.SPProvisioningAssistant.DeleteFileOrDirectory(FileSystemInfo fi) at Microsoft.SharePoint.Administration.SPUsageLogImporter.ImportUsageLogFiles(List`1 usageLogFileList)

This causes a few unwanted side effects: The usage logs will grow as they are not getting imported and purged and this timer job will take a looong time to run and can cause your timer service recycle timer job to fail. I was manually restarting the timer service each day for a while, but we ended up uninstalling the patch as a longer term solution. This issue is fixed in the December 2013 CU, but that was not an option in this case.

This is why I always recommend you have a test environment…This was caught before it got pushed to PROD!

-AJB

SharePoint 2010 Service Pack 2 – Server 2012 Support

Short and sweet here. If you want to install SharePoint 2010 on a Server 2012 machine you need to go to MSDN and grab the updated ISO. This new ISO file has updated installers (prerequisites included) that now support Windows Server 2012. A slipstreamed install with previous releases will not work like you want it to. If you do not grab the new ISO and you want SharePoint 2010 on a Server 2012 machine take a look at the steps needed to get that done: http://sharepoint.nauplius.net/2012/06/installing-sharepoint-2010-and-sql-server-2012-on-windows-server-2012-release-preview/. This is a great post by Trevor Seward, but I’d definitely rather just have it work out of the box.

-AJB

Using Fiddler2 as a proxy for SharePoint Search

I was looking for a way to troubleshoot search crawl errors a little bit better and figured why not use a tool I already use daily…Fiddler! Here is a quick guide on how to use Fiddler2 as a search proxy so you can see what is happening when the user agent is crawling the content.

  1. Login to the appropriate SharePoint 2010 Application Server where Fiddler is installed
  2. Run Fiddler2 as the SharePoint 2010 default content access account
  3. Minimize the Fiddler2 window and browse to http://localhost:8888
  4. You should see a screen similar to this:
  5. Fiddler Echo Service
  6. Login to central admin
  7. Go to Application management > Manage Service Applications > Search Service Application
  8. Click on None next to Proxy Server: Select “use the proxy server specified” and type http://localhost for Address and 8888 for port.
  9. Click OK
  10. Now run a full crawl on the content source in question. The crawl results will appear in the Fiddler2 window on the server.

Now watch for any errors…especially those pesky red 500 errors!