I think that one of the coolest features of Exchange 2010 is the seamless free/busy and calendar federation between organizations. In order to get federation provisioned there are a number of steps you need to take which you can find detailed on Technet.

The first step of this setup involves creating a Federation Trust to the Microsoft Federation Gateway (MFG), but in order to create this trust you need to use a public certificate issued by one of the following Certificate Authorities (the haphazard thumbprint formatting is Technet’s, not mine):

I recently was involved an Exchange deployment that involved purchasing a SAN certificate from Comodo. One of the certificate authorities Comodo uses to issue SAN certs is the USERTrust Legacy Secure Server CA, which has its own certificate issued by the Entrust.net Secure Server Certification Authority. Bottom line is the certificate you get verifies up to the Entrust certificate you can see below which the Federation Gateway supports.

After trying to create the Federation Trust we were seeing the following error:

An error occurred while attempting to provision Exchange to the Partner STS. Detailed information “An error occurred accessing Windows Live. Detailed information “The request failed with HTTP status 403: Forbidden.”.”

Basically this is the MFG’s way of saying “I don’t trust this certificate.” It turns out the MFG is geared to only accept certificates issued directly from one of the certificate authorities listed above which is not something I saw in the documentation. So if the Entrust Secure Server Certification Authority had issued our webmail certificate it would have been accepted. But like in our case, if your certificate is issued from a 3rd party intermediate certificate authority it won’t be accepted even if it technically verifies up to a support rooted authority.

The good news is a call to PSS resulted in Microsoft making a change on the MFG to accept certificates issued by this particular intermediate CA going forward for everyone. So if ran into this error previously you should be able to try again with the same certificate and see the trust succeed. As of this writing I’ve requested them to also add support for the AAA Certificate Services intermediate CA Comodo also issues certificates from.

One of the deployments I’ve been working on recently involved using F5 BigIP hardware load balancers to do SSL offloading for a two-node Exchange 2010 design. To give some background here usually you would just pass through port 443 (I’m skipping over the RPC Client Access piece since it’s not relevant here) from your load balancer straight to the Exchange servers, letting the servers handle the SSL encryption like in this diagram:

The benefit of that approach is it’s simple and a very common deployment method. On the flip side, you can benefit from offloading SSL encryption to the BigIPs and gain some more advanced forms of load balancing. In this case the improved load balancing was the goal along with some internal policies forcing this approach. What happens with SSL offloading is the HTTPS traffic ends at the BigIPs which turn around and pass port 80 clear-text traffic back to the Exchange servers so they have a bit less CPU work to do. That strategy looks more like this:

The problem with this configuration is Exchange is really designed to operate with SSL in mind and you have to go out of your way to allow it to operate in clear-text. What you’ll need to configure on each CAS server is:

• Set the Outlook Web Access SSLOffloaded registry key: http://technet.microsoft.com/en-us/library/bb885060(EXCHG.80).aspx
• Remove the SSL requirement from all Exchange virtual directories via IIS Manager.
• Edit the Exchange Web Services web.config file to force HTTP: http://technet.microsoft.com/en-us/library/ee633481.aspx
• Configure Outlook Anywhere SSL Offload: http://technet.microsoft.com/en-us/library/aa998346.aspx

The issue I ran into is after following all of these steps Autodiscover was still not functional through the load balancing. I could enter https://<CAS Array FQDN>/Autodiscover/Autodiscover.xml into a browser and reach the XML file with no problem, but running the Autodiscover test within Outlook would return a 404 error. Every other service was working just fine:

This threw me for awhile and after a bit of searching I ran across KB 980048 where it’s noted that Autodiscover cannot be used on port 80 with an HTTP POST request, which is what Outlook uses. My attempts at accessing the XML directly succeeded because I was only trying to download the file. Supposedly this is going to be fixed in Service Pack 1.

While the KB provides no immediate solution what I found that works is to use the same methodology Technet recommends for the Exchange Web Services web.config file. Go into your /Autodiscover folder and edit the web.config to replace all instances of httpsTransport with httpTransport (a simple search and replace should work). Be sure to save a copy before you make modifications, restart your server after making the change and you should be able to offload SSL for Autodiscover successfully. Since as far as I know this is undocumented today you can try this at your own risk, but it appears to be working.

Setup

• It’s brain-dead. It uses Autodiscover, so e-mail and password is all you need. You get prompted if you’d like it to also configure iCal and your address book.

• I haven’t tried from home yet, but the external server path is not filled out. Internal picks up EWS/Exchange.asmx URL just fine, but external is blank. I double-checked our Exchange server and this parameter isn’t filled out so that makes sense. The difference here is Outlook assumes the external is the same as internal if this value is blank, but it appears Apple Mail will not. Be sure to set your –ExternalURL parameters on the virtual directories appropriately.

Mail

• Responses to meetings come across as an .ics attachment, no special functionality here. This is especially bad if someone proposes a new time.

• The Exchange RSS Feeds folder does not integrate with the RSS feeds section in Mail. This would have been nice.

• Name suggestions are offered from the GAL and your contacts.

• Rules do not sync.

• UM voice mails have a built in media control. My codec is set to G.711 and I see embedded QuickTime controls in the message for playback.

• The actually listing of your notes is displayed in the Marker Felt font. It’s horrendous and tough to read.

• No out of office assistant.

• You can add multiple Exchange accounts.

iCal

• You can schedule meetings and invite attendees.

• You can view free/busy details for attendees.

• iCal does not differentiate between people and resources as attendees.

• You can view responses for meetings. Accepted, tentative, declined or unknown.

• Tasks sync to iCal “To-Dos”. The default view shows all completed items. Hit the iCal preferences to change this view.

• You can view Delegate calendars and grant access to your calendars and tasks.

• Name suggestions are offered from the GAL and your contacts.

Address Book

• My contacts came across just fine.

• I can’t see the GAL for some reason. The URL in the account settings looks correct, but the GAL is empty. Really strange considering I get GAL-suggestions when typing names in other applications.

I’m sure there are more to come, but despite some of the caveats this is still a huge improvement over Entourage. I’m looking forward to the Outlook for Mac client coming next year, but until then I’ll be using the native applications.

This post was originally written based on the Exchange 2010 beta bits before the Technet documentation was updated to reflect the actual required permissions for a DAG’s FSW. Consequently, it had a major error. You’ll want to visit Devin’s page for a full explanation and the correct way to set up the DAG. Always helps when you can read the documentation, right?

You can see my installer completed in about 12 minutes, which is pretty damn cool. This was a VM with 3 GB of RAM with its VHD on a RAID 10 set. Imagine if this was a production machine with a real amount of RAM.

]]> http://www.confusedamused.com/notebook/installing-exchange-2010-in-20-minutes-or-less/feed/ 0 http://www.confusedamused.com/notebook/office-communicator-outlook-integration-error-problems-when-using-isa-2006-and-exchange-kerberos-constrained-delegation/ http://www.confusedamused.com/notebook/office-communicator-outlook-integration-error-problems-when-using-isa-2006-and-exchange-kerberos-constrained-delegation/#comments Thu, 13 Aug 2009 23:37:05 +0000 Tom Pacyk http://www.confusedamused.com/?p=457

Now that’s a wordy title. I’ve been meaning to write this up since about March in more detail with some fancy diagrams, but I’ve finally given in and decided to just get the information published and update it later. One of the nicest features of ISA 2006 is the ability to use Kerberos Constrained Delegation (KCD) in reverse proxy scenarios. This can used to publish applications like Exchange or SharePoint externally and allows passing NTLM credentials over an SSL channel to ISA which authenticates to Exchange or SharePoint via Kerberos on behalf of the user, making for a seamless experience regardless of location. Read: No freaking login prompts outside the firewall, even in Outlook Anywhere with ISA performing pre-authentication of users. Jason Jones has an outstanding article already written outlining how to set up KCD with Exchange 2007 and ISA 2006 that I recommend following if you’re interested. The point of this article is not to explain how to configure KCD, but to highlight two issues you’ll find when deploying this with Microsoft Office Communicator. If you’ve deployed KCD for Outlook Anywhere and have users with Communicator outside the firewall they’ll probably see the dreaded “Outlook Integration Error” or “Communicator could not retrieve calendar or Out of Office information from Exchange Web services” warnings.

There are actually two issues here that we need to resolve. The first is that Communicator itself actually uses some slightly different RPC over HTTPs logic than Outlook which causes the KCD authentication through MOC to flat out fail. In R1 of OCS 2007 I found the clients were prompted for credentials 3 times for the Outlook integration and then the integration would fail even with correct credentials. With the R2 client you’ll no longer see the authentication prompts, but the Outlook Integration error would eventually show up. The problem is in how ISA 2006 handles POST requests than do not have a POST body, which is apparently the difference between Outlook and MOC’s logic. There is a hotfix available for this which requires running a .vbs script to make the change to ISA. You can find that hotfix and script here: http://support.microsoft.com/default.aspx?scid=kb;EN-US;942638. You actually need to apply the ISA 2006 Supportability Update package before you can install this hotfix and that package is here: http://support.microsoft.com/kb/939455/.

The second issue you’ll find is that when ISA offers Communicator the Negotiate and NTLM authenticate headers Communicator actually tries to negotiate and fails. This can be remediated by changing ISA to offer only NTLM headers to clients. There is another hotfix and .vbs script to fix this issue which you can find here: http://support.microsoft.com/kb/927265/en-us. One warning I should point out is this is a system-wide setting and will disable Kerberos for outbound-proxy scenarios. I’m not a big fan of ISA for anything other than a reverse proxy so this had no issues on my environment, but be careful to evaluate your existing rules if you use ISA for anything else.

You can test out the second hotfix without making any changes to the ISA server by going in to IE’s advanced settings on a client and unchecking the box “Enable Integrated Windows Authentication.” (Thanks to Scott Oseychik for this tip). Contrary to the outstanding verbiage, this only disables Kerberos authentication in IE and will force IE to only try to authenticate via NTLM.

Once you have all of your hotfixes installed you should be able to login to MOC only and receive no more Outlook integration errors. Perfectly seamless authentication anywhere you are. Jason Jones pointed out the two hotfixes for me originally, so a huge thanks is in order to him.

Replication Host Names are an Exchange 2007 SP1 feature that I don’t think is used very often or that well known. This is a great article on setting it up from both a Windows 2003 and 2008 perspective.

Via Neil Hobson.

This one killed me today. Exchange 2007 SP1, with Rollup Update 6 on Server 2008. Everything working perfectly with one exception – the offline address book (OAB) never downloads from the file distribution point for Outlook 2007 clients. Works fine via public folders, but not web-based. No error, no timeout, no progress indicator, no login prompt, Outlook just looks like it’s endlessly trying to download the OAB. I double-checked all the URLs, flipped around SSL settings, but still couldn’t figure out why it wouldn’t download. I would have been happy to see an error so I had something to search on. There were actually 2 problems here that made the situation a real pain in the ass.

First – the same bug that affects Outlook Anywhere on Server 2008 apparently does a number on the OAB too. The solution is to turn off kernel-mode authentication in IIS. Run this command to fix that issue and you’re halfway there. I ran across some blog that mentioned Rollup Update 7 may include this change by default.

C:\Windows\system32\inetsrv\appcmd.exe set config /section:system.webServer/security/authentication/windowsAuthentication /useKernelMode:false

Second – I had enabled a redirect at the Default Web Site root to dump clients to the /owa folder gracefully using the Microsoft methodology at Technet. If you read the procedure you’ll notice setting the redirect at the root sets the same redirect on every single virtual directory. So, you need to go in to each virtual directory and undo the change you made for the root. This works fine, or appears to until your Outlook 2007 client tries to download the OAB and hangs forever.

I brightly plugged the URL to the OAB.XML file into IE and was greeted with a 500 – Internal Server Error message without an authentication prompt. That didn’t seem right. After some searching I realized the reason why Outlook hangs forever is that it tries to hit this URL, gets denied, uses some back-off logic, and tries again. I believe the back-off gets longer and longer each time it fails.

What happens is that when you disable that redirect for the OAB virtual directory IIS 7 generates a web.config file in the C:\Program Files\Microsoft\Exchange Server\ClientAccess\OAB folder. This seems logical, as it overrides the redirect at the root level, and is necessary. Unlike every other web.config that is generated in the other folders like Autodiscover and OWA, Authenticated Users do not have read access to the file. This is why Outlook and IE can’t even access the /OAB virtual directory.

The fix is pretty easy. Open the web.config in the OAB folder, and give Authenticated Users both the read and read and execute permissions. Run a iisreset /noforce on the CAS server to bounce IIS. Just for good measure, on the client side I wiped out the Outlook profile, and the contents of the %USERPROFILE%\Local Settings\Application Data\Microsoft\Outlook folder. Once I recreated the profile the OAB downloaded just fine. All in a day’s fun…

Hallelujah. Some decent support for Exchange on the Mac side. Significant changes include:

• Enhanced Autodiscover service to keep user account settings up to date after the account setup.
• Synchronization between Exchange Server and Entourage 2008 Notes, Tasks, and Categories.
• Addition of an Enable Logging (troubleshooting) preference, to log all events that can be used as diagnostic information.
• Use of attachments in Entourage for Exchange calendar events.

At a minimum you need Entourage 2008, but what version of update rollups your Exchange server needs to be at is a little confusing. The blogs say Update Rollup 4, but when you fill out the survey to get in the beta it says Update Rollup 5. I guess I’d go better safe than sorry and assume Update Rollup 5 at this point.

You can sign up for the beta here: http://www.microsoft.com/mac/itpros/entourage-ews.mspx

Ever tried to prepend the subject of every email message with [SPAM] if it meets a certain SCL value? I figured it would be easy enough with a transport rule. Walked through the wizard and set up a basic rule set that I thought seemed reasonable.

Apply rule to messages
With a spam confidence level (SCL) rating that is greater than or equal to 4
And from users outside the organization
Prepend the subject with [SPAM]

Now that should work, right? Wrong. Messages kept flowing through without the subject modified at all. I took a look at the mail headers and I could see the SCL value being set to 4 or 5, so why wasn’t the subject being modified?

Turns out the Content Filtering Agent fires after the Edge Filtering Agent. So messages would flow through my custom rule with an SCL of 0, continue on because they didn’t meet my criteria of 4 or higher, then get passed to the Content Filtering Agent which would set the SCL 4, and then end up in my mailbox. In order to fix this you need to flip the agents around so the Content Filtering Agent is processed before Edge Transport Agent. By default The Edge Rule Agent is 3rd and the Content Filtering Agent is 4th. This Powershell line should flip them around:

Set-TransportAgent ‘Edge Rule Agent’ –Priority 4

Or, if you prefer to actually read documentation before banging your head against the wall wondering why it doesn’t word you could be smarter than me and just read this article in advance: How To Make the SCL Value Available to Edge Transport Rules