Office 365 and “There are no items to show in this folder”

Posted on April 11, 2012 by Michel de Rooij

Be advised that when accessing shared mailboxes on Office 365 using Outlook in online mode, you may experience an issue with Outlook not properly updating the mailbox view.

Instead, Outlook will return a “There are no items to show in this view” message. The folder in the folder navigation pane displayed the proper number of (unread) items in the folder.

This could be the symptom of an issue which was already solved in Exchange 2010 Service Pack 1 Rollup 5. It seems the Office 365 data centers are not running a current version of Exchange, as today I received the message the Office 365 environment is currently being upgraded with Exchange 2010 Service Pack 2. The message also mentions the upgrade is to be completed at the end of the month.

More information on the issue in knowledge base articles kb2500648, announcing the fix is included in Exchange 2010 SP1 RU5.

Until then, the suggested workaround is to click one of the columns twice after which Outlook will update the view properly. Of course, you could also enable cached mode, if your setup and company policy permits (e.g. not running Outlook on terminal server).

Federation Information could not be received ..

Posted on March 23, 2012 by Michel de Rooij

When setting up federation between Exchange organization using the Hybrid Configuration Wizard, to connect your on-premise Exchange environment with Office 365, you may encounter an error message in the 2nd step of the Hybrid Configuration Wizard, Update-HybridConfiguration:

When inspecting the Update-HybridConfiguration results, it reads:

Updating hybrid configuration failed with error ‘Subtask Configure execution failed: Creating Organization Relationships.
Execution of the Get-FederationInformation cmdlet had thrown an exception. This may indicate invalid parameters in your Hybrid Configuration settings.
Federation information could not be received from the external organization.
..

The problem lies in the sentence “Federation Information could not be received from external organization”. To see where it goes wrong, you could run Set-HybridConfiguration and Update-HybridConfiguration manually, using additional parameters as shown in the result screen, providing proper credentials and additionally addint the Verbose parameter to increase output logged.

Most of the time this problem comes down to one of the following issues, which can be verified by running the following cmdlet, where example.com is to be replaced by the federated domain:

Get-FederationInformation example.com –Verbose

You’ll probably see the cmdlet going trough the discovery motions using autodiscover, ending up in the same “Federation information could not be received from the external organization” message. When analyzing this output, you’ll see it contains two hints on the potential issues:

Get-FederationInformation : The discovery process returned the following results:
Type=Failure;Url=https://autodiscover.example.com/autodiscover/autodiscover.svc;Exception=Discovery for domain example.com failed.; …

1. Autodiscover
The first issue often overlooked is internal autodiscover not working via DNS or not being set up properly, i.e. split DNS configurations. Some customers don’t configure internal DNS autodiscover records or don’t allow (internal) autodiscover to go through the proxy from inside.

Normally, when using regular clients like Outlook, this isn’t an issue because domain joined clients will be using SCP records from AD. However, federation will use DNS records so you need allow it or set it up in DNS; a CNAME for autodiscover.example.com as well as autodiscover.service.example.com pointing to your hybrid server will suffice.

Also make sure you enable WSSecurity authentication for autodiscover on your hybrid server using:

Set-AutodiscoverVirtualDirectory -Identity ‘autodiscover (Default Web Site)’ –WSSecurityAuthentication $true

2. Proxy rules
In the error message you’ll notice a autodiscover-related request going to /autodiscover/autodiscover.svc. These requests are normally caught by the autodiscover rule (path /autodiscover/*) in ISA or TMG. Issue is, these service requests require unauthenticated traffic. When you turn on logging in TMG, you’ll notice the requests for /autodiscover/autodiscover.svc will be denied.

To solve this issue, and to get federation working, you need to set up an additional ISA/TMG rule pointing to the hybrid server, using the proper public names (don’t forget autodiscover), bound to the OWA listener. You need to allow All Users (as opposed to Authenticated Users), set authentication to “No Authentication, but users can authenticate directly” and configure the following paths:

/EWS/Exchange.asmx/wssecurity
/Autodiscover/Autodiscover.svc
/Autodiscover/Autodiscover.svc/wssecurity

After configuring the rule, you need to put it above all the other Exchange rules, making it the first matching rule when federation traffic hits ISA/TMG.

After applying the rule changes, Get-FederationInfo example.com should work and you can continue with the Hybrid Configuration.

For more information on setting up co-existence, consult the steps provided by the Exchange Deployment Assistent.

Exchange PST Capture Tool released

Posted on January 30, 2012 by Michel de Rooij

It took a while, but today the Exchange Team released the long awaited Microsoft Exchange PST Capture Tool (initial version 14.3.16.4). The tool can be used to discover and inject PST files in an Exchange 2010 Exchange Online mailbox or archive.

The tool was originally from Red Gate and known as PST Importer. It’s architecture consists of three components: the central service, (optional) agents for PST discovery, registration and collecting PST files and an administrative console (image by Red Gate):

The online documentation can be found here.

Note that although it’s only supported for Exchange 2010 and Exchange Online, you can use it with Exchange 2007; it’s only untested (and probably unsupported) with that product.

You can read the official announcement here; you can download the tool and the agents here.

Remote PowerShell to Office 365

Posted on May 11, 2011 by Michel de Rooij

While trying Office 365 you might want to connect your to a remote Exchange Management Shell session instead of using the portal interface. Here’s how to proceed.

Start up a PowerShell session. The first thing we’re going to do next is store credentials in a variable for later usage:

$cred= Get-Credential

A popup will be displayed where you can enter your Office 365 admin credentials, e.g. myadminname@yourdomain.onmicrosoft.com.

Next, create a new remote PowerShell session using the following cmdlet:

$o365= New-PsSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $cred -AllowRedirection -Authentication Basic

Next, we can import the session. However, this might be confusing since you have no context; are you creating a mailbox local or in the Office 365 environment?

The cool thing is that with Import-Session you can specify a prefix. This prefix can be specified before the cmdlet noun so that PowerShell knows which session you want the cmdlet to run against. As you probably know, cmdlets are normally constructed using <verb>-<noun> syntax, but this should be <verb>-<session prefix><noun>. When the session prefix is omitted, PowerShell assumes the current session.

For example, let’s import our Office 365 session with a prefix of “o365”:

Import-PsSession $o365 –Prefix o365