FixMAPI

Clearly, keeping up on this blog hasn't been at the top of my to-do list. We've made some big changes at Artech, and business is booming at the moment, so I've been busier than ever.

This blog was originally going to be a collection of articles that I could spit out at my own pace, and then use in a newsletter format on a periodic basis to send to our clients. However most of my clients wouldn't really care to read any of this, so it's basically turned into a collection of fixes for which I couldn't find anything on Google when trying to fix an error myself.

A recent example of this came up when I migrated a client from GroupWise 6.5 to Exchange 2007 with Outlook 2007 on the client side. The vast majority of people could no longer use any mailto links or the "Send to" function of Explorer when choosing Mail Recipient. The only solutions people tended to talk about was to verify that you had Outlook selected as the default email program under Internet Explorer.

So if you are being prompted to "Choose Profile", and then nothing happens when trying to use any of these functions, check out the version of your mapi32.dll. There's a program that's been pushed out since IE5 called fixmapi.exe in your system32 directory, which makes a backup of the current MAPI DLL, and restores the correct version. Be careful, because this will break older versions of Outlook.

Hopefully this will help other people when looking for a solution to this issue.

Creating a Secondary OWA Instance

(continued from previous post: AuthAnvil on OWA 2007)

So I set out on the task of creating a secondary OWA instance in IIS for the purpose of securing using AuthAnvil. First, I bound a second IP address to the server under TCP/IP properties. Then I created a new website named "AA-Secured" and set it to only listen on the new IP address. Then I set it to use the same SSL certificate that the original site used (e.g. webmail.domain.com).

So far, so good. I'm no PowerShell guru, but I'm impressed with how versatile it is. I have used it to perform many of the regular Exchange tasks with ease. I'm a command shell junkie at heart, but I never learned how to do "real" programming beyond some horribly complicated CMD files and some very simple VB.

One of the commandlets is called "New-OwaVirtualDirectory". So I executed the command:

New-OwaVirtualDirectory -owaversion:exchange2007 -websitename "AA-Secured"

I watched the new OWA virtual directory show up in IIS manager while PowerShell plugged away. However after a little bit, it returned an error:

New-OwaVirtualDirectory : An error occurred while creating the IIS virtual directory 'IIS://server.domain.local/W3SVC/448843799/ROOT/owa' on 'SERVER'.
At line:1 char:24
+ New-OwaVirtualDirectory <<<< -owaversion:exchange2007 -websitename "AA-Secured"

Yes, I know I don't need to specify the version when executing this command - this is just one of the many ways I tried to get it to work.

In researching this issue, it seems that everybody's solution was to uninstall CAS (client access server - component of Exchange 2007), reinstall IIS and then reinstall CAS. Why would I want to do that? The original OWA listener works just fine.

If part of your job involves supporting and troubleshooting of Exchange environments, I really hope you follow the MS Exchange Team's blog. It's full of a lot of useful information. The part that specifically interested me was this article, titled "Supportability for multiple OWA/ Exchange Web Sites on Client Access Servers in Exchange Server 2007 and Exchange Server 2007 Service Pack 1" (quite the long title). However it was exactly what I was looking for.

1. If you are using Forms-Based Authentication for your /OWA and/or legacy (/Exchange and /ExchWeb) virtual directories, Microsoft supports a single Web site per Client Access Server. Further, the /OWA and legacy virtual directories must be in the same Application Pool (AppPool).
2. If you do not use Forms-Based Authentication, you can use as many Exchange Server-related Web sites as needed for your organization.
   However, Microsoft recommends that you use a Microsoft ISA Server 2006 server to handle Forms-Based Authentication for your various Web sites, in this circumstance.
3. If Forms-Based Authentication must be used on the Exchange Server 2007 computer *and legacy virtual directories are not used*, you can use multiple Application Pools (AppPools) for each Web site.
   Note: Lack of legacy virtual directories will prevent proxy to Exchange Server 2003 mailbox servers and prevent Entourage clients from synchronizing with the Exchange Server using the Exchange service.

Here was my reaction to these points:

1. Crap... We need forms-based authentication.
2. Who cares? We need forms-based auth and there's no way we're moving the firewall over to the ISA box (which we use for web proxy).
3. BINGO!

At this particular site, we only have a single Exchange server, which is 2007, and there's nobody using Entourage. So I used the following command to remove any legacy OWA directories:

Remove-OwaVirtualDirectory "exchange (default web site)"
Remove-OwaVirtualDirectory "public (default web site)"
Remove-OwaVirtualDirectory "exchweb (default web site)"

(I should mention that we didn't even have a public store at this site, much less users who use public folders via OWA, however I wanted to include it since most sites probably would have to remove that directory too)

After removing those other OWA virtual directories from the main site, I was able to execute the command successfully. Here's what IIS Manager and Exchange Manager looked like after all was said and done.





After making the new OWA virtual directory on the second site, we tested it to make sure it was fine on its own. Once we were confident everything was working, we locked it down with AuthAnvil's Web Logon agent, and modified the firewall so external users could only hit the new IP.

AuthAnvil on OWA 2007

If you're not familiar with AuthAnvil, you should check it out. It's a great two-factor solution designed for the SMB market. It's easy to install, and the support is great.

They're getting ready to release the 1.6 version of their agents (edit: It was released yesterday). I've been running 1.5 for a while and we use it to secure our desktop machines as well as OWA.

Did I mention that we use Exchange 2007? Exchange 2007 requires a 64-bit server OS. However there's one little problem. There isn't a 64-bit version of the ISAPI available for AuthAnvil yet (I think that's coming out in 1.6).

I've had many conversations with Dana Epp, the owner of Scorpion Software, makers of AuthAnvil. I told him that I wanted to experiment with securing OWA 2007 using their Web Logon Agent. He was kind enough to send me the 64-bit version of the ISAPI DLL and some instructions. I ran into some roadblocks along the way, but was able to get past all of them. We have been running AuthAnvil with our OWA server with no issues for over two months now.

With this in mind, I was confident telling a client of mine that we would have no problem installing it onto their Exchange 2007 OWA server. However their environment was a little bigger than ours. One of the features of AA's web logon agent is the whitelist. You can setup individual IP addresses that don't require two-factor logins. This is handy if you have internal users using OWA and you don't want to buy tokens for them. However this environment has 12 class-C networks spread out across Central Iowa. Many of the internal users use OWA for their email. That means we would have roughly 3000 IP addresses to whitelist.

So my solution was to create a secondary OWA in IIS on a different IP. Internal users would continue to hit the old, unsecured version. However external users would be directed to the new listener in IIS, which would be secured with AuthAnvil. I've had to create secondary OWA listeners in older versions of Exchange. How hard could it be with this shiny new version?

Famous last words...

(to be continued)