I came across an interesting issue when using the Exchange Hybrid Configuration Wizard in a multi-namespace environment recently. Autodiscover was configured and working correctly for Outlook and EAS clients but the wizard would not complete successfully and would generate the following error: “Federation information could not be received from the external organization…” as seen below:

After some investigation, I discovered that this problem was related to Autodiscover. Typically in an on-premises Exchange 2010 deployment, there are a number of different ways to configure Autodiscover when using multiple namespaces. These are:

Option 1 - Single SSL Certificate that is valid for all DNS names (SAN Certificate)
Pros:

• Requires only one certificate.
• Requires only 1 public IP.

Cons:

• Cost of additional DNS names in the SAN certificate could be expensive.

Option 2 - Single-name SSL Certificate with DNS SRV Lookup
Pros:

• Requires only 1 public IP.
• Requires 1 single-name SSL certificate.

Cons:

• Not all DNS hosting providers support DNS SRV records.
• Outlook users may be prompted.
• Outlook 2007 required client-side hotfix.

Option 3 - Single-name SSL Certificate with HTTP redirect
Pros:

• Requires 1 single-name SSL certificate.

Cons:

• Requires 2 public IPs
• Requires a second IIS site or ISA/TMG

While these will all work and have their pros and cons, I would usually always use ‘option 1’ listed above unless there is a good reason not to. In this particular instance, the Autodiscover was configured using ‘option 3’ and even though Autodiscover worked fine for clients, the Hybrid Configuration Wizard did not seem to like this configuration.

The Office 365 documentation does not go into a great amount of detail about multi-domain Autodiscover configuration and says: “Configure the Autodiscover public DNS records for your existing SMTP domains to point to an on-premises Exchange 2010 SP2 Client Access server” which is technically what had been done. The reason this caused a problem is because unlike Outlook or EAS clients, Office 365 does not use the Autodiscover discovery process and instead makes a direct connection to https://autodiscover.domain.com/autodiscover/autodiscover.svc/wssecurity for each domain being used and does not obey the web redirect that had previously been configured.

In order to solve this problem, we purchased a new SAN certificate and reconfigured Autodiscover as described in ‘option 1’. In short, this is the only way to configure Autodiscover if you plan to implement an Exchange Hybrid Deployment. Additionally, if you are not using split DNS and have an internal DNS zone that is different to your external DNS (eg. domain.local), you need to ensure that the relevant external Autodiscover records are resolvable internally as well.

As a side note, if you are using ISA/TMG to publish EWS/Autodiscover, you need to create a separate rule without authentication delegation for the following paths:

• /ews/mrsproxy.svc
• /ews/exchange.asmx/wssecurity
• /autodiscover/autodiscover.svc/wssecurity
• /autodiscover/autodiscover.svc

If you have a Exchange Hybrid deployment configured and attempt to create a new remote move request you may receive an ”Exception has been thrown by the target of invocation” error similar to the one below.

Here are a few things you can check in order to help troubleshoot this error:

• Have you enabled MRSProxy?
• Have you correctly set the EWS “External URL” (WebServicesVirtualDirectory)?
• Do you have a certificate installed that contains the DNS name used in the  EWS “External URL”?
• Are you entering the correct FQDN in the MRSProxy field of the new remote move request wizard?
• Are you using TMG/ISA to publish EWS? If so, ensure that you are not using authentication delegation on the following paths:
  • /ews/mrsproxy.svc
  • /ews/exchange.asmx/wssecurity
  • /autodiscover/autodiscover.svc/wssecurity
  • /autodiscover/autodiscover.svc
• Are you seeing “405” errors in the IIS log on the Exchange Hybrid server? If so, see KB2626696

One of the downsides of using Exchange 2010 voicemail is that if you live in an English speaking country other than the United States (en-US) you have to set your Exchange language pack to en-US if you would like to make use of the Exchange voice mail preview feature. This has been a source of constant debate around our office as we have quite a multinational team. There are a few of us who don’t actually mind the American sounding prompts/greetings/etc.. but then there are those who do. In a attempt to keep everyone happy my friend and colleague Greig Sheridan decided to investigate and found quite a neat workaround.

Basically, what he has done is set the Default language of the Dial Plan to en-US, and then changed EVERY other reference to the language back to en-AU. The end result is that the only time you hear a greeting in the American accent is when you dial the Subscriber Access number, before you’ve logged-in. Read all about it on his blog. For a direct link to the post, click here.

I came across this error recently while running the Hybrid Configuration Wizard on Exchange 2010 SP2. It caught me out a little and as it turns out the fix is quite simple. It seems the wizard does not recognise certificates that begin with anything other than “CN=”. In my particular case I was being tripped up by a certificate beginning with “E=”. What made this even more confusing was that the certificate causing the problem was installed, but completely unrelated and not actually the one I was using to configure my Hybrid Exchange environment.

It seems this is a known bug and was fixed in Update Rollup 1 for Exchange Server 2010 Service Pack 2. I can confirm that after installing the update, it all worked as expected.

For more info and to download Update Rollup 1 for Exchange Server 2010 Service Pack 2, click here

The Microsoft Exchange team recently released Microsoft Exchange PST Capture which allows you to search for .pst files on computers in your organization and then import those files to mailboxes in both on-premises Exchange servers and Exchange Online.

PST Capture was initially developed by ISV partner, Red Gate, and was recently acquired by Microsoft. After some further development and testing, it can now be downloaded for free here. PST Capture is comprised of the following components:

• PST Capture Central Service: The Central Service maintains the list of all PST files found in your organization and manages the data as it’s moved to the Exchange servers or Exchange Online.
• PST Capture Agent: Discovery of the PST files is performed by PST Capture agents that are installed on computers in your organization. The agents also send the PST files they find to the host computer when an import operation is started on the PST Capture Console.
• PST Capture Console: The PST Capture Console is the interface you use to configure PST searches, specify the target mailboxes for PST files, and track the status of PST import operations and reports. You can also use the console to import PST files stored on network attached storage (NAS) devices, on which you can’t install PST agents.

 

For more information on Microsoft Exchange PST Capture see this TechNet article

To download Microsoft Exchange PST Capture click here

Some of Lync’s Client-side error messages don’t really explain the reason for the failure. Luckily my friend Greig Sheridan has started to compile a very handy list of these on his blog.

If you ever spend time troubleshooting Lync client side error messages, I would definitely recommend that you check it out. Here’s a link:

https://greiginsydney.com/decoding-lyncs-client-side-error-messages/

In almost every environment I have ever seen there are usually some devices and/or systems that need to send email and typically these will require some SMTP server to relay these messages. More often than not these also do not have the ability to authenticate to the relaying host.

How do we deal with these in Exchange? I have seen some pretty silly solutions and the default answer seems to be “Just allow anonymous users on the default connector”. This is not true and is actually quite a dangerous thing to do, so my advice is DON’T. In fact, I would go so far as to say, don’t ever touch the default connector. The correct way is to create a new receive connector and allow relay from only the devices that are required to use this connector.

Allowing anonymous relay is serious and requires thought and planning. If could be exploited by spammers and IMHO should not be configured on internet-facing servers.

So lets say that we have three devices that need to relay anonymously, their IPs are 10.0.0.30, 10.0.0.31 and 10.0.0.32. First we need to create a new receive connector:

New-ReceiveConnector -Name "Anonymous Relay Connector" -Usage Custom -PermissionGroups AnonymousUsers -Bindings 10.0.0.20:25 -RemoteIpRanges 10.0.0.30-10.0.0.32 –Banner "220 Anonymous Relay Connector"

Next we need to to grant relay permission to anonymous connections on the new Receive connector:

Get-ReceiveConnector -Identity "Anonymous Relay Connector" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

What happens if you have multiple servers and would like to duplicate your receive connector settings. Say for example you have two Exchange servers and you have a receive connector on a server called EXHUB01 that allows 100 devices to relay. You would now like to create the same connector on EXHUB02. Instead of manually adding each address, you could do this:

New-ReceiveConnector "Anonymous Relay Connector" -Server EXHUB02 -Usage Custom -PermissionGroups AnonymousUsers -Bindings 10.0.0.21:25 -RemoteIPRanges ( Get-ReceiveConnector "EXHUB01\Anonymous Relay Connector" ).RemoteIPRanges -Banner "220 Anonymous Relay Connector"

Don’t forget to grant relay permission to anonymous connections on the new Receive connector:

Get-ReceiveConnector -Identity "EXHUB02\Anonymous Relay Connector" | Add-ADPermission -User "NT AUTHORITY\ANONYMOUS LOGON" -ExtendedRights "Ms-Exch-SMTP-Accept-Any-Recipient"

Just in case you missed it, Exchange 2010 SP2 was released earlier this month. The following features and functionality has changed since Service Pack 1 for Exchange 2010:

• Hybrid Configuration Wizard
• Address Book Policies
• Cross-Site Silent Redirection for Outlook Web App
• Mini Version of Outlook Web App
• Mailbox Replication Service
• Mailbox Auto-Mapping
• Multi-Valued Custom Attributes
• Litigation Hold

I wanted to call out a couple of these that I have been eagerly awaiting:

Hybrid Configuration Wizard
Exchange 2010 SP2 introduces the Hybrid Configuration Wizard which provides you with a streamlined process to configure a hybrid deployment between on-premises and Office 365 Exchange organizations. Hybrid deployments provide the seamless look and feel of a single Exchange organization and offer administrators the ability to extend the feature-rich experience and administrative control of an on-premises organization to the cloud.

Cross-Site Silent Redirection for Outlook Web App
In Exchange 2010 SP1, there was three types of redirection for OWA in Exchange 2010 on-premises:

• Manual Redirection
• Temporary Manual Redirection
• Legacy Silent Redirection (for Exchange 2003/2007)

With Exchange 2010 SP2, you can enable a silent redirection when a Client Access server receives a client request that is better serviced by a Client Access server located in another Active Directory site. This silent redirection can also provide a single sign-on experience when forms-based authentication is enabled on each Client Access server.

For more information about what’s new in Exchange 2010 SP2, click here

To download Exchange 2010 SP2, click here

This handy little tool has been around for some time now but I’ve found that it does not seem to be very well known so I thought I would write up a quick post.

This performance tool tests your Internet connection to a Microsoft Online Services data center and measures the response times, bandwidth, and overall connection quality. The results can help you evaluate your network configuration for potential use with Microsoft Online Services.

For America use http://speedtest.microsoftonline.com

For Asia Pacific use http://speedtest.apac.microsoftonline.com

For Europe, Middle East and Africa use http://speedtest.emea.microsoftonline.com

I recently came across this error while using Jetstress to test and validate the performance of their Exchange storage. I was running the tool on Windows Server 2008 R2 and I don’t recall ever seeing this before. After finding what is actually an easy fix, I thought I would  write up this post just in case this has anyone else baffled. The entire error was:

Ensure that you’re running the application as a member of built-in Administrators security group.

The MSExchange Database or MSExchange Database ==> Instrances performance counter category isn't registered.

The admin account I was using is a member of the domain admins security group so I assumed I had the correct permissions but went away and checked just to be sure. I also checked to make sure that the domain admins group was a member of the local built-in Administrators security group, which it was. After spending a few minutes thinking about it, I thought I would try running Jetstress “as an administrator” (right-click the shortcut and select “Run as administrator”

That solved the problem.

I have since checked the Jetstress installation in my Exchange 2010 Lab which also runs on Windows Server 2008 R2 and this step is not required there, it works fine by just clicking the Jetstress shortcut (no right-click required). Not really worth spending time investigating the cause as it may just be a once-off occurrence, but at least it is now documented.