Neil Johnson - a rock 'n roll nerd....

Outlook 2007 fails to connect to Outlook Anywhere via NTLM on Vista

Neil Johnson [MSFT] — Tue, 26 Jun 2012 07:47:28 GMT

So, firstly an apology for the lack of posts recently... I always said that if I didn't have anything interesting or useful to post I just wouldn't post, so that's what happened…

Anyway, I have been working with a customer to deploy Outlook Anywhere, we used Greg Taylors awesome white paper on this to get UAG to do the necessary publishing and authentication. This worked fine in my test lab but when we configured in production the clients couldn't connect and received perpetual credential prompts...

We did the usual host of troubleshooting (there is plenty of hocus-pocus on internet forums about OA password prompts!) but basically drew a blank… then someone in the project team noticed that their test Windows 7 machine could connect, but the production Vista machines were failing.

After some head scratching and searching we came across the following KB article…

http://support.microsoft.com/kb/2408187/

"Consider the following scenario. You have a computer that is running Windows Vista or Windows Server 2008. You configure the computer to use the RPC over HTTP feature to access certain services. In this scenario, the RPC over HTTP module (Rpchttp.dll) may not work correctly. Therefore, the RPC over HTTP connection does not establish successfully. For example, you cannot sign in to Outlook Anywhere or in to Office Communicator. Additionally, you are prompted to provide your user credentials."

So.. We dutifully downloaded and installed this hotfix which resolved the issue J

I wanted to post this here since we don't get to see Vista very often and I was totally unaware of this issue.

Microsoft Exchange Online Migration Performance Guide for Office 365

Neil Johnson [MSFT] — Wed, 11 Apr 2012 13:22:04 GMT

I guess it's pretty obvious by now that I am a bit of a nerd when it comes to Exchange and Outlook performance. One area that has always felt like a black box though is migrating data into Office 365 Exchange Online service.

The problem for me was that sometimes I would be able to migrate very quickly and at other times the migration would seem much slower, even though the network availability seemed the same during both times. This made migration planning extremely difficult since it was difficult to actually understand what the constraints actually were… this obviously leads to projects over and under provisioning migration schedule time which is not a good place to be.

There was also much confusion about if Office 365 was throttling some migration types and not others.

Well, I am extremely pleased to say that a guide has been released that discusses many of these questions and also finally shows what throttling policies are being applied to which migration mechanisms.

This document is a must read for anyone planning an Office 365 migration to Exchange Online

http://community.office365.com/en-us/f/183/t/45466.aspx

Forcing a full OAB download in Outlook 2011

Neil Johnson [MSFT] — Fri, 23 Mar 2012 09:54:12 GMT

I want to start this blog by apologising for the lack of posts recently… this is mostly due to me not having anything interesting to say and not wanting this blog to be watered down with irrelevant nonsense… that and working on stuff that I can't talk about yet…

Anyway, one thing that I can talk about is the Exchange Client Network Bandwidth calculator that was released a few months ago on the Exchange Team Blog

http://blogs.technet.com/b/exchange/archive/2012/03/09/exchange-client-network-bandwidth-calculator-beta2.aspx

Why do I mention this when the post title clearly talks about Outlook 2011 and Offline Address Book Download? Well… I have been working with Outlook 2011 this week to derive the network bandwidth formulae required for the calculator and one thing caused me to get stuck... how could I predict OAB download usage for Outlook 2011 when I couldn't see a way to force a full OAB sync?

As it turns out you can force a full OAB sync on Outlook 2011, it's just not exposed in the GUI…

If we open a terminal and take a look inside ~/Library/Caches/Outlook/Main Identity/1/Download we can see the OAB.XML file that has been downloaded from our Exchange server.

To trigger a full OAB file download following these steps.

Fully exit Outlook 2011
Remove the ~/Library/Caches/Outlook/Main Identity directory
Restart Outlook 2011

NOTE: One thing worth pointing out here is that "Main Identity" refers to the primary account that was configured for Outlook 2011 – if you are working with a different account you need to change the paths accordingly, otherwise you will remove the OAB file from the wrong account!

Once this directory has been removed, re-start Outlook 2011 which will re-create the Main Identity directory for you, however it may take up to 15 minutes before the OAB download is triggered.

Hopefully this helps someone else out there.

Using your iPad, iPhone or Windows Phone with Lync 2010 and Office 365

Neil Johnson [MSFT] — Thu, 02 Feb 2012 11:25:03 GMT

I have had a few recently from customers wanting to use Lync 2010 Mobile on their shiny mobile devices. I thought I would go through the steps here to connect iOS devices, such as iPad and iPhone as well as Windows Phone WP7 devices to Lync Online in Office 365.

Prerequisites

This post assumes that you have configured your tenant correctly and have all of the necessary DNS records in place. To check what you should have in pace

login to https://portal.microsoftonline.com as tenant administrator
Click on Domains
Click on the Domain you are using for your Lync users
Click on DNS settings

Check that each and every one of the DNS records required for Lync is in place and configured correctly. It is not worth continuing unless this has been done (because it won't work! ).

iPad and iPhone

I am going to use my iPad here but the same approach should work for your iPhone.

First we need to download the Lync 2010 App from the App Store, the easiest way is to search for it in the App store on your device but you can do it via iTunes as well if you need to.

Once downloaded you should now have the Lync 2010 App icon on your device…

When you first start the app it will ask you to login, you will need to know the following information

Sign-in Address: This is your UserPrincipalName
Password: Yeah, this is your password 
User Name <Click More Details>: This is your UserPrincipalName

Your UserPrincipalName (UPN) is usually the same as your email address, but it may not be. This will be the name you use to login to the Office 365 portal with.

Enter the login details at the Sign-in page and tap Sign-in…

Lync will then validate your credentials and attempt to log in…

Once logged in you should see the contacts page – as you can see I don't have many friends in my lab 

There is an info screen for settings and general configuration…

Plus a screen showing your current Chats…

I really just wanted to show how to connect in this post, so I am not going to dig into any of the detailed usage here.

Windows Phone

Firstly we need to download the Lync 2010 app from the Windows Phone Marketplace. The easiest way to do this is to search for it on your WP device. Once installed, you should have an icon for Lync 2010 – I have pinned mine to the start screen for easy access and the live tiles.

Note: WP does not have the ability to take screenshots so I am attempting to do my best with my HTC Mozart and my Cannon DSLR – I will apologise for the quality before we go on 

On opening Lync 2010 will request your credentials, these are exactly the same as for the iPad and iPhone versions..

Sign-in Address: This is your UserPrincipalName
Password: Yeah, this is your password 
User name <Click More Details>: This is your UserPrincipalName

Your UserPrincipalName (UPN) is usually the same as your email address, but it may not be. This will be the name you use to login to the Office 365 portal with.

Tap the circle with a tick inside at the bottom and Lync 2010 will attempt to log you in to Office 365…

Once connected for the first time Lync 2010 will run through a few initial start-up screens…

Conclusion

Hopefully, this post shows that's it's pretty easy to connect your mobile device to Lync 2010 in Microsoft Office 365. The most common causes of connection problems that I see are either incorrect DNS records or ADFS authentication problems (for federated identities obviously!).

I would like to dig into these mobile a clients further but this post is already much longer than I anticipated, so I am going to leave it as just a connection post and do something in the future about the features and functionality that these clients provide.

Office 365 Proxy Server Exclusion List – Office 365 Service URL’s

Neil Johnson [MSFT] — Thu, 26 Jan 2012 12:46:50 GMT

I am just posting this here since it's a bit of information I regularly provide to customers and I always have trouble remembering where I found it (yes I know I should create a browser bookmark, but I thought I would share!).

When you deploy Office 365 one of the most difficult (and poorly documented) areas is network connectivity for clients and servers on terra firma connecting to the cloud. My recommendation is to bypass your normal internet proxy servers for all Office 365 services to provide the best experience for your earthlings trying to access their cloud based email – this obviously raises the question "Which names do I need to exclude?" and that's where the following TechNet page comes in…

Office 365 URLS and IP Address Ranges

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh373144.aspx

Exchange Online URLs and IP Address Ranges

http://technet.microsoft.com/en-us/exchangelabshelp/gg263350

RSS Updates for URL and IP Address Range Changes

http://go.microsoft.com/fwlink/?linkid=236301

Exactly how you engineer your bypass list is specific to your network topology and technology.

Outlook Performance Troubleshooting including Office 365

Neil Johnson [MSFT] — Mon, 23 Jan 2012 11:50:09 GMT

I have been involved in a number of discussions recently regarding Outlook performance troubleshooting in the cloud. Mostly these discussions were in the context of why the customer didn't want to move to the cloud since they figured it would be impossible to troubleshoot Outlook performance afterwards

Discussion Summary:

When we have clients and Exchange on terra firma we can monitor some performance counters such as RPC Average Latency on Exchange and use the Outlook and client performance counters to establish if a poor end user experience is being caused by the Exchange Server, the Network or the Client machine. If we move the messaging service out to the Office 365 cloud we can no longer monitor RPC Average Latency so we don't know if poor performance at the client is being caused by network or the Exchange server.

Outlook Performance

This started me thinking about how to deal with this situation and what items make up the client experience from an Outlook performance perspective.

The following items can both have a fairly dramatic effect on Outlook client performance and either could cause the end customer to pick up the phone to support and say that "E-mail is slow".

MAPI RPC Latency
Client system performance

If we make the assumption that our service is running in the Office 365 cloud, how do we go about determining the actual cause of Outlook performance problems?

MAPI RPC Latency

RPC Latency is made up of two parts

Server side RPC processing
Round-trip-time Network Latency

Network latency is probably the easiest to examine on the surface since we really just need to use ping.exe to find out what our TCP round-trip-time (RTT) value is to the target server. There is a snag though, as you might expect…

Here is the ping response from my Office 365 server…

Not exactly useful since ICMP Echo is blocked at the external firewall. So, if we can't use ping.exe how do we determine our Network RTT latency? Well, luckily Outlook has us covered here and keeps a track of some stuff that can help us out…

In your task tray you should see an Outlook Icon. If you hold down CTRL + RIGHT CLICK on this icon it will show the Outlook context menu…

From the Outlook Context menu select "Connection Status"

In the Connection Status dialog box find the columns called Avg Resp and Avg Proc. The difference between these two values represents the network latency for each connection.

In this example you can see that I have two logical connections listed as Mail (To see the physical TCP connections use TCPview). This is normal for a cached mode Outlook 2007+ client. One connection is used for item synchronisation and the other is reserved for sending new messages. This architecture prevents sending a large message from blocking Outlook receiving new items like it did in Outlook 2003.

Generally speaking the connection with the larger Req count is for synchronisation which is the one we will use in this example.

Avg Resp is 87ms
Avg Proc is 10ms

This means that my Network RTT time is 77ms and the Server side RPC processing latency is 10ms.

In my example this makes perfect sense since I am based in the UK and my mailbox is hosted on Office 365 in North America. It also shows that my Network and Server latency are within acceptable limits.

Generally speaking I use the following recommendations to maintain a good client experience in Cached mode for Outlook 2007 and later.

Max Avg Proc Time (Exchange RPC Latency) = 25ms
Max Network RTT Time (Network Ping Time) = 300ms
Max Avg Resp Time (Exchange RPC Latency + Network Latency) = 325ms

Once armed with these values it is possible to direct troubleshooting more specifically. For example, if Network RTT is high you could look at your network links or firewalls. If the Avg Proc time is high then a call to Office 365 support might be in order.

One final point here is to check the Req/Fail column. A high value for Fail represents high number of network disconnection events. If this is combined with a high Avg Proc time it potentially points to a service issue in Office 365, however if Avg Proc is good then it suggests that you may have a network connectivity problem between the client and the service. A common cause of this is source port exhaustion for environments with more than 2000 users.

Client System Performance

So what happens if the Network and Exchange RPC metrics are all good but the end customer is still experiencing poor Outlook performance? Since we have ruled out Network and Exchange performance the most likely culprit is the client workstation.

So what could be causing Outlook performance problems on the local workstation?

For this we need to look at the usual trinity of performance areas within the operating system

CPU
RAM
DISK I/O

To take a look at these further I am going to use Process Explorer.

Client CPU

Outlook is generally not that CPU intensive, however if your CPU is flat out doing other stuff then Outlook will respond slowly. To check this, open Process Explorer and arrange the table in descending CPU order.

We are looking for a few things here. Firstly what is our System Idle Process value? This tells us how much CPU time we have spare. Generally speaking if this value is less than 20% the system will feel sluggish. In my example you can see that I have plenty of CPU time available and so it is unlikely CPU is an issue here.

If Outlook appears at or near the top of this list then the most likely culprits are that you have a faulty add-in installed, (try running Outlook in safe mode), or that your OST file is damaged (Try running the Inbox Repair Tool).

To get a better idea of how Outlook is consuming resources, find OUTLOOK.EXE in the Process list, double click it and then open the Performance Graph tab in the properties dialogue box.

This will show some historical values for CPU Usage for the Outlook process. Even a large Mailbox (mine is 10GB) shouldn't require Outlook to take up a large amount of CPU time.

Client RAM

Insufficient RAM has a number of effects on Outlook. Firstly the process can be starved of physical RAM and so run slowly; secondly the operating system will have to page large chunks of memory to disk which will cause disk I/O problems. Since we are going to look at disk I/O in the next section, I will just look at identifying client memory problems here.

It is important to realise that Windows will page out an amount of memory to the page file and this both normal and advantageous. However, where the system has significantly more committed memory than it can accommodate in physical RAM we may run into performance problems as the process accesses its data in virtual memory and instead has to wait for that data to come from disk. This process is known as hard paging. A sustained high level (>5) of hard page faults is a strong indicator that there is not enough RAM in the system.

Unfortunately Process Explorer can't help us here since it shows a combination of hard and soft paging. For this task we are going to need to break out Performance Monitor (perfmon.exe).

Open, Perfmon and then add in the MEMORY\Page Reads/sec counter.

You can see clearly that this system has to retrieve data from the page file frequently. In fact this is from a virtual machine running Windows 7 and Outlook 2010 in 512MB RAM with a 5GB mailbox. Almost every single action performed within Outlook triggers a spike in Page Reads/sec. The user experience is very slow, however if we look at the Exchange Connection status for this client…

Avg Resp = 4ms
Avg Proc = 0ms

This clearly shows that the poor user experience is being driven by the client and not by the server or network and more importantly that a bit of extra RAM is likely to make this customer happy – clever right? J

Client Disk I/O

This is a bit of a soapbox of mine at the moment. As Exchange professionals we go to great lengths to monitor our messaging service on the basis that we want to provide the best user experience. However, the reality is that the most likely cause of poor user experience is accessing a large Outlook OST file stored on an underperforming client system. Over time these OST files generally reach roughly double the size of your mailbox. If we take Office 365 as an example with a 25GB quota, this means that it's not impossible for a user to have a 50GB OST file on their laptop HDD. Let's think about that for a minute… we have a 50GB file, with data in it that we need to access quickly – if that was a Word document or Access database most users would accept a minute or two's delay as it was opened and yet we expect Outlook to open it in 5 seconds or we think something is broken J

Speedy access to a large OST file access relies on two things…

A fast HDD that isn't dealing with too much other stuff
A mostly contiguous OST file

HDD Usage

If the hard disk drive is busy doing other things then Outlook in cached mode will perform slowly and deliver a poor user experience.

Physical Disk\Disk Queue Length

This is a measure of how many requests are waiting for the disk. Ideally the disk queue length should be no more than 1.5-2 times the number of disks that make up the volume. For most client workstations this means that disk queue length should be <2. As a general rule don't provide older laptops with 5400rpm HDD's very large mailbox sizes, i.e. don't just give everyone a 25GB mailbox without checking to see if their hardware is going to cope J

Contiguous OST File

Since Outlook makes frequent reads and writes to the OST file it can become very fragmented over time. A heavily fragmented OST file (>1000 frags/file) can lead to poor Outlook client performance.

The easiest way to check and defragment the OST file is via the sysinternals tool contig.exe. First close down any applications that may be accessing the OST file, such as Outlook or Lync.

To check the OST file for fragmentation use the command

Contig.exe –a <path to OST file>

Note: You must be running contig.exe with elevated privileges to perform defragmentation.

To defragment the OST file use the command.

Contig <path to OST file>

Conclusion and further reading

Outlook performance is just like any other application. It relies on CPU, Memory, Disk and Network. If any of those resources are performing badly then the end customer is likely to experience poor performance. Exactly the same troubleshooting processes apply on-premises or for Office 365 users. The only real difference that applies to Office 365 performance troubleshooting is that we cannot directly observe Exchange performance counters and so we need to rely on the data that Outlook provides us.

Performance Monitor Tips and Tricks with John Rodriguez

Neil Johnson [MSFT] — Mon, 16 Jan 2012 21:35:09 GMT

Hello everyone … My name is John Rodriguez, and I'm a Principal PFE based in Minneapolis, MN. I'm also one of Neil's frequent collaborators, particularly on load simulation tools. When he wrote his recent article on performance analysis of Jetstress data, I suggested that he include some of our time-saving tips. He's a busy chap, and asked me to write the article instead. So, to that end, I'm here as a guest contributor to share with you some of the things we as performance specialists do within Perfmon. [Neil: Actually John taught me Exchange perf when I first joined Microsoft in 2007 and again when I went through MCM; it is a great honour to have him write stuff for my blog, so thanks again John J].

If you spend a lot of time in Perfmon, whether for general performance analysis, reviewing Jetstress data, or trying to identify the source of a bottleneck, you tend to look for ways to automate tasks – to simplify things. Thankfully Perfmon provides some extremely useful interfaces which provide us with our time-saving opportunities.

When you first launch Performance Monitor, and switch to the Performance Monitor node, you should see the general screen with a single counter (usually Processor(_Total)\% Processor Time). In the example below, I've deleted the default counter and added four specific ones of great Exchange importance: MSExchangeIS\RPC Averaged Latency, \RPC Operations/sec, \RPC Packets/sec, and \RPC Requests.

How did I add those counters? Believe it or not, I pasted them. Pasted? Into Perfmon? Really? Yes, really. Here's how.

When you first launch Perfmon and want to add counters, you can click the green Plus symbol, or right-click the display and select "Add Counters…" as shown below.

Now, if you look at the context menu, you can see an option to "Save Settings As…" This is one of the most underappreciated items in Perfmon, and enables a lot of incredibly useful behavior. "Save Settings As" predictably enough saves the existing set of counters to an HTML file which you can then open and edit to your heart's content. If you right-click the file and select Open With > Notepad, you should see a bunch of entries beginning with <PARAM NAME="Counter#" and then details on the counters themselves, like so:

[It's important to select Open With > Notepad, rather than double-click on the file. We'll see why in a minute.]

Notice that there's no server name in this data – the value is just the counter name – "\MSExchangeIS\RPC Averaged Latency", "\MSExchangeIS\RPC Packets/sec", and so on. This means that this set is rather portable – to our great advantage. I can use this information to automatically add a whole group of counters to Perfmon at once. But we're not going to load them from the file – we're going to paste them into Perfmon! This may sound odd, but Perfmon actually supports copy-and-paste. If I want to add all of those counters at once, I can simply open that HTML file with Notepad, copy the contents (select all, copy), open Perfmon, click anywhere in the right-hand pane, and then click Ctrl-V, Perfmon will add all of those counters at once. In other words, if you add the counters to one server, and save the settings to HTML, you can quickly add all of those counters for any other server! This is extremely useful, but we're only just getting started.

Now that we have our settings file (in my case, "rpc counters.htm"), we can perform a few little tricks. First, since it's HTML, we can actually open this settings file with Internet Explorer. Unless you've weakened the security settings for IE, you'll need to click "Allow blocked content", but do that and you see Perfmon embedded within Internet Explorer:

Notice that Perfmon includes not just the counter list I added before, but visible data points as well (which was saved in the settings file). But more importantly, this is a fully functioning instance of Perfmon. Notice the two green buttons in the menu bar at the top of the Perfmon instance – the one on the left (similar to the "Play" button on a CD or DVD player) switches the display to live data, while the second (the "Skip Forward" button) leaves the display paused but updates the data to the present moment.

The green "Play" button has changed to a blue "Pause" button, and many of the other buttons have also been enabled as well (including add and remove counters).

"This is nice," you may say to yourself, "but what good does it do?" Well, for one thing, you can select a specific set of counters, save the settings file, and then distribute the settings file to your teammates so that they can open that same set of counters. This is very useful if you have a large set of counters and want to make sure that everyone's looking at the same data.

Where the "Save Settings As" option really becomes useful is when you're working with performance logs (BLG files). In this case, I've captured performance data using a custom Data Collector Set, and the results of the data are saved in C:\Perflogs\Admin\New Data Collector Set\DC1_datetime.log. I switched back to the Performance Monitor tab, and selected View Log Data from the action menu (you can also press Ctrl+L to do the same thing).

On the Data tab, I select all four counters from the log file and add them into the list to display.

Because I don't have very much data in the BLG, the resulting display isn't terribly exciting. But it's not the display that I'm concerned with here – it's what I can do with the data I selected. Again, I right-click and select "Save Settings As" and save the list of counters to another HTML file. [Side note: when you select "Save Settings As" when viewing data from a BLG, other options become available, including Save Data As, which gives you the option to reduce the size of an existing BLG by saving only a subset of data points.]

However, when you open this second HTML file, you'll notice that things look a little different. The counter names are prefaced by the server name:

My lab machine is named DC1, but if I want to use this on a performance log I collected from DC2, all I need to do is a simple find-and-replace in the HTML file, open the appropriate saved log (View Log Data), and then perform the same copy/paste trick listed above. Again, Perfmon will add all of the relevant counters directly into the display. That means that you can create the list of counters once and use that same list for every single BLG you want to review. Just change the name of the server within the HTML file for each server, then paste the contents.

To summarize, Perfmon allows you to save and load sets of performance counters, and you can use this functionality to make your performance life a little easier. By saving the settings to disk, you can ensure that you use the same list every time, even if you've closed Perfmon. You can launch Perfmon from within Internet Explorer using a saved settings file, which helps ensure consistency so that everyone uses the same counters. Last, you can use a settings file as a template to view the same set of counters from different BLG files from different servers.

Hopefully these tricks help you become more efficient in your use of Perfmon. Let us know in the comments!

Analysing Exchange Server 2010 Jetstress BLG Files By Hand

Neil Johnson [MSFT] — Thu, 05 Jan 2012 09:22:00 GMT

Quite often when I am working through Jetstress escalations I will ask to see the BLG files from the test. These files contain performance counter information that was logged during the test run and they show us a lot more about what is really going on than the data in the report HTML files.

To keep this post short, let's assume that you have already read through the Jetstress Field guide and move on to the fun stuff straight away J

Why Analyse the BLG file by hand?

Given that Jetstress already parses the BLG files and searches for various counters and values, why on Earth would we ever need to look in the BLG file ourselves? There are a number of reasons..

Establish failure severity

Was the failure caused by a single event, or do the performance logs show prolonged and repetitive issues? This is often useful when trying to put together a resolution plan – can we fix this by adding a few extra spindles or are we going to need a significantly bigger storage solution?
Analyse failure mode scenarios

When we test for failure modes, such as disk controller failure etc. the test may fail due to one very high latency spike, however as long as the test resumes in an acceptable timeframe and performance is acceptable we would conclude that the test passed even though Jetstress reported it as failed.

Finding the Jetstress test BLG File

Jetstress defaults to storing all test data in the folder in which it was installed. When you look in that folder you are looking for files of type Performance Monitor File. Given that you are probably not going to perform this analysis on the Exchange server, make a copy of the file to your workstation.

Hint:

BLG files are generally very compressible, so if you need to copy them over a WAN it is worth compressing them first.

Opening the Jetstress test BLG File in Performance Monitor

For this section I am going to assume that you have access to a Windows 7 workstation. One of the most frequent mistakes that I see people make at this stage is to simply double click on the BLG file… this will automatically open the trace file in perfmon and open the top 50 counters… firstly this takes ages and secondly it looks like this… which as you can see is pretty busy and pretty useless…

So, instead we are going to open Performance monitor and then open our BLG files. Performance monitor is stored in the Administrative Tools section of your start menu…

Start -> All Programs -> Administrative Tools -> Performance Monitor

Once Performance Monitor has started…

Select Performance Monitor under the Monitoring Tools section
Click on the View Log Data icon

Check the Log Files radio button, then click Add
Select the Jetstress BLG that you want to analyse
Click OK

You should now be looking at a totally empty Performance Monitor page…

Analysing the Jetstress Performance Data

Now we have Performance Monitor open and our Jetstress BLG file attached, the next step is to begin looking at the data. Before we begin this it is worth a quick recap of the counters and objects that we are interested in during an Exchange 2010 Jetstress test.

The best place to read about Exchange 2010 performance counter values is here:

http://technet.microsoft.com/en-us/library/ff367871.aspx

The following values are of specific interest when analysing Jetstress performance files.

Counter	Description	Threshold
MSExchange Database Instances(*) \I/O Database Reads (Attached) Average Latency	Shows the average length of time, in ms, per database read operation.	Should be <20 ms on average. Less than 6 spikes >100ms
MSExchange Database Instances(*) \I/O Log Writes Average Latency	Shows the average length of time, in ms, per Log file write operation.	Should be <10ms on average. Less than 6 spikes >50ms
MSExchange Database(JetstressWin) \Database Page Fault Stalls/sec	Shows the rate that database file page requests require of the database cache manager to allocate a new page from the database cache.	If this value is nonzero, this indicates that the database isn't able to flush dirty pages to the database file fast enough to make pages free for new page allocations.
MSExchange Database(JetstressWin) \Log Record Stalls/sec	Shows the number of log records that can't be added to the log buffers per second because the log buffers are full. If this counter is nonzero for a long period of time, the log buffer size may be a bottleneck.	The average value should be below 10 per second. Spikes (maximum values) shouldn't be higher than 100 per second.

Examples

The following are from some recent example tests.

Normal Jetstress test results

Before we move on to more interesting data I thought it would be useful to show what good test data looks like…

Database Read Latency

The following chart shows the MSExchange Database Instances (*)\I/O Database Reads (Attached) Average Latency values for the test. In this instance it is clear that all instances average is below 20ms and there are no read latency spikes. I have discarded checksum instances since they are not required. The _Total instance is highlighted in black and is discussed below.

I often see people quoting the _total instance for database read latencies. The _total instance is simply an average across all observations for that point in time and so serves no purpose other than to obscure the latency peak values.

The default Jetstress sample time is 15s which is already too large in my opinion (I recommending dropping this down to 2s for manual analysis – edit the XML to do this) so using an average value across all instances usually serves to make the results look better than they really are.

In the example above I have highlighted the _Total instance to show how it flattens out the results. Do not use the _total instance; it will often hide latency spikes from your results.

Log Write Latency

This chart shows the MSExchange Database Instances (*)\I/O Log Writes Average Latency. As you can see the results show that the write latency values are way below the 10ms average and there are no spikes.

Log Record and Page Fault Stalls

This chart shows both Log Record Stalls/Sec and Database Page Fault Stalls/Sec. As you can see both counters recorded 0 stalls/sec during the test which shows that the storage was able to meet the demands required by the database.

Failure Mode Test – Disk Controller Failure

The following test data came from an Exchange 2007 deployment where the customer was performing failure mode analysis of their storage. This specific test simulated a failure of a disk controller within their storage subsystem. The expected behaviour is to experience a brief storage outage and then for I/O to continue as normal. Manual analysis was required for this test since Jetstress just shows a failure due to average latency being >20ms.

The following charts show the recorded BLG data, it clearly shows that the test was actually in good shape apart from a single event caused by the simulation of the disk controller module. This event caused an I/O outage of 60 seconds, which was recorded as 4 x 20,000ms spikes on the chart. These few, very high values were enough to skew the average latency values of the test. In reality this test showed that the storage is capable of recovering from a disk controller failure in an acceptable time and the performance after the failure is the same as it was before.

Although Jetstress reports this as a failed run, I classified this as a test pass since the storage solution recovered from the failure quickly and resumed operations at the same level of performance. The operations team are now aware what a failure of this module will look like for Exchange and how long it will take to recover.

Figure 1: Database Read Latency

Figure 2: Log File Write Latency

Jetstress Log Interval Time Case

This is an interesting example since the initial Jetstress test actually passed the storage solution, however the team involved were suspicious since they had previous experience with this deployment and knew that it reported storage problems when analysed via SCOM or the PAL tool. When Jetstress passed the storage they began further analysis…

This is the DB read latency from their first test with the Jetstress log interval set to the default of 15s. Nothing unusual to report and Jetstress passed the test. The chart looks good and the maximum latency values are all below 100ms.

The team were concerned by this and decided to reduce the log interval time within the Jetstress test XML file.

Was changed to

This reduced the sample interval time from 15s to 1s. The team then re-ran the test.

This chart shows the test data for the run with the LogInterval reduced to 1s. It is clear that something is different – the average values seem fine, however the maximum values are way over 100ms suggesting latency spikes - Jetstress failed the test due to disk latency spikes.

If we zoom in to this chart a little to get a closer look it is evident that there are a significant number of read latency spikes over 100ms during this 15 minute zoomed in window. Further analysis suggests that these spikes are observed throughout the test. The initial run with log interval set to 15s had totally missed these latency spikes.

Just in case my point about using the _Total instance wasn't clear earlier in this post I decided to add it in and highlight it on this example. Even though it is clear that this test is suffering from significant read latency spikes, the _Total instance (Highlighted in black) is smoothing this out and hiding those 100ms+ spikes. If you were only looking at the _Total instance you would have missed this issue, even with the reduced LogInterval time.

Conclusion and summary

Manual analysis of Jetstress test data is not always required, however it is often useful, especially if the storage platform is new to your organisation and you want to get a better understanding of how it is performing under load.

Manual analysis of test data during failure mode testing is very highly recommended. It is critically important that you understand how component failure will affect your storage performance under normal working conditions. The only way to do this is to take a look at the BLG data that was logged during these tests and assessing if that behaviour is acceptable for your deployment.

The default log interval time of 15s can mask instantaneous latency spikes. In most test cases this is not a problem, however I recommend that you reduce the log interval time down to between 2-5s where more granular data logging is desired; this is especially useful if you are using a shared storage platform or are using some form of advanced storage solution (Direct Attached Storage rarely requires this reduction in sample interval).

Note:

Reducing the LogInterval time in your Jetstress configuration XML file will significantly increase the size of your BLG file. A 2hr test at 2s interval will create an 800MB BLG file. This also has an impact on your ability to work with the data. Performance monitor can suffer from significant slowdown with very large BLG files.

Using Word 2010 with TechNet Blog Platform

Neil Johnson [MSFT] — Tue, 20 Dec 2011 09:46:20 GMT

This is obviously not a post about Exchange Server, but as a blogger I wanted to share this since it's been something that has been irritating me for some time…

Basically I like to write in Word rather than Live Writer. Live Writer is great but I spend a lot of time writing documentation in Microsoft Word 2010 and so that is my preferred writing tool. Most of my blog posts start off life in Word 2010 and then I have to transfer them over to Live Writer to get the content uploaded to my Blog. The problem is that the formatting is often lost during the transfer and I have to spend time trying to make it look how I wanted in the first place… surely there must be a way to get Word 2010 to write to my TechNet blog in the first place? Surely?? J

So… after some searching and some trial and error I have finally managed to come up with a solution to connect Word 2010 with the TechNet Blog platform…

Connecting Word 2010 to TechNet Blog Platform

Open Microsoft Word 2010
Click File -> New
Pick Blog Post from the Available Templates
Word should prompt you to Register a Blog Account at this stage
Select Register Now
In the Choose your blog provider drop down, select Other and click Next
Select MetaWebLog in the API type
Enter your TechNet blog URL with /metablog.ashx tagged on the end – in my case this ends up being http://blogs.technet.com/b/neiljohn/metablog.ashx
Enter your username and password

Click OK
Your TechNet Blog account is now registered in Word 2010

Hopefully someone else out there will find this useful J

Database Maintenance in Exchange Server 2010

Neil Johnson [MSFT] — Wed, 14 Dec 2011 14:56:20 GMT

If there is one area of Exchange 2010 that was poorly documented and poorly understood it has to be database maintenance. The problem stemmed from the significant changes that we made in the store for Exchange 2010 and a confusion of terms. This has led many people in the field to get confused about what is actually going on in the various database maintenance activities.

Well.. I am pleased to say that Ross Smith IV has written a fantastic article that explains what is actually going on inside these mystical processes and what they actually do for us…

http://blogs.technet.com/b/exchange/archive/2011/12/14/database-maintenance-in-exchange-2010.aspx

Exchange Server 2010 Service Pack (SP2) is released!

Neil Johnson [MSFT] — Tue, 06 Dec 2011 08:25:57 GMT

Last week when the internal announcement was made to say that SP2 had been completed and was scheduled for release, I added a few blog articles onto my “to do” list. Imagine my surprise this morning when I woke up to find that the internets were crammed full of SP2 news and that most of the articles I was planning to write, had already been written! (if only that happened with my design deliverables!)

So, I have decided to write a post today about all of the others posts instead.

Firstly here is a link to download SP2 if that's all you need – I still recommend that you skim through the release notes, even if you are progressing through your own test plan since it may save you some time.

http://www.microsoft.com/download/en/details.aspx?id=28190

Released: Exchange Server 2010 SP2

The Exchange Team Blog (this is owned by the Microsoft Exchange Server Product Group if you were not aware) announced the release of SP2 on Dec 5th at 6.38pm with the following post…

http://blogs.technet.com/b/exchange/archive/2011/12/05/released-exchange-server-2010-sp2.aspx

Some interesting things to note…

It requires a schema update (just like every other Exchange SP since 2007!)
It provides the following new features…

Exchange Server 2010 SP2 Release Notes

Before you consider deploying any new service pack for Exchange I strongly urge you to take a look at the release notes…

http://technet.microsoft.com/en-us/library/hh529928.aspx

For this release the following areas may require attention – all are discussed in the release notes.

Installation Prerequisites for Client Access Servers has changed
Possible issue with RBAC on non SP2 servers after upgrading one server to SP2 in the organisation
Outlook Web App redirection issue after upgrading to SP2
Mailbox Replication Proxy
Hybrid Configuration Wizard error with domains starting with a numeric value

It is worth noting here that Exchange Service packs are inclusive of all previous service packs and update rollups. This means that Exchange Server 2010 SP2 includes the fixes and changes up to and including Update Rollup 6 for Exchange Server 2010 Service Pack 1.

Exchange Server 2010 SP2 Internet Content

This is a subset of the non-TechNet material I recommend reading to get up to speed on Exchange Server 2010 SP2

Greg Taylor : Featuring GAL Segmentation (This is a TechEd recording on ABP’s)
Greg Taylor: Exchange Server 2010 SP2 and Support for Hosted Exchange
Henrik Walther: Changes to the MRSProxy Service Configuration
Tony Redmond – Installing Exchange 2010 SP2

Other Interesting Stuff

I spotted that we released a new version of the Exchange Server User Monitor yesterday also – I don't know if this is required if you deploy SP2 but I thought I would include it here just in case

Exchange Server User Monitor 14.2.247.5 (EXMON)

Hopefully this provides enough information in one place to save you searching the rest of the internet for your Exchange Server SP2 news

Exchange Service Availability….For the greater good…

Neil Johnson [MSFT] — Thu, 24 Nov 2011 10:51:08 GMT

I recently authored a post over at the Exchange Team Blog about Exchange ESE and Windows Disk Timeout values.

http://blogs.technet.com/b/exchange/archive/2011/11/17/windows-disk-timeouts-and-exchange-server-2010.aspx

Whilst writing that article and especially researching how ESE timeouts have evolved, I began thinking about the history of Exchange availability and how the product has evolved over my time working with it…

In the beginning…

Back when I began in enterprise infrastructure (1997) the name of the game was all about server uptime, not necessarily service uptime. What was interesting back then was that our servers were monitored for availability but we didn't have the technology to record service available very well. We didn't really have many options to improve our service availability with Exchange 5.5 – I used to pack out my servers with resilient components such as redundant network cards, power supplies and raid controllers to ensure that they would keep running for as long as possible, but if the server did go down our only option was to bring it back up as quickly as possible. My first concern during an outage was always the health of my 30GB EDB files – I knew that if one of these was damaged or the storage was unrecoverable then I was in for a minimum 10 hour restore from tape, I also knew that my manager would be pretty unimpressed when I delivered this news, so I would go to elaborate lengths to try and avoid it.

Towards the end of my time with Exchange 5.5 we were encouraged (by Microsoft) to look at clustering technology. I duly did this in my test lab (with real physical servers and a SCSI “Y” cable!) and I have to admit that I was pretty impressed initially. This clustering I would be able to tolerate an entire server failure and be back online in a few minutes. This was a huge step forward.

It was only when I started to write my business case to justify my new hardware requirements, I realised that over the previous two years all of my serious outages had come from storage issues (Raid controller firmware, cache failure, multiple HDD failure). I was hoping to use previous outage details to justify my request for new Exchange clusters, but the reality was that we had only had 1 real server failure (main board) and I was able to replace that fairly quickly with one from the test lab and it was back online in 2 hours. All of the serious service outages had come from storage related failures where i had to revert to tape restoration. I realised right at this point that clustering based on a shared storage model probably wasn't going to give me what i needed.

The next level…

A few years later I was going through the design phase for Exchange 2003. My primary goal for the new platform was to improve our service levels, which I was informed by our service delivery manager were fairly steady at 99% for messaging. I was still very aware at this point that to do this I needed to improve my restore times from tape. Some progress had been made with the switch to DLT drives, but my EDB files were growing at an incredible rate and it only took 18 months before my restore times were back at 10 hours per server again. I re-visited clustering during this timeframe but came to the same conclusion as before that it was just adding complexity and wasn't going to materially effect my service availability. Instead I chose some fancy SAN technology which allowed me to use snapshots to recover my EDB files in minutes rather than hours. This technology also allowed me to mirror my data off-site. Management were duly impressed with my solution, until they realised how much it was going to cost!. Still, they eventually implemented the design and service levels did improve somewhat (although not as much as I had hoped).

What I had totally neglected during this design was that my new storage technology was a lot more complicated than my old raid controllers were. I quickly discovered that it was very easy to break things on a monumental scale. One wrong command given to my clever new storage technology would be sufficient to stop the entire messaging service. This realization very quickly lead me to adopt the “if it isn't broke, don't fix it” approach to maintaining service. This brought its own issues though and I was faced with an annual update task to bring the messaging servers back inline with our enterprise standards, this was always a disaster and would entail almost a days worth of downtime while we tried to get the magical combination of OS hotfixes, drivers, firmware and SAN revision right. Then, once we had a shiny rack of twinkly green lights we would leave it alone for another year…

Clustering that works?

Exchange 2007 seemed to address all of my previous concerns. I was now working for Microsoft so I was getting to see lots of customers, all struggling with the same basic issue I had previously experienced as a customer, i.e how do we recover service quickly in the event of a database problem. Exchange 2007 seemed to solve this elegantly with the introduction of CCR clusters. I loved the simplicity of this solution – just copy all of the changes from the active server to the passive server and then fail over in the event of a problem. It meant that even in a serious failure scenario we could just bring up our passive copy and be back online in minutes! The solution was out-of-box and so there were no supportability issues either! Customers loved CCR and I thought it was the best Exchange feature ever developed.

Over time though I started to see issues with the CCR model. The most frustrating was that we had to fail the whole server over to the passive node. This meant that if we had a isolated storage failure on the active node we had a difficult decision to make… leave the users on the failed database offline until a maintenance window was available, or interrupt service for everyone on the server and fail its workload over to the passive node. Not a great position to be in and often it would depend “who” was on the failed database and how important they were, rather than anything more scientific!

Service Availability?

Exchange 2010 took the CCR model and addressed many of the issues reported by customers. Now we could fail over individual databases between server nodes. This was a huge step forward and meant that many customers were now actually hitting 99.9% availability. Given that best practices were followed it took an unusual situation to take Exchange 2010 offline for any significant period of time.

Over the past couple of years I have noticed some interesting service outages for my customers though. Given that the server experiences a clean failure of a storage component the database hosted on that storage will simply move to an alternate copy and service will be resumed. However, if the storage device does not fail cleanly and instead just begins responding slowly or intermittently the database will not simply fail over. This is quite common with JBOD or where the storage controller suffers an unusual failure, such as overheating or memory corruption.

Self Sacrifice

Now we return to the present day (well, earlier this year). I was in a storage design meeting with a customer and their core storage vendors. I began talking about changes in Exchange 2010 SP1 and how Exchange would force BSOD (bugcheck) a server if we didn't hear back from a LUN in 4 minutes. At this point I could hear a sharp intake of breath from pretty much everyone involved. The feeling in the room was that forcing a server to crash reboot was insane!

I began to question this behaviour myself and started to think back to some of the failures I had seen and how or if this behaviour would have helped. I have to admit that forcing a server to blue screen does seem pretty extreme, however upon reflection I came to the conclusion that I quite liked this behaviour. Given that we have multiple independent copies of our database in a DAG then would I rather a workload remained on a server with a storage I/O problem (4 minutes is a long time to get a response back from your storage!) or that it was moved to another copy? Well, obviously I want it to be moved and actually I'm not even sure i want to wait 4 minutes!

For me the decision is pretty obvious. If I have multiple independent copies of my databases, I want Exchange to switch over intelligently if it detects a problem with the currently active copy. It may seem counterintuitive to crash reboot a server hosting an active service to improve service availability, but the alternative is to leave the service running on a wounded server until a human being comes along and does the same thing. Frequently in my support days I would arrive in the datacentre to find a hung server with a black screen. I would try remote RDP access, maybe trigger a remote reboot via RPC but all too frequently once a server gets into this state you need to press and hold the big red button on the front to get it to come back up and begin troubleshooting the event logs. All of the time the server is in this hung state the service is unavailable. By triggering a bugcheck someone still needs to troubleshoot the root cause, but at least the service is only interrupted for a few minutes rather than a few hours…

Recommended Windows Hotfix for Database Availability Groups running Windows Server 2008 R2

Neil Johnson [MSFT] — Mon, 21 Nov 2011 23:01:45 GMT

Scott just posted this article up on the team blog..

http://blogs.technet.com/b/exchange/archive/2011/11/20/recommended-windows-hotfix-for-database-availability-groups-running-windows-server-2008-r2.aspx

A summary of the issue…

“This hotfix is strongly recommended for all database availability groups that are stretched across multiple datacentres. For DAGs that are not stretched across multiple datacentres, this hotfix is good to have, as well. The article describes a race condition and cluster database deadlock issue that can occur when a Windows Failover cluster encounters a transient communication failure. There is a race condition within the reconnection logic of cluster nodes that manifests itself when the cluster has communication failures. When this occurs, it will cause the cluster database to hang, resulting in quorum loss in the failover cluster.”

If you haven't already picked this up I strongly recommend taking a look and assessing if you need it on your production clusters.

Microsoft Lync 2011 for Mac and Office 365 Fix

Neil Johnson [MSFT] — Fri, 21 Oct 2011 15:13:33 GMT

Last month I wrote a blog about connecting Office 2011 for Mac to Office 365. This post generated a lot of interest within the community, but mostly for the wrong reason! i.e pretty much everyone that tried this was unable to connect Lync 2011 on Mac to Office 365.

The Lync engineering team have been working with a number of customer escalations and those of us with working test environments and non working environments.

Well, I am pleased to announce that the team have finally produced a fix for this and its available for download here…

http://support.microsoft.com/kb/2634523

“This update resolves an issue for users of Mac OS X 10.7.2 (Lion) that causes Microsoft Lync for Mac 2011 to close unexpectedly when you sign in. This update also resolves an issue that prevents users from signing in to Office 365. This update is required for all users who use Lync for Mac 2011 with Office 365. ”

I hope that this fixed the issues being experienced previously and now EVERYONE can enjoy Lync 2011 o Mac

A fix for the interoperability issues between Exchange 2007 and 2010 EMC and IE9 is now available

Neil Johnson [MSFT] — Mon, 17 Oct 2011 14:42:09 GMT

This has been irritating me more and more recently – I am generally quite a tolerant person, but sometimes its the smallest things that irritate you the most!. Anyway, it looks like there is a fix available.. I am out for most of this week without lab access so I cant test this, however I wanted to share it with as many people as I could!

http://blogs.technet.com/b/exchange/archive/2011/10/17/a-fix-for-the-interoperability-issues-between-exchange-2007-and-2010-emc-and-ie9-is-now-available.aspx

Outlook Performance Counters are missing–take 2

Neil Johnson [MSFT] — Wed, 12 Oct 2011 17:45:48 GMT

Back in the summer (remember that?) I wrote an article about viewing the Outlook performance counters and how to get them to be visible on Windows 7 and Vista.

I have recently noticed that there are further complications to this. On one customer site we could not get the Outlook performance counters to register, even after following the guidance in my previous post.

After some research today (huge thanks to Laurent Chaumien in support for finally resolving this!) it turns out that the performance counters are only visible if you are running the same version of perfmon (64-bit or 32-bit) as the version of Outlook (64-bit or 32-bit).

Lets take some examples…

Outlook 32-bit on Windows 32-bit – running Outlook as Administrator should enable the counters and make them visible.

Outlook 32-bit on Windows 64-bit – the default perfmon.exe here will be 64-bit and so will not be able to view the 32-bit performance counters registered by Outlook. To view these counters you need to run the 32-bit version of perfmon here : C:\Windows\SysWOW64\perfmon.exe

Outlook 64-bit on Windows 64-bit – both Outlook and perfmon are 64-bit and so once you run Outlook as Administrator the perfmon counters should be available.

Note: You must still run Outlook as an Administrator to enable the counters, in addition to using the correct instance of perfmon!

Hopefully that should work for everyone!

Exchange Server 2010 Cross Forest Delegation

Neil Johnson [MSFT] — Wed, 12 Oct 2011 16:45:31 GMT

This has been an interesting bit of work for me. I have been working with a customer who really needed to provide their users with the ability to manage calendars across different Exchange organisations. When they initially presented this requirement to me, my first thought was that we would be able to provide cross-forest availability sharing but that cross-forest delegation was not going to be possible…

So, as with most projects like this I began by asking my colleagues and quickly discovered that some thought it was possible and some thought it wasn't. This at least gave me the incentive to dig a little deeper to determine what we could and couldn't achieve. This digging discovered a few articles about ILM FP1 SP1 and FIM that showed a check box called “support cross-forest delegation (Exchange 2007 or 2010 only)”…

A little more research suggested that given a few pre-requisites it should be possible to achieve cross-forest delegation for Outlook users. This article will briefly go through the required steps and link to further information to assist with configuration…

Prerequisite requirements

To get cross-forest delegation to work the following prerequisites must be met…

Forest Trust between Forests
Cross-Forest Availability Configured
GALSYNC configured with either ILM FP1 SP1 or FIM 2010 (or manual cross-forest mail contacts created)
Exchange Server 2007 SP1+
Outlook 2007 SP1+

Forest Trust

Before we continue we need to establish a forest trust between the forests…

http://technet.microsoft.com/en-us/library/cc780479(WS.10).aspx

Cross-Forest Availability

The next step is to establish cross-forest availability. This provides users availability data between exchange organisations.

Note: The documentation in TechNet regarding cross-forest availability is particularly difficult to follow. Where the examples contain reference to the “Client Access Servers” group you must either create this group and add in your CAS servers or simply use “Exchange Servers” instead. Additionally the steps assume that your CAS servers are using public certificates that are trusted – if you are using an internal PKI CA you must ensure that all of your CAS servers trust the root CA.

http://technet.microsoft.com/en-us/library/bb125182.aspx

Here is my short-cut version of that guidance…

Run In the source forest

Add-AvailabilityAddressSpace -ForestName "TargetSMTPnamespace.com" -AccessMethod PerUserFB -UseServiceAccount $true

Run In the target forest

Get-ClientAccessServer | Add-AdPermission -AccessRights ExtendedRight -ExtendedRights "ms-exch-epi-token-serialization" -User "Source Forest\Exchange Servers"

Note: You must perform these steps in both forests for a 2-way configuration

Configuring cross-forest Autodiscover

$a = Get-Credential <Enter Administrator credentials in the remote forest when prompted>
Export-AutoDiscoverConfig -DomainController <Local GC> -TargetForestDomainController <Target GC> -TargetForestCredential $a -MultipleExchangeDeployments $true

So, by the time we get here it should be possible to lookup availability data for a user in the other forest.

GALSYNC

This is where the secret sauce happens for cross-forest delegation. Basically we are going to use FIM in this example to read in mailbox objects from each forest and create contacts in the target forest to build a common GAL for both Exchange Organisations.

The official guidance for configuring this is available here, however I have included my steps as well below

http://technet.microsoft.com/en-us/library/aa998597.aspx

The steps I follow are as follows…

Note: I generally create an OU in each forest called Contacts to receive contacts from FIM. These steps assume that you have created this OU already.

Open Synchronisation Service Manager (FIM)
Click on Management Agents
On the Actions Menu, click Create
Select Active Directory global address list (GAL) from the Management Agent drop down
Enter a name for this MA and click Next
Enter the forest name and credentials that this MA will retrieve information for and click next
In Select directory partitions enable the checkbox for the root of the forest
Click on Containers
Deselect all OU’s and manually select OU’s that contain mailboxes + ensure that the Contacts OU is checked and click ok
Click Next
Click Target, Click Container and Check the Contacts OU and click Ok
Click Source, Add Containers and check all OU’s that contain mailboxes, then click OK
Under Exchange configuration, click Edit, Add in the SMTP namespace you want the contacts to use that are created for this forest, click Add and finally OK
Check Route mail through this forest for all contacts created from contacts in this forest
Check Support cross-forest delegation (Exchange 2007 or 2010 only)
Click Next
Click Next until the Configure Extensions page is displayed
In the Exchange 2010 RPS URI: Enter http://<CAS Server>/Powershell
Click Finish

Repeat these steps for all forests.

Note: By default ILM and FIM have provisioning disabled, to enable provisioning click on Tools, Options and check the Enable Provisioning Rules Extension checkbox.

Once all MA’s have been created run the following profiles (Right click on the MA, select RUN)

Full Import (Staging Only)
Full Synchronization
Export
Delta Import

Finally check the contacts OU in each forest to ensure that FIM has populated it with contacts from the remote organisation. If there are problems, the first thing to do is check the event logs on the FIM server to begin troubleshooting…

User Experience

By this point you should now have a common global address list amongst your Exchange Organisations and if you look into the Contacts OU it should be populated with contacts from the remote organisations. If you look in the Exchange Management Console you should see that the contacts have been created as a Recipient Type of Cross-forest mail contact. This recipient type means that you can use this contact to assign delegate permissions.

In my lab I have two Exchange Organisations in two Forests

org4.lab (org4user1)
org5.lab (org5user1)

As a test I am going to delegate calendar editor permissions over org4user1’s to remote user org5user1. I did this simply by opening the delegates tab on org4user1’s mailbox and tagged in the contact for Org5user1.

I then logged on to the org5user1’s mailbox and attempted to open org4user1’s calendar. This worked as expected, so I then attempted to make changes to the shared calendar, again which worked as expected! result

Manually Creating a cross-forest mail contact

So this is an interesting exercise (interesting is relative here obviously, but lets go with it for now!). My current customer does not have FIM or ILM deployed to synchronise contacts between forests, however they wanted to enable cross forest delegation for a few users. We have a project planned to deploy FIM to solve this issue strategically but due to the importance of some of the users affected they really pushed me to come up with a temporary solution for cross-forest delegation.

My solution to this was to perform all of the configuration for cross-forest availability and then to manually create the cross-forest mail contacts in the target forest. The challenge of course was how to create a cross-forest mail contact!

After some investigation the following attributes looked to be of interest…

mAPIRecipient = TRUE
msExchMasterAccountSID = objectSID from Mailbox
msExchOriginatingForest = Target Forest FQDN
msExchRecipientDisplayType = –1073741818
msExchRecipientTypeDetails = 32768
proxyAddresses = X500: + LegacyExchangeDN from Mailbox; existing addresses

Here is an example…

Source Mailbox Attributes for Org4User1@org4.lab

legacyExchangeDN: /o=Org4/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1;
mail: Org4User1@org4.lab;
mailNickname: Org4User1;
objectSid: S-1-5-21-1575148580-663765585-2685387708-1129;

Cross-forest mail contact attributes for Org4User1@org4.lab

legacyExchangeDN: /o=Org5/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1;
mail: Org4User1@org4.lab;
mailNickname: Org4User1;
mAPIRecipient: TRUE;
msExchMasterAccountSid: S-1-5-21-1575148580-663765585-2685387708-1129;
msExchOriginatingForest: org4.lab;
msExchRecipientDisplayType: -1073741818;
msExchRecipientTypeDetails: 32768;
proxyAddresses (2): X500:/o=Org4/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Recipients/cn=Org 4 User 1; SMTP:Org4User1@org4.lab;
targetAddress: SMTP:Org4User1@org4.lab;

Conclusion for Cross Forest Delegation in Exchange Server

I must admit that I did feel like I had missed a day at school when I first started this. For me this is a huge feature area that is pretty poorly documented and even the fact that you can do cross-forest delegation is relegated to a one liner in TechNet under the cross forest implementation section.

However, the user experience is absolutely great once this is configured and in fact it is difficult to tell which organisation a user is from simply by the features you have enabled, i.e it doesn't really matter to a user where the people are that they are collaborating with, everything just works.

Update: Quite a few people have asked me about licensing for FIM when used only for GALSYNC. My understanding here is that the GALSYNC MA is free of charge and so the only thing you need to purchase is the FIM Server License (no CAL’s are required) + Server + SQL licenses.

This functionality was first made available in ILM FP1 SP1 and works with Exchange 2007 SP1 and Exchange 2010. The clients need to be Outlook 2007 or above.

Exchange 2010 MCM–Rotation 10

Neil Johnson [MSFT] — Thu, 06 Oct 2011 06:17:06 GMT

MCM Rotation 10 has just completed and was the first rotation that I have been involved as an instructor (albeit remotely on this occasion!). I noticed that Jeff Guillet had posted his experience here so I thought I would share it to give some more insight into what the program entails…

http://www.expta.com/2011/10/exchange-mcm-training-comes-to-end.html

I always like to read what others make of the program and in this case its particularly interesting since the program has changed structure recently and R10 is the first proper run through of the new material.

Building 40 – Exchange MCM candidates call this building home for 3 weeks!

Office 365–With Mac OS X Lion, Microsoft Office 2011 and Lync 2011 for Mac

Neil Johnson [MSFT] — Thu, 15 Sep 2011 10:22:47 GMT

Many of the customers I work with are currently making their way through an Office 365 technical pilot that needs to include Mac OS X machines as well as various versions of Windows. The Windows stuff seems fairly well documented and since we now have a GA release of Lync 2011 for Mac OS X I thought I would write a post about using OS X with Office 365…

Note: Most of this is documented on the following page, however it does not include Lync or any screenshots..

http://onlinehelp.microsoft.com/en-us/office365-enterprises/hh180727.aspx

Software requirements for Mac OS X and Office 365

There are some things that you need to know before rushing out to connect your Max OS X machines to Office 365. Firstly you will need a version of Outlook that supports Exchange Web Services (EWS). Older versions of Outlook for Mac used WebDAV which is not provided in Exchange Server 2010 and therefore is also not available in Office 365. Plus there are some minimum versions of Mac OS X and Browsers that are supported…

Microsoft Office for Mac 2011 Service Pack 1+
Microsoft Lync for Mac 2011 (v14.0.1)
Microsoft Office for Mac 2008 12.2.9+
Microsoft Entourage 2008 for Mac, Web Services Edition
Mac OS X 10.5.8+
Safari 4 or 5
Firefox 3.5 or 4
Chrome 3

Note: If you are using an internal CA for any of your Exchange or ADFS servers you must import the root CA certificate onto your Mac before working through these steps…

For the purposes of this article I will concentrate on Office 2011 since it represents the best end user experience and it is also the version I have the most experience with (and happen to have handy!).

Connecting to Office 365 Web Portal

OK, so this bit isn't very exciting however it is always my first step since it proves that my Office 365 account credentials are good and that the Mac has connectivity to the Office 365 service and ADFS.

Open your browser (In this example I am using Safari 5)
Navigate to https://portal.microsoftonline.com
Login with your Office 365 user credentials
Click on the Outlook link to connect to Outlook Web Access
Select the Language and Time Zone preferences (if prompted)

Assuming everything went well, you should now be looking at your Office 365 users Outlook Web Access page via OS X Safari! For some of my customers this is actually “good enough”, however for the large majority they need the rich experience provided by Outlook and Lync on their Mac… so we need to continue on

Connecting Outlook 2011 for Mac to Office 365

Ok, so we have already connected to OWA via Safari so the next thing to do is configure Outlook. When you start Outlook for Mac 2011 the first thing it will ask you to do is to Add Account…

Click the checkbox to make Outlook the default application for e-mail, calendar and contacts then click Add Account

Once the Add an Account page is displayed, click on Exchange Account
Fill in your account details on the Exchange Account Information Page, ensure that Configure Automatically is checked and then click on Add Account

Outlook will warn you that your AutoDiscover request has been redirected to a different server
Ensure that the Always use my response for this server checkbox is checked and click on Allow

At this point Outlook will reconfigure itself to connect to your Office 365 mailbox by using the data from AutoDiscover
I typically also change the Account Description on the next page to show that it is an Office 365 Account

Close the Accounts Window and Outlook should show as connected and begin synchronising your mailbox content…

Connecting Lync 2011 for Mac to Office 365

NOTE: Lync 2011 requires an update to connect to Office 365 which is provided here…

http://support.microsoft.com/kb/2634523

I have to admit that despite being a Microsoft Employee I am also a Mac user (occasionally anyway) and for me Lync was the missing piece of the puzzle for making a Mac a usable experience.

Anyway, enough of that lets move on to connecting Lync…

Start Lync for Mac 2011
The first thing that Lync will ask is to set it as the default application for presence – if you want presence information then select Use Lync
The next screen will be the Lync for Mac 2011 login screen
Click on the Advanced icon at the bottom

Click on the Advanced button at the bottom of the Lync client
Set Internal Server name to sipdir.online.lync.com:443
Set External Server name to sipdir.online.lync.com:443
Click OK

Enter your login account details and password
Check the Remember my password checkbox and click Sign In

If everything went to plan, you should now see your Microsoft Lync for Mac 2011 client open up and show as connected!
I suspect this isn't actually that exciting to everyone, but I (and some of my customers) have been waiting for nearly a year to get this far!

The screenshot below shows my OS X Lion desktop connected to Microsoft Office 365 via a federated Active Directory account… and who says Microsoft and Apple cant work together!

Conclusion

As a regular Mac and Windows user it is vital to me that my systems are able to collaborate and share data effectively. It is also vital that I am able to communicate and collaborate effectively with my colleagues running Windows or Mac machines. I have to say that prior to having Lync my Mac experience was definitely lacking… however now I can connect Outlook and Lync to Office 365 I am able to function just as effectively on my Mac as I am on my Windows 7 machine. Being able to join conference calls, share my desktop etc even when I am on my Mac is a huge improvement to my productivity…

Having worked with a few customers who have a Mac OS X community to support I have to say that connecting them to Office 365 has been relatively painless… in fact it is arguably easier to connect a Mac running Office 2011 to Office 365 than Windows; largely since OS X doesn't require any patch updates or the Windows Live Sign In Assistant to connect reliably. The biggest problem area that I have seen is that organisations who have chosen to use their internal CA to issue certificates for their internal Exchange and ADFS services, must remember to import the root CA certificate on every new Mac that is deployed… failure to do this leaves the machine unable to authenticate to ADFS and AutoDiscover failing to configure Outlook.

Overall though I have to say that this is great work from both the Office 365 and Office 2011 for Mac teams…!

Office 365 User Community in the UK

Neil Johnson [MSFT] — Mon, 05 Sep 2011 10:44:58 GMT

Brett Johnson brought this to my attention last week – Way back at the beginning of this century I was a part of the NetApp user group and I found it a hugely rewarding experience. Since joining Microsoft I try to support all of our independent user groups for Exchange and UC where I can.

I am really pleased to see an open user group for Office 365! My experience with these user run community groups is that they are a great way to meet other Administrators and technical professionals facing the same challenges as you are. It is incredibly useful to be able to talk through your plans and problems with other like minded individuals.

http://www.office365usergroup.co.uk/Pages/default.aspx

Register Your Attendance Here…

http://www.office365usergroup.co.uk/Pages/default.aspx

Agenda

Welcome (Microsoft)
Microsoft Session: (Microsoft)

Where are we with Office 365..? Facts and Figures
Introductions to the Office 365 Team in the UK
Customer Decision Framework
BPOS to Office 365 Transitions

AvePoint and Office 365: (AvePoint - Dawid Kozlowski)
Office 365 Lessons Learnt: (Tony Sloggert/Andy Hutchins – Avanade)
Office 365 and the hybrid organisation: (Ant Clay – 21 Apps)

Office 365 Service Accounts–How do I stop DIRSYNC from breaking every 90 days…

Neil Johnson [MSFT] — Mon, 05 Sep 2011 09:56:21 GMT

So, this is something I wanted to blog about a few months ago but it got pushed to the bottom of the list of things to do (As usual!).

Anyway… during the early adopter testing of the Office 365 service we had a number of customers who had deployed what was termed “Exchange Rich Coexistence” or “Hybrid” as it is termed now. At the time (12 months ago now!) the documentation to get this up and running was fairly patchy and it took quite a bit of trial and error to get things working as people wanted. However, most customers managed to get things working after 4 weeks or so and were able to begin testing…

Then came the problem… we had talked most of our customers through deploying DIRSYNC at around the same time (within a few days of each other), imagine our confusion when they all stopped working at pretty much the same time! Lots of red errors in the event logs… this was one of the errors from my test lab…

OK, so its pretty clear that we have an authentication problem, but which credentials, our terra-firma or cloud? and how do I fix it?

Well, it turns out that the the problem is pretty predictable… its caused by the 90 day password expiry policy applied to all Office 365 managed accounts, this will happen repeatedly every 90 days. In the case of our early adopters they all hit this within 2 days of each other because everyone was so keen to get up and running that they pretty much all installed DIRSYNC as soon as we made the code available!

Luckily we have a couple of ways around this…

Establish an operations process every 90 days to change the password and reconfigure DIRSYNC
Create a service account for DIRSYNC and disable password expiry

For this blog I will concentrate on option 2 and how to reconfigure DIRSYNC after you have created a new account.

Note: If you can create this managed account before setting up DIRSYNC for the first time, then you wont have to visit it again!

Creating an Office 365 service account for DIRSYNC…

The first thing we need to do is to create an Office 365 managed account to use for DIRSYNC. I find it easiest to do this in the GUI.

Login to https://portal.microsoftonline.com as a tenant Administrator
Under the Management menu, click on Users
Click on New, then select User from the drop down
Enter the appropriate details for the new user account and click next
Assign the new account “Global Administrator” rights
Complete the user creation process (You do not need to assign this user an Office 365 License!)
Make a note of the temporary account password
Start IE in “InPrivate” mode and browse to https://portal.microsoftonline.com
Login with your new DISRYNC service account
On first login Office 365 will prompt you to change the password
Verify that you can logon to the Office 365 portal with your new account

Re-configuring DIRSYNC to use the new Office 365 service account…

Before we can complete this section, we are going to need a few bits of information…

Local Active Directory Enterprise Administrator Account details and password
DIRSYNC service account details and password in Office 365

Process…

Logon to your DIRSYNC server
Open Start –> All Programs > Microsoft Online Services –> Directory Synchronization : Directory Sync Configuration
Click Next at the welcome screen
Enter your new DIRSYNC service account details into the Microsoft Online Services Administrator Credentials box
Click Next (DIRSYNC will validate your credentials)
Enter your existing Enterprise Administrator Credentials into the Active Directory Enterprise Administrator Credentials box
Click Next (DIRSYNC will validate your credentials)
Enable the "Rich Coexistence” checkbox if you are deploying in “Hybrid” and want AD write-back
Click Next
DRSYNC Will re-configure itself to use the new account
Ensure that the Synchronize directories now checkbox is checked and click “Finish”
Start Event Viewer and open the Application Log
Look for Directory Synchronisation Events 1 – 4 (4 means its finished “Export has completed”)

OK, so now we have a new account dedicated for DIRSYNC, but its password is still going to expire in 90 days…

Disabling password expiry on your Office 365 DIRSYNC service account…

Now, before we go through these steps it is important to realise that disabling your DIRSYNC service account password expiry has some obvious security risks involved. This is a powerful account with full rights to your tenant, if it gets compromised then so does your entire tenant! Make sure that you fully understand these risks before continuing and discuss appropriately with your security team.

OK, so assuming you have decided to go ahead this is what we will need…

Install the Microsoft Online Sign-In Assistant

Install the Microsoft Online Services Module for PowerShell

Launch a PowerShell Window and run the following commands…

   1: Import-Module msonline

   2: $cred = Get-Credential

   3: Connect-MsolService -cred $cred

   4: Get-Command –Module msonline

Once connected we have access to some new MSOL Remote PowerShell cmdlets. We are going to make use of the get-msoluser and set-msoluser cmdlets.

Firstly, lets take a look at our DIRSYNC service account as it was originally created

get-msoluser –userprincipalname dirsync@neiljohn.onmicrosoft.com | fl

   4: ExtensionData               : System.Runtime.Serialization.ExtensionDataObject

   5: AlternateEmailAddresses     : {dirsync@neiljohn.onmicrosoft.com}

   6: BlockCredential             : False

   7: City                        :

   8: Country                     :

   9: Department                  :

  10: DisplayName                 : DIRSYNC Service Account

  11: Errors                      :

  12: Fax                         :

  13: FirstName                   : DIRSYNC

  14: ImmutableId                 :

  15: IsBlackberryUser            : False

  16: IsLicensed                  : False

  17: LastDirSyncTime             :

  18: LastName                    : Service Account

  19: LicenseReconciliationNeeded : False

  20: Licenses                    : {}

  21: LiveId                      : 10033FFF80B3EF03

  22: MobilePhone                 :

  23: ObjectId                    : d756d167-fcf3-4505-99e2-fd1100952182

  24: Office                      :

  25: OverallProvisioningStatus   : None

  26: PasswordNeverExpires        : False

  27: PhoneNumber                 :

  28: PostalCode                  :

  29: PreferredLanguage           :

  30: State                       :

  31: StreetAddress               :

  32: StrongPasswordRequired      : True

  33: Title                       :

  34: UsageLocation               : GB

  35: UserPrincipalName           : dirsync@neiljohn.onmicrosoft.com

  36: ValidationStatus            : Healthy

As you can see from the output, PasswordNeverExpires is to to False, this means that our service account user will inherit the standard 90 day password expiry policy. To change this we need to issue the following command…

Set-MsolUser -UserPrincipalName dirsync@neiljohn.onmicrosoft.com -PasswordNeverExpires $true

If we then repeat the earlier command, we can see that now PasswordNeverExpires is now set to True

   1: ExtensionData               : System.Runtime.Serialization.ExtensionDataObjec

   2: AlternateEmailAddresses     : {dirsync@neiljohn.onmicrosoft.com}

   3: BlockCredential             : False

   4: City                        :

   5: Country                     :

   6: Department                  :

   7: DisplayName                 : DIRSYNC Service Account

   8: Errors                      :

   9: Fax                         :

  10: FirstName                   : DIRSYNC

  11: ImmutableId                 :

  12: IsBlackberryUser            : False

  13: IsLicensed                  : False

  14: LastDirSyncTime             :

  15: LastName                    : Service Account

  16: LicenseReconciliationNeeded : False

  17: Licenses                    : {}

  18: LiveId                      : 10033FFF80B3EF03

  19: MobilePhone                 :

  20: ObjectId                    : d756d167-fcf3-4505-99e2-fd1100952182

  21: Office                      :

  22: OverallProvisioningStatus   : None

  23: PasswordNeverExpires        : True

  24: PhoneNumber                 :

  25: PostalCode                  :

  26: PreferredLanguage           :

  27: State                       :

  28: StreetAddress               :

  29: StrongPasswordRequired      : True

  30: Title                       :

  31: UsageLocation               : GB

  32: UserPrincipalName           : dirsync@neiljohn.onmicrosoft.com

  33: ValidationStatus            : Healthy

OK, so now we are done! DIRSYNC will no longer require that your account password is changed every 90 days.

Conclusion

This is a more interesting topic than I had originally, thought, the actual process to configure a service account without password expiry is relatively quick and simple, however there are significant security implications from having an Office 365 account that never requires its password to be changed with such high access rights.

For me what this configuration does is to put the control back into the hands of the Administrator – you now have control over when you change your service account password. My experience with fixed password expiry on service accounts is that eventually the password will expire when the person responsible for that service is on leave or away sick and nobody else knows what to do – this is a recipe for further disaster.

I would recommend combining this solution for disabling password expiry with an operations process to change the password regularly. This process should be documented clearly and executed regularly to meet your security policies. This approach gives you the flexibility of being able to choose your own account password change policy, without the risk of the password expiring and stopping your directory sync process from working.

Office 365 Hybrid Configuration Certificate Planning–ADFS, Exchange Web Services, OWA, OA??

Neil Johnson [MSFT] — Thu, 25 Aug 2011 12:32:53 GMT

I recently wrote about configuring Office 365 hybrid to get cross premises availability working, since that article a number of people have asked me about certificate planning. This is pretty well understood for an Exchange deployment, but what names are required for an Office 365 Hybrid configuration during a migration?

Certificate Requirements in Office 365 Hybrid Configuration

The easiest way to determine your requirements is to make a list of client and service SSL endpoints that will be required on premises. For this example I will continue with my lab namespace of groovycloud.co.uk

Let’s walk through the services and where they are required in more detail…

ADFS 2.0

Active Directory Federation Services (ADFS) is used to provide a single identity to which users can logon and access both Office 365 service and on-premises services. This is generally a desired requirement for most deployments to avoid users having to remember multiple sets of account details. If you are deploying ADFS for Office 365 then you need to plan for a certificate to publish the ADFS 2.0 server externally, even if you only have on-premises clients (this is a relatively complex discussion, however the bottom line is that until SPNEGO is enabled all clients authenticating via ADFS will authenticate directly to Office 365 with basic credentials, Office 365 will then attempt to validate those credentials via your externally published ADFS namespace).

Exchange Web Services

Exchange Web Services (EWS) is used by many clients and services to gain access to Exchange 2010. Office 365 hybrid configurations uses EWS to provide cross premises availability (Free/Busy) and also to perform cross organisation mailboxes moves via the mailbox replication service. If you are planning an Office 365 Hybrid Configuration you must plan for a certificate to publish the EWS endpoint externally.

Outlook Web Access

Outlook Web Access (OWA) is used by many organisations to provide lightweight browser access to the messaging service, both internally and externally. If you are planning to co-exist OWA on-premises with OWA in Office 365 it is highly likely that you will want to plan for a certificate to publish OWA externally to provide a single OWA URL for all users.

Outlook Web Access (Legacy)

Outlook Web Access (OWA Legacy) is used to redirect users hosted on legacy versions of Exchange by Exchange Server 2010. This is required if you will have OWA users on both Exchange 2003 and Office 365. By moving your primary OWA namespace to your Exchange 2010 Hybrid server it is possible for end users to be redirected to both Exchange 2003 OWA and Office 365 OWA depending on where their mailbox is stored. If you are migrating from Exchange Server 2003 and are using OWA it is highly likely that you will require this and should plan for a certificate to publish your OWA Legacy namespace externally.

AutoDiscover

Office 365 uses AutoDiscover to determine the correct EWS endpoints to use for your on-premises infrastructure during the initial organisation relationship creation. Additionally external AutoDiscover aware clients will need an on-premises AutoDiscover service to query during Hybrid coexistence, even if their mailbox is running in Office 365 (The on-premises AutoDiscover service will either service the request locally or redirect the request to Office 365 if the mailbox is not hosted locally). If you are using clients that support AutoDiscover it is highly recommended that you plan for a certificate to publish AutoDiscover namespace externally.

Outlook Anywhere

If you have Outlook Anywhere (OA) clients configured already then you will have already planned for and deployed a certificate for this service. There is no need to change this name during Hybrid Coexistence, however if you are planning to request a new certificate you should ensure that you include your OA namespace on the certificate to ensure that the service continues to function.

Transport

One area that often gets missed during certificate planning is the certificate required to establish secure SMTP transport between on-premises and FOPE for your Office 365 tenant and vice-versa. It is beyond the intended scope of this post to discuss secure transport; however you should plan for it if you intend to run in prolonged hybrid coexistence. I have included a link below to a TechNet section to help with this planning.

Note: For further information see the following links…

OK, so now I know what my Office 365 Hybrid certificate requirements are… where should I install it/them?

This is where things get more interesting. In my lab environment things are really easy… I have a single TMG server that I use to publish my Exchange Services and an ADFS 2.0 Proxy server that I use to publish my ADFS services. So, I requested a single UCC certificate with the following four names…

sts.groovycloud.co.uk
mail.groovycloud.co.uk
legacy.groovycloud.co.uk
autodiscover.groovycloud.co.uk

I then installed the certificate onto my TMG and ADFS Proxy + ADFS 2.0 servers. To make this work I also had to configure an internal Windows Certificate Authority and deploy certificates on my internal servers and ensure that my TMG server trusted the internal Certificate Authority by importing the trusted root certificate from my CA. This deployment obviously requires two public fixed IP Addresses to publish both TMG and ADFS.

Note: It is possible to do this just with TMG, however you will need to disable pre-authentication and HTTPS protocol checking on the publishing rule for ADFS which essentially means that TMG is just passing the TCP request straight through to your internal ADFS 2.0 server. This is potentially acceptable in a PoC Lab but extremely unwise for production.

This is actually how many of my customers have also deployed their certificates. Where things become more complex is if there is no internal CA…

Using the same public certificate for Office 365 Hybrid internally and externally…

OK, so you don’t have an internal PKI or Windows CA to provide you with internal certificates. This means that you are going to need to use the same public certificate on all of the servers… this also means that you need to use the same URL’s for your Exchange services internally and externally so that the requests match the names on the certificates…

If your environment is very simple (like my lab for example) and you have split brain DNS then you could get away with just installing the public certificate onto the internal servers as well. Make sure that if you do this that you change your Exchange Server 2010 Virtual Directory Internal URL’s to match the names on your certificate and create the appropriate DNS entries to point to your Exchange Server 2010 coexistence server, otherwise your clients will get certificate warning errors if they attempt to connect to the internal AutoDiscover service for example… (Not nice!).

If your internal environment is more complex and/or you do not have split brain DNS (this means you cannot use the same URL for your services internally and externally) then you will need to use multiple certificates. If you are in this circumstance I recommend that you plan for your internal certificate requirements first and then add on your Office 365 Hybrid requirements. Once you have a combined list of names it is much easier to plan your certificate locations and generate the requests accordingly.

The most important thing is to determine your requirements and conduct an appropriate planning exercise – a large number of support cases are caused due to inadequate certificate and namespace planning for Exchange and Office 365 Hybrid.

A word of warning about certificates for Office 365 in Hybrid Mode…

I was recently working with a customer who had deployed their user pilot for Office 365 in Hybrid Mode in a very similar way to the configuration that I use in my lab; the one exception was that they had used an internal certificate on their ADFS 2.0 server. This solution had been working for several weeks quite nicely. One Monday morning they called me up and said that nobody could logon to Office 365 via their federated identities. We did some troubleshooting and their ADFS 2.0 server was getting the requests for authentication but not sending back the necessary SAML token. Further analysis showed that their internal certificate authority certificate had expired!

They have since taken steps to monitor this more closely, however it does highlight one extremely important point… if you are using ADFS for federated identities the ADFS service must be available at all times, any interruption of the ADFS server will result in Office 365 service downtime for your end users. In this case the customer had a well drilled high availability solution deployed for ADFS to avoid this situation and yet a simple certificate error still caused them several hours of downtime…

Office 365 Microsoft Office Services Diagnostics and Logging (MOSDAL) Tool 3.2–With ADFS 2.0 Diagnostic tools

Neil Johnson [MSFT] — Wed, 24 Aug 2011 17:22:03 GMT

The Microsoft Office Services Diagnostics and Logging (MOSDAL) tool has been around for a while, certainly most BPOS customers will have come across it before… however it has now been updated to provide AD FS authentication diagnostic information so its now useful for Office 365 deployments as well!

Deploying ADFS for Office 365 is a relatively trivial process, although when things do go wrong they can be complex to troubleshoot. If you are in this position, then get the new version of MOSAL and see if it can help you out…

http://support.microsoft.com/kb/2598459

Microsoft Certified Master Exchange Server –2 years later…

Neil Johnson [MSFT] — Wed, 17 Aug 2011 16:47:24 GMT

All the way back in May 2009 I had just completed my Exchange 2007 Microsoft Certified Master rotation in Redmond, on my return I decided that I would write up my experience… it was actually quite emotional re-reading this post, many of the people I went through this experience with are now good friends, which is one thing I didn't expect when I turned up at building 40 in 2009…

http://blogs.technet.com/b/msukucc/archive/2009/05/05/microsoft-certified-master-exchange-2007-a-survivors-guide.aspx

The reason for this post is that we have had a few new starters into the MCS UC and Messaging team recently and all except one (who is already MCM) they all want to go through the Microsoft Certified Master program. This has given me cause to reflect on the program itself and what it has meant to me over the last two years… firstly to assess if it was worthwhile me attending and secondly to help me figure out if its necessarily right for everyone…

What has happened to me in the two years since passing Microsoft Certified Master?

Well, I have certainly been involved in some things that I don't think that I would have been without being a part of the MCM Exchange community. From a community perspective I was able to write the Jetstress Field Guide, which was only really opened up to me by having a number of storage performance cases in the UK escalated and as the only Exchange Server 2010 MCM in MCS UK at the time I was the person tasked with sorting them out… working through these cases I was able to work with the MCM Exchange community and the Exchange product group and eventually the field guide was born… likewise working with Ross Smith IV on the database copy distribution section of his Mailbox Role Calculator mostly came about from discussions within the MCM community (of which Ross is a long standing member).

In addition to the community work I have been involved with some of the largest and most interesting Exchange challenges in MCS UK – it is a common practice now for our more demanding enterprise customers to request a “Ranger/MCM” for their projects. Being a part of such a community helps to keep you in demand… which is always good in consulting!

I also attended the Exchange Server 2010 MCM upgrade back in June 2010 – this was an experience I will never forget and made the main rotation seem quite relaxed in comparison.. essentially the upgrade rotation ran through the full 2010 rotation materials and exams, but condensed it into 5 days rather than the usual 15… by the end of it we were all like zombies!

Recently I also went through the MCM Office 365 training… despite working with Office 365 since the very early CTP days almost 12 months ago, this 5 day training course in Redmond was extremely rewarding. It was run at the usual very high MCM level and the class only consisted of other Exchange MCM’s. Access to this kind of training is invaluable – it simply does not exist anywhere else in the world…

Was Microsoft Certified Master worth it?

When I think about the cost of the program its obviously expensive, both in terms of the outright cost and in terms of your own emotional and personal commitment. At the time I went through MCM in 2009 it was provided free for internal candidates, this is no longer the case and we have to generate a business case for attending the rotation, additionally I think that many people do not realise just how much personal commitment is required to be successful with this qualification. Simply having some Exchange experience and attending the course is unlikely to result in a happy ending… strangely most of the criticism that I see aimed at the MCM program seems to suggest that you are buying a qualification… I can assure you that this is most certainly not the case and I know of a number of candidates that attended an MCM rotation and are still working on passing the exams months later…

So… given the expense and commitment required is it worth attending? I think the answer here depends on how you view your career. For me it was definitely worthwhile, I wanted to step up from the background and establish myself as a technology leader. Passing MCM definitely provides a level of kudos with your colleagues and customers that very few other qualifications can match. Sure, it was tough to convince my management to pay for me to attend (lost revenue, flights + expenses, etc.) and it was even tougher to actually pass, but I think it has repaid me hundreds of times over by making it possible for me to engage on larger, more complex projects because I was now seen as a more established consultant due to having the MCM badge. On the other hand, if you are not aspiring to take on larger, more complex projects and engage with your community peers at a worldwide level, then I would question if MCM is the right path to take. Fundamentally you need to ask yourself why you want to join the MCM community and how much effort are you prepared to put in to join?

Microsoft Certified Master Preparation

One of the common questions I am asked is how to best prepare for an Microsoft Certified Master rotation? On the surface this seems like a sensible question, but the problem is that the answer is often different for each person.

For sure the most difficult aspect of the Exchange MCM is the practical lab at the end of the course – sure, some people find this easier than the exam process, but for the majority it seems to be the hardest part. So, I would say that not only do you need to know the technology, you need to be competent at hands on configuration and troubleshooting… you also need to be able to do it quickly, very quickly!.

One bit of advice I do give is that before you attempt a rotation you should be in a position to be able to talk about almost any area of Exchange confidently, in front of your peers and be able to demonstrate your understanding practically. For example, could you explain how cross forest availability works and the requirements to your colleagues right now? and then actually configure it in less than an hour? Take this and apply it to pretty much any area of Exchange and when you get to a topic that you think you couldn't do it, that's something you need to learn before turning up in rainy Redmond…

Conclusion

On balance I think that attending the Microsoft Certified Master program was the right thing for me to do. It was an extremely demanding, but rewarding experience and the returns it has provided me in terms of career growth have been immense. So, on that basis I would say that if you were looking to move up to the next level in your career and were prepared to put the effort in, then MCM is a great way to go. However, it is not necessarily right for everyone… I tend to view MCM as the PhD of the Exchange Server world… and just as in every other field, not everyone needs to hold a Doctorate in their area of expertise to be successful…

Microsoft Certified Master – An Insiders View

Bojan’s journey to MCM

And of course keep up to date on the MCM program by following the Master blog.

http://blogs.technet.com/b/themasterblog/

Office 365 Hybrid Deployment / Exchange Rich Coexistence – Sharing Availability (Free/Busy)

Neil Johnson [MSFT] — Mon, 15 Aug 2011 05:56:51 GMT

** Updated 24-08-2011 to include enable-OrganizationCustomization step as an optional extra.

I have been working with a number of customers and consultants recently who have been keen to explain to me just how difficult they are finding the configuration of Exchange Rich Coexistence or Hybrid Deployment as its now known with Office 365, and to be fair I agree, its definitely not as simple as we would like. We do have improvements coming in Exchange Server 2010 SP2 that will simplify this process, but I thought that I would post this to attempt to help out with some basics…

What is Office 365 Hybrid Deployment?

During the early adopter programs and beta this was known as Exchange Rich Coexistence and it is essentially a way to share availability data between your on premises Exchange Organisation and your Office 365 tenant. This type of deployment is extremely useful both for large migrations and where organisations wish to split their users permanently into a hybrid configuration, where some users are provisioned in the Office 365 service and some remain on premises. The basic idea behind the solution is that users shouldn't need to know where their mailbox is located and instead should just be able to arrange meetings and see availability data for everyone, regardless of their location.

What do I need to make it work?

To keep this post relatively brief I have decided not to walk through tasks that are relatively well understood, such as installing Exchange Server 2010 and publishing EWS. Instead I have assumed that several tasks have already been completed…

Cross organisation availability sharing uses the availability service, which is built on Exchange Web Services (EWS). This means that your on premises Exchange organisation must have a published EWS endpoint with a valid public certificate attached, plus a few other things.

So.. with that in mind, this is what we really need…

Admin access to your Office 365 tenant
Admin access to your Exchange organisation on premises
Ability to edit your DNS Zones
An established Microsoft Federation Gateway Trust
A published EWS endpoint with public certificate
An Exchange Server 2010 deployed into your on premises Exchange organisation

In reality of course most Office 365 enterprise deployments require ADFS and Directory Synchronisation to meet design requirements, which adds to our list..

ADFS 2.0
Directory Synchronisation

Note: Since all of my customers are working with ADFS and Directory Sync the rest of this post assumes that you have already configured them and they are working correctly…

Prerequisite Tasks…

It is assumed that the following tasks have been completed…

Trust has been established with the Microsoft Federation Gateway : http://technet.microsoft.com/en-us/library/dd335198.aspx
All required SMTP domains have been verified in Office 365
Exchange Web Services have been published on premises : http://blogs.technet.com/b/exchange/archive/2010/07/16/3410408.aspx
ADFS 2.0 is configured and working
Directory Synchronisation is configured and working

Pre Flight Checks…

Before we begin it is important that we verify that a few things are working….

Microsoft Federation Gateway Trust
To test the MFG trust we need to issue the “test-federationtrust” PowerShell commandlet from our on premises Exchange Server 2010 server… it is vital that all of the test outputs show as “Success”

Exchange Web Services
To test Exchange Server 2010 EWS on premises use the Exchange Remote Connectivity Analyzer…

Complete the “Microsoft Exchange Web Services Connectivity Tests”

TIP: The EWS test requires an empty mailbox, so create a new “ewstest” mailbox and logon to it via OWA or Outlook prior to running the test to ensure that it is functioning properly… once you have logged on to the mailbox and checked that it is empty, then progress on to the RCA EWS test…

Configuration…

OK, so now we are ready to begin some configuration… we will follow this order to get things up and running…

Create service domain
Create on premises –> Office 365 organisation relationship
Create Office 365 –> on premises organisation relationship
Test

Create service domain

The service domain is used primarily for forwarding SMTP E-mail from on premises to the Office 365 tenant. We cannot use the *.onmicrosoft.com namespace given to all users since that name is blocked from the Office 365 DIRSYNC process. This is a problem since we need to stamp the service domain as a proxyAddress for all on premises users to ensure that when we migrate a user and set the service domain to be the targetAddress it matches the right user in the Office 365 tenant. The service domain also acts as targetAddress for availability requests for Office 365 mailbox.

TIP: To make things easier it is recommended to use a subdomain of your primary SMTP domain for the service domain. In my lab the primary smtp domain is groovycloud.co.uk, so I will use service.groovycloud.co.uk as my service domain.

Use the following blog to establish a remote PowerShell session to your Office 365 Tenant –

NOTE: This is NOT the same as connecting to your Exchange tenant PowerShell in Office 365..

http://blog.powershell.no/2011/05/09/administering-microsoft-office-365-using-windows-powershell/

Tip: This is a useful thing to remember, so save the blog URL for future administration tasks with Office 365…

Once you have established your Office 365 remote PowerShell session, lets check some settings by running…

Get-MsolDomain –DomainName <primary SMTP domain>

We are looking primarily for the authentication type of the parent domain, in my case it is a federated domain that passes authentication requests back to an on premises ADFS 2.0 infrastructure.

Now we can create our service domain. Note that you need to replace the Authentication type to be the same as reported in the previous step.

Add-MsolDomain –name service.<primary SMTP domain> –Authentication federated

Note: Since this is a subdomain of a previously verified domain, Office 365 will not require that you re-verify the domain.

Now we have our service domain, we need to provide it with DNS information for MX record to ensure that SMTP traffic destined for the domain is routed appropriately and an Autodiscover CNAME record to ensure that Autodiscover works correctly…

Contact your DNS Registrar and ask for the following records to be created…

Create MX Record for your Service Domain that points to : mail.outlook.com
Create CNAME record in your Service Domain for “autodiscover” that points to : autodiscover.outlook.com

Note: You can continue the configuration while waiting for these records to be created.

The final things we need to do with our service domain is to add it as a Remote Domain, Accepted Domain and add a proxyAddress for our on premises Exchange users.

Adding the Service Domain as an Accepted Domain…

new-AcceptedDomain -Name 'Office 365 Service Domain' -DomainName 'service.groovycloud.co.uk' -DomainType 'InternalRelay'

Adding the Service Domain as a Remote Domain and setting it as our “BPOS” Domain (TargetDeliveryDomain $true)

New-RemoteDomain -Name 'Office 365 Service Domain' -DomainName 'service.groovycloud.co.uk'
Set-RemoteDomain -Identity 'Office 365 Service Domain' -TargetDeliveryDomain $true

Adding the service domain to all users proxyAddresses…

The easiest way to achieve this is to edit the E-mail Address Policy. In my case I only have a single “Default Policy”, so I will add the service domain in there…

Tip: If this is the first time you have attempted to edit your E-mail Address policy since installing Exchange Server 2010 you may need to upgrade it. If like me you only have a single policy you can upgrade with the following Exchange Server 2010 PowerShell command…

Set-EmailAddressPolicy "Default Policy" -IncludedRecipients AllRecipients -Confirm:$false

Once upgraded, edit the policy and apply to all users.

Note: If you cannot do this, then you will need to either script the proxyAddress update or perform a manual update on each user.

Once all of these tasks are completed, either wait for your scheduled directory synchronisation to complete or force directory synchronisation by following the instructions here..

http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652557.aspx#BKMK_SynchronizeDirectories

Create on premises –> Office 365 organisation relationship

This process is performed on premises in the Exchange 2010 Management Console. However, before we continue we need to know what our Office 365 tenant POD name and EWS namespace is…

Logon to portal.microsoftonline.com with your tenant Admin account
Click on “Outlook” in the top menu bar
In the far right hand side top menu, click on the drop down next to the “?”
Select “About”
Scroll down until you find your External SMTP Setting

Record your POD name, in my case this is : pod51007.outlook.com
Your EWS Namespace will be : https://<POD>/EWS/Exchange.asmx

Configuring the Org Relationship…

Open the Exchange Server 2010 Management Console
Expand Organization Configuration
Open the Organization Relationships tab
Click on New Organization Relationship

When prompted, select to Automatically discover configuration information and enter in the *.onmicrosoft.com domain for your tenant.

Once the Org Relationship has been created we need to modify a few settings in PowerShell…

Firstly we need to see what the settings are…

Get-OrganizationRelationship -Identity "Office 365" | fl

Set TargetSharingEPR…
This value overrides the autodiscover URL and instead hard codes the EWS endpoint that will be used. This is not required, however hard coding this URL has proven to be more reliable in most deployments. Note, use the “POD” server name that you recorded earlier via OWA.

Set-OrganizationRelationship -Identity "Office 365" -TargetSharingEpr https://pod51007.outlook.com/EWS/Exchange.asmx

Enable Mailtips…
Thesesettings enables mailtips to work between Exchange Org’s

Set-OrganizationRelationship -Identity "Office 365" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True

Check that the correct domain names are listed on the Organisation Relationship…
As general rule the following should be listed as a minimum…

Primary SMTP Domain (groovycloud.co.uk in my example)
Service Domain (service.groovycloud.co.uk in my example)
Office 365 Domain (neiljohn.onmicrosoft.com in my example)

Use the following command to write the correct domain names on the Org Relationship…

Set-OrganizationRelationship -Identity "Office 365" –DomainNames groovycloud.co.uk, service.groovycloud.co.uk, neiljohn.onmicrosoft.com

Set the TargetOwaURL to enable OWA redirection…
Note that the URL should end with your federated namespace to ensure that users are directed to the correct authentication platform. This should match the domain portion of the UPN that users use to login to Office 365 with.

Set-OrganisationRelationship –Identity “Office 365” –TargetOwaURL http://outlook.com/owa/groovycloud.co.uk

Example of a working OnPrem Organisation Relationship…

Primary SMTP Domain Name : groovycloud.co.uk
Service Domain Name : service.groovycloud.co.uk
Tenant Root Domain : neiljohn.onmicrosoft.com
Tenant POD Name : POD51007.outlook.com

[PS] C:\Windows\system32>Get-OrganizationRelationship | fl

RunspaceId            : 75c03ec6-47bb-4070-807d-ec2a09d112f1

DomainNames           : {service.groovycloud.co.uk, groovycloud.co.uk, neiljohn.onmicrosoft.com}

FreeBusyAccessEnabled : True

FreeBusyAccessLevel   : LimitedDetails

FreeBusyAccessScope   :

MailboxMoveEnabled    : False

DeliveryReportEnabled : True

MailTipsAccessEnabled : True

MailTipsAccessLevel   : All

MailTipsAccessScope   :

TargetApplicationUri  : outlook.com

TargetSharingEpr      : https://pod51007.outlook.com/EWS/Exchange.asmx

TargetOwaURL          : http://outlook.com/owa/groovycloud.co.uk

TargetAutodiscoverEpr : https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity

OrganizationContact   :

Enabled               : True

ArchiveAccessEnabled  : False

AdminDisplayName      :

ExchangeVersion       : 0.10 (14.0.100.0)

Name                  : Office 365

DistinguishedName     : CN=Office 365,CN=Federation,CN=GroovyCloud,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=groovycloud,DC=local

Identity              : Office 365

Guid                  : 3da3da88-22fa-444a-ac4e-4eaafe84d917

ObjectCategory        : groovycloud.local/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship

ObjectClass           : {top, msExchFedSharingRelationship}

WhenChanged           : 15/08/2011 10:39:28

WhenCreated           : 15/08/2011 07:23:48

WhenChangedUTC        : 15/08/2011 09:39:28

WhenCreatedUTC        : 15/08/2011 06:23:48

OrganizationId        :

OriginatingServer     : DC1.groovycloud.local

IsValid               : True

Create Office 365 –> on premises organisation relationship

Now we need to create a relationship between our Office 365 tenant and our Exchange on premises infrastructure. This process is very similar to the previous Org Relationship…

First we need to create a remote PowerShell session to our Exchange tenant in Office 365, follow the instructions in Mike’s post here to sort that out..

http://www.mikepfeiffer.net/2010/11/office-365-connecting-to-exchange-online-with-remote-powershell/

Once we have that session established we need to create a new Org Relationship…

New-OrganizationRelationship -DomainNames groovycloud.co.uk -Name "Exchange OnPrem"

Once created we need to check the same settings as previously..

Get-OrganizationRelationship -Identity "Exchange OnPrem" | fl

Again, we will need to configure some settings here to make the relationship work…

TargetSharingEPR
Set this to be your published on premises EWS endpoint that you verified with the Exchange Remote Connectivity Analyzer earlier in the process…

Set-OrganizationRelationship -Identity "Exchange OnPrem" -TargetSharingEpr https://mail.groovycloud.co.uk/EWS/Exchange.asmx

Set TargetApplicationURI to delegated OnPrem Namespace
If you followed the documentation to establish your federation trust this will be "federation.<primary SMTP domain>”

Set-OrganizationRelationship -Identity "Exchange OnPrem" -TargetApplicationUri exchangedelegation.groovycloud.co.uk

Enable Mailtips
This setting enables mailtips to work between Exchange Org’s

Set-OrganizationRelationship -Identity "Exchange OnPrem" -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True

Enable Free/Busy Access

Set-OrganizationRelationship -Identity "Exchange OnPrem" -FreeBusyAccessEnabled:$true -FreeBusyAccessLevel LimitedDetails

Check that the correct domain names are listed on the Organisation Relationship
As general rule the following should be listed as a minimum…

Primary SMTP Domain (groovycloud.co.uk in my example)

Use the following command to write the correct domain names on the Org Relationship…

Set-OrganizationRelationship -Identity "Exchange OnPrem" –DomainNames groovycloud.co.uk

NOTE: By default your tenant will be provisioned as a “tiny tenant”, this means that many of the configuration attributes are non writeable. If you intend to customize your address policies or RBAC polices then it is probably worth “hydrating” your tenant at this stage by running the “enable-OrganizationCustomization” cmdlet. This is not necessary to get hybrid availability working, but it may save you some headaches later on! (Thanks for the recommendation Tim!)

Example of a working Office 356 Organisation Relationship…

Primary SMTP Domain Name : groovycloud.co.uk
OnPrem EWS URL : https://mail.groovycloud.co.uk/EWS/Exchange.asmx

PS C:\LiveMesh\Tools\RemotePS> Get-OrganizationRelationship -Identity "Exchange OnPrem" | fl

RunspaceId : 94f72750-98a0-495d-91cc-bb26a88611da

DomainNames : {groovycloud.co.uk}

FreeBusyAccessEnabled : True

FreeBusyAccessLevel : LimitedDetails

FreeBusyAccessScope :

MailboxMoveEnabled : False

DeliveryReportEnabled : True

MailTipsAccessEnabled : True

MailTipsAccessLevel : All

MailTipsAccessScope :

TargetApplicationUri : exchangedelegation.groovycloud.co.uk

TargetSharingEpr : https://mail.groovycloud.co.uk/EWS/Exchange.asmx

TargetOwaURL :

TargetAutodiscoverEpr :

OrganizationContact :

Enabled : True

ArchiveAccessEnabled : False

AdminDisplayName :

ExchangeVersion : 0.10 (14.0.100.0)

Name : Exchange Onprem

DistinguishedName : CN=Exchange Onprem,CN=Federation,CN=Configuration,CN=neiljohn.onmicrosoft.com,CN=ConfigurationUnits,CN=Microsoft Exchange,CN=

Services,CN=Configuration,DC=eurprd02,DC=prod,DC=outlook,DC=com

Identity : Exchange Onprem

Guid : e3f00a9d-1534-479d-a439-d187aa02e05a

ObjectCategory : eurprd02.prod.outlook.com/Configuration/Schema/ms-Exch-Fed-Sharing-Relationship

ObjectClass : {top, msExchFedSharingRelationship}

WhenChanged : 15/08/2011 09:48:18

WhenCreated : 15/08/2011 07:39:43

WhenChangedUTC : 15/08/2011 08:48:18

WhenCreatedUTC : 15/08/2011 06:39:43

OrganizationId : eurprd02.prod.outlook.com/Microsoft Exchange Hosted Organizations/neiljohn.onmicrosoft.com - eurprd02.prod.outlook.com/Config

uration/Services/Microsoft Exchange/ConfigurationUnits/neiljohn.onmicrosoft.com/Configuration

OriginatingServer : AMSPRD0202DC004.eurprd02.prod.outlook.com

IsValid : True

Testing…

Ok, so now were all set up so the next step is to logon as some users to see what happens…

I am going to use the following accounts

On premises User : ewstest@groovycloud.co.uk
Office 365 User : office365User1@groovycloud.co.uk

On premises to Office 365

For this test I am going to log on to my ewstest account via Outlook 2010 and attempt to view availability data for my Office365User1 account. I have created a test meeting in each mailbox and set the default calendar permission level to “Free/Busy time, subject, location”.

A new meeting request running on premises logged on as user ewstest with Office 365 user Office 365 User 1 added as an attendee. You can clearly see that both users are returning rich availability data… yay!

Office 365 to On premises

For this test I am going to log on to my Office365User1 account via Outlook 2010 and attempt to view availability data for my ewstest account. I have created a test meeting in each mailbox and set the default calendar permission level to “Free/Busy time, subject, location” the same as before…

As you can clearly see, the experience is exactly the same for an Office 365 user collaborating with an on premises user…. double yay!

Conclusion

Hopefully this article shows that it is possible to get availability to work cross premises. It does show however that even in this extremely simple example where I only have a single Exchange 2010 server and a handful of users, there were still a number of steps to complete and plenty of scope to get something wrong. I for one cant wait for Exchange Server 2010 SP2 to come along and simplify the whole thing!

In my experience working in labs and with customers the following are the most common areas of misconfiguration…

Incorrect DomainNames on the Organization Relationship configuration
Missing DNS Records for the Service Domain will stop client Autodiscover working for on premises clients accessing mailboxes in the cloud.
Incorrect URL for TargetSharingEPR
TargetApplicationURI missing from Organization Relationship configuration – note: it doesn't seem to matter what you set this to as long as its not $null!

For further information and detail around more complex configurations please see

Exchange Server Deployment Assistant http://technet.microsoft.com/en-us/exdeploy2010/default.aspx