AYUB KHAN

Lesson 3: Microsoft Exchange 2010, Pre-Requests & AD Preparation

2009-06-22T00:26:00.000-07:00

Lesson 3: Microsoft Exchange 2010, Pre-Requests & AD Preparation

In first lesson, we talk about an Exchange Overview, History, Licenses and Editions.

In second lesson, we talked about Exchange 2010 roles and system requirements.

From this lesson, we will start interact with Exchange 2010, we will start that by installing the Pre-Requests and & prepare Active Directory. You will start seeing the installation and configuration snapshot.

Windows Server 2008 Hyper-V technology will be use in our LAB, Our LAB will include the latest technology from Microsoft, our LAB will contain the following:

1-Windows Server 2008 SP2 as a Domain Controller.

2-Windows Server 2008 SP2 to install Exchange 2010 on it.

3-Windows 7 as a client join to the domain and Office 2007 installed in this Machine (we try to get a copy from office 2010 to use it in our LAB).

Microsoft Exchange 2010 Pre-Requests

To perform the following procedures to install Exchange 2010 Pre-Requests you have to make sure from the following:

1- The account you use must be membership in the local Administrators group in Exchange Server.

2- The full installation option of Windows Server 2008 must be used for all Exchange 2010 servers and management workstations. Exchange 2010 can’t be installing in Windows Server 2008 Core.

3- For all server roles other than the Edge Transport server role, you must first join the computer to the internal Active Directory domain.

There are two types of Exchange 2010 Pre-Requests, Windows components and Software Pre-Requests. Let’s see what each one include.

1- Windows Component Pre-Requests

· Active Directory Management Tools. This component used to allow preparing Active Directory Schema & Domain from server running Windows 2008.

· Install Internet Information Services (IIS) with the necessary services.

· Install Microsoft Windows Media Player Audio/Video codec’s which required for Unified Messaging server.

2- Software Pre-Requests

I. Microsoft .NET Framework 3.5

II. Extensions for ASP.NET AJAX 1.0

III. Windows PowerShell V2 CTP3

IV. Install Office 2007 System Converter: Microsoft Filter Pack

Let’s start install Exchange 2010 Pre-Requests:

Windows Component Pre-Requests

1. Install Active Directory Management Tools. From CMD, run “ServerManagerCmd -i RSAT-ADDS” as the following:

As we can see above, the command is succeeded and it’s requiring to restart the server. We will restart the server then we will do the next step.

1. Install the necessary Internet Information Services (IIS) prerequisites by running the following commands in the order in which they are listed:

· ServerManagerCmd -i Web-Server

· ServerManagerCmd -i Web-ISAPI-Ext

· ServerManagerCmd -i Web-Metabase

· ServerManagerCmd -i Web-Lgcy-Mgmt-Console

· ServerManagerCmd -i Web-Basic-Auth

· ServerManagerCmd -i Web-Digest-Auth

· ServerManagerCmd -i Web-Windows-Auth

· ServerManagerCmd -i Web-Dyn-Compression

· ServerManagerCmd -i NET-HTTP-Activation

· ServerManagerCmd -I RPC-over-HTTP-proxy

ServerManagerCmd -i Web-Server:

ServerManagerCmd -i Web-ISAPI-Ext:

ServerManagerCmd -i Web-Metabase:

ServerManagerCmd -i Web-Lgcy-Mgmt-Console:

ServerManagerCmd -i Web-Basic-Auth:

ServerManagerCmd -i Web-Digest-Auth:

ServerManagerCmd -i Web-Windows-Auth:

ServerManagerCmd -i Web-Dyn-Compression:

ServerManagerCmd -i NET-HTTP-Activation:

ServerManagerCmd -I RPC-over-HTTP-proxy:

3. You can Install Microsoft Windows Media Player audio/video running the following Command:

All IIS components installed now, let’s restart the server and continue after that.

Software Pre-Requests

Now we will start install Exchange 2010 software Pre-Requests. We mentioned above, there are 5 Software-requests as the following Picture:

1. Install Microsoft .Net Framework 3.5, in “Welcome to Setup” page, select “I have read and ACCEPT the terms of the License Agreement” then Click Install:

As you can see, .Net Framework starts downloads some components and then installs them. You need to keep your server connected to the Internet to do this task.

Installation done, click Exit:

2. Install Extensions for ASP.NET AJAX 1.0, in “Welcome to the Microsoft ASP.NET 2.0 AJAX Extensions 1.0 Setup Wizard” page, click next:

On “End-User License Agreement” page, select “I accept the terms in the license agreement” and then click next:

On “Ready to install Microsoft ASP.NET 2.0 AJAX Extensions 1.0” page, click on Install:

Installation is done, Click Finish:

3. Install Windows PowerShell V2 CTP3, Click on OK when the MSG appears:

Click on “I Accept” button to continue:

Installation Start:

Installtion finish, Click on “Restart Now” to restart the server after the installation of PowerShell V2 have been done:

4. Install Office 2007 System Converter: Filter Pack 1.0, on welcome page, click next:

On “End-User License Agreement” page, click on “I accept the terms in the license Agreement” then click next:

Installation finishes successfully, Click OK:

Now; do we can say; we did all Exchange 2010 Pre-Requests. The answer is YES, but it’s recommended to do another three steps which they are:

1- Check Windows Update and make sure it’s updated up to date and it’s appear like the following:

2- Run the Microsoft Baseline Security Analyzer (MBSA). MBSA a tool which designed to determine the security state according to Microsoft security recommendations and offers specific report. You can apply this tool locally and remotely.

After you download and install the tool, run it and then click on “Scan a Computer”:

In the following page, select to computer name and all scan options and then click on “Start Scan”:

MBSA start now downloading the security update form Microsoft, after this finish, the tool will start checking the server:

Scan is finish; MBSA provide you a report for you server settings. Review the report, check the errors and warning and see if you need to change them and check the recommendation. In the following a snapshot of MBSA report:

Prepare Active Directory and Domains

In the following we will explains how to prepare the Active Directory and domains for installing Exchange 2010. You must complete this procedure before you install Exchange 2010 on any servers in your organization.

Note: If you run the Exchange 2010 Setup wizard with an account that has the permissions required to prepare Active Directory and the domain, the wizard will automatically prepare Active Directory and the domain. But we will do it manually through command prompt.

Prepare Schema:

To install Exchange Server 2010, you need First Extend the Active Directory Schema; we will do this by using the "PrepareSchema" switch with "Setup" command from the command prompt. To use this command, you need to be a member of schema administrator and enterprise administrator groups. We will do that by the following steps:

1- You have to point the command prompt to the Exchange 2010 Folder as the following:

2- Run PrepareSchema command as the following:

3- After the Schema is extended, you can prepare the Active Directory of the organization by using "PrepareAD" Switch with Setup Command. Note that you need to specify the Organization name with the command as the following:

4- Now you need to prepare the Domain by using “PrepareDomain” switch. To run this command, you need to be a member of Domain Administrator Group:

In this lesson, we did all Exchange 2010 Pre-Request installation and Active Directory preparation. In next lesson, we will install Exchange 2010.

Regards,

AYUB KHAN

Lesson 2: Microsoft Exchange 2010, before deployment

2009-06-21T02:35:00.000-07:00

Lesson 2: Microsoft Exchange 2010, before deployment

In first lesson, we talk about an Exchange Overview, History, Licenses and Editions. You can check in the following link:

In lesson 2, we will talk about Exchange 2010 roles and system requirements. This lesson is important to deploy Exchange 2010 in the right way. Let’s start.
Exchange 2010 Roles

A server role is a unit that logically groups the features and components that are required to perform a specific function in the messaging environment.
Each server role includes features that support its function together with related configuration and security settings and a list of predefined tasks for managing and configuring those features.
Exchange 2010 provides five server roles, in the following a list of all roles and a brief of each one:

1- Client Access Server (CAS): Client Access server role supports OWA, ActiveSync POP3 and IMAP4 clients. The CAS role also supports services, such as the Autodiscover service and Web services.

2- Hub Transport Server: Hub Transport server role handles all mail flow inside and outside the organization, applies transport rules, applies journaling policies, and delivers messages to a recipient's mailbox. If you don’t have Edge Transport server, you can install and configure the Edge Transport server agents on the Hub Transport server to provide anti-spam and antivirus protection inside the organization.

3- Mailbox Server: The Mailbox server role hosts mailbox and public folder databases. It also generates the offline address book (OAB). Mailbox servers provide services that calculate e-mail address policies and address lists for recipients, and enforce managed folders.

4- Edge Transport server: Exchange 2010, the Edge Transport server role is deployed in your organization's perimeter network. Designed to minimize the attack surface, the Edge Transport server handles all Internet-facing mail flow, which provides Simple Mail Transfer Protocol (SMTP) relay and smart host services for the Exchange organization.

5- Unified Messaging (UM): Unified Messaging combines voice messaging and e-mail into one Inbox, which can be accessed from the telephone and the computer.

Exchange Role Notes:
1- You should have CAS, HUB and Mailbox at least in your Exchange Environment.
2- Edge server should be installing in DMZ as a workgroup.
3- All roles except Edge can be installed in one server.
4- Edge Transport role always installed alone, you can’t add any role with edge in the same server.
5- Combined or separated of roles could be happen, it’s always depending in your requirements.

System Requirements

Before you start install Microsoft Exchange 2010, you should make sure that you review all of Exchange 2010 system requirements such as network, hardware, software, clients. In the following, we are going to list all requirements of Exchange 2010:

1- Operating System: You can install Exchange 2010 in a 64-bit edition of Windows Server 2008 Standard or Enterprise with SP2.

2- Domain & Forest Functional Level: Exchange 2010 requires Domain and Forest (both) Functional Levels to be at least Windows 2003. In another worlds; all domain controller in your environment they should be installed at least by windows 2003.

3- Global Catalog: You should implement a Global Catalog Server in each site that you need to install Exchange 2010 on it.

4- Hardware: To run Microsoft Exchange Server 2010 Enterprise Edition Beta on x64 platforms, you need:
· x64 architecture-based computer
· Minimum of 4 GB of RAM.
· At least 1.2 GB on the drive used for installation and additional 500 MB for each Unified Messaging (UM) and language pack that you plan to install plus 200 MB of available disk space on the system drive
· Drive―DVD-ROM drive.
· Disk partitions formatted as NTFS file system

Note: It’s recommended to install Exchange 2010 in member server. Installing Exchange 2010 in a domain controller is not recommended. Changing the server role to be a Domain controller or vice-versa after installing exchange 2010 is not supported.

Second lesson is done, in the next lesson; we will start installing Exchange Prerequisites and preparing the active directory to install Exchange 2010.

Regards,
AYUB KHAN

Lesson 1: Microsoft Exchange 2010, Start from here

2009-06-21T02:19:00.000-07:00

Lesson 1: Microsoft Exchange 2010, Start from here

As we promise you; this is the first lesson of Exchange 2010 learning series. We will post a new lesson every week. In this lesson, we will talk briefly about Exchange 2010 Overview, History, Licenses and Editions. It’s important to know that information before you start implementing Microsoft Exchange 2010 in your network.

Overview

Microsoft Exchange Server is a messaging and collaborative software product developed by Microsoft. It is part of the Microsoft Servers line of server products and is widely used by enterprises using Microsoft infrastructure solutions. Exchange's major features consist of electronic mail, calendaring, contacts and tasks; support for mobile and web-based access to information; and support for data storage.

History

The history of Microsoft Exchange is quite interesting and began in 1993 when the XENIX mail system was changed to the Exchange Server. In January 1995; around 500 users were migrated and start using the Exchange Server Beta 1. By April 1996; 32,000 users were migrated to the environment

In the following a list of all Exchange history versions:
· Exchange Server 4.0 released on June 1996, it's the original version of Exchange Server sold to the public.

· Exchange Server 5.0 released On May 1997, it's introduced the new Exchange Administrator console, as well as opening up integrated access to SMTP-based networks for the first time.

· Exchange Server 5.5 released On November 1997, it sold in two editions, Standard and Enterprise. They differ in database store size, mail transport connectors and clustering capabilities.

· Exchange Server 2000 (v6.0) released on November 2000, unlike Exchange Server 5.5, Exchange Server 2000 had no inbuilt Directory Service, and had a dependency upon Active Directory.

· Exchange Server 2003 (v6.5) released on September 2003, this version has enhanced disaster recovery, Outlook Mobile Access and server-side ActiveSync functionalities added, Better anti-virus and anti-spam protection have also been added, improved message and mailbox management tools.

· Exchange Server 2007 (v8 or with SP1 v8.1) released on November 2006 to business customers as part of Microsoft's roll-out wave of new products. It includes new clustering options, 64-bit support for greater scalability, voice mail integration, better search and support for Web services, better filtering options, and a new Outlook Web Access interface.

· Exchange Server 2010 version will be available from the second half of 2009. A 360 day beta is now downloadable from TechNet.

Licenses

Exchange Server requires Client Access Licenses (CAL), which are different from Windows CALs. Corporate license agreements, such as the Enterprise Agreement (EA), include Exchange Server CALs. It also comes as part of the Core CAL.

Just like Windows Server and other server products from Microsoft, you can choose to use User or Device CALs. Device CALs are assigned to a device (workstation, laptop or PDA). User CALs are assigned to a user or employee (not a mailbox).

User CALs allow a user to access Exchange e-mail from any device. User and Device CALs are the same price, however cannot be used interchangeably.

Two types of Exchange CAL are available: Exchange CAL Standard and Exchange CAL Enterprise. The Enterprise CAL is an add-on license to the Standard CAL.

Editions

Exchange 2010 comes in two editions (Standard & Enterprise); these are licensing editions that are defined by a product key. When you enter a valid license product key, the supported edition for the server is established.

Product keys can be used for the same edition key swaps and upgrades only, and they cannot be used for downgrades. You can use a valid product key to go from the evaluation version (Trial Edition) to either Standard Edition or Enterprise Edition. You can also use a valid product key to go from Standard Edition to Enterprise Edition.

The next lesson will cover Exchange 2010 Roles and System requirements to implement the product. We will not keep you waiting for a week for this lesson; we will post it at next Monday. We will do that because; next week we will start implementing Exchange 2010.

Regards,
AYUB KHAN

2009-05-19T01:35:00.000-07:00

Step By Step Guide for Installing Exchange Server 2010 On Windows server 2008

Install the Windows Vista operating system prerequisites for Exchange Management Tools

To install the Windows Server 2008 operating system prerequisites for Client Access servers

1. Install the Active Directory remote management tools by running the following command:
Copy Code
ServerManagerCmd -i RSAT-ADDS
2. Install Microsoft .NET Framework 3.5.
3. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
4. Install Windows PowerShell V2 CTP3.
5. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
6. Install the extensions for ASP.NET AJAX 1.0.
7. Install the necessary Internet Information Services (IIS) prerequisites by running the following commands in the order in which they are listed:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-ISAPI-Ext
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Digest-Auth
ServerManagerCmd -i Web-Windows-Auth
ServerManagerCmd -i Web-Dyn-Compression
ServerManagerCmd -i NET-HTTP-Activation
ServerManagerCmd -I RPC-over-HTTP-proxy

To install the Windows Server 2008 operating system prerequisites for Edge Transport servers

To install the Windows Server 2008 operating system prerequisites for Hub Transport servers

1. Install Microsoft .NET Framework 3.5.
2. Install the Active Directory remote management tools by running the following command:
Copy Code
ServerManagerCmd -i RSAT-ADDS
3. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
4. Install Windows PowerShell V2 CTP3.
5. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
6. Install the extensions for ASP.NET AJAX 1.0.
7. Install the necessary Internet Information Services (IIS) prerequisites:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth

To install the Windows Server 2008 operating system prerequisites for Mailbox servers

1. Install Microsoft .NET Framework 3.5..
2. Install the Active Directory management tools by running the following command:
Copy Code
ServerManagerCmd -i RSAT-ADDS
3. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
4. Install Windows PowerShell V2 CTP3.
5. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
6. Install the extensions for ASP.NET AJAX 1.0.
7. Install the 2007 Office System Converter: Microsoft Filter Pack.
8. Install the necessary IIS prerequisites by running the following commands in the order in which they are listed:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth
9. If the Mailbox server will be clustered, you must also install the Failover Clustering feature by running the following command:
Copy Code
ServerManagerCmd -i Failover-Clustering

To install the Windows Server 2008 operating system prerequisites for Unified Messaging servers

1. Install Microsoft .NET Framework 3.5.
2. Install Windows Remote Management ( WinRM ) 2.0 Community Technology Preview 3 (CTP3).
3. Install Windows PowerShell V2 CTP3.
4. Install the update for the Microsoft Management Console (MMC) in Windows Server 2008. See Microsoft Knowledge Base article 951725 An update that extends the mechanism for displaying snap-in context Help topics is available for the MMC in Windows Server 2008.
5. Install the extensions for ASP.NET AJAX 1.0.
6. Install the necessary IIS prerequisites by running the following commands in the order in which they are listed:
Copy Code
ServerManagerCmd -i Web-Server
ServerManagerCmd -i Web-Metabase
ServerManagerCmd -i Web-Lgcy-Mgmt-Console
ServerManagerCmd -i Web-Basic-Auth
ServerManagerCmd -i Web-Windows-Auth
7. Install the Microsoft Windows Media Player audio/video codecs required by the Unified Messaging server by running the following command:
Copy Code
ServerManagerCmd -i Desktop-Experience

To install the latest optional Windows Updates

1. Install multiple Right Management Services (RMS) Client sessions update. See Knowledge Base article 950888 You cannot create multiple RMS Client sessions for one user context on a Windows Vista-based computer.
2. Install performance counter updates. See Knowledge Base article 951116 A memory leak occurs in performance counters that are used to monitor Windows Server 2008-based computers.
3. Install the System Center Operations Manager 2007 console update. See Knowledge Base article 951327 The System Center Operations Manager 2007 console may crash in Windows Server 2008 or in Windows Vista when you open the Health Explorer window.
4. Install the Event Log service update. See Knowledge Base article 952664 The Event Log service may stop responding because of a deadlock on a Windows Server 2008-based computer.
5. Install performance counter values update. See Knowledge Base article 953290 An application may crash when it uses legacy methods to query performance counter values in Windows Vista or in Windows Server 2008.
6. Install Windows PowerShell V2 CTP3.

Installation Steps For Exchange Server 2010

• Insert The DVD of Microsoft Exchange Server 2010 & Click Install Microsft Exchange.

• Click Install Microsoft Exchange Server 2010 & click Next

• Click Next

• In the Language Page, click Next

• Click I accept click to proceed

• Click Next In Error Reporting Page.

• Click Custome Exchange Server Installation Select the Roles you Needed.

• Click next after Entering the Exchange Organization group.

• Click Next.

• Click Next in the page of Readiness Checks.

• Click Install .

• Click Next.

• Click Finish.

Managing Receive Connectors (Part 4)

2009-05-17T23:50:00.000-07:00

Managing Receive Connectors (Part 4)

In this concluding article we will configure more permissions at the Receive Connector level and we will also configure TLS authentication in a receive connector.

In the last article we saw how to manage permissions using the Exchange Management Shell and AdsiEdit.msc. In this article we are going to personalize receive connector permissions in a different way without using the default Permissions groups.

Exchange Server 2007 has a set of predefined Permissions Groups which makes it easier to administer using a single checkbox to define the required permissions. When we have more than one server it might be painful since some organizations need a more restrictive receive connector which can be reached using the procedure outlined in this article. If you do not really need such feature it is strongly recommended to stick with the default Permissions Groups available through the Exchange Management Console or Exchange Management Shell.

Let’s say that we just want an AD Group called Grp_Relay to be allowed to relay in Exchange Server 2007. In order to do that we have to go further than the Receive Connector permission configurations to assign different users than the default list.

Note:
If you use more than one HUB Transport in an NLB scenario for this receive connector, all changes must be made in all NLB nodes to provide the same mode of authentication and permissions.

First of all, we should remove all known groups of the Receive Connector Permissions tab in the Exchange Management Console. To do that we can get the properties of the Internal Relay connector and make sure that there is no group checked on the Permissions tab.

Now, let’s go back to AdsiEdit.msc and right-click on our Internal Relay connector and click on Properties. Click on the Security tab, and add the Grp_Relay group from Active Directory. Make sure that the group has at least the following permissions
(Figure 01):

Submit Messages to Server
Submit Messages to any Recipient
Bypass Anti-Spam
Accept routing Headers

Figure 01

Now, only users that belong to the Grp_Relay group will be able to send messages using the Internal Relay Receive Connector. If any user outside of that group tries to send a message, they will be asked for credential several times; you can validate the error in the Receive Connectors log file. The error will contain the following information:

Inbound authentication failed because the client DOMAIN\username doesn’t have submit permission.

If you have a situation where some servers must relay on Exchange Server without using authentication, you can use the same procedure above to grant permission to Anonymous entry on the Receive Connector Security tab.

Note:
It is not best practice to allow anonymous permission to relay in an Exchange Server box. Make sure that only a set of servers can use this connector using the RemoteIPRanges configuration of the receive connector.

Configuring TLS on a Receive Connector

Okay, now that we have seen how to properly configure the authentication methods and groups in a Receive Connector, we are going to enable TLS in our Receive Connector. First of all, let’s go to the properties of the Internal Relay Receive Connector and then click on the Authentication tab and check the option TLS, as shown in Figure 02.

Figure 02

Now let’s try to connect to this receive connector which has the FQDN defined as relay.apatricio.local (Apatricio.local is my AD FQDN name). Let’s just use the first SMTP verb, EHLO example.org and we can see that the STARTTLS is not being presented which means that even with TLS enabled on the Receive Connector we are not able to use it right now. (Figure 03)

Figure 03

After that connection we can go to the Event Viewer of our Exchange Server and the EventID 12014 (Figure 04) will be there, and the error message gives us a clue about what is happening with our current environment. The simple answer is that there is not a Certificate with the name configured in the FQDN of that Receive Connector.

Figure 04

So, let’s fix it. I will assume that we are using an internal PKI and in order to request a new SMTP certificate using the Exchange Management Shell use the following cmdlet:

New-ExchangeCertificate –GenerateRequest –Path c:\cert.req –SubjectName “cn=relay.apatricio.local” –FriendlyName “Internal Relay Certificate” –PrivateKeyExportable:$True

Now, let’s request the certificate created using the Certification Authority webpage:

1.Logged on Exchange Server open the http:///certsrv, where is your server which hosts the Certification Authority.
2.Click on Request a Certificate link.
3.Click on advanced certificate request.
4.Click on the second link which is Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file.
5.Open the file C:\cert.req which was created by New-ExchangeCertificate cmdlet and copy the content.
6.Paste the content of that file into the Base-64-encoded certificate request field in the webpage.
7.On the same page, select Web Server in the Certificate Template field and then click the Submit button.
8.On the new page, click on the Download Certificate link and save it in the C:\ root of the Exchange Server.
Let’s import the new certificate, to do that use this cmdlet:

Import-ExchangeCertificate –Path:C:\certnew.cer

Note:
The file name and path is just an example, you have to use the file name and path that you have used in the previous step.

Time to enable the new imported certificate to be used by the SMTP service using the Exchange Management Shell. To enable it we just need to copy the Thumbprint that was shown when we imported the request in the previous step and use this cmdlet:

Enable-ExchangeCertificate –Thumbprint -Services SMTP

You will be prompted to change the default SMTP certificate, just type in N and hit enter.

Let’s test our changes, we will be connecting again in the Internal Relay Receive Connector and we are going to type in the first SMTP verb, ehlo example.org. Did you notice any change? You should, now we have the STARTTLS being offered by Exchange Server. We can also go back to the Exchange Server Event Viewer and we will not see any Transport error like we saw before.

Figure 05

Let’s go back to our Outlook Express to confirm the solution. In the Outlook Express account properties, we have to use an FQDN name in the Outgoing mail (SMTP) field, and this name must be resolved by the client and it also must be same used by the certificate deployed recently (Figure 06).

Figure 06

The second step that must be done is on the Advanced tab where the option This server requires a secure connection (SSL) must be checked, as shown in Figure 07.

Figure 07

Now, let’s send a message using our Outlook Express. We do not need to receive on the Outlook Express client because we did not set up the proper POP3 server, only the SMTP. If the message disappears from the Outbox folder it is a good sign, but let’s validate the log files and we will see that the last message was sent using TLS, as shown in Figure 08.

Figure 08

Conclusion
In this article we have seen how to avoid Event ID 12014 when we configure a new FQDN in a Receive Connector, how to configure a specific group to relay in a specific Receive Connector, and how to configure a certificate and validate the log files to make sure that the configuration is working properly

Managing Receive Connectors (Part 3)

2009-05-17T23:16:00.000-07:00

Configuring Receive Connector Logging Settings

We can configure logging per receive connector. In order to enable log filing in a receive connector we should make sure where the log files will be generated. To configure where the log files will be kept before enabling the logging feature at the connector level:
Open the Exchange Management Console.
Expand Server Configuration.
Click on Hub Transport.
Select an available hub transport on the right hand side, and click on Properties.
Click on the Log Settings tab. In the Protocol Log section we can change the path where either Receive Connectors or Send Connectors will be stored by clicking on Browse button. (Figure 01)<>

Now, that we already know where the log files are stored, we can get the properties of any Receive Connector and we have an option called Protocol logging level which by default is defined as None and we are going to change to Verbose (Figure 02). Use Verbose mode only during a troubleshooting scenario, otherwise keep it configured as None

Now, we can send a test message using the SMTP verbs that we saw previously in this series and we will be able to track all communication in the log file, as shown in Figure 03

Configuring Authentication and Permission...
What we have been working on so far is on how to create the receive connector, how to manage some security features and also how to change the listening IPs to make each connector unique. Now we will go over the Authentication methods and Permissions available that can be associated with a Receive Connector.
Receive Connectors use 7 (seven) different types of authentication, which are: No authentication, TLS, Integrated, Basic Authentication, Basic Authentication over TLS, Exchange Server Authentication (Gssapi and Mutual Gssapi) and External Authoritative. These authentication methods are offered to the clients during the SMTP session and after authentication is made the permissions are applied. In order to configure the authentication method that a specific Receive Connector will use, follow these steps:
Open the Exchange Management Console.
Expand Server Configuration.
Click on Hub Transport.
Click on a Receive Connector and click on Properties.
Click the Authentication tab (Figure 04).

Figure 04
We are able to see the authentication method used by a receive connector through a simple telnet session. All available authentication methods are shown after the SMTP verb ehlo. The following table shows the difference on the SMTP answer for each authentication method:
Authentication Method
Response of EHLO
Transport Layer Security (TLS)
250-STARTTLS
Basic Authentication
250-Auth Login
Integrated Windows Authentication
250-Auth NTLM
Externally Secured
250-Auth250 XEXCH50
Okay, we have just seen how to configure the authentication methods that can be applied in a Receive Connector, now we are going to configure an internal relay server, it might be useful where some users/printers/servers must send message using an internal relay server. We are going to create an internal relay connector from scratch and then we will be changing some configurations to demonstrate how we can play with receive connector authentication and permissions to fit your needs.
Let’s create an Internal Receive Connector. This connector will accept a connection on port 25, however the connections will be made only from a set of machines (172.16.171.1 to 172.16.171.20 in this example). We are also going to specify a different FQND; for this internal receive connector we will be using relay.apatricio.local, the following cmdlet can be used to create the connector:
New-ReceiveConnector –Usage:Client –Bindings:0.0.0.0:25 –RemoteIPRanges:172.16.171.1-172.16.171.20 –FQDN:relay.apatricio.local –Server srv-ex01 –ProtocolLoggingLevel:Verbose –Name:”Internal Relay”
Now, that we have just created the Receive Connector, we can go to any machine that belongs to the defined remote IP range and we will receive a prompt of our new receive connector. We can verify the FQND information displayed in the first line (Figure 05).

Figure 05
Okay, now let’s open the Event Viewer in our Exchange Server, and we will see an error number 12014 and MSExchangeTransport Source. This error occurred because we do not have a certificate for the relay.apatricio.local FQDN, yet. We can avoid that message error for now by configuring the internal Receive connector to use Basic Authentication and Integrated Windows Authentication, as shown in Figure 06. We are going to play with TLS and certificates for this connection in the next article.

Figure 06
In the Permission Groups tab, we have 5 different permissions groups which we can associate to a receive connector. These predefined permissions groups are a set of objects that might include users, computers and security groups and they define permissions to well-know SID (Security Identifier), for example (Exchange Users group permission is the Authenticated Users Group in the AD). Using these permissions groups is the recommended solution for the majority of the companies, however we cannot change these permission groups using the Exchange Management Console.
In the Permissions Groups tab, we are going to validate who is allowed to connect to our Receive Connector. In a Client Connector only “Exchange Users” are allowed by default. (Figure 07)

Figure 07
Since we have the proper Authentication method and a permission associated with Exchange Users we are able to test it. To test we can use Outlook Express to create a dummy account using a fake POP3 Server account just to test the SMTP protocol. Make sure that the reply address used in the Outlook Express account belongs to the current list of Accepted Domains in your Exchange organization and also that you are using the proper username and password, and finally configure the account to use authentication using the option “My Server requires authentication”.

Figure 08
Now you can send a message to any e-mail address and the message will be sent. How do we make sure that authentication is working? Easy! During the receive connector creation we configured the logging level to Verbose. Now you understood why I said easy, right? Just look at the log files generated and we will see the authentication process, as shown in Figure 09.

Figure 09
The default configuration works in most scenarios, however sometimes a special set of permissions is required in order to configure a Receive Connector to fit in with company requirements. We are able to configure Receive Connector permissions in two different ways: using the Exchange Management Shell or AdsiEdit.msc.
The first method is using the Exchange Management Shell. To view the current permission of a Receive Connector run this cmdlet:
Get-ReceiveConnector Get-ADPermission
To manage the permissions use Add-ADPermission to add entries in that list and Remove-ADPermissions to remove entries as well.
The second method to set Receive Connector permissions is by using AdsiEdit.msc (by default it comes with Windows Support Tools, the process to install it can be found at Adsiedit Overview).
Using ADSIEdit.msc we can play around with Receive Connector permission:
Open AdsiEdit.msc.
Expand Configuration.
Expand CN=Services.
Expand CN=Microsoft Exchange.
Expand CN=.
Expand CN=Exchange Administrative Group (FYDIBOHF23SPDLT).
Expand CN=.
Expand CN=Protocols.
Expand CN=SMTP Receive Connectors.
On the right hand side, we will see all the Receive Connector of that specific Server (Figure 10).

Figure 10
Right click on a Receive Connector and click on Properties.
Click on the Security tab, and in the list we will see all the Security Identifiers of each permission Group that was associated with the receive connector and all permissions granted as well.
Now we are able to manage the permissions easily using Adsiedit.msc instead of the Exchange Management Shell that requires a little more effort.
Conclusion
In this article we saw how to configure the log settings in a Receive Connector and also how to configure permissions using AdsiEdit and the Exchange Management Shell.

Migration from Exchange 2000/2003 to Exchange Server 2007 (Part 3)

2009-05-17T04:46:00.000-07:00

How to replicate Public Folders, move Mailboxes as well as decommission the Exchange 2003 Server.

Replicating Public Folders
When deploying an Exchange 2007 Server with the Mailbox Server role installed into a legacy Exchange organization, Exchange Setup will create one Mailbox database and one Public Folder database on the respective server by default as can be seen in Figure 3.1 below.

Figure 3.1: Exchange 2007 Mailbox and Public Folder Database
The Public Folder database is created so that you can replicate any Public Folder data stored on your legacy Exchange servers to Exchange 2007. Even though you don’t use Public Folders to store data in your environment, there’s one other reason why you might want to keep the Public Folder database mounted on your Exchange 2007 Server. As some of you may already know, Exchange 2007 no longer uses a Public Folder (or more specifically a System Folder named SCHEDULE+ FREE BUSY in your Public Folder hierarchy) to store free/busy information for the mailbox users in the organization. Instead free/busy information is stored directly in each user’s mailbox, and retrieved using a new web-based service called the Availability service. The advantage of this new approach is that there no longer are any 15 minute delays when free/busy time for a user is updated. Instead the update will happen instantly. So why would I want to keep the Public Folder database on my Exchange 2007 server, if free/busy information is retrieved using this new method? Well if you still have legacy Outlook clients (that is Outlook 2003 and earlier versions) running in your organization, these clients still need to use Public Folder method to retrieve free/busy information, since only Outlook 2007 supports the new Availability service. If you don’t use Public Folders to store data and only have Outlook 2007 clients deployed in your organization, you can safely remove the Public Folder database, as you don’t have anything to use it for in that case. This also means you can skip the following steps.
Okay let’s get going with setting up a replica for the Public Folders on our Exchange 2003 Server that should be replicated with the new Exchange 2007 Public Folder database. In order to do so we must use either the Exchange 2003 System Manager or the Exchange Management Shell (EMS). For the purpose of this example we’ll use the Exchange 2003 System Manager.
NoteManaging Public Folders using the Exchange Management Console (EMC) is not possible in Exchange 2007 RTM, but will be integrated with Exchange 2007 Service Pack 1.
To add the Exchange 2007 Public Folder database to the replica list on the Exchange 2003 Server, open the Exchange 2003 System Manager, then expand Administrative Groups > First Administrative Group > Folders > Public Folders as shown in Figure 3.2
Figure 3.2: Public Folders in the Exchange 2003 System Manager

Now open the property page of each public folder, then click the Replication tab and add the Exchange 2007 to the replica list as shown in Figure 3.3.

Figure 3.3: Public Folder Replication Tab

NoteExchange 2003 Service Pack 2 introduced a new Public Folder Settings Wizard which makes it a breeze to add servers to replica lists. So if you have a lot of Public Folders in your Public Folder tree, I highly recommend you use this wizard, which you can read more about in a previous article of mine. If you have thousands of Public Folders, you might want to use the Public Folder replica scripts located in the Exchange Scripts folder (which can be found under C:\Program Files\Microsoft\Exchange Server).
Even though you still have legacy Outlook clients (Outlook 2003 and earlier) in your organization, you don’t need to set up a replica for the SCHEDULE+ FREE BUSY or the OFFLINE ADDRESS BOOK system folder. This will be done automatically when deploying an Exchange 2007 Server in a legacy Exchange organization.
When all Public Folders have been replicated to the Exchange 2007 Server, you should remove the old Exchange 2000 or 2003 Server(s) from the replica lists. When any Public folder data has been removed from the respective Public folder instances, you can dismount the old Public Folder stores (E2k3 SP2 won’t let you remove the Public Folder store until the data is gone and it won’t get removed while it’s dismounted). You should verify that your clients are still capable of seeing Public Folder data as well as free/busy information and accessing the offline address book before you delete it though. If this is not the case, I recommend you wait a little longer so that you’re sure the replication has occurred properly.Important:Outlook Web Access (OWA) 2007 doesn’t include a GUI for accessing Public Folders, so in order to access Public Folders using Internet Explorer you must open a separate browser window and type https://FQDN/public. It’s important you’re aware of this missing feature!

Pointing Internet Clients to the Client Access Server
Now would be a good time to point any Internet clients that are OWA, EAS and RPC over HTTP (now called Outlook AnyWhere) in your organization to the Client Access Server running on the Exchange 2007 Server. If you’re using a firewall such as ISA server (which you do, right?), this change is done at your ISA Server firewall. If you for some reason don’t use an ISA Server in your DMZ, but perhaps a Check Point Firewall 1 or a wannabe firewall such as a Cisco PIX, you should do the redirection there. If you don’t have a firewall you should make the change on the external DNS server hosting your Internet domain.
Note:If your ISA Server is configured to pre-authenticate your OWA users, you must change the Authentication method for the OWA virtual directory under Server Configuration > Client Access in the EMC to basic authentication, since it’s configured to use forms-based authentication by default.
So will any users with a mailbox on my Exchange 2000 or 2003 Server still be able to use OWA, Exchange ActiveSync or Outlook AnyWhere (formerly known as RPC over HTTP) to access their mailbox? Yes this will work just fine since the Client Access Server is backward compatible and will redirect the clients to the respective legacy mailboxes on the Exchange 2000 or 2003 server.
Note:When you perform the above changes, your users will no longer be able to access their mailbox using Outlook Mobile Access (OMA), as OMA has been discontinued in Exchange 2007.

Moving Legacy Mailboxes to Exchange 2007
Alright we have reached the part where we’re going to move our legacy mailboxes from Exchange 2000 or 2003 Server to Exchange 2007. Doing so is a straightforward process and can be done using either the Move Mailbox wizard in the Exchange Management Console (EMC) or the Move-Mailbox cmdlet in the Exchange Management Shell (EMS). For the purpose of this article series we’ll use the EMC. So if it’s not already open, launch the EMC, then expand the Recipient Configuration work center and click the Mailbox sub-node. Now highlight all the legacy mailboxes as shown in Figure 3.4, and then click the Move Mailbox task in the Action Pane.

Figure 3.4: Selecting Legacy Mailboxes in the Exchange Management Console

This will launch the Exchange 2007 Move Mailbox wizard, where you need to specify the destination server, storage group and mailbox database. Select the Exchange 2007 Server in the drop down box (Figure 3.5), and then click Next.

Figure 3.5: Specifying the Exchange 2007 Server as the Destination Server

Now specify how you want to manage any corrupted messages found in a mailbox (Figure 3.6), then click Next.

Figure 3.6: Specifying how corrupted messages in mailboxes should be managed

On the Move Schedule screen shown in Figure 3.7, select Immediately (unless you want the mailboxes to be moved automatically at a later time) and click Next.

Figure 3.7: Move Mailbox Scheduling Options

Finally click Move in order to start moving the legacy mailboxes to the Exchange 2007 Server (Figure 3.8).

Figure 3.8: Move Mailboxes Summary Page

As is the case with the Move Mailbox wizard in Exchange 2003, the Exchange 2007 Move Mailbox wizard can move 4 mailboxes at a time, and only one instance of the wizard can run on a server.
When all the mailboxes have been moved to the Exchange 2007 Server click Finish in order to exit the Move Mailbox wizard, and then check that mail flow to/from the Internet to the mailboxes on the Exchange 2007 works as expected.
If you will be running in a co-existence environment for a period of time, it’s important to understand that mailboxes stored on an Exchange 2007 server must not be managed using the Active Directory Users and Computers (ADUC) MMC snap-in, but instead must be managed using the Exchange Management Console (EMC) or the Exchange Management Shell (EMS). However Exchange 2003 mailboxes can still be managed using ADUC.
Note:If you want to move the Mailboxes using the Exchange Management Shell (EMS), you do so using the Move-Mailbox cmdlet. Using the Move-Mailbox cmdlet gives you a set of advanced options, among which the most interesting one is the option of specifying the number of mailboxes to be moved at a time (as you read earlier the Move Mailbox wizard is limited to 4).

Redirecting Inbound Mail to the Exchange 2007 Server
When all legacy mailboxes have been moved to the Exchange 2007 Server, we can point SMTP traffic (port 25/TCP) directly to the Exchange 2007 Server, so that inbound messages are routed directly to this server. It’s recommended to deploy an Edge Transport Server in your perimeter network (aka DMZ), and let this server route inbound messages to the Exchange 2007 server on your internal network. Instructions on how to deploy an Edge Transport server is outside the scope of this article series, but I’ll cover that topic in another article in the near future. If you don’t want to deploy an Edge Transport server, you should bear in mind that you need to change the Permission Groups settings on the Default receive connector under the Server Configuration work center node> Hub Transport sub-node in the EMC so Anonymous users are allowed to connect to the Exchange 2007 Server as shown in Figure 3.9, otherwise you won’t be able to receive e-mail messages from other SMTP servers on the Internet.

Figure 3.9: Permission Groups Settings on the Default Receive Connector

In addition you should make sure that any Send Connectors under Organization Configuration > Hub Transport > Send Connector tab are configured so that they can send outbound mail (either using a smart host or DNS MX) properly (Figure 3.10).

Figure 3.10: Send Connector Settings

When the necessary changes have been made, we can delete the routing group connector which was set up to establish mail flow between the Exchange 2003 and 2007 Routing Groups. In order to do so you should expand Administrative Groups > First Administrative Group > Routing Groups > Connectors and right-click on the respective Routing Group Connector then select Delete in the context menu as shown in Figure 3.11.Note:Officialy the correct way of deleting the routing group connectors is to use the Remove-RoutingGroupConnector cmdlet, but since Exchange 2003 version blocking doesn’t block deletes, you can also use the Exchange 2003 System Manager as well.

Figure 3.11: Deleting the Routing Groups Connector

Since the Routing Group connector won’t be deleted in both ends, you also need to delete it under the Exchange Administrative Group (FYDIBOHF23SPDLT) > Exchange Routing Group (DWBGZMFD01QNBJR) > Connectors.

Decommissioning Exchange Legacy Servers
The final step is to decommission the Exchange 2000 or 2003 Server and we can consider the transition done. The Exchange 2003 server should be removed using the Exchange 2003 Setup program, which can be launched via Add or Remove Programs (Figure 3.12).

Figure 3.12: Add or Remove Programs

But before you begin uninstalling the Exchange 2003 Server, we first need to assign the Recipient Update Service (RUS) to our Exchange 2007 Server. Not because RUS should be used (in fact Exchange 2007 no longer uses RUS), but because the Exchange 2003 Setup program won’t let us uninstall Exchange 2003, before RUS has been assigned to another server. In order to assign RUS to the Exchange 2007 Server, open the Exchange 2003 System Manager, then expand the Recipients node and select Recipient Update Services. Now open the property page both for Recipient Update Service (Enterprise Configuration) and Recipient Update Service (domain), then click the Browse button under the Exchange Server text box and specify the Exchange 2007 Server instead, then click OK twice and close the System Manager as shown in Figure 3.13.
NoteIt's important you don't delete the recipient policies in the Exchange 2003 System Manager, since Exchange 2007 uses them when provisioning users.

Figure 3.13: Assigning the Recipient Update Service to the Exchange 2007 Server

Note:Microsoft will release an Exchange 2003 hotfix, which will prevent one from reassigning the RUS to an Exchange 2007 server some time in the future. The reason being, this really is an invalid setting that should be blocked. Instead the recommendation will be to use ADSIedit to remove the enterprise RUS object.
Now we can continue uninstalling the server, so select Microsoft Exchange then click the Change/Remove button.
The Exchange 2000 or 2003 wizard will appear, click Next then select Remove in the Action dropdown box as shown in Figure 3.14. Click Next.NoteIf your organization relies heavily on Public Folders, you might want to leave the Exchange System Management Tools intact, as you can use them to administer Public folders on your Exchange 2007 server. Remember Exchange 2007 doesn't have a UI for Public Folder Management.
Figure 3.14: Exchange 2003 Installation Wizard Component Selection Page
On the Installation Summary page click Next and wait for the Exchange 2003

uninstallation process to complete (Figure 3.15).
NoteIf the Exchange 2000 Setup files aren’t located on an accessible drive, network share, you will be prompted to insert the Exchange 2003 CD media during the uninstallation process.

Figure 3.15: Exchange 2003 Uninstallation Process
When the uninstallation process has completed click Finish to exit the Exchange 2003 Setup wizard (Figure 3.16).

Figure 3.16: Exchange 2003 Successfully Uninstalled

Alright we’re done!
NoteIf the Exchange 2003 uninstallation for some reason fails, it may be necessary to remove the Exchange 2003 Server by deleting the Server object in the Exchange System Manager or even via ADSIEdit if this isn’t possible. But please don't delete the respective legacy (Exchange 2003) Administrative Group, as the user's legacyDNs still points there, even though their mailboxes are being moved in a native organization.
Conclusion
Doing a transition from an Exchange 2000 or 2003 Server to an Exchange 2007 in the same Active Directory Forest is a straightforward process, and since Exchange 2007 co-exists just fine with legacy Exchange servers, you can do the transition at your own pace. Co-existence support is laudable as a transition process typically happens in several phases. This is especially true if you’re going to do a transition from multiple legacy Exchange Servers to multiple Exchange 2007 Servers.I like the fact that the Exchange 2007 Setup wizard knows when Exchange 2007 is deployed in an existing legacy Exchange organization, and in this case prompts you to create a routing group connector so that mail flow is established between the legacy routing group and the Exchange 2007 routing group. It’s also nice to see that Exchange 2007 Setup, in this case, creates a Public Folder database and automatically adds the Exchange 2007 Server to the OFFLINE ADDRESS BOOK and SCHEDULE+ FREE BUSY system folders replica lists, so you only have to concentrate on replicating Public Folders.Finally it’s a real pleasure working with the Exchange 2007 Move Mailbox wizard (or Move-Mailbox cmdlet) in order to move legacy mailboxes to an Exchange 2007 Mailbox Server, but I must admit, support for Public Folder management in the Exchange 2007 Management Console GUI is missed.

Migration from Exchange 2000/2003 to Exchange Server 2007 (Part 2)

2009-05-17T04:11:00.000-07:00

Installing Exchange Server 2007

We have reached part 2 in this 3 part article series covering how you transition from an Exchange 2000/2003 to an Exchange 2007 Server deployed in the same Active Directory Forest. For the purpose of this article we will only install one Exchange 2007 Server, and we’ll do so by selecting a typical installation of Exchange 2007. Since a typical installation of Exchange Server 2007 installs the Mailbox, Hub Transport and Client Access Server roles on the respective server, we must make sure the following software and Windows components are installed on the server prior to launching Exchange 2007 Setup.
Required Software
Microsoft .NET Framework Version 2.0 (including this update)
Microsoft Management Console (MMC) 3.0 (bear in mind MMC 3.0 is installed by default when using Windows Server 2003 R2)
Windows PowerShell V1.0 (can be found here or on the Exchange 2007 DVD media)
Required Windows Components
Mailbox Server
Enable network COM+ access
Internet Information Services
World Wide Web Service
When installing the Mailbox Server role, you also need to make sure you install the hotfixes mentioned in MS KB article 904639 and 918980.
Client Access Server
World Wide Web Service
Remote procedure call (RPC) over Hypertext Transfer Protocol (HTTP) Proxy Windows networking component (Required only if you are deploying clients that will use the Outlook Anywhere functionality, previously called RPC over HTTP)
ASP.NET v2.0
Hub Transport Server
No additional Windows components are required by the Hub Transport server; however you must make sure that the SMTP and NNTP services are NOT installed.
NoteListing the hardware requirements for Exchange 2007 is outside the scope of this article's series. For information on hardware requirements see this section in the Exchange Server 2007 Online Documentation.
When ready navigate to the network share containing the Exchange 2007 Setup files, or insert the Exchange Server 2007 DVD media, then double-click on Setup.exe. This will bring us to the Exchange 2007 splash screen shown in Figure 2.1. Click Step 4: Install Microsoft Exchange.

Figure 2.1: Exchange 2007 Setup Splash Screen

Setup will copy the necessary files and soon after begin initializing. After initialization completes, you will be taken to the first step in the Installation Wizard, the Introduction page where you should click Next.
You will now be presented with and need to accept the terms of the end-user license agreement (EULA). I know reading the License Agreement is not among the most exciting things in the world, but you should at least spend a couple of minutes skimming through it. When you have done so, select I accept the terms in the license agreement, and then click Next. After clicking Next you will be taken to the Error Reporting page, where you should decide if you want to enable this feature or not. When you have done so click Next.
As you can see in Figure 2.2, now is the time to select the type of installation we want to perform, as we’re going to do a typical installation of Exchange Server 2007, select this option, then click Next.

Figure 2.2: Selecting a Typical Exchange Server Installation

In order to establish mail flow between the Exchange 2000/2003 and the Exchange 2007 routing groups, we now need to create a routing group connector (Figure 2.3). To do so click Browse then select the Exchange 2000 or 2003 bridgehead server to which you want to connect Exchange 2007, then click Next.

Figure 2.3: Specifying an Exchange 2000 or 2003 Routing Group

The Exchange 2007 Setup wizard will now go through a set of prerequisite checks in order to see whether Exchange is ready to be installed. If you have installed all the necessary software, Windows components and hotfixes, it should complete without any warnings or errors. If this is not the case you should review the issue and if possible click the Recommended Action link in order to see an explanation of or a resolution to the warning or error.
When all issues have been resolved click the Install button and let Exchange Setup copy the necessary Exchange files and install and configure each server role.
Note:If you didn’t run any of the setup preparation switches mentioned in part 1 of this 3 part article series, the Exchange 2007 Setup wizard will prepare the Active Directory before it begins installing the respective server roles.
When Setup has completed installing all the Server roles, click Finish (Figure 2.4).

Figure 2.4: Exchange 2007 Setup Completed

Finalizing Deployment
With the Exchange 2007 Server installation in place let’s launch the Exchange Management Console (EMC). Note that the first time the EMC is launched it will show you the Finalize Deployment tab under the Microsoft Exchange node as shown in Figure 2.5. You should examine each of the deployment tasks listed here, and perform the ones that are relevant for your environment.

Figure 2.5: Finalize Deployment Tab in the Exchange Management Console

Since each deployment task is explained in a step by step fashion, I won’t go into details about each of them here.
End-to-End Scenario Tasks
In addition to the Deployment Tasks we just covered, there’s also an End-to-End Scenario tab (Figure 2.6), which provides a list of tasks that are optional for configuring features, but you should at least skim through each of them and see whether any of these tasks are relevant to your Exchange environment.

Figure 2.6: End-to-End Scenario Tab in the Exchange Management Console

Again, since each task under this tab is pretty much self-explanatory, covering each of them is outside the scope of this articles series.
Global Settings
Global Settings that have been configured on an Exchange 2000 or 2003 Server will be transferred to the Exchange 2007 Server automatically, as these settings are stored and read from Active Directory. This means that recipient policies, Internet Message Formats, SMTP connectors and Exchange delegation permissions are applied to user mailboxes stored on Exchange 2007 as well. Figure 2.7 below shows you the Default Policy which was originally created on our Exchange 2003 Server.

Figure 2.7: Default Policy in the Exchange 2007 Management Console
Also note that when the Exchange 2007 Server has been deployed in the legacy Exchange organization, any of the organization-level settings should be managed using Exchange 2007 Management tools (EMC or EMS) during the co-existence period.
That was it for part 2 but you can look forward to part 3, which is the last article in this article series, which will be published in the near future. In part 3 we’ll replicate public folders, move mailboxes as well as a few other things before we finally decommission the Exchange 2003 server. See you then!

Migration from Exchange 2000/2003 to Exchange Server 2007 (Part 1)

2009-05-17T03:53:00.000-07:00

Introduction

In this 3 part article series I’ll walk you through how to perform a transition from Exchange 2000/2003 to Exchange Server 2007. A transition is the process in which you perform an upgrade to Exchange 2007, that is you move data from any legacy Exchange servers in your Exchange organization to new Exchange 2007 Servers, after which you decommission the legacy Exchange servers. A transition should not be confused with a migration, because unlike a transition a migration is the process in which you move data from a non-Exchange messaging system (such as GroupWise, Lotus Notes or SendMail) to an Exchange organization, or move data from a legacy Exchange organization in an existing Active Directory Forest to an Exchange organization in a new Active Directory Forest.

It’s important to note that unlike previous versions of Exchange, in-place upgrades from Exchange 2000 or 2003 to Exchange Server 2007 aren’t supported, because, among other reasons, Exchange 2007 is 64-bit and therefore requires the x64-bit version of Windows Server 2003.

Note:
Exchange Server 2007 also exists in a 32-bit version but this version is meant to be used for testing and evaluation purposes only, so unless we’re speaking management tasks, it’s only the 64-bit version of Exchange Server 2007 that’s supported in a production environment.

Although in-place upgrades to Exchange 2007 are unsupported, I can assure you that a transition from Exchange 2000 or 2003 to Exchange 2007 in the same Active Directory Forest is a straightforward process, as I’ll show you throughout this article series.

Prerequisites
Before you even start thinking about deploying Exchange 2007 Servers in your existing environment, there are several requirements that must be fulfilled first.

You must make sure that the Exchange organization is set to Native Mode (no pre-Exchange 2000 servers) as shown in Figure 1.1 below.

Figure 1.1: Exchange Organization set to Native Mode

Since any pre-Exchange 2000 servers that may exist in your Exchange organization must be decommissioned before you can switch to native mode, it means that any Exchange 5.5 Servers in your organization must be properly removed before you can perform this step. 'So does this mean that you cannot do a transition directly from Exchange 5.5 to Exchange 2007 in the same Active Directory Forest?' I hear some of you ask. Yes that is correct! Those, hopefully few, of you who still have an Exchange 5.5 organization who want to move to Exchange 2007 must first upgrade from Exchange 5.5 to 2000 or 2003 and then do the transition from Exchange 2000 or 2003 to Exchange 2007.

You must also make sure that any Exchange 2000 Servers in your Exchange organization run with Exchange 2000 Service Pack 3, and that any Exchange 2003 Servers have Service Pack 2 applied. In addition you should take note that if you plan to keep at least one Exchange 2000 or 2003 server in the Exchange organization, the following services are unsupported by Exchange Server 2007:

Novell GroupWise connector (Exchange 2003 Service)
Microsoft Mobile Information Server (Exchange 2000 Service)
Instant Messaging service (Exchange 2000 Service)
Exchange Chat Service (Exchange 2000 Service)
Exchange 2000 Conferencing Server (Exchange 2000 Service)
Key Management Service (Exchange 2000 Service)
cc:Mail connector (Exchange 2000 Service)
MS Mail connector (Exchange 2000 Service)

You must make sure that the Domain Controller that is the schema master in your Active Directory runs Windows Server 2003 with at least Service Pack 1 applied. This is also true for any Global Catalog servers in each Active Directory site in which you plan on deploying Exchange 2007. Actually I recommend you run Windows Server 2003 with at least Service Pack 1 applied on all Domain Controllers in the Active Directory Forest. This version supports Exchange 2007 service notifications, allows users to browse the address book in Microsoft Outlook Web Access and provides the ability to look up distribution list membership in a more efficient manner than in Windows 2000 Server.

Note:
If you have any non-English Domain Controllers in your Active Directory, you should also apply the hotfix mentioned in MS KB article 919166 to those servers, as you otherwise can experience issues accessing the address book via OWA 2007.

Finally Exchange 2007 requires that the Active Directory functional level is set to Windows Server 2000 or Windows Server 2003 as shown in Figure 1.2 below.

Figure 1.2: Active Directory Domain Functional Level

If you’re unsure whether your Active Directory environment is ready for deploying the first Exchange 2007 Server, I recommend you run the latest version of the Exchange Best Practices Analyzer (ExBPA) to see if there’s anything you need to resolve before you continue.

The latest version of ExBPA version 2.7, which you can download at http://www.exbpa.com/, includes an Exchange 2007 Readiness Check option as shown in Figure 1.3.

Figure 1.3: Exchange 2007 Readiness Check Option in ExBPA

You may also have heard that you must suppress Link State updates on any Exchange 2000 or 2003 Servers when deploying an Exchange 2007 Server into a legacy Exchange organization. But this is only true if you’re planning on having more than one routing group connection established between Exchange 2000/2003 and Exchange 2007. For the purpose of this article series we’re deploying one Exchange 2007 Server into a legacy Exchange organization consisting of one Exchange 2003 Server, and therefore don’t need to suppress Link State updates. If you plan on establishing more than one routing group connector, see this link for instructions on how to suppress Link State updates.

Preparing Active Directory
With all prerequisites fulfilled we can move on and prepare the Active Directory using the respective Exchange 2007 Setup.exe switches. Exchange 2007 Setup includes several switches; we’ll go through each of those related to preparing the Active Directory in this section.

Important:
Each of the switches we go through below will be run automatically during the deployment of the first Exchange 2007 server in the Exchange legacy organization, so it’s not mandatory to run them before installing Exchange 2007, but depending on the size as well as topology of your environment, it may be wise to prepare the Active Directory first using these switches before you start the actual deployment process.

Prepare Legacy Exchange Permissions
The first thing we need to do when deploying an Exchange 2007 into a legacy Exchange organization is to run Setup.com /PrepareLegacyExchangePermissions. This is in order to grant specific Exchange permissions in the Active directory domain(s) in which one or more Exchange 2000 or 2003 Servers exist, or where Exchange 2000 or 2003 DomainPrep has been executed. The reason why we must run the Setup.com /PrepareLegacyExchangePermissions is because the Exchange 2003 or Exchange 2000 Recipient Update Service otherwise won’t function correctly after the Active Directory schema has been updated with Exchange 2007 specific attributes.

Note:
For a detailed explanation on why the Setup.com /PrepareLegacyExchangePermissions must be run in an Active Directory domain in which one or more Exchange 2000 or 2003 Servers exist, or where Exchange 2000 or 2003 DomainPrep has been executed, see this section in the Exchange 2007 Online Documentation.

In order to run Setup.com /PrepareLegacyExchangePermissions, you must open a Command Prompt window and navigate to the directory, network share or DVD media containing your Exchange 2007 Setup files, then simply type Setup.com /PrepareLegacyExchangePermissions and hit Enter as shown in Figure 1.4.

Figure 1.4: Running Setup.com with the /PrepareLegacyExchangePermissions Switch

Note:
Some of you might be in a situation where you want to prepare the Active Directory domain before you install the x64-bit version of Windows Server 2003 on a server in the Active Directory Forest, and therefore cannot run Setup.com /PrepareLegacyExchangePermissions using the 64-bit version of Exchange 2007 as you don’t have any x64-bit Windows 2003 Servers deployed yet. But fear not, as it’s fully supported to use the 32-bit version of Exchange 2007 to prepare your production Active Directory environment. As I mentioned in the introduction, the 32-bit version of Exchange 2007 is fully supported in a production environment, when speaking management tasks, and preparing the Active Directory is considered a management task.

Prepare Schema
The next command to run in order to prepare the environment is the Setup.com /PrepareSchema, which will connect to the Domain Controller schema master and import LDAP files to update the schema with Exchange 2007 specific attributes. In order to do so, open a Command Prompt window and type Setup.com /PrepareSchema followed by hitting Enter like we did with the previous switch. Setup will now update the schema as necessary as shown in Figure 1.5.

Figure 1.5: Running Setup.com with the PrepareSchema Switch

Like was the case with the previous command, this can be done using the 32-bit version of Exchange 2007.

Prepare AD
The Setup.com /PrepareAD command is used to configure global Exchange objects in Active Directory, create the Exchange Universal Security Groups (USGs) in the root domain as well as prepare the current domain. The global objects reside under the Exchange organization container. In addition, this command creates the Exchange 2007 Administrative Group which is named Exchange Administrative Group (FYDIBOHF23SPDLT) as well as creates the Exchange 2007 Routing Group called Exchange Routing Group (DWBGZMFD01QNBJR).

As some of you may be aware, Exchange 2007 doesn’t make use of Routing Groups and Administrative Groups like Exchange 2000 or 2003 did. Administrative Groups have been dropped completely and message routing in Exchange 2007 is based on Active Directory Sites. But in order for Exchange 2007 to co-exist with Exchange 2000 or 2003, Exchange must create the mentioned Administrative Group and Routing Group, which can only be viewed via an Exchange 2000 or 2003 System Manager or by using ADSIEdit as can be seen in Figure 1.6 and 1.7 below.

Figure 1.6: Exchange 2007 Administrative and Routing Group in the Exchange 2003 System Manager

Figure 1.7: Exchange 2007 Administrative and Routing Groups in ADSIEdit
You can run the Setup.com /PrepareAD command before running /PrepareLegacyExchangePermissions and /PrepareSchema. Doing so will run the /PrepareLegacyExchangePermissions and /PrepareSchema commands automatically.

Note:
Okay with all these boring switches it’s time for a little fun! Did you know that although coding a product such as Exchange 2007 is a lot of hard work, the Exchange Product Group always has time for a little humor? To prove it let us try to take the GUID of the above Administrative Group shown in Figure 1.6 and shift each letter upwards. Do the same for the GUID of the Exchange Routing Group shown in Figure 1.7 but do it downwards. Did you manage to see what it translates to?

In order to run this command, open a Command Prompt window and type Setup.com /PrepareAD followed by Enter. Setup will now configure the organization as necessary as shown in Figure 1.8.

Figure 1.8: Running Setup.com with the PrepareAD Switch

PrepareDomain and PrepareAllDomains
It’s also possible to prepare a local domain or all domains in the Active Directory using the Setup.com /PrepareDomain and Setup.com /PrepareAllDomains respectively. These switches will set permissions on the Domain container for the Exchange Servers, Exchange Organization Administrators, Authenticated Users, and Exchange Mailbox Administrators, create the Microsoft Exchange System Objects container if it does not exist, and set permissions on this container for the Exchange Servers, Exchange Organization Administrators, and Authenticated Users and create a new domain global group in the current domain called Exchange Install Domain Servers. In addition it will add the Exchange Install Domain Servers group to the Exchange Servers USG in the root domain.

As with the commands we have already been through, these commands also need to be run from a Command Prompt window as shown in Figure 1.9.

Figure 1.9: Running Setup.com with the PrepareDomain Switch

This was all there was for part 1 in this 3 part article series covering a transition from Exchange 2000/2003 to Exchange 2007 in the same Active Directory Forest. In part 2 which will be published soon here on MSExchange.org, we’ll prepare the new server for Exchange 2007 and then do the actual Exchange 2007 installation.

Managing Receive Connectors (Part 2)

2009-05-16T23:48:00.000-07:00

In the last article we created a Receive Connector to receive mail coming from the Internet, and we also tested it using the telnet utility.

In order to test a receive connector we have to be aware of the basic SMTP verbs to send a message using a telnet session. These following commands will enable you to send a test message using the telnet utility. All the basic SMTP verbs required to send a message are below:

1.The receive connectors that we have just created is listening on port 25 and on a specific IP address. Let’s use the telnet utility to connect in our server:

telnet 25
Expected result: 220 Banner information
2.Start the SMTP communication.

EHLO example.org

Expected result: a list of all SMTP verbs that are accepted by the receive connector. In the first line a hello answer with the IP Address used by the sender will be shown.
3.Define the sender of the test message.

Mail from:user@example.org

Expected result: 250 2.1.0 Sender OK

4.Define the recipient of this test message. The SMTP domain used by the recipient must exist in the current organization.

Rcpt to:user@

Expected result: 250 2.1.5 Recipient OK

5.Start the test message.

Data

Expected result: 354 Start mail input; end with .

6.Hit the key twice and type in the content that will appear in the body of the test message. To finish type a period “.” in a blank line and hit .

This is a test message.

.

Expected result: 250 2.6.0 Queued mail for delivery

7.Closing the session.

Quit

Expected result: 221 2.0.0 Service closing transmission channel

We can log on to OWA to check if the message was received. The entire process can be seen in Figure 01.

Figure 01

Knowing this process is important to troubleshooting mail flow and to validate a Receive Connector as well.

Playing with Receive Connector security features...
Now that we have just configured a Receive Connector using both the Exchange Management Console and Exchange Management Shell we can start playing with some security configurations for our Receive Connectors. All the security that we are going to see here is modified by the Receive Connector and they must be configured using the Exchange Management Shell. Let’s configure some features in our new Internet Receive Connector, as follows:

Changing Banner information…
Some companies do not like the idea of displaying the server name in SMTP connections. We can change the banner information used by a Receive Connector using the cmdlet below and the result will be shown in Figure 02.

Set-ReceiveConnector -Banner “220 Mail Server”

Figure 02
If you still have Exchange Server 2003/2000 and you want to change this behavior you can use the following Microsoft KB Article: How to change the default connection response that you receive after you connect to the SMTP port in Exchange 2003.

Specifying a number of errors during a session…
We can control the number of protocol errors in a single session. The default value is 5, to configure it to 2 we can use the following cmdlet:

Set-ReceiveConnector -MaxProtocolErrors 2

Now if an SMTP Server/user connects and reaches the maximum number of errors defined in the receive connector the following message will be shown (Figure 03):

Figure 03

Throttling a Receive Connector…
Receive connectors allow us to restrict inbound traffic to prevent high usage from a determined source, preventing an unnecessary overload of the system. Here are the three options that we have:

MaxInboundConnectionsperSource: Defines the maximum number of connections made in the receive connector at the same time by the same source. This default value of this setting is 100.
MaxInboundConnection: Defines how many connections the receive connector will accept at the same time. The default value of this setting is 5000.
MaxInboundConnectionPercentagePersource: Based on the MaxInboundConnection value it indicates how many connections the same source can establish with the receive connector. The default value is 2%.
To configure the Receive Connector using the new settings that we have just seen, we can run the following cmdlet:

Set-ReceiveConnector -MaxInboundConnection -MaxInboundConnectionsperSource -MaxInboundConnectionPercentagePerSource

We can also configure time-out in a receive connector in certain aspects, such as: during SMTP communication and also during an inactive connection .To configure the ConnectionTimeout we can run this following cmdlet:

Set-ReceiveConnector -ConnectionTimeout

To disconnect due to Inactive time, we can use the cmdlet below:

Set-ReceiveConnector -ConnectionInactiveTimeout

We can also restrict the number of recipients, Rate Limit and Max message size at connector level, to configure these settings we can use the following parameters:

MaxRecipientsPerMessage: The maximum number of recipients in a single message, the default value is 200.
MaxMessageSize: The maximum size of a message; the default value is 10MB.
MaxRateLimit: This specifies the maximum number of messages that can be sent by the same client per minute.
Let’s change our Internet Receive connector to accept 100 users maximum, the message size should be more than 2MB and the rate limit is 200, as follows:

Set-ReceiveConnector –MaxRecipientsPerMessage:100 –MaxMessageSize:5MB –MaxRateLimit:200

The last feature we will cover in this article is the TarpitIntervall. In Exchange Server 2003 we have to configure it through the Registry Editor (http://support.microsoft.com/kb/842851). In Exchange Server 2007 we can do that using the Exchange Management Shell. The tarpit feature inserts a pre-defined delay in each SMTP response that contains the 5.x.x error code during the SMTP communication between servers. The tarpit feature is only applied to anonymous connections and it should be used with the Recipient Filter Agent and Recipient Lookup features enabled.

In this article we are using a single Exchange Server 2007 box with all three main roles installed (Mailbox, CAS and Hub Transport) and it is receiving messages from the Internet, we also configured the Anti-spam agents on that box (we can validate how to configure a single Exchange Server to receive internet messages and anti-spam features in this article: Configuring Mail Flow in a Single Exchange Server 2007). Let’s look at the Recipient Filtering agent and enable the Recipient Lookup feature:

1.Open the Exchange Management Console.
2.Expand Organization Configuration.
3.Click on Hub Transport.
4.Click the Anti-Spam Tab.
5.Double click Recipient Filtering.
6.Click the Blocked Recipients tab.
7.Check the first option “Block messages sent to recipients not listed in the Global Address list” (Figure 04).

Figure 04

Okay, from now on all messages addressed to unknown address in our organization will be refused by the Exchange Server, as shown in the first rcpt to: SMTP verb in Figure 05. However we might encounter a problem where a spammer can try a harvest attack against our Exchange Server using a dictionary attack to find out which e-mails are valid in your organization. So, how can we stop it? There is no way to stop it but for each wrong address tried in the SMTP communication a “5.1.1 User unknown” error is displayed and for each of these errors we can configure tarpit to delay the server response.

Figure 05

The default value is 5 seconds, to change this configuration we can run the following cmdlet:

Set-ReceiveConnector “” –TarPitInterval:

Conclusion
In this article we have gone over how to configure some security settings and limits in a Receive Connector. We also saw that the some configuration must be done using the Exchange Management Shell. In the next article we are going to play with logging information and start playing with authentication methods and how to configure permissions using AdsiEdit.msc and the Exchange Management Shell.

Managing Receive Connectors (Part 1)

2009-05-16T23:12:00.000-07:00

Introduction

Exchange Server 2003 uses the SMTP Virtual Server that comes with the Operation System to control message flow. In Exchange Server 2007 the SMTP service bits are installed within the Exchange Server 2007 installation process. Because of this, we have two different components when we are talking about SMTP traffic in the Exchange 2007 architecture: the receive connectors and the send connectors. They are configured in two different places, the Send Connector is configured at Organization level and the receive connector at Server level. The receive connector is responsible for all SMTP incoming traffic which can originate from an external source, a client, a partner, or another Exchange Server and on top of that the receive connector uses authentication and some other features to manage all received connections.
By default Exchange Server 2007 has two new receive Connectors called Client Receive Connector and Default , where is the Netbios name of the Exchange Server. The default Receive connectors can be found under Server Configuration / Hub item using the Exchange Management Console, as shown in Figure 01. They can also be found using the Get-ReceiveConnector cmdlet through the Exchange Management Shell. By default any new Exchange Server can receive messages from other Hub Transport servers due the Default Receive connector which is named Default and is configured to receive traffic from any host, to any local IP address on port 25 but this traffic must be authenticated first

Figure 01

Creating a Receive connector
Now we are going to create a new Receive Connector from scratch and during the process we will explain the available options that can be defined during the wizard. The server used in this article has two IP addresses: 172.16.171.11 and 172.16.171.12.

Each connector has a unique set of the following attributes: IP Address, Port number and remote IP Address range. These parameters are always validated during the New Receive Connector wizard. If you have an existent connector with the same values a new connector cannot be created.

In this article we are going to create an Internet Receive Connector using the second IP address of the server, as follows:

1.Open the Exchange Management Console.
2.Expand Server Configuration.
3.Click on Hub Transport.
4.Select the server name on the right hand side.
5.In the Toolbox Actions. Click on New Receive Connector.
6.Introduction. Let’s name this new connector using the Name field, and we can also select which kind of connector it is for (Figure 02). We have five options: Internet, Internal, Partner, Client and Custom and each one of them defines a set of authentication and permissions on the connector that we are creating. The choice of connector also changes the New Receive Connector wizard, so it is not the same wizard for all types of pre-configured connectors. In this article we are going to start playing with an Internet Receive Connector, so let’s click on Internet and click on Next.

Note:
If we choose a wrong type of connector we can always change the configuration afterwards. It is not necessary to recreate it due to choosing the incorrect option.

Figure 02

Okay, what if we had chosen Client, Partner or Internal instead of Internet? What would be the difference? The following table shows which changes will be applied for each type of receive connector chosen. We have three columns, the first one (During Wizard) shows which information will be required during the New Receive Connector Wizard; the second one (Authentication) shows what authentication method will be configured by default in the new Receive Connector and the last one (Permissions) shows which groups are marked in the Receive Connector permissions. Remember that all those values can be changed through the Exchange Management Console or Exchange Management Shell afterwards.

During Wizard
Authentication
Permissions

Internet
In Local Network settings page, we can manage the Local IP Address(es), Port and specify FQND.
TLS
Anonymous Users

Internal
In Remote network settings we can change the remove IP Address range.
TLS

Exchange Server Authentication
Exchange Servers,

Legacy Exchange Servers

Client
In Remote network settings we can change the remove IP Address range.
TLS

Basic Authentication and Offer Basic authentication only after starting TLS
Exchange Users

Partner
On the Local Network settings page we can manage the Local IP Address(es), Port and specify FQND.

In Remote network settings we can change the remove IP Address range.
TLS and Enable Domain Security (Mutual Auth TLS)
Partners

Custom
On the Local Network settings page we can manage the Local IP Address(es), Port and specify FQND.

In Remote network settings we can change the remove IP Address range.
TLS
None

We will go over Authentication and Permissions later on in this article series, for now let’s finish our Internet Receive Connector.

7.Local Network Settings. Let’s use only the second IP address of the local server on port 25. We are also going to use the mail.andersonpatricio.org as FQDN, as shown in Figure 03. This name will be displayed when a connection is established with this Receive Connector. Click on Next.

Figure 03

8.New Connector. A summary of our choices made so far. Click on New to create the Receive Connector.
9.Completion. Final screen of the new receive connector wizard with all the information provided during the wizard and the cmdlet used to create it. Click on Finish.
Okay, these are the steps required to create a new receive connector; we can do the same using the Exchange Management Shell. To create we have to use the New-ReceiveConnector cmdlet. In this example we are going to create the same connector described in the steps above:

New-ReceiveConnector -Name “Connector Name” –Usage:Internet –Bindings:: -fqdn: ‘’ –Server

Testing the new Receive connector…
Okay, we have just created our new connector. We can start testing it using the following command: telnet 172.16.171.12 25 where 25 is the port that will be used (Figure 04). The connection will be made and the FQDN name that we defined in our new Receive Connector will be shown. If we try to connect using the IP address 172.16.171.11 we will receive a different prompt because it is a different connector. Our Internet connector is only listening on the 172.16.171.12 IP address.

Figure 04

Conclusion
In this article we have seen how to create a receive connector and we also saw that a Receive Connector must be unique in at least one of these attributes: IP Address, port, Remote IP Address, in order to be created. In the following article we are going to use the telnet utility to test a Receive Connector and also take a look at some security and throttling configurations