SharePoint 2007–Self-Healing?

I was at a client site dealing with a Custom List that used the Calendar View.

The Custom List also had a copy of NewForm.aspx called QuickAdd.aspx. There was no customization done to QuickAdd.aspx. The Supporting Files for the Custom List had been updated to set New Item form to QuickAdd.aspx.

In the Calendar view of this Custom List, clicking on any existing item within the Calendar lead to this QuickAdd.aspx?ID=n which in turn lead to NewForm.aspx?ID=n which did not display the item clicked on, but the default New Item form entry. Obviously not desired behavior.

The solution: Delete QuickAdd.aspx.

The self-healing nature of SharePoint allows it to correct the Supporting Files. Once QuickAdd.aspx was deleted, the Custom List Calendar view correctly registered DispForm.aspx as the Display Form.

Pretty neat trick!

Enable CollectSPRequestAllocationCallStacks with PowerShell

Every once in a while the ULS viewer will throw this error message:

An SPRequest object was reclaimed by the garbage collector instead of being explicitly freed.  To avoid wasting system resources, dispose of this object or its parent (such as an SPSite or SPWeb) as soon as you are done using it.  Allocation Id: {057C0995-CC5A-4652-B5A3-48B46A225269}  To determine where this object was allocated, set Microsoft.SharePoint.Administration.SPWebService.ContentService.CollectSPRequestAllocationCallStacks = true.

The following Powershell script will enable the CollectSPRequestAllocationCallStacks:

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
[System.Reflection.Assembly]::LoadFile($Env:CommonProgramFiles+"\Microsoft Shared\Web Server Extensions\14\ISAPI\Microsoft.SharePoint.dll") | out-null

# Get Content Service of the farm
$contentService = [Microsoft.SharePoint.Administration.SPWebService]::ContentService

# Display and change the setting of property "CollectSPRequestAllocationCallStacks"
write-host "Current: " $contentService.CollectSPRequestAllocationCallStacks
$contentService.CollectSPRequestAllocationCallStacks = $true

write-host " New: " $contentService.CollectSPRequestAllocationCallStacks

SharePoint 2010 – Change the Central Admin Port Number

I always try to standardize here I can to make my life easier.  When setting up SharePoint you can choose the port number for Central Admin.  I always suggest using the same port number whenever possible.  So what about when you’re working for a company that already has several SharePoint farms set up?

Our trust PowerShell once again comes to the rescue.  Using the Set-SPCentralAdministration cmdlet, you can change the port hosting your Central Administration web application.

Set-SPCentralAdministration –Port 7000

You can read more about the Set-SPCentralAdministration cmdlet here:

While I usually have my farms’ Central Admins bookmarked, sometimes when I’m on a remote computer I just want to type in the address and add the my standard central admin port.  Thanks to PowerShell I can quickly and easily remember my standard port without having to rely on bookmarks.

SharePoint 2010–Changing the FavIcon

The favicon, the icon that represents the website, is an important part of any page. Specifically in SharePoint, if this icon is left unchanged it leaves the default bright orange icon.
To maintain the branding of your webpage in your favicon, follow these steps.

  1. Upload your favicon file to your images library.
  2. Publish and Approve your icon through the SharePoint Publishing Workflows
  3. Open your master page in SharePoint Designer 2010.
  4. Find the <SharePoint:SPShortcutIcon> tag in the HTML header.
  5. Change the "IconUrl" tag to the relative URL of your favicon.
  6. Save and check-in your master page.
  7. Publish and Approve your master page through the SharePoint Publishing Workflows.

SharePoint 2010 – 503 Error, Service Unavailable After Successful Installation and System Reboot

Nothing is more frustrating than doing everything right and when the moment of payoff appears, getting some MSCryptic error message with no hint as to what the real issue may be.  During a recent setup of SharePoint 2010 I followed my usual script of installing the system and configuring everything using Central Admin.  It went without a hitch until the reboot of the WFE when IIS 7.5 returned a nice 503 error instead of what we were expecting.

The Event Logs and SharePoint logs were useless… Until I saw the Windows Process Activation Service (WAS) error.

Long story short, in some locked down domains where the admins go a little GPO crazy a domain group policy may override some of the permissions of the application pool accounts, specifically the “Log on as batch job” permissions.  The applicaion pool account needs to be allowed the log on as batch job policy, and the farm admin account and all other service accounts need to be allowed the “Log on as service” permissions.  So while the setup and initial running of SharePoint was great and everything appeared to be working, it was the server reboot that was the culprit as the first time after a reboot the policies are overwritten with the more restrictive domain policies.

The solution is to add the app pool accounts to the “Log on as batch job” and all the service accounts to the “Log on as service” domain policies and run a “gpupdate /force” to upgrade the policy on the WFE.  Just for good measure do another reboot and you should see SharePoint in all it’s glory humming along and ready for content.