One of this nicest features of Outlook 2003 is that it can "phone home" to the Exchange server using not only the normal NETBIOS protocols, but it can also proxy this over a secure web connection. This is ideal for remote users who need the full-strength Outlook integration (as opposed to the almost-Outlook of OWA), all without the problems associated with a VPN.
It's just a great mechanism, there there is a lot of good guidance out there. My favorite is Troubleshooting RPC over HTTPS by fellow MVP Rodney Buike, but I've found a corner case which caused me to waste a maddening amount of time.
My environment is an SBS2003 machine hosted at a data center, and 100% of the real users being remote, not part of the domain, and with no access to any of the NETBIOS-ish protocols that Outlook normally uses to talk with Exchange.
Furthermore, the machine's real hostname uses the .lan extension (others typically use .local), as we didn't want to use our real company domain because Windows would then want to "own" it. So by calling it sbs.company.lan, Active Directory wouldn't interfere with the rest of our DNS.
The gotcha is during initial setup of the mailbox, you must enter the internal hostname of the Exchange server, and this will fail the first time. The remote users are not in the same data center, have no access to the .company.lan nameservers, so of course name lookup will fail. This is expected!
Simply clicking through these error messages allows you to get to the [More Settings] button to configure the Exchange Proxy Settings in the Connections tab. At this point you'll enter the external name of the machine (https://sbs.company.com) to allow it to make the actual TCP connection to the IIS-based proxy.
Once the proxy is configured, it becomes the exclusive communications channel for this session to Exchange. Then later, when Outlook tries to connect, it passes the internal name (found in the initial setup screen) over the protocol exchanged via the proxy.
My mistake was using the external name (the hostname of the proxy) where Outlook wanted the name of the Exchange server. Even though the proxy was indeed making the proper SSL connection, the use of the wrong name passed over the protocol failed the connection.
My familiarity with DNS was leading me astray: "that name can't resolve" got me to use the external hostname, and it always failed.
It turns out that SBS users have a little bit of extra help configuring this: the RWW (Remote Web Workplace) default website on the SBS server itself. When visiting the site (http://sbs.example.com/Remote) and logging in, there is a Configure Outlook via the Internet link in the box on the left; it provides instructions filled in with the particular parameters required.
So we learned something here, though I don't think I appreciate the difficulty of debugging this.