1. Make certain everything (operating system, Outlook, Exchange, etc.) is fully patched, on both the clients and the servers.
2. Verify that the Outlook profiles are configured correctly, per the instructions on the Remote Web Workplace page, including the installation of the Remote Web Workplace's SSL certificate on the client computers.  (One can also push the SSL certificate to all domain members with a Group Policy object.  One may also want to enable cached Exchange mode on all clients, so they can at least access a local copy of their mailbox while they're off-network.)
3. Take the computers in question off the SBS network and start Outlook with the "/rpcdiag" switch (see also http://www.amset.info/exchange/rpc-http-diag.asp).
4. Check the IIS log file for the web site that contains the "Rpc" web application (usually the Default Web Site, aka W3SVC1).  (Errors like the following may indicate a problem with the "ValidPorts" list in the RPC proxy configuration: "RPC_IN_DATA /rpc/rpcproxy.dll SBSSERVERNAME.DOMAIN.TLD:593 443 - CLIENTIPADDRESS MSRPC 401 1 0".)
5. Install RPC Ping and use it to verify connectivity to the Exchange server (see also http://support.microsoft.com/kb/831051), using commands similar to the following:
   

   rpcping -t ncacn_http -s INTERNALSERVERNAME -o RpcProxy=PUBLICSERVERNAME.DOMAIN.TLD -P "username,NETBIOSDOMAINNAME,password" -I "username,NETBIOSDOMAINNAME,password", -H 1 -u 10 -a connect -F 3 -v 3 -E -R none
   rpcping -t ncacn_http -s INTERNALSERVERNAME -o RpcProxy=PUBLICSERVERNAME.DOMAIN.TLD -P "username,NETBIOSDOMAINNAME,password" -I "username,NETBIOSDOMAINNAME,password", -H 1 -F 3 -a connect -u 10 -v 3 -e 6001
   rpcping -t ncacn_http -s INTERNALSERVERNAME -o RpcProxy=PUBLICSERVERNAME.DOMAIN.TLD -P "username,NETBIOSDOMAINNAME,password" -I "username,NETBIOSDOMAINNAME,password", -H 1 -F 3 -a connect -u 10 -v 3 -e 6001 -B msstd:PUBLICSERVERNAME.DOMAIN.TLD
   rpcping -t ncacn_http -s INTERNALSERVERNAME -o RpcProxy=PUBLICSERVERNAME.DOMAIN.TLD -P "username,NETBIOSDOMAINNAME,password" -I "username,NETBIOSDOMAINNAME,password", -H 1 -F 3 -a connect -u 10 -v 3 -B msstd:PUBLICSERVERNAME.DOMAIN.TLD
   rpcping -t ncacn_http -s INTERNALSERVERNAME -o RpcProxy=PUBLICSERVERNAME.DOMAIN.TLD -P "username,NETBIOSDOMAINNAME,password" -I "username,NETBIOSDOMAINNAME,password", -H 1 -F 3 -a connect -u 10 -v 3 -f a4f1db00-ca47-1067-b31f-00dd010662da,0 -B msstd:PUBLICSERVERNAME.DOMAIN.TLD

I found that while some clients worked with only the default Exchange RPC ports proxied via the RPC-HTTP service, one client could not connect without me also proxying the RPC end point mapper.  If the end point mapper is not proxied, those last two rpcping commands will fail with error 1722 and generate an error in the IIS log file similar to the one found in step 4.  To resolve the connectivity problem, I configured the RPC proxy to allow connection to port 593 on all of my domain controllers.  The "ValidPorts" list now looks something like this:

SBSSERVER.DOMAIN.TLD:593;SBSSERVER:593;DOMAINCONTROLLER.DOMAIN.TLD:593;DOMAINCONTROLLER:593;SBSSERVER.DOMAIN.TLD:6001-6002;SBSSERVER:6001-6002;SBSSERVER.DOMAIN.TLD:6004;SBSSERVER:6004;

Note that the HTTP 401 "not authorized" error in the IIS web site logs was generated not because of an authentication error, but because the RPC proxy denied access (port 593 wasn't in the ValidPorts list).