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.

Search for Commands Using Command Line Tools

Command line management on SharePoint 2007 is handled by STSADM.EXE, and on 2010 by PowerShell commandlets. There are so many options it is hard to keep track.

Using the command line on 2007, the first step to easy access to these commands is to add the path to the executable (C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\12\BIN) into your environment path variable.

Now you can open a command prompt and type stsadm <Enter>. When run without any parameters, it will display help information. The problem is there are so many pages of information it zooms by very quickly. If your buffer is large enough, you can scroll back through the output. Alternately, you can pipe the output into more, and view it one page at a time.

But typically you are looking for a particular operation (-o). Say for example, that you are looking for the operations relating to solutions. In this case, pipe the output to the find command, filtering on the string you are looking for.

stsadm | find “solution”

Then to see the syntax for the operation you want, run it without any parameters, and if additional parameters are required, the syntax will be displayed.

stsadm -o addsolution

In SharePoint 2010, stsadm is still available, and the technique above works the same, but I highly recommend switching to PowerShell. In PowerShell, SharePoint operations are provided via Cmdlets which are loaded automatically in the SharePoint 2010 Management Shell.

If you open Windows PowerShell, you can load the SharePoint Cmdlets with this command:

Add-PSSnapin Microsoft.SharePoint.Powershell

To see a list of all Cmdlets offered, use:

Get-Command -module Microsoft.SharePoint.Powershell

To filter the results, pipe the output to Where-Object:

Get-Command -module Microsoft.SharePoint.Powershell | Where-Object {$_.Name -like “*solution*”}

Obviously this is much more complicated than stsadm and find. When I come across an easier method I will update the post. Feel free to leave a comment with your suggestion.

To see the help information on a particular Cmdlet, use the Get-Help Cmdlet, or the -? parameter:

Get-Help Add-SPSolution

-or-

Add-SPSolution -?

Update 6/21/11

Get-Command accepts wildcards in it’s default parameter, and shows Cmdlets from all loaded modules. To simplify my example above, it is not necessary to specify the -module parameter, and the filter specified as so:

> Get-Command *solution

Much simpler, yes?!?