Use Telnet to test SMTP communication on Exchange servers(Copy: https://technet.microsoft.com/en-us/library/bb123686(v=exchg.160).aspx)

Exchange 2016

Other Versions

  Applies to: Exchange Server 2016
Topic Last Modified: 2016-08-09
Learn how to use Telnet to test SMTP connectivity and mail flow on Exchange servers.
You can use Telnet to test Simple Mail Transfer Protocol (SMTP) communication between messaging servers. SMTP is the protocol that's used to send email messages from one messaging server to another. Using Telnet can be helpful if you're having trouble sending or receiving messages because you can manually send SMTP commands to a messaging server. In return, the server will reply with responses that would be returned in a typical connection. These results can sometimes help you to figure out why you can't send or receive messages.
You can use Telnet to test SMTP communication to:

• Test mail flow from the Internet into your Exchange organization.
  
• Test mail flow from your Exchange to another messaging server on the Internet.
  

Tip:

Did you know that, instead of using Telnet to test SMTP connectivity, you can use the Microsoft Remote Connectivity Analyzer at https://testconnectivity.microsoft.com/? With the Remote Connectivity Analyzer, you can choose the connectivity test you want to do, in this case Inbound SMTP Email, and follow the instructions shown. It'll step you through the information you need to enter, run the test for you, and then give you the results. Give it a try!

What do you need to know before you begin?

• Estimated time to complete: 15 minutes
  
• Exchange permissions don't apply to the procedures in this topic. These procedures are performed in the operating system of the Exchange server or a client computer.
  
• This topic shows you how to use Telnet Client, which is included with Windows. Third-party Telnet clients might require syntax that's different from what's shown in this topic.
  
• The steps in this topic show you how to connect to an Internet-facing server that allows anonymous connections using TCP port 25. If you're trying to connect to this server from the Internet, you need to make sure your Exchange server is reachable from the Internet on TCP port 25. Similarly, if you're trying to reach a server on the Internet from your Exchange server, you need to make sure your Exchange server can open a connect to the Internet on TCP port 25.
  
• You might notice some Receive connectors that use TCP port 2525. These are internal Receive connectors and aren't used to accept anonymous SMTP connections.
  
• If you're testing a connection on a remote messaging server, you should run the steps in this topic on your Exchange server. Remote messaging servers are often set up to make sure the IP address where the SMTP connection is coming from matches the domain in the sender's email address.
  
• For information about keyboard shortcuts that may apply to the procedures in this topic, see Keyboard shortcuts in the Exchange admin center.
  

Tip:
Having problems? Ask for help in the Exchange forums. Visit the forums at: Exchange Server, Exchange Online, or Exchange Online Protection.

How do you do this?

Step 1: Install the Telnet Client on your computer

On most versions of Windows, you'll need to install the Telnet client before you can use it. To install it, see Install Telnet Client.

Step 2: Find the FQDN or IP address of the destination SMTP server

To connect to an SMTP server by using Telnet on port 25, you need to use the fully-qualified domain name (FQDN) (for example, mail.contoso.com) or the IP address of the SMTP server. If you don't know the FQDN or IP address, you can use the Nslookup command-line tool to find the MX record for the destination domain.

Note:
Network policies might prevent you from using the Nslookup tool to query public DNS servers on the Internet. As an alternative, you can use one of the freely-available DNS lookup or MX record lookup web sites on the Internet.

1. At a command prompt, type nslookup, and then press Enter. This command opens the Nslookup session.
   
2. Type set type=mx, and then press Enter.
   
3. Type the name of the domain for which you want to find the MX record. For example, to find the MX record for the fabrikam.com domain, type fabrikam.com., and then press Enter.
   

   Note:
   When you use a trailing period ( . ), you prevent any default DNS suffixes from being unintentionally added to the domain name.

   The output of the command looks like this:
   
   fabrikam.com mx preference=10, mail exchanger = mail1.fabrikam.com
   fabrikam.com mx preference=20, mail exchanger = mail2.fabrikam.com
   mail1.fabrikam.com internet address = 192.168.1.10
   mail2 fabrikam.com internet address = 192.168.1.20
   

   You can use any of the host names or IP addresses that are associated with the MX records as the destination SMTP server. A lower value for preference (preference = 10 vs. 20) indicates a preferred SMTP server. Multiple MX records and different values of preference are used for load balancing and fault tolerance.
   
4. When you're ready to end the Nslookup session, type exit, and then press Enter.
   

Step 3: Use Telnet on Port 25 to test SMTP communication

In this example, we're going to use the following values. When you run the commands on your server, replace these values with ones for your organization's SMTP server, domain, etc.

• Destination SMTP server   mail1.fabrikam.com
  
• Source domain   contoso.com
  
• Sender's e-mail address   chris@contoso.com
  
• Recipient's e-mail address   kate@fabrikam.com
  
• Message subject   Test from Contoso
  
• Message body   This is a test message
  

Tip:

The commands in the Telnet Client aren't case-sensitive. The SMTP command verbs in this example are capitalized for clarity. You can't use the backspace key in the Telnet session after you connect to the destination SMTP server. If you make a mistake as you type an SMTP command, you need to press Enter, and then type the command again. Unrecognized SMTP commands or syntax errors result in an error message that looks like this: 500 5.3.3 Unrecognized command

1. Open a Command Prompt window, type telnet, and then press Enter.
   This command opens the Telnet session.
   
2. Type set localecho, and then press Enter.
   This optional command lets you view the characters as you type them, and it might be required for some SMTP servers.
   
3. Type set logfile <filename>, and then press Enter.
   This optional command enables logging and specifies the log file for the Telnet session. If you only specify a file name, the log file is located in the current folder. If you specify a path and file name, the path needs to be on the local computer, and you might need to enter the path and file name in the Windows DOS 8.3 format (short name with no spaces). The path needs to exist, but the log file is created automatically.
   
4. Type OPEN mail1.fabrikam.com 25, and then press Enter.
   
5. Type EHLO contoso.com, and then press Enter.
   
6. Type MAIL FROM:chris@contoso.com, and then press Enter.
   
7. Type RCPT TO:kate@fabrikam.com NOTIFY=success,failure, and then press Enter.
   The optional NOTIFY command specifies the particular delivery status notification (DSN) messages (also known as bounce messages, nondelivery reports, or NDRs) that the SMTP is required to provide. In this example, you're requesting a DSN message for successful or failed message delivery.
   
8. Type DATA, and then press Enter.
   
9. Type Subject: Test from Contoso, and then press Enter.
   
10. Press Enter again.
    A blank line is needed between the Subject: field and the message body.
    
11. Type This is a test message, and then press Enter.
    
12. Type a period ( . ), and then press Enter.
    
13. To disconnect from the SMTP server, type QUIT, and then press Enter.
    
14. To close the Telnet session, type quit, and then press Enter.
    

Here's what a successful session using the steps above looks like:

C:\Windows\System32> telnet

Microsoft Telnet> set localecho
Microsoft Telnet> set logfile c:\TelnetTest.txt
Microsoft Telnet> OPEN mail1.fabrikam.com 25

220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at Fri, 5 Aug 2016 16:24:41 -0700
EHLO contoso.com
250-mail1.fabrikam.com Hello [172.16.0.5]
250-SIZE 37748736
250-PIPELINING
250-DSN
250-ENHANCEDSTATUSCODES
250-STARTTLS
250-X-ANONYMOUSTLS
250-AUTH NTLM
250-X-EXPS GSSAPI NTLM
250-8BITMIME
250-BINARYMIME
250-CHUNKING
250 XRDST
MAIL FROM: chris@contoso.com
250 2.1.0 Sender OK
RCPT TO: kate@fabrikam.com NOTIFY=success,failure
250 2.1.5 Recipient OK
DATA
354 Start mail input; end with <CRLF>.<CRLF>
Subject: test
   
This is a test message.
.
250 2.6.0 <c89b4fcc-3ad1-4758-a1ab-1e820065d622@mail1.fabrikam.com> [InternalId=5111011082268, Hostname=mail1.fabrikam.com] Queued mail for delivery
QUIT
221 2.0.0 Service closing transmission channel

Step 4: Success and error messages in the Telnet Session

This section provides information about the success and failure responses to the commands that were used in the previous example.

Note:
The three-digit SMTP response codes that are defined in RFC 5321 are the same for all SMTP messaging servers, but the text descriptions in the responses might be slightly different.

SMTP reply codes

SMTP servers respond to commands with a variety of numerical reply codes in the format of x.y.z where:

• X indicates whether the command was good, bad, or incomplete.
• Y indicates the kind of response that was sent.
• Z provides additional information about the command

When a response is received by the server that opened the connection, it can tell whether the remote server accepted the command and is ready for the next one, or if an error occurred.
The first digit (X) is particularly important to understand because it indicates the success or failure of the command that was sent. Here are its possible values, and their meanings.

 

Reply code	Meaning
2.y.z	The command that was sent was successfully completed on the remote server. The remote server is ready for the next command.
3.y.z	The command was accepted but the remote server needs more information before the operation can be completed. The sending server needs to send a new command with the needed information.
4.y.z	The command wasn't accepted by the remote server for a reason that might be temporary. The sending server should try to connect again later to see if the remote server can successfully accept the command. The sending server will continue to retry the connection until either a successful connection is completed (indicated by a 2.y.z code) or fails permanently (indicated by a 5.y.z code). An example of a temporary error is low storage space on the remote server. Once more space is made available, the remote server should be able to successfully accept the command.
5.y.z	The command wasn't accepted by the remote server for a reason that is isn't recoverable. The sending server won't retry the connection and will send a non-delivery report back to the user who sent the message. An example of an unrecoverable error is a message that's sent to an email address that doesn't exist.

The table above is based on information provided by RFC 5321 (Simple Mail Transfer Protocol), section 4.2.1. Additional information, including descriptions of the second (Y) and third (Z) digits of SMTP reply codes is included in this section, and in sections 4.2.2 and 4.2.3.

OPEN command

Successful response   220 mail1.fabrikam.com Microsoft ESMTP MAIL Service ready at <day-date-time>
Failure response   Connecting to mail1.fabrikam.com...Could not open connection to the host, on port 25: Connect failed
Possible reasons for failure

• The destination SMTP service is unavailable.
  
• Restrictions on the destination firewall.
  
• Restrictions on the source firewall.
  
• Incorrect FQDN or IP address for the destination SMTP server.
  
• Incorrect port number.
  

EHLO command

Successful response   250 mail1.fabrikam.com Hello [<sourceIPaddress>]
Failure response   501 5.5.4 Invalid domain name
Possible reasons for failure

• Invalid characters in the domain name.
  
• Connection restrictions on the destination SMTP server.
  

Note:

EHLO is the Extended Simple Message Transfer Protocol (ESMTP) verb that's defined in RFC 5321. ESMTP servers can advertise their capabilities during the initial connection. These capabilities include the maximum accepted message size and supported authentication methods. HELO is the older SMTP verb that is defined in RFC 821. Most SMTP messaging servers support ESMTP and EHLO. If the non-Exchange server that you're trying to connect to doesn't support EHLO, you can use HELO instead.

MAIL FROM command

Successful response   250 2.1.0 Sender OK
Failure response   550 5.1.7 Invalid address
Possible reasons for failure   A syntax error in the sender's e-mail address.
Failure response   530 5.7.1 Client was not authenticated
Possible reasons for failure   The destination server doesn't accept anonymous message submissions. You receive this error if you try to use Telnet to submit a message directly to a Mailbox server that doesn't have a Receive connector that's configured to accept anonymous connections.

RCPT TO command

Successful response   250 2.1.5 Recipient OK
Failure response   550 5.1.1 User unknown
Possible reasons for failure   The specified recipient doesn't exist.

Read more »

Posted in: Chec Mail,Exchange,Lotus Dominino,Lotus Notes

Step-by-Step: Publishing a Single Exchange 2003 OWA with ISA 2004 Firewall Forms Based Authentication

I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access using forms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.

Step-by-Step:
Publishing a Single Exchange 2003 OWA with
ISA 2004 Firewall Forms Based Authentication by Liran Zamir
By Liran Zamir

Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106
I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access using forms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.

The procedures in this article will not work for multiple Exchange server environments as the publishing rule can only redirect request to a single server. If implemented in a multiple server environment, users will only be able to access OWA mailboxes located on the published server. I presume that in a multiple server environment the procedure could be configured only when the actual published server is an Exchange front-end server.
The advantage of publishing Exchange Outlook Web Access (OWA) using the ISA firewall's Forms-Based authentication is the ability to off load the authentication of web clients from the Exchange server to the ISA firewall, and to prevent unauthenticated communication from reaching the Exchange server. The ISA firewall's Forms-Based authentication works with Exchange 5.5, 2000 and 2003.
This article will focus on Exchange 2003, where a web site certificate is used for two purposes:

1. Provide SSL communication between the remote client and the ISA firewall.
2. Provide SSL communication between the ISA firewall and the Exchange server.

This will create an SSL to SSL bridge where the SSL communication from the remote client is terminated at the ISA firewall, and another SSL session is created between the ISA firewall and the exchange server. The remote client does not actually connect directly to the Exchange server over SSL.
Steps for deployment:
Preparing the Exchange server 2003 and certificates.Decision point – Which certificates to use
Create your own certificates
Generating the web site certificate request
From a request to a certificate
Importing the certificates to the ISA firewall.Checking SSL connectivity between the ISA firewall and the OWA site
Importing the certificates
Checking Browser connectivity from ISA to the OWA site
Configure the ISA Web Listener and Publishing rule.
Verify External connectivity.

Preparing the Exchange server 2003 and certificates.

NOTE! Do not enable forms-based authentication on the Exchange server itself.

The first step to take is to configure your internal Exchange 2003 server to use a web site certificate for client connections. The clients may be internal or external network clients, as far as the Exchange server is concerned. Since in our case remote clients will actually connect to the ISA firewall, the ISA firewall itself will act as a client to the OWA web site. The Exchange server OWA web site can be configured to require SSL communication only, but this article will not cover this issue as it is usually not necessary to encrypt OWA connections within the internal network.

Decision point – Which certificates to use?

The best way to approach the use of certificates for a publicly accessible web site is to acquire a certificate from a known Certificate Authority such as Verisign.
The advantage of such certificate is that the issuer (the company which owns the certificate authority who generated the certificate) is already trusted by Windows based computers. You can use Internet Explorer's Internet Options and Content tab to see the list of trusted certificate authorities. Another option is to open an mmc console and use the Certificates snap-in to view the list of Trusted Root Certificate Authorities.

If you cannot afford the purchase of a publicly signed certificate, you can issue your own certificates using a Windows 2000/2003 server, with the free Certificate Authority services within those network operating systems.

Note!
In some cases, such as when using the Exchange 2003 RPC over HTTP feature, you will be required to manually import the home-brewed CA certificate to the client computers in order for those computers to trust the unfamiliar Certificate Authority.

Create your own certificates

To issue your own certificate from a Windows 2003 server, use the following steps to install the required components.
Open Add/Remove programs, and select Add/Remove Windows components.
To make the process to issuing certificates easier, you should install both
the IIS server and the Certificate Services which include both the Certificate Authority installation and the Certificate Services Web Enrolment support.

During the installation process you will be asked to select which type of Certificate Authority you would like to install. If the sole reason you install the CA is to generate a web site certificate, select a "Stand-Alone root CA". In a larger environment when PKI infrastructure is deployed you should check if an Enterprise root CA is installed - which will be able to issue the certificates.

Continue the installation process; provide a common name for the CA. I suggest you enter the public domain that you are using. In the following case I used my own registered domain name: liran.org

Accept the installation defaults and finish the installation.
When done, you will notice that on the CA server, a CA certificate is placed in the %windir%\system32\certsrv\CertEnroll folder. You will need to import the CA certificate to the trusted root Certificate Authorities store on the ISA firewall later on.

Generating the web site certificate request

Log on to the Exchange 2003 server you intend to publish. Open the Internet Information Services (IIS) Manager tool from the Administrative Tools menu, and expand the web sites tree. Locate and click Properties on the Default Web Site, which holds the OWA virtual directories. Select to the Directory Security tab, and click Server Certificate…. In the Wizard select: Create a new certificate.

Select to Prepare the request now, but send it later, and click Next. Leave the certificate name as Default Web Site, and the Bit Length: 1024 and click Next. Type the name of your organization and an OU, and click Next. In the Common Name window, make sure to enter the exact FQDN that will be used by external users to access the OWA web site. If the following example I used owa.liran.org. You should register this record with your publicly available DNS service provider for your domain. This record should point to the ISA firewall external interface IP address.

Note!
For smaller companies, the external IP address of the ISA firewall may already be configured on your public DNS for your domain as the MX record with a name such as mail.liran.org . When creating the certificate, you may use this record as the certificate common name, and save some time on calling the DNS provider for additional DNS record registration, but I will advise against it as you might want to set up a mail gateway in the future which will use the mail.liran.org as the MX record, but will no longer point to the ISA External interface IP address. The is no problem having more then one DNS record pointing to a single IP address, so just add another host record such as owa.liran.org.

Continue running the certificate wizard, enter additional information in the Geographical Information page. In the Certificate Request File Name page make sure to note the location and file name of the certificate request file. The default location is c:\certreq.txt. Continue the process and click Finish.

Form a request to a certificate

To approve the certificate request, open a web browser on the Exchange server and enter the URL to the CA server. For example: http://CAServer/CertSrv (replace CAServer with the IP address or computer name of your CA server) On the Certificate Services Welcome screen, click Request a certificate. Select advanced certificate request, and click Submit a certificate request by using…. On the Submit a Certificate Request or Renewal Request page focus on the Saved Request window.
Open the request file generated earlier, (c:\certreq.txt), with notepad, and copy the content code between the Begin and End sections, and paste into the Saved Request window.

When done click Submit. Wait for the Certificate Pending, and close the web browser. Log on to the certificate server, open the Certification Authority console from the Administrative tools menu. Expand the CA, and navigate to the Pending Requests tree. On the right pane you will see the certificate request just waiting there to be approved. Right click the certificate and select All Tasks and then Issue. The issued certificate will be moved to the Issued Certificates container.

Go back to the Exchange server, and open the web browser. Again point to http://CAServer/CertSrv , and click View the status of a pending certificate request. Click the saved request certificate link, and select Download certificate using the DER Encoded. Save the file certnew.cer to the Exchange server desktop. Open the IIS console on the Exchange server, and again navigate to the Directory Security tab of the Default Web Site. Click Server Certificate… and use the wizard to process the pending request. Provide with the certnew.cer file, verify port 443 as the SSL port, click Next, Finish, and OK to close the properties page. Restart the Default web site.
At this point, the Default web site is SSL enabled, which means you can access it using either HTTP or HTTPS.
If you try to access the OWA web site using a web browser with https://, you might be prompted with an Alert such as the following one:

Note that the Alert contains three parts as explained:
a. Warning will appear if the CA that generated the certificate is not trusted.In case you generated the certificate yourself from a privately installed CA,
you will need to import the CA certificate to the computer Trusted root
certificate authorities store. This is NOT required process on every client
unless you find this message very annoying.
b. Warning will appear if the certificate dates are invalid. This could happen if the date scope of the certificate does not match
the date settings on the browsing computer, or if the certificate dates
themselves either will start in the future or already ended.
c. Warning will appear if contacting with a URL that is different for the certificate common name.
In the above example I used the server NetBIOS name instead of
https://owa.liran.org/exchange, which caused the alert to appear.
In order for ISA firewall to properly publish the secured web site, you must make sure that SSL connection to the OWA web site will not fail any of the above tests. This will be covered later on.

Importing the certificates to the ISA firewall.

The ISA firewall will require the web site certificate with its private key to make client-to-ISA SSL connections, and ISA-to-OWA SSL connections. You should export a copy of web site certificate for a later use.
To do so, return to the Directory Security tab of the default web site on the Exchange server, and click View Certificate. On the certificate window, select the details tab, and click Copy to file. In the wizard, select Yes, export the private key, select to enable strong protection, set a password, and select to save the certificate to a file named c:\owasitecert.pfx. Copy the file to the ISA firewall hard drive. As I explained at the last section on step 1, the ISA 2004 server must be able to perform SSL client connectivity to the Exchange secured OWA site without any warning messages.

Checking SSL connectivity between ISA 2004 and the OWA site

Make sure SSL connection can be made from the ISA firewall to the Exchange server. Open a CMD console, and enter the following line to test SSL connectivity: telnet ExchangeIP 443. (Replace ExchangeIP with the Exchange server internal network IP address).
If a connection could not be made, create a computer definition for the Exchange server in the ISA console, and then create an access rule to allow HTTPS from LOCALHOST to the Exchange server computer object. Check connectivity again using telnet. When the connection could be made, continue by importing the required certificates to the ISA firewall.

Importing the certificates

On the ISA firewall, click Start -> Run, type mmc and click OK. In the new console either click CRTL+M, or select Add/Remove Snap-in from the file menu. On the Standalone tab, click Add, and select Certificates. Select Computer Account, and click Next. Select Local Computer and click Finish. Click Close and OK.
In the console, expand Certificates (Local computer), and navigate to Trusted root Certificate Authorities -> Certificates. Try to locate the Certificate server certificate. It should be named as your external domain name if you used my suggestion earlier for naming the CA. (This is not required if using 3^rd party certificate) If you cannot find the certificate, you will need to import it. Copy the .crt file from the \system32\certsrv\CertEnroll folder of the Certificate authority server to the ISA firewall.
Back on the ISA firewall, right click the copied certificate, and select Install Certificate. Click Next, and select Place all certificates in the following store. Click Browse, enable Show physical stores, expand the Trusted root certificate authorities, and select Local Computer. Click OK, Next and Finish. You will be prompted with a security warning, click Yes, and OK to confirm the certificate installation.
To confirm the certificate installation, refresh the Trusted root Certificate Authorities certificate list and verify the certificate can be located.

Keep the certificate console open on the ISA firewall.
Next, you will need to import the Web site certificate to the ISA firewall.
Use the certificates console again.
In the Console tree, expand Certificates (Local Computer), and select the Personal container. Right click Personal and select All Tasks -> Import. Use the Browse to locate the owasitecert.pfx file you copied from the Exchange server earlier, provide the password, and place the imported certificate to the personal certificate store. When down, refresh the personal store and locate the imported web site certificate under Personal -> Certificates.
The certificate will be named based on the Common Name you selected for the published web site.

Close the Certificates console. You are not required to save it.

Checking Browser connectivity from ISA to the OWA site

Now we will check if the ISA firewall can connect to the OWA web site. As explained on the first section of the article, a few checks are made when connecting to a site with an SSL certificate.
We already covered the importing of the CA certificate to the ISA firewall, so the CA should already be trusted.
I assume that the web site certificate dates are valid as well as the date/time configuration on the ISA firewall clock, so we are only left with making sure that the URL used to connect to the OWA site is the one specified in the common name. This means that in our lab case, we should be able to resolve the URL owa.liran.org from the ISA firewall to the Exchange server internal IP address.
If the ISA firewall cannot resolve the common name (owa.liran.org) to the Exchange IP address using DNS, (test by performing a ping command), you should edit ISA firewall's hosts file (located in the %systemroot%\SYSTEM32\DRIVERS\etc folder) to include a name to IP translation of the common-name FQDN to the Exchange IP address. After updating the HOSTS file, try to ping the FQDN again, and verify that the ping request indeed tries to ping the Exchange IP address. Note that we are looking for a successful name resolution and not a successful ping as ping traffic might be blocked by the ISA firewall default rule.
Open a web browser on the ISA firewall, and enter the URL for test. The URL should be in the form of: https://common-name/exchange (You should replace the common name with the actual FQDN). If you are getting the Security Alert message, you should resolve the cause of the problem and try again. If you are unable to access the site at all, disable any web proxy settings in the browser LAN Settings and try again. Do NOT delete the added entry to the hosts file!
After resolving any problems you might have, you will be able to connect and logon to a mailbox on the Exchange OWA web site using basic authentication pop-up window. Form based authentication will be performed for remote clients by the ISA firewall.

Configure the ISA 2004 Listener and Publishing rule

In our example, the ISA firewall is configured with two network adapters. The first adapter connects to the LAN and the second adapter to the Internet. To publish the OWA web site, we will open the ISA management console, and navigate to the Firewall Policy on the left pane. On the right pane, expand the Task Pane. Click Publish a mail server on the Tasks tab. The Welcome to the new mail server publishing rule wizard will appear. Select your desired rule name and click Next. Select Web Client Access, and click Next. On the Select Services page, make sure that Outlook Web Access is selected and click Next.

On the Bridging Mode page select Secure Connection to client and mail server.
On the Specify the Web Mail Server page, type the FQDN of the published site (not the IP address, not the NetBIOS name and not the internal domain FQDN unless the full server name of the Exchange server in the internal Active Directory DNS matches the Common name FQDN, which is not likely).

On the Public Name Details page, enter the FQDN again, and click Next.
On the Select web Listener pane either edit an existing listener or create a new Listener in case no listener exists.

Configure the listener to listen on the External network segment. You can use the Address option to specify the specific external IP address to listen to in case you got multiple external IP addresses.

On the Port Specification page, enable SSL on port 443 and clear "Enable HTTP". Click Select to select the web site certificate that will be used for the client secure connection. If clicking Select results with no certificates, you should either close and reopen the ISA console (it might have been open when you imported the certificate), or re-check the certificate existence in the Personal certificate store of the Local Computer. Click Next and Finish to close the Listener configuration. Back in the Select Web Listener page, click Edit to edit the listener further more.

On the Preferences tab click Authentication.

Remove the Integrated selection, and select the OWA forms-Based instead. Click OK twice to confirm the Listener configuration and return to the Select Web Listener page. Click Next twice to make the rule apply to all users, and click Finish. Back in the ISA console, click Apply to activate the new rule.

Verify External connectivity.

The final step is to make sure that external clients can indeed access the OWA web site. Connect a computer to the Internet, and ping the web site common name. The name should be resolved to the ISA firewall external interface IP address that you specified on the listener. If the name could not be resolved by the public DNS service for your domain, verify that the record was registered with the ISP/DNS service provider. To temporarily overcome the record registration issue, update the client HOSTS file to provide the name-to-IP translation, where the common name translates to the ISA External IP address.
After name resolution is available, open a web browser and connect to the URL, for example: https://owa.liran.org/exchange

Note!
As the Web Publishing rule is configured to answer requests directed specifically to the FQDN in addition to the specific Exchange virtual directories, no other URL entered will allow you to access the OWA site.

Other requests will be answered with the error message: Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)
A successful connection attempt will probably provide with the following Security Alert, as the CA certificate is unknown to the external client.

Disregard this warning, by clicking Yes.
If your users are concerned with this message either install the CA certificate on each remote computer (which might not be possible in every Internet Café in Bangkok), or get yourself a web certificate from a trusted CA.

The users will now be instructed to provide logon information using the form based authentication page provided by the ISA firewall. The transport of the user credentials are encrypted by SSL 128bit encryption.

Voila! We are there. Enjoy your secure Outlook Web access solution.
If you find any faults in this article you are welcome to contact me at: liran.zamir@getronics.com

We hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Liran Zamir releases another article on ISAserver.org, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.

Read more »

Posted in: Active Directory,CA,Exchange,ISA

SBS 2008 Using the POP Connector

To access the Windows Small Business Server POP3 Connector properties

1. Open the Windows SBS Console.
   
2. On the navigation bar, click Network.
   
3. Click the Connectivity tab.
   The list view displays information about your network connections.
   
4. In the list view, click POP3 Connector.
   
5. In the Tasks pane, click View POP3 Connector properties.
   

To view error messages for the POP3 Connector

1. Click Start, type eventvwr, and then press ENTER.
   
2. In the console tree, expand Applications and Service Logs.
   
3. Expand Windows Small Business Server 2008, and then select Microsoft Windows Small Business Server/Operational.
   The details pane displays error and event messages for Windows SBS 2008 including error messages from the POP3 Connector.
   

Read more »

Posted in: Exchange

Fix Outlook 2007 Certificate Errors

For SBS 2008 run the following commands in Exchange Management Shell:

Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx

For Exchange 2007 Standard or Enterprise on Windows Server 2008 run the following commands in Exchange Management Shell:
Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (Default Web Site)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (Default Web Site)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (Default Web Site)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx
If you’re not sure which set of commands to use, type Get-WebServicesVirtualDirectory in Exchange Management Shell and see what is listed for name. You will either see EWS (SBS Web Applications) or EWS (Default Web Site). Match that up with the command set above and it should find the appropriate virtual directories.
On Windows Server 2008, if you see access denied errors then make sure you use Run As Administrator to run Exchange Management Shell.

Read more »

Posted in: Exchange,Outlook

Exchange 2007 Autodiscover Issues

We have recently begun installing a lot of Exchange 2007 servers, both Exchange 2007 standard and as part of SBS 2008. Starting with Exchange 2003 there is a lot of reliance on the web services part of the server which reside in IIS. In order to get things working properly we get a SSL certificate, usually from GoDaddy, to secure the exchange directories. This allows us to set up devices with Exchange Activesync, OWA without certificate warnings, and Outlook Anywhere.
We’ve noticed that when installing these certificates, Outlook clients on the domain begin to see a certificate error. This is because of the Autodiscover URLs that are part of Exchange server and the fact they no longer match the self-signed certificate that Exchange produces on installation.
In order to update those URLs you need to use Exchange Management Shell to run some commands. The commands are different for SBS installations and Standard installations. In the following commands, replace yourserver with the netbios name of your Exchange server and external.yourdomain.com with the external address of your server.
For SBS 2008 run the following commands in Exchange Management Shell:
Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx
For Exchange 2007 Standard or Enterprise on Windows Server 2008 run the following commands in Exchange Management Shell:
Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (Default Web Site)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (Default Web Site)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (Default Web Site)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx
If you’re not sure which set of commands to use, type Get-WebServicesVirtualDirectory in Exchange Management Shell and see what is listed for name. You will either see EWS (SBS Web Applications) or EWS (Default Web Site). Match that up with the command set above and it should find the appropriate virtual directories.
On Windows Server 2008, if you see access denied errors then make sure you use Run As Administrator to run Exchange Management Shell.
At this point, we have solved problems with Autodiscover that resulted in error messages in Outlook clients but have not actually set up Autodiscover. The Autodiscover setup process usually includes setting up a new site in IIS for autodiscover.yourdomain.com and adding the autodiscover virtual directory to it. You’ll also need a SSL cert for it which is why we don’t usually set it up. We have yet to see any advantages to setting up Autodiscover since our clients usually don’t have that many clients connected to their Exchange server.

Read more »

Posted in: Exchange

Changing SBS 2008 Exchange Mailbox Limits

In Windows SBS 2008, the mailbox database and the individual mailboxes have a size limit of 2 GB. If the size limit of the mailbox database or the individual mailboxes on the Source Server is more than 2 GB, you must manually change the size limits on the Destination Server

To change the size limit of the mailbox database

1. On the Destination Server, click Start, click All Programs, click Microsoft Exchange Server 2007, and then click Exchange Management Console.
   
2. Click Continue in the User Account Control dialog box.
   
3. In the Exchange Management Console navigation pane, expand the Server Configuration node, and then click Mailbox.
   
4. In the result pane, click the Destination Server name.
   
5. In the work pane, right-click Mailbox Database, and then click Properties.
   
6. Click the Limits tab, specify the mailbox database limits, and then click OK.
   

To change the size limit of the individual mailboxes

1. On the Destination Server, open the Windows SBS Console.
   
2. In the navigation bar, click the Users and Groups tab, and then click Users.
   
3. Click a user account, and then click Edit user account properties.
   
4. Click the E-Mail tab, update the maximum mailbox size information, and then click OK.
   
5. Repeat steps 3 and 4 until all user accounts are updated.
   

Read more »

Posted in: Exchange

Changing Exchange 2003 Message Size Limits

To change the default limits for sending and receiving message size

1. In Exchange System Manager, expand Global Settings. Right-click Message Delivery and then click Properties.
   
2. Select the Defaults tab.
   
3. Change the limits for Sending Message Size and Receiving Message Size.
   

To change the size limit of the individual mailboxes

1. On the Exchange Server, open Active Directory Users and Computers.
   
2. Select the user for which you would like to change message size limits, then right-click and click Properties.
   
3. Select the Exchange General tab.
   
4. Click on Delivery Restrictions.
   
5. Set the Sending Message Size and Receiving Message Size and click OK.
   

Read more »

Posted in: Exchange