Updated: Exchange 2007 Splitting OWA and Autodiscover onto two different websites.

This post explains how I split Exchange Web services and Autodiscover into two separate websites so that I could use two separate SSL certificates ($30) instead of a $300 UCC certificate.

We have a wildcard certificate (*.foo.com) for our primary domain. Since we have a metric crapton of servers it saves us loads of money.

The exact minutiae of getting Outlook Anywhere working will be another post. Suffice it to say that A.) It has a showstopper IPV4/IPV6 bug out-of-the-box and B.) Wildcard certificates do not work with Outlook Anywhere.

Happy to have that particular learning experience behind me and $15 later we had a GoDaddy certificate for newmail.foo.com. Yeah!

Now that was working it's time to setup the Autodiscover service. I set a SRV record for autodiscover to point to newmail.foo.com, but the users were getting a pop-up asking for permission to connect to it. I am an anti-popup person. So I setup autodiscover.foo.com in DNS to point to the OWA webserver. Did it work?

No.

Why?

Another SSL problem with the certificate names. "autodiscover.foo.com" != "newmail.foo.com"

ARGH!

The Microsoft solution is to use a certificate with multiple "Subject Alternative Names", also known as a Unified Communications Certificate. They cost about $300. Personally I don't like spending that for a certificate. That's why we got a WILDCARD certificate you asshats!

After a healthy dose of expletives, I set out to move the autodiscover "application" to a separate website using our existing wildcard certificate.

Here is the part where that "doing it the hard way" feeling comes in. I couldn't find any commands or options to setup the /Autodiscover application under the new website.

After about 10 minutes of trying to figure out how to copy the settings over, I ...

1. Set another IP for the new site.
   
2. Popped a hole in Mr. Firewall for http and https.
   
3. Opened IIS.
   
4. Created the new site.
   
5. Edited the bindings to use the right ssl certificate.
   
6. Stopped IIS.
   
7. Opened c:\windows\system32\inetsrv\config\applicationhost.cfg in notepad.
   
8. Copied <sites><Application Path> information from the default site to the autodiscover site. See update note below.
   
9. Copied the <locations> information from the default site to the autodiscover site.
   
10. Whispered a prayer of penance to the IT gods.
    
11. Started IIS.
    

Update 2009-03-17: I WAS doing it the hard way! There is a powershell command to create a new autodiscover virtual directory. It is new-autodiscovervirtualdirectory.

And wow, It worked! Was I ever surprised?!

Ttfn,
-ellie

Exchange SCR and ESE function Error

I'm running into some errors setting up SCR between our sites. I'll edit this post with the solution when I get it sorted out.

[PS] C:\Exchange>update-StorageGroupCopy -Identity Orl-exg1\Sg1 -standbymachine
lor-exg1
WARNING: Replication for storage group 'ORL-EXG1\SG1' is still suspended. If
needed, you can use the Resume-StorageGroupCopy cmdlet in the Exchange
Management Shell to resume replication.
Update-StorageGroupCopy : Seeding failed : Database seeding error: Error return
ed from an ESE function call (0xc7ff1004), error code (0x0).
At line:1 char:24
+ update-StorageGroupCopy  <<<< -Identity Orl-exg1\Sg1 -standbymachine lor-exg1

It looks like it is something with the Windows firewall. Turning it off makes it work. Feature. Now to figure out what application needs to be permitted through the fw.

PPTP Vpn through a Linux IpTables/Netfilter firewall

I spent some time configuring a pptp vpn for one of our offices yesterday, but it kept failing to connect during testing. Each failure generated these errors in the firewall (the one I was Vpn-ing too) log.

pptpd[9078]: GRE: Bad checksum from pppd.
pptpd[9078]: CTRL: Received PPTP Control Message (type: 15)
pptpd[9078]: CTRL: Got a SET LINK INFO packet with standard ACCMs
pptpd[9078]: GRE: read(fd=7,buffer=80505a0,len=8260)
 from network failed: status = -1 error = Protocol not available
pptpd[9078]: CTRL: GRE read or PTY write failed (gre,pty)=(7,6)

As my comp.sci instructor would say, "Bad Times".

The vpn connection worked from a direct-internet-connected host, so logically the VPN setup was probably right. Here in the office I am behind a Linux IpTables firewall, and I deduced that it was probably the issue. Nothing was set to block the GRE protocol though, so I was a little puzzled.

I found this TLDP post (Do not bother reading it...) on how to make pptp work through iptables. Ah-ha! It was the firewall. Then I realized that documentation was ancient. By Ancient I mean it refers to the 2.0 and "new" 2.2 kernel. The current Linux kernel is > 2.6! eep! It was probably translated from some obscure dead language it is so old.

Anyway, the solution is much simpler... Iptables has a module that allows pptp to pass through NAT. My tale of woe happily resolved with this command.

modprobe ip_nat_pptp

One more useful tidbit. You can see a list of available IpTables modules with this command..

locate netfilter | grep .ko

Good Luck,
-Ellie