Collection:Exchange 2007 Edge Transport Server Role (2)

Exchange Address Rewrite in Exchange Server 2007

Exchange Address Rewrite in Exchange Server 2007 is already installed with the core messaging subsystem but is not enabled. You have to use the Exchange Management Shell to activate Exchange Address Rewrite.
One other new feature of Exchange Address Rewrite in Exchange Server 2007 is that you can enable this feature on a per user, SMTP domain and/or SMTP sub domain base and not for the whole Exchange 2003 Virtual SMTP Server as in Exchange Server 2003.
You configure Address Rewriting agents on the SMTP receive connector and send connector on a computer that has the Edge Transport server role installed.
Please note:The Exchange Server 2007 Address Rewrite Agent is only available on Edge Transport servers.

Collection: Exchange 2007 Mail Transport Query (2)

Troubleshooting Edge Transport Server Queues That Contain Mail Destined to a Hub Transport Server

This topic explains how to resolve issues where messages queue on a Microsoft Exchange Server 2007 Edge Transport server that are destined for delivery to an internal Exchange Hub Transport server. In the Queue Viewer, these messages display the error message 451 5.7.3 "Cannot achieve Exchange Server authentication".

This issue occurs when both Transport Layer Security (TLS) and Exchange Server Authentication are not configured on the default Receive connector of the receiving Exchange Hub Transport server. Therefore, you can resolve this issue by enabling TLS and Exchange Server Authentication on the default Receive connector.

Collection: Exchange 2007 Hub Transport Role Server(3)

Exchange Server 2007: Using Journaling Rules

Journaling: The traditional way...

In Exchange Server 2003, journaling took place directly in the mailbox store because there was no hub transport role.

In Exchange Server 2007 we can choose either to have the same option (allowing a Journal mailbox to receive all message traffic from a mailbox database) or to support a number of Mailbox databases. We can also create a separate mailbox database to store the mailbox which will receive the journaling.

In the following example, we are going to configure a mailbox database in Exchange Server 2007 to record all user messages that have been sent and received within the same database to be redirected to a specific mailbox.

To configure Journaling for a specific mailbox database, follow these steps:

Collection: Exchange 2007 Mailbox Server Role(2)

Exchange 2007 Messaging Records Management

Introduction

One major new feature of Exchange 2007 is that of Messaging Records Management (MRM). The main principle behind MRM is that it helps an organization with its legal compliance requirements, something that previous versions of Exchange aren’t particularly good at. It does this by placing the onus on the user to categorize their messages, leading to these messages being retained where appropriate. Obsolete messages are then removed. Sounds simple enough? In truth it is, although there are a few processes to understand and some terminology to become familiar with.

The strategy to make Exchange 2010 messaging retention management and policy enforcement more reliable, effective, and easy to use is based on three principles:

  Users classify their own messages.

  Messages that have no retention value are removed.

  Messages that have some retention value are retained.

Collection:Exchange 2007 Client Access Server Role(2)

Uncovering the New Outlook 2007 AutoConnect feature

Introduction

Microsoft Outlook 2007 AutoConnect (formerly known as AutoDiscovery) is a new Exchange Server 2007 feature, or more specifically Web Service, which makes it so much simpler as well as easier to configure the Outlook 2007 profiles in your organization. In order to automatically configure and connect previous versions of Outlook to Exchange 2000 and 2003 Servers, you needed to do so using the Custom Installation Wizard from the Office Resource Kit or a similar tool. But now the users can configure their Outlook profile themselves, as they only need to click next a few times and specify their e-mail address and password, depending on whether they're using a client machine member of the respective Active Directory domain or not.
The AutoConnect feature is provided by the Client Access Server (CAS) role, which is the server role that replaces the front-end server we know from Exchange 2000 and 2003. So in order to make use of the new AutoConnect feature, it’s a requirement that you have at least one Exchange 2007 Server, with the CAS role installed, and deployed in your organization.

Collection: Exchange 2007 Hub Transport Server Role(2)

Managing Receive Connectors

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 <Server Name>, where <Server Name> 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 <Server Name> and is configured to receive traffic from any host, to any local IP address on port 25 but this traffic must be authenticated first.

Collection: Windows Server 2003 (3)

Recursive vs Iterative Query.

With a recursive name query , the DNS client requires that the DNS server respond to the client with either the requested resource record or an error message stating that the record or domain name does not exist. The DNS server cannot just refer the DNS client to a different DNS server.Thus, if a DNS server does not have the requested information when it receives a recursive query, it queries other servers until it gets the information, or until the name query fails.

Recursive name queries are generally made by a DNS client to a DNS server, or by a DNS server that is configured to pass unresolved name queries to another DNS server, in the case of a DNS server configured to use a forwarder.

An iterative name query is one in which a DNS client allows the DNS server to return the best answer it can give based on its cache or zone data. If the queried DNS server does not have an exact match for the queried name, the best possible information it can return is a referral (that is, a pointer to a DNS server authoritative for a lower level of the domain namespace). The DNS client can then query the DNS server for which it obtained a referral. It continues this process until it locates a DNS server that is authoritative for the queried name, or until an error or time-out condition is met.This process is sometimes referred to as "walking the tree," and this type of query is typically initiated by a DNS server that attempts to resolve a recursive name query for a DNS client.