Some notes on my experience so far with Apple’s 10.6 Snow Leopard OS and Microsoft Exchange Server 2007:
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.
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.
In Exchange 2007 Service Pack 1, a new feature was introduced that allowed additional redundant networks to be added to a CCR environment for the purposes of log shipping and database seeding. With specific networks dedicated to log shipping and database seeding, the remaining network is dedicated to its task of servicing client communications. Such a configuration avoids situations where the network that is servicing client communications also has to process a large number of transaction logs.
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…
Recently I ran into a situation where we had purchased an Exchange certificate from a fairly common certificate authority (GeoTrust) and everything worked well with browsers automatically trusting the certificate… and then we picked up a Windows Mobile 6.0 device from Verizon. For whatever reason, Verizon or Microsoft has decided this particular CA was not trustworthy and isn’t in the default list, so ActiveSync fails to connect to the Exchange server. Fortunately, we can force the device to trust the certificate.
Windows Mobile 6.0 brought a change in how to install certificates. Users cannot install a certificate into the root certificates store on a phone unless the certificate is self-signed. This ensures that only true root certificates exist in the root store.
The pain here is that when you try installing a certificate such as the one used to secure Outlook Web Access it gets dumped in the personal store, and ActiveSync won’t connect because it can’t verify the certificate authority associated with the certificate. The solution is to get the certificate authority’s self-signed certificate into the root store. We can do this with the following steps:
Open Internet Explorer and navigate to the site securing OWA. Click the lock next to the address bar.
Click the View Certificates link.
Click the Certification Path tab at the top.
Click the top certificate name first (the root CA) and then click View Certificate.
Click the Details tab.
Click the Copy to File… button.
Click Next to start the Certificate Export Wizard.
Click Next to export the certificate as a DER encoded binary X.509 (.CER)
Browse to a location where you’d like to save the certificate and give it a name.
Click Finish to complete the Certificate Export Wizard.
You should see a dialog that the export was successful.
Now copy that .cer file you created to the device in some way. Via a storage card, USB cable, Bluetooth, whatever. Just get the .cer in the file structure of the phone somehow.
Power up the phone and click Start.
Find and open File Explorer.
Locate the .cer file you copied to the phone. I called mine root.cer.
Press Menu and then Install.
You should see a dialog that the install was successful. I’ve seen it fail on the first attempt before, so try a few times if you get an error. Press OK.
Navigate to the phone’s Settings option.
Click on Security and press OK.
Click on Certificates and press OK.
Click on Root and press OK.
Scroll to the end of the certificates list or keep pressing More. You should see the certificate you installed listed at the very end of the list. If it’s not there, try starting over and making sure you’re exporting the certificate authority’s certificate, and not yours.
You can now test ActiveSync and it should be able to connect to the Exchange server without ever needing to install your OWA certificate. It’s automatically trusted because the certificate authority now exists in your root certificates store.