Don’t mix up your HTML and ASPX comments, and keep your code clean

At a client recently I came across a strange problem with a 2007 page layout not working under SharePoint 2010. My troubleshooting uncovered many issues in the environment (with content types and page layout properties), but the root cause of the problem was a bug caused by the misuse of comments.

The page layout had been modified since it’s first draft. The person revising the page had commented out some sections. This is common practice when developing. Even with source control, it is often easier to comment and uncomment sections in place of rolling back an entire file. And it is sometimes useful to have a visual reference of the original  part while working on the changes.

The main problem was that the coder used the wrong type of comment. He (yes, it was a he:) used an HTML comment

<!–    –>

to enclose SharePoint controls. While HTML comments will keep browsers from rendering content, it doesn’t prevent SharePoint from rendering the control, and generating the HTML markup that would go inside the HTML comment markers. This wastes a small amount of server processing and network every time the page is called.

On top of this, Since SharePoint was aware of this control on the page, it adjusted it’s behavior in other ways, which, when combined with the fact that the output of the control was not being rendered by the browser, caused the page to break. The original editor was lucky, since this issue was not exposed in 2007, only 2010.

The correct way to comment part of an ASPX file is

<%–    –%>

Note the percent sign is in the trailing section too. This comment prevents SharePoint from rendering the control, and makes it effectively invisible, not only to the client, but to the server as well.

But in the end this comment should not have been left in the code. After debugging is complete, these remnants of code should be completely removed from the source before being used in production. A source code repository should be used if reference to old code is desired. Comments should only be used to help describe interesting or complex pieces of code, but not to “hide” unused code.

SharePoint Branding Article

I have authored an article on SharePoint branding which has recently been published in Coyote Creek’s October 2011 Newsletter. Check out my article and Mike Faster’s poignant take on off-shoring.

The SharePoint article is based on my experience including recent projects at Silicon Image Inc., Rosendin Electric Inc., and Trimble Navigation Limited. I would like to thank Coyote Creek Consulting for providing me with the opportunities and for allowing me to contribute to their newsletter.

Managing SharePoint 2010 Access Request Settings Via PowerShell

SharePoint has a built-in mechanism to manage access requests. Users can request access to sites and documents when they are denied access, or they can request additional privileges to update content if they only have read access.

The requests go to one or more email addresses which are defined at the site level. The definitions follow inheritance, meaning that if a child site inherits its parent’s permissions, the child site will inherit the access request settings as well. The property to check if a site is inheriting permissions is named HasUniqueRoleDefinitions.

There are two properties which control the access request configuration, first is RequestAccessEnabled, a Boolean flag which turns on or off the access request feature for the site. The second property defines one or more email addresses where requests will be sent to. It is named RequestAccessEmail. To specify multiple email addresses, separate each with a semicolon. The image below illustrates the GUI for modifying these two properties. It is accessed on the site permissions page, on the far right of the ribbon.

Today I will share some sample code which walks through every site collection and site within a given web application, and writes to the screen the relevant access request settings.

Add-PSSnapin Microsoft.SharePoint.Powershell
$webapp = Get-SPWebApplication "Portal Home"
foreach($spsite in $webapp.Sites)
   foreach($web in $spsite.AllWebs)
      Write-Host "On Web" $web.Title ", URL" $web.URL
      if (!$web.HasUniqueRoleDefinitions) {
         Write-Host "`tAccess request settings inherited from parent."
      if ($web.RequestAccessEnabled) {
         Write-Host "`tAccess requests go to :" $web.RequestAccessEmail
      else {
         Write-Host "`tAccess requests are disabled."

SharePoint 2010 My Inbox and My Calendar Web Parts

If you are having problems with the My Inbox and My Calendar web parts on SharePoint 2010, and you are using Exchange 2010, check for these potential issues:

  1. Have you deployed Exchange SP1 on your CAS server hosting Outlook Web App? The RTM release of Exchange 2010 doesn’t work with these web parts. They  show HTTP error 400 after you authenticate.
  2. Are you getting forms based authentication, or are you being prompted by your browser for authentication? You will want to configure an instance of OWA which uses Windows integrated authentication. I will describe this in more detail below.

Create a new OWA instance

  1. Create a new web site in IIS. If you want to use SSL for the existing and new OWA, you will need a new IP for the Exchange server. IIS cannot route SSL traffic based on host headers.
  2. In the Exchange management shell, run this PowerShell Cmdlet
    > New-OWAVirtualDirectory -Name <owa name> -WebSiteName <name of site created in step 1>
  3. In the Exchange management console, configure the new OWA for integrated authentication.
  4. Run iisreset

Check the new OWA site directly from a browser. If you are prompted by the browser for authentication:

  • make sure you configured OWA properly in step 3 above
  • make sure your browser supports integrated authentication
  • if using IE, check that the URL you are using is in the Local Intranet zone

Once the OWA app opens without authentication, use the same URL in the web part on SharePoint.