Exchange 2003 and POP3 accounts

NOTE: My answers to your questions are presuming that they client is still using a Windows SBS 2003 server.
<<Are we correct with our description of the role or purpose of the POP3 Connector?  >>
<<What are the concerns with Outlook having both the POP3 and Exchange accounts? >>
The POP3 Connector running on the server connects to the email provider (Provider B) and POPs the email (send and receive) directly from/to the user's Exchange mailbox. If the user also has a POP3 account set up in Outlook on their workstation, then this may cause problems.  This is an "either-or" type of setup; if the POP3 Connector is used, Outlook should not be set up with a POP3 account download.
As to your question #3, if this user was set up using the POP3 Connector on the server, then the difference was either a password issue or a timing issue.  The POP3 connector has a scheduler in it that controls when it connects to upload and download the email.  I believe the smallest interval allowed is something like 10 or 15 minutes.  So, it could have been a timing issue.  It also could have been a password issue if the password on her account at the email provider end had been changed for some reason. You can set the logging level for the POP3 connector to Medium or Maximum in the properties of the connector. Then, when it runs, you will be able to see in the event log every action taken by the connector.  This would highlight any problems with passwords, as you would see the errors in the log.
<<Remote or webmail access is a feature the customer wants with e-mail.  >>
 Outlook Web Access is a feature of Exchange 2003 that is automatically installed and configured when Exchange 2003 is installed.  If the user is, as stated above, using Windows SBS 2003 server, then you may need to run the Configure Email and Internet Connection Wizard (CEICW) to configure Outlook Web Access properly.  This will also allow you to configure the Remote Web Workplace, which includes Outlook Web Access and Remote Desktop Access through a website - if the client wants that level of remote access.  The wizard also provides a method of generating a self-signed SSL certificate for the OWA/RWW website, which is important for security purposes.
If the client is NOT using SBS, then OWA is still available, but you may need and want to have them purchase an SSL certificate from a public certificate authority.  RWW is not available with a standard Windows 2003 server.  If this is the case (Non-SBS server), you will want to read up on Exchange and Outlook Web Access configuration before you try to manage this server.
 

Thanks for your reply.  Your information is very helpful.  your explanation of the POP3 Connector is easy to understand.  I think one reason the POP3 download was added to their existing Exchange account was to deliver all messages to the "Malbox" instead of personal folders.  I need to discuss the issue relating to personal folders with my customer.

I have read about OWA and believe that is an option we need to investigate.  If we were able to use OWA to meet the remote access requirement, could we eliminate directing mail thru Provider B?  This would appear to be a more direct path for messages.  If we leave the message flow "as-is" with the POP3 Connector pulling messages, could we still configure OWA for remote access?  Shouldn't the inhouse messages then be available for web access since we are accessing the Exchange server instead of the POP3 server?  How does a user access OWA from his home computer?  

Thanks again for the reply.  Your reply prompted the additional questions but I believe we have a better understanding of the project ahead of us.

You're correct about the POP3 Connector.  The POP3 Connector downloads the POP mail directly to the user's Exchange mailbox. There is no need for personal folders and, in fact, the existence of personal folders could be confusing for the user.  In the presence of an Exchange server, you really don't want your users to be using personal folders for anything, as it just mucks things up for the user. Plus, anything stored in the personal folders would not be backed up with the Exchange database backups that I assume they are running regularly.
Using OWA could eliminate their need for Provider B, assuming that you run all of their email (send and receive) directly through their local Exchange server and eliminate all POP accounts.  In any case, even if you continue to use the POP3 Connector, as long as all the email is downloaded directly into the user's Exchange mailbox, eliminating any personal folders, then all of the email will be available through OWA.
The client needs to have a public static IP address for their server, however, so assuming that's in place, you can eliminate all POP mailboxes and use the client's Exchange server directly to send and receive all email.  You would need to change the MX record on Provider A's DNS servers to point to the client's static IP address.  If you're not familiar with DNS requirements, what you need is an A record for the mail host (i.e., mail.domain.com) pointing to the client's static IP address; a MX record pointing to that host name; and a PTR (rDNS) recording to resolve the reverse DNS entry to that host name as well.  An SPF record is also a good thing, although not absolutely necessary.
For spam filtering purposes, you might want to have the look at 3rd party spam software. However, there is some spam filtering built into Exchange 2003, so you would want to review the information in this tech article to configure that properly:
http://technet.microsoft.com/en-us/library/aa997261(EXCHG.65).aspx
 

Thanks again for the reply.  Your reply is easy to understand and provides information we need to discuss the options with our customer.  Please give us a few days to work with our customer and see if this is the path they want to take.

If there are other comments or suggestions, please let us know.  

<<How does a user access OWA from his home computer? >>
Reviewing this, I realized I forgot to answer this one final question. The URL of the website would be similar to any web page, i.e., http:// or https:// (depending on whether you're using SSL or not) followed by the server name, following by "/exchange." So, assuming you use SSL and the public server name of "mail.domain.com," the URL would be: https://mail.domain.com/exchange. This will bring up a login page, and when the user logs in with his/her network credentials, it opens Outlook Web Access to that user's mailbox.
 

Using remote desktop, I ran the CEICW Wizard and found the options for OWA and RWW were checked.  I used cancel to stop the wizard.  Using the HTM file, I copied the following into a Word document.    I changed the  domain name and I.P. information in this attachment.  Can you tell by the following if OWA is configured correctly?  As a test, I tried the https://mail.domain.com/exchange and got a message about the website's security certificate being issued for a different website's address.  I tried CONTINUE and got webpage not found.  

Without contacting our customer (the manager is out of town until Monday), I think they would want to continue using the POP3 connector but I do not know the terms of their contract with Provider B.

Just to be sure of terminology, is the I.P. address I use for remote desktop to their server the same I.P. address you reference as "public static IP address" in you second reply.  I'm assuming the are the same.

Thanks.

Wizard Information:
SUMMARY OF SETTINGS FOR CONFIGURE E-MAIL AND INTERNET CONNECTION WIZARD
This file contains detailed information about the configurations specified in the Configure E-mail and Internet Connection Wizard.  The configurations specified in the Configure E-mail and Internet Connection Wizard determine the settings for your network, firewall, secure Web site, and e-mail.

NETWORKING CONFIGURATION SUMMARY

After the wizard completes, the following network connection settings will be configured:
Connection type: broadband connection using  a local router device with an IP address
After the wizard completes, the following broadband connection settings will be configured:
Router connection information:
Local IP address of the router: 192.168..X.1
Preferred DNS server: 208.XX.XXX..222
Alternate DNS server: 208.XX.XXX.220
Connection information for the network adapter used to connect to your local network:
Local network connection name: Server Local Area Connection
Local network connection IP address: 192.168.X.10
Local network connection subnet mask: 255.XXX.XXX.0
The Default Gateway for the network adapter used to access the local network is cleared so that network traffic is routed correctly.
      NOTE: The router device connects to the Internet using the same network adapter as the one used to connect to the local network.
Routing and Remote Access will be configured as follows:
      Enable the service as a router for the local area network to route network traffic to the Internet.
      Enable IP routing to route network traffic to the Internet.
      Enable broadcast name resolution.
      Enable Basic Firewall on the demand-dial interface.
      Disable the option to automatically assign IP addresses by using the DHCP allocator because DHCP is provided by your servers DHCP server.
      Disable the option to resolve IP address for clients using DNS because DHCP is provided by your servers DHCP server.
Bind the DHCP Server service to the IP address of the local network adapter so that your servers DHCP server does not provide DHCP addresses to computers on the Internet.
Configure the DHCP scope to assign IP addresses to client computers using the following scope options:
      Set the router option (003) to 192.168.X.1 to define the default gateway used by client computers.
      Set the DNS server option (006) to 192.168.X.10 to provide client computers with name resolution services for the local network.
      Set the DNS domain name option (015) to DOMAINNAME.local.
      Set the Windows Internet Name Service (WINS) server option (044) to 192.168.X.10.
      Set the WINS node type option (046) to h-node. Set forwarders to 208.XX.XXX.222 and 208.XX.XXX.220 so that name resolution requests intended for the Internet are forwarded to the DNS servers at your ISP.
Set the DNS Server service to listen to the IP address of the local network adapter to ensure that the DNS server is not responding to DNS request from the Internet.
Enable dynamic and secured updates to allow client computers to update DNS, but not allow DHCP to update DNS. This allows client computers to update the DNS table when they are turned on.
Modify the binding order so that the local network adapter has the highest priority to route network traffic to the Internet.
Set Internet Explorer to never dial a connection, to not use proxy settings, and set the home page to the address of the computer running Windows Small Business Server.

FIREWALL CONFIGURATION SUMMARY

After the wizard completes, the following firewall settings will be configured:
      Enable IP routing.

      Add the loopback adapter IP address of 127.0.0.1 to support the http://localhost for IIS.

Internet Information Services (IIS) will be configured as follows:

      Restrict default Web site of IIS to only respond to requests from the local network.

      Set the maximum number of incoming Web request connections allowed to the default Web site to 500. This improves system availability and reliability by mitigating denial-of-service attacks against your Web site.

      Allow access to Outlook Web Access to the Internet by modifying the IP permissions of the Web site for the following IIS Web site directories to allow clients from any IP address to connect: /exchange/, /exchweb/, /public/.  Additionally, the Default Web site is configured for Forms Based Authentication (also called Cookie Authentication).  The Public folder is also configured to accept Windows Integrated Authentication.

      Allow access to Remote Web Workplace to the Internet by modifying the IP permissions for the Remote IIS Web site directory to allow clients from any IP address to connect.

      NOTE:  Users connecting to Outlook Web Access, Remote Web Workplace, and Outlook via the Internet, must use an https:// connection. Additionally, these Web site directories are configured to require 128-bit encryption. All other Web sites can use either https:// or http:// connections.


SECURE WEB SITE CONFIGURATION SUMMARY

After the wizard completes, the following secure Web site settings will be configured:
Secure Sockets Layer (SSL) will be configured as follows:
Do not change current Web server certificate

E-MAIL CONFIGURATION SUMMARY

After the wizard completes, the following e-mail settings will be configured:
Exchange will be configured as follows:
Email: Do not change Exchange configuration for Internet e-mail.
      Keep the existing Internet e-mail configuration.

After the wizard completes, the icwlog.txt in E:\Program Files\Microsoft Windows Small Business Server\Support is updated.
After the wizard completes, the wizard script file config.vbs is created in E:\Program Files\Microsoft Windows Small Business Server\Networking\Icw.
NOTE: Each time the wizard runs, a new config.vbs file is automatically generated to preserve the previous settings. For example config.vbs, config1.vbs, config2.vbs, and so on.

Another detail about the CEICW Wizard.  On the Web Server Certificate section, the option to DO NOT CHANGE CURRENT WEB SERVER CERTIFICATE was selected.  However, in the CREATE A NEW CERTIFICATE section, there was a Web server name listed.  The format is servername.domain.com.  

Thanks

<<is the I.P. address I use for remote desktop to their server the same I.P. address you reference as "public static IP address">>
Yes - the same IP address would be used for email and web access, including RWW and OWA.
<<Restrict default Web site of IIS to only respond to requests from the local network>>
This is the default configuration for IIS. However, what it does is effectively prevent anyone from accessing OWA and RWW except from internal IP addresses. You need to follow these steps, as shown in the log, to enable access:
<< Allow access to Outlook Web Access to the Internet by modifying the IP permissions of the Web site for the following IIS Web site directories to allow clients from any IP address to connect: /exchange/, /exchweb/, /public/....>>
<<Allow access to Remote Web Workplace to the Internet by modifying the IP permissions for the Remote IIS Web site directory to allow clients from any IP address to connect.

      NOTE:  Users connecting to Outlook Web Access, Remote Web Workplace, and Outlook via the Internet, must use an https:// connection. Additionally, these Web site directories are configured to require 128-bit encryption. All other Web sites can use either https:// or http:// connections.>>

The web site security message is normal for the SBS self-signed certificates.  Users need to click the Continue option and install the certificate locally.

Just saw your second post.  Whoever created that certificate obviously used a different name from my suggestion of "mail.domain.com."  If that name is registered on Provider A's DNS server as the public host name of that server, then you should be able to connect to it using either the IP address or that server name:  https://servername.domain.com/exchange or https://IPaddress/exchange.
 

<<Restrict default Web site of IIS to only respond to requests from the local network>>
Where do I change this setting?  Is this setting in IIS?  Since I am not familiar with IIS, I opened the IIS manger and checked the DEFAULT WEB SITE.  Under this site, I saw EXCHANGE, EXCHWEB, and PUBLIC.  EXCHANGE and PUBLIC did not have any entries to view.  EXCHWEB had entries.  I do not know what to look at for IP permissions on any entry.    Should there be a specific site for OWA and RWW?  

OWA appears to be the best choice for our customer and I believe we are close to making this work if we can understand how their system was originally configured.  Some components appear to be in place but probably never implemented becaus eth eneed was not there.  

Thanks for your assistance and patience on this project.  

The security settings can be found in IIS in the properties sheet of each site or virtual directory. Under the Default Web Site, the Exchange, ExchWeb and Public folders (virtual directories) represent the various components of Outlook Web Access. The Remote virtual directory is the RWW website directory. If the client isn't going to use Remote Web Workplace, then you don't have to check this one, of course.
Refer to my screen captures to see what these dialog boxes look like. On each of these folders:

1. Right-click and then select Properties.  
2. In the Properties dialog box, click the Directory Security tab.
3. On that tab, click the Edit button under the IP address and domain name restrictions section.
4. In that dialog box, make sure that the radio button for Granted access is selected.
5. Click OK on all dialog boxes to accept your changes and close them.

IIS-Right-Click-menu.jpg
IIS-Properties-DS-tab.jpg
IIS-DS-IP-Granted.jpg

I checked Exchange, ExchWeb, and Public folders.  All were set for Granted Access.  Other observations:  
There is an Exchange-OMA folder.  Access is denied except for two I.P. addresses.
On the Properties screens, there is an additional tab for ASP.NET.  Any concern here?
After opening the properties of Exchange/Directory Security, I noticed a Secure Communications that was not on your screen print.  View Certificate shows the certificate has expired.  Any concern here?  
Thanks

The Exchange-OMA directory is used for synchronization with mobile devices.  You don't have to worry about it unless that becomes an issue for this client.
Yes, the SSL certificate expiration would be a problem. What I would suggest is that you remove that certificate, then re-run the CEICW and create a new certificate.  While running the wizard, you would want to select the checkmarks to avoid changing your Internet connection or email settings. Just create a new certificate and then run through the rest of the wizard.  You might want to remove the checkmark for RWW if they are not going to use it, and just let it recreate the OWA setup.  Then re-check the security settings, including the IP access to make sure that the SSL certificate is current and the directory access is still set up correctly.
If you still can't get to the website by name, try IP.  If you still can't connect, let me know what error(s) you are getting - for example, do you get the login box, do you get the SSL certificate warning, do you get a 500 or 404 error, etc.

OWA, IIS, and SSL certificates are all areas I have not worked with before but, with your guidance, has been a good learning experience.  I know my questions are relating to some basic knowledge but this is new to me.  I believe I understand the role of the certificate, but  is there a way to run OWA, as a test, without the certificate?   I did test OWA on a local client and proceeded around the expired certificate warning.  
I found instructions on how to remove expired SSL certificate on following link:  https://www.experts-exchange.com/questions/22520240/Remove-Replace-expired-SSL-certificate.html
Is this still a good solution?  Is it possible that other areas may use this certificate?  If I delete the certificate, will I be prompted to create a new certificate when I rerun CEICW or should a new certificate be created before starting the wizard?  I have seen some EE articles that indicate a certificate must be purchased.
Thanks

You can run OWA without a certificate. It just isn't a good idea in the long run for security reasons.  If you just want to test, you can remove the certificate, test OWA without it, and then re-run the CEICW to create a new certificate.
That solution is fine, except that instead of selecting the option to replace the certificate, you want to select the option to remove it. Don't worry about other areas using that certificate - it's expired so it should be removed anyway. You will be prompted to create a new certificate when running the CEICW. You want to go ahead and do this, and it will create and automatically install the certificate into the Default Web Site.  Be sure to use the public FQDN of the server that you will be using to access this server through the web - i.e., the name that is registered with the ISP's DNS servers as the public host and MX record name.
This is a self-signed certificate created by the server itself.  This is fine for SBS running OWA and RWW.  If you wanted a higher level of security (encryption higher than 128) or needed a certificate from a public certificate authority due to other considerations, you could purchase one from a number of providers - GoDaddy, Verisign, Thawte, etc.  For your purposes I don't think this is necessary.

I removed the certificate and reran CEICW.  (I was not sure how to test OWA without a certificate.) I created a new certificate when prompted.  I accepted the values that were displayed such as I.P. addresses.  I restarted the web site and tested OWA.  It ran fine on the local network.  The attached file shows the errors when I tried to access OWA from my computer on my network.  The first print shows the error when I used https://servername.domainname.com/exchange.  The second print used https://xxx.xx.xx.xx.domainname.com/exchange.  The third print shows the error when selecting Continue.  Is there a possible issue with the firewall?  What should be the directory security setting in the Default Web Site properties?
Thanks.  
OWA.pdf

When you use the IP address, are you putting ".domain.com" after the IP?  Try it with just the IP address, no "domain.com" - i.e., https://1.2.3.4/exchange

I tried with and without "domain.com".  Without "domain.com", I get same error as Print 1.  Do you think we are close to making this work?  I think our customer will be better satisfied with OWA than the webmail provided by Provider B.  I really appreciate your time, assistance and patience..  
Thanks

I think we're very close to making this work. A lot depends on the internal Exchange domain name. Could you please post the following info - you can mask the actual domain name - what I'm after is what root domain is being used (i.e., ".com" or ".local"):
1.  Internal AD domain name.
2.  Internal email domain name.
3.  Public domain name.

Checking Exchage Server Properties, "domainname.local" is listed Directory Access tab under Domain.
In Active directory, Domain Controllers, Server name, Properties, the DNS name is "servername.domainname.local"
The website name is "www.domainname.com"

If this is not what you are needing, please provide location of the information.  Getting to this level of detail is new to me but I've learned a lot from this project.  
Thanks again for your patience and guidance.

If the www.domainname.com website resides on the SBS server, then you can use this URL to get to OWA - just add the "/exchange" after it.  You would have to once again delete and recreate the certificate, however, and make sure you user that URL (www.domainname.com).
However, if this website is hosted somewhere else, i.e., at Provider A or B, then this won't work, obviously.  What you need to to is:
1.  Add a host name for the Exchange server on the Provider A's DNS server that points to your clients' public IP address.  For example, using an IP of 221.112.221.1 and a server name of "server," you'd have to add a host record for "server.domainname.com" pointing to 221.112.221.1. IF and ONLY IF there is already a host record for this IP address (i.e., "smtp.domainname.com" or "mail.domainname.com" or something like that), you can use that name.  Again, you'd have to remove and recreate the certificate to match that name. The public host name, including the "domainname.com" needs to match exactly the FQDN that you use when you created the certificate on the SBS server. It cannot be a ".local" domain, it must match the client's public domain name.
If you don't have this information - i.e., you don't know what Provider A's DNS records for this client look like, you can use any number of DNS look-up websites to check this.  I use www.dnsstuff.com, but there may be a charge for using their services. It used to be free, but I have a membership now and I'm not sure what tools they offer on a free usage basis and which ones are only available to members.
2.  Make sure that the client's firewall/router  is set to allow incoming communications on both HTTP (port 80) and HTTPS (port 443), and forward those ports to the internal IP address of the SBS server. We didn't check this before, but I think it's probably already set. However, it's worth checking to be sure.
Once you've got that set, you can test again.  It may take a day or two after you add the DNS record for it to resolve correctly. The objective here is to eliminate the error message that says that the certificate is for the incorrect server name.  You may still get an error message, but it should look like the one in the attached screen capture instead. If you get the error, you can then click the Continue button and you should get the website login page.

Provider A has an A Record for "servername.domainname.com" pointing to the I.P. of the local server.  TTL is set to 7200.  "servername.domainname.com " is the name used on the certificate generated last week.  There are 5 A Records listed.  Only one points to the local server.  As information, I also noticed a CNAME record showing "mail.domainname.com" refers to webmail.providerB.com with TTL 2700.

I will check the firewall ports but wanted to forward the above information.

Thanks

The ports appear to be open in the Sonic firewall.  While reviewing the setting of CEICW, I noticed the PreferredDNS and alternate DNS server addresses are not in line with DNS listed in ipconfig.  The router address is correct.  The I.P. is not for local server, Provider A, or Provider B.  When I recreated the certificate, I did not change the router connection information.  Is this a concern?

The CEICW asks for the ISP's DNS server addresses, which are then added to the DNS forwarders on the SBS machine. You should definitely fix these if they are not pointing to the correct ISP's DNS server addresses.
In the ipconfig of the server, it should be pointing to itself and only itself - i.e., it's internal IP address.
 

At this point, would recommend running through the entire CEICW and reconfiguring everything except the certificate - if you're sure the certificate you created before was for the correct public server name. If you're unsure at all about the name on the certificate matching, then go ahead and create a new certificate again.

I contacted Provider A for their DNS server address.  I'm considering putting this address as the Preferred DSN server in CEICW and the old Preferred as the alternate.  Should this work and should I wait a couple of days before I try OWA?  Any concerns I should be aware of?  (We have checked and changed so many items without resolving the problem that I want to be sure I do not create more problems.)  Is there another place on the server that the ISP's DNS server is entered?  Maybe I'm second guessing myself but I want to verify I'm using the correct address.
Another observation:  When I run servername/exchange on the local network, OWA can be used to check email.  I did notice that after the username and password is entered, the username is changed to username.local.  Is this correct?

Thanks

<<I'm considering putting this address as the Preferred DSN server in CEICW and the old Preferred as the alternate.....Is there another place on the server that the ISP's DNS server is entered?>>
The IP address(es) you enter while running the CEICW are potentially put in two different locations.  (1) If you are using a UPnP router and you say "yes" to the question about autoconfiguring the router, then these will be added to the router automatically as DNS resolvers for the WAN link. (2) They will be added to the "Forwarders" tab in the properties of the DNS Server service on the SBS server.  You can check this, if you want, by opening the DNS management console on the server, right-clicking on the top-level DNS object, and opening the Properties dialog. Look on the Forwarders tab and you should see those addresses there.
The username being changed is automatic, because it is referencing the local domain for the user's login name.  That is correct.

Am I correct in thinking that the ISP's DNS server address may be the missing link on this project?  If I change the records as stated in the earlier reply, how long should I wait before testing OWA?  
Thanks

Well, I doubt it's a major part of the problem, as it would be causing problems internally rather than externally.  Those forwarders are only used on the internal DNS server to resolve names that are not on the local domain. The change is immediate after you run the CEICW, there is no waiting period.
The parts of the CEICW that are more pertinent to your specific problem are the creation and naming of the server SSL certificate, and the setup of the access to the different web components, such as OWA and RWW.

I removed the certificate and reran CEICW and selected only OWA.  I tried to run OWA on our network and received the message about Internet Explorer could not display the webpage.  (Tried https://xxx.xxx.xx.xx/exchange and https://servername.domainname.com/exhange.)  I returned to the customer's server and looked at the properties of the certificate.  On the General tab, the only item checked is Enable only the following purposes.  Server Authentication is the only item checked.  Is there anything to check on the View Certificate/Details tab?
Another observation:  In IIS, Website, Default Web site shows IP Address *All Unassigned*, Port 80, SSL port 443.  Companyweb shows IP Address server internal IP, Port 80, SSL port 444.  Any issues here?
Thanks.  

Your certificate should look like the screen capture attached.  Sounds like there's something going wrong in the creation of the certificate.
The Default Web Site settings are correct.  The Companyweb is designed for internal access only, so that's why it shows the internal IP address only.  Outlook Web Access runs under the Default web site, not the Companyweb site.

SBS-SSL-cert-sample.jpg

At this point, let's try it without the SSL certificate.  To disable it for the moment, go to the properties of the Default Web site, Directory Security tab. Click the Edit button under Secure communications, and uncheck the Require SSL ... check box.  You need to also uncheck this box on the properties of the Exchange, Exchweb, and Public virtual directories. Then re-try your OWA connection with the http:// instead of https:// and see what happens.

I tried without the certificate but received the same messages.  I have returned the settings to require SSL.  I did notice this item was not checked on the Default Web Site although the item was checked on Exchange, Exchweb, and Public.  I tried OWA with and without SSL requirement on all directories.  

Looking back at your responses, on 4/27 @10:13am, you referenced Provider A's DNS server.  This address is not in CEICW.  In CEICW, Preferred DNS server is the ISP's DNS server address.  The Alternate address is the DNS Preferred address server listed in CEICW when we started this project.  Should I recheck Provider A's server?  

Have we encountered a problem that we may not be able to resolve?  Since we did not originally configure the server, e-mail, and network could there may be something that we are overlooking?
Thanks.

I assumed that Provider A was the ISP. The DNS server(s) listed in the CEICW should be the ones that you want to use as forwarders.  Usually this would be the ISP's DNS servers.
Since you can't get to OWA from outside (your own network), let's see if you can get to it from inside the client's network.  First, open a command prompt on the client's server and run the command: iisreset.  This will restart all of the IIS services, including the SMTP service, so there will be a momentary (1-2 minute) interruption of email service on the client's side. Then, again on the client's server, open IE, put in https://[]servername]/exchange and see if OWA will come up that way. If that doesn't work, then there's something wrong in the configuration of the OWA website.

Sorry for the confusion on the roles of Provider A and B.  I was not sure myself until we started researching DNS.  Internet service is provided by AT&T.  Provider A manages domain name and DNS.  Provider B hosts the website and has e-mail and webmail service.  E-mail is directed to Provider B and pulled to local Exchange with POP3 connector.  OWA appeared to be a better product than B's webmail client.  

OWA is working on the local server.  I did not run iisreset but will try to run it at the end of the day or after hours.  The customer depends on e-mail service and I do not want to interrupt no more than necessary.  I stopped and restarted the sites when we tested without SSL certificate.  

Thanks    

I cannot ping the server by name or address from our network.  I can ping servername.local.domain.com I and get an address for Provider B.  
The URL does not work.  To insure I did not miss something, can you please restate the steps for checking permissions, the firewall, and DNS?
Thanks again for your assistance and patience.  

This would be much quicker if you would be willing to post your client's actual domain name and public IP address here so that I can do some tests myself. However, I can understand if you are reluctant to do so.
The fact that you can't ping the server by name indicates that something is wrong with the public DNS records for this server. This is probably the root of the problems you're having.
Is the IP address that you get back when you ping servername.local.domain.com the same public IP address that you are using for servername.domain.com?
The fact that you can't ping by IP address could be significant, or it could just mean that the client's firewall is set to refuse to respond to ICMP packets.
The first step is to double-check that there is a host record on the public DNS zone at Provider A (that's where the zone is hosted, right?) matching the server name and IP address that you are trying to use.  I thought you had already checked this, but let's check again.  You can use this website:
http://www.dnswatch.info/
Put in the server name, including the domain (i.e., servername.domain.com) in the lookup box on the site and click Resolve.  This should come back with results similar to the following:
Searching for servername.domain.com. A record at J.ROOT-SERVERS.NET. [192.58.128.30] ...took 14 ms
Searching for M.GTLD-SERVERS.NET. A record at B.ROOT-SERVERS.NET. [192.228.79.201] ...took 157 ms
Searching for M.GTLD-SERVERS.NET. A record at A.GTLD-SERVERS.NET. [192.5.6.30] ...took 135 ms
Searching for servername.domain.com. A record at M.GTLD-SERVERS.NET. [192.55.83.30] ...took 361 ms
Searching for servername.domain.com. A record at [Provider A's DNS server name]. [Provider A's IP address] ...took 97 ms

A record found: [Your client's public IP address] Domain Type TTL Answer servername.domain.com. A 86400 [Your client's public IP address]
If you get a different result:

• if the last "Searching for " line shows a different host than Provider A's DNS server; or
• if the last line of the response shows a different IP address than what you expected; or
• if the last line of the response says "No such host"

Then we can go from there.

Since this is a customer of ours, I am reluctant to post their information on this site.  I realize if I could get this information to you in a more secure setting, the issue may be resolved quicker.  This is the result of the dnswatch:  The A record was found.  The domain is correct (servername.domain.com), TTL is 7200, and answer is the I.P. we use for Remote Desktop.  This is also the name and address in Provider A's "A" record.  The last entry shows the address of Provider A's DNS server.  Provider A shows five entries in their IP Address (A Records) section.  The above record is the fourth entry.
Thanks.

So, you can use Remote Desktop, but you can't get to the OWA website?  That sounds like a port forwarding problem to me.  It's odd, though, that you can't ping the server by name, either.  That sounds suspicious.  How are you getting to the remote desktop? Are you using a VPN connection?
What type of router are you using?  Have you check to make sure that the ports (80 and 443) are not only open on the router for incoming traffic, but are forwarded to the server's internal IP address?

We do not use VPN for Remote Desktop.  They have a Sonic firewall.  Since I am not familiar with the Sonic device or checking ports, I had another Tech check ports 80 and 443.  He said they were open.  I'm not sure about forwarding.  He will be out of the office most of the day.  I can access the device if you can give me a few instructions on what to look for.  Where would I check the server's internal IP address on the Sonic firewall?
Thanks

Unfortunately, I'm not familiar enough with Sonicwall products to be able to guide you through checking that.  Interfaces and terminology can be very different among different firewall manufacturers. What you need him to check is whether those two ports are open for incoming as well as outgoing traffic, and whether the incoming traffic on those ports is redirected (i.e., forwarded or NATted) properly to the internal IP address of the SBS server.  If the ports are open, but there is no redirection, then the packets will be dropped.

Just an update.  We were onsite today and checked the Sonic device.  It is model Pro100.  The ports appear to be open but we are not sure about redirection.  We are looking for more information on this before we make any changes.

Thanks for your willingness to help with this issue.  I selected this response as the "solution" because this is the point where all the initial questions had been answered.  From an Exchange view, I am satisfied with the answers and feel my questions were answered with the information I was requesting.  OWA is still an issue but it does not appear to be related to issues in Exchange.  I appreciate your honesty regarding the Sonicwall device.  I have posted a new question relating to this issue.  

Thanks again for your assistance, time, and patience.