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.

Configuring initial Exchange database

Posted on January 12, 2012 by Michel de Rooij

Something which I still see many Administrators do, right after installing Exchange 2010, is renaming the mailbox database or relocating the database or logs files that were created during the setup of Exchange 2010.

To configure the initial mailbox database name, the location of the initial mailbox database (and catalog) files or its log files, you can incorporate the following parameters in your setup command line:

MdbName is the name of the initially created mailbox database, e.g. MDB01
DbFilePath is the full path of the initially created mailbox database file, e.g. E:\MDB01DB\MDB01.edb
LogFolderPath is the folder used to store the database log files, e.g. D:\MDB01LOG

Note that you must use the complete filename of the edb file, including the .edb extension. Also, you don’t need to create the folders; Exchange will do that for you during setup.

So, to setup Exchange with a custom initial mailbox database name and non-default locations of database and log files, you can use the following command line for example:

setup /mode:install /roles:c,h,m,t /mdbname:MDB01 /DbFilePath:E:\MDB01DB\MDB01.edb /LogFolderPath:D:\MDB01LOG

Of course, these parameters are nice to incorporate in your scripted setup to deploy multiple servers.

ManageScheduledTask.ps1 issue uninstalling Exchange

Posted on January 6, 2012 by Michel de Rooij

Today I encountered a strange issue when trying to decommission a DAG member, after properly removing it from the DAG as explained here, and checking services like address book generation server where hosted on one of the other DAG members.

I started the removal process from an elevated command prompt (using the GUI doesn’t work as it complains about the need to use setup.com, which I can’t since I’m using the GUI):

setup /m:uninstall

The output was the following:

Hmm. Without even looking at the Exchange setup log, I noticed there was something strange with the error message:

The term ‘C:\Program Files\Microsoft\Exchange Server\V14\Bin\ManageScheduledTask.ps1’ is not recognized as the name of a cmdlet, function, script file, or operable program.

As you probably know, all Exchange scripts are located in the Scripts folder, not the Bin folder.

I tried a quick and dirty fix, which was to copy the ManageScheduledTask.ps1 and ManageScheduledTask.strings files to the Bin folder, and again started setup /m:uninstall. This time, Exchange uninstalled nicely.

From experience, this isn’t expected behavior, but in case you encounter this problem in the field, you now know how you can easily work around this.

Update: I’ve seen identical issues when retrying an upgrade on Exchange 2010 SP1 to SP2. I think the problem is code-related (i.e. bug), as the uninstall part of the upgrade process should check for those files in “scripts”, not “bin”. Note that with case of the failing SP2 upgrade, the file EnterpriseServiceEndpoints.xml was also MIA (that one should be in bin). I worked around that by copying the file from the installation source.

Microsoft Office Filter Pack 2010 SP1

Posted on June 28, 2011 by Michel de Rooij

Right after launching Office 365, Microsoft released Service Pack 1 for Microsoft Office 2010 (KB2460049) which includes Office 365 support besides a big list of fixes. For those interested, Office 2010 SP1 can be downloaded here (x86) and here (x64). For a full list of changes, check out Microsoft Office 2010 Service Pack 1 Changes Excel sheet.

More interesting for Exchange folks is that there’s also an SP1 for the Microsoft Office Filter Pack 2010, which of course you install during Exchange setup as one of the prerequisites. As you probably know, the Filter Pack is used to index Office documents stored in Exchange databases to speed up queries.

You can download Service Pack 1 for Microsoft Office Filter Pack 2010 x64 Edition here. The related knowledgebase article is KB2460041.

Exchange & Dynamic Memory : Don’t

Posted on March 14, 2011 by Michel de Rooij

With the arrival of Service Pack 1 for Windows Server 2008 R2, Dynamic Memory was introduced. In brief, Dynamic Memory is a memory management enhancement for Hyper-V which allows running virtual machines (VM) to allocate memory from the host and releasing it when possible, giving a minimum and maximum memory boundary. The main benefit is a higher VM density, because each VM will only allocate what’s required and you don’t have to approximate memory allocations.

Now this mechanism works well for many applications, but not for Exchange. Exchange’s goal – at least that of servers holding the mailbox role – is to claim as much memory as possible in order to cache information. This amount depends on the installed of memory (more information here). This cache is used for performance reasons, more cache means less I/O’s, less I/O’s result in better performance. You can guess what happens when you run Exchange with a minimal amount of memory and lots of dynamic memory configured, optionally shared with other Dynamic Memory-enabled VM’s. If Exchange starts up and wants to claim memory for caching or allocate memory for other reasons (transactions), instead of the memory being available instantly the host first needs to allocate it, or worse have other VM’s surrendering it their memory. That doesn’t make sense and will result in significant performance penalty.

Besides it being pointless to configure Dynamic Memory for Exchange, it’s also not recommended. From the Exchange 2010 System Requirements:

Many of the performance gains in recent versions of Exchange, especially those related to reduction in I/O, are based on highly efficient usage of large amounts of memory. When that memory is no longer available, the expected performance of the system can’t be achieved. For this reason, memory oversubscription or dynamic adjustment of virtual machine memory should be disabled for production Exchange servers.

Also, from the paper Implementing and Configuring Dynamic Memory, on applications that may not perform as well after Dynamic Memory is enabled:

Applications that perform their own memory management by taking over certain aspects of memory management from the operating system. Such applications typically grab as much memory as they possibly can in order to ensure the application’s best performance which can cause the amount of memory allocated to their virtual machine to grow until it reaches the amount specified by the Maximum RAM setting;
Applications where memory allocation is a one shot operation that is performed either when the application starts for the first time or each time the application starts.

Concluding, yes you can use Dynamic Memory for your lab or testing environment and it works. But don’t use it in production for Exchange Server.

Credits to Jetze who blogged about this originally here (Dutch).