Master Exchange 2007

powershell, automation & more…

Archive for the ‘Transport’ Category

This category contains cmdlets and scripts that relate to the management of transport services within Exchange 2007/2010.

Protocol Logging with Exchange 2007 / 2010 (log file size, log directory size, log age emc shell)

Posted by shauncroucher on May 6, 2010

SMTP mail flow logging with Exchange 2007/2010


Purpose of this document

There are many reasons why you may need to log the mail flow arriving at your Exchange connectors. You have the ability to record a good deal of detail regarding the SMTP conversations that are occuring in your organisation.

The process to turn the logging feature on and to specify the location for the log files is very straighforward, but if you plan on retaining logs for an extended period of time and therefore wish to keep a lot of log file data, or would like to alter the file size of each log file, you will need to use the Exchange Management Shell. The process is simple. This guide hopes to focus on the main configuration requirements.

Turning Logging ON/OFF

To turn logging on or off can be controlled using either EMC or EMS.

To use the console, simply navigate to the Receive or Send Connector and then on the main page select ‘Verbose’ for Protocol Logging Level.

Using the shell, simply find the connector information using the following:

Get-ReceiveConnector | fl Id*,Pr*

Get-SendConnector | fl Id*,Pr*

Then you can use the Identity to turn logging on if required, using the following:

Set-ReceiveConnector “IDENTITY” -ProtocolLoggingLevel Verbose

Set-SendConnector “IDENTITY” -ProtocolLoggingLevel Verbose

Set Location, Directory size and file size for logging

The location of the files can be controlled using either EMC or EMS.

To use the console, if you have the Hub Role installed navigate to Server Config –> Hub Transport –> Action pane on right hand side –> Servername –> Properties –> Log Settings –> Send connector/Receive connector log file path.

(Note that when selecting properties on right hand side ‘Actions’ pane, it is the server properties, not the receive connector properties)

Using the shell, simply find the connector log file location using the following:

Get-TransportServer | fl Id*,*pro*log*

Then you can use the Identity to change the paramters as required (change ReceiveProtocol to SendProtocol for send connector logging):

Set-TransportServer “IDENTITY” -ReceiveProtocolLogPath “PATH”

Set-TransportServer “IDENTITY” -ReceiveProtocolLogMaxDirectorySize “250MB”

Set-TransportServer “IDENTITY” -ReceiveProtocolLogMaxAge “DAY.HH:MM:SS”

Set-TransportServer “IDENTITY” -ReceiveProtocolLogMaxFileSize “10MB”

Setting Intra-organisation connector protocol logging (the hidden SMTP connector):

In order for your log files to record intra-organisation SMTP activity you will need to enable this using the shell. You cannot configure this using EMC. The intra-org logging will log activity from a hidden SMTP connector used to communicate with other Hub servers in your org, to communicate with your edge server or for legacy Exchange 2000\2003 systems.

Set-TransportServer “IDENTITY” -IntraOrgConnectorProtocolLoggingLevel “Verbose”

Reading the Log Files

It’s all well and good configuring logging, but how do you use this information? What can it be used for?

The great thing about the log files is that they are full accounts of the SMTP conversation for every mail item in and out of your Exchange organisation. You will be able to see any SMTP level rejections and evaluate at what stage the rejection is sent.

I would advise that once logging is enabled, always try to get the log file in a more readable format, such as Excel, or other text delimited file capable program, this way you can more easily see the data to start analysis.

External References – Configuring Protocol Logging 


Posted in Transport | Leave a Comment »

Exchange Send Connector EHLO and DNS data, rDNS, PTR, MX, SPF, TXT, ‘A’ record!

Posted by shauncroucher on March 12, 2010

Exchange 2007 / 2010 DNS Data


Purpose of this article

Throughout the online technical support community it is so common to find administrators struggling to figure out what DNS records need to be configured to allow reliable inbound and outbound SMTP services. This article has been written to clear up a few myths that I’ve heard and to clarify what is required, and what is not.

My Top 5 Myths

1) DNS changes take 24-48hrs to update\propagate around the internet.

  • This is such a common myth it has to make my number 1 spot. The truth is that DNS records don’t propagate in the true sense of the word, there is no automatic process that pushes these records anywhere. The myth originates from the ‘caching’ mechanism which is used within the DNS framework. A brand new DNS record (of any type) should be available as soon as the change is made to the domain zone (usually the hosting company do this or you have a web portal to make changes and there may be a delay here with actually processing your request – check with your hosting provider). Once this change is made, it will be live everywhere. Now, there may be a delay if you change the details of a record such as adding a MX record or changing the ‘A’ record associated with a MX record, the delay will be as long as the TTL (time to live) value for that record and this is usually 1-3hrs. There are some exceptions where your ISP may cache the results for longer than the TTL on your records but this is quite rare nowadays and the vast majority of DNS changes will be seen within 4 hours to be honest. You can check with your hosting company (or go to and type your domain to see the TTL in seconds for your DNS records.

2) Your MX record needs to match your reverse DNS (aka PTR) record

  • This is just not true. The pointer record (PTR) can also be known as the reverse DNS (rDNS) record and it does not need to match your MX records at all, it is really as simple as that. Imagine a company that use a third party hygiene service like messagelabs (where they have changed the MX records to the messagelabs servers), they may still use their own servers to send mail, and they wouldn’t want to change their PTR to match messagelabs as this would go against general DNS principles entirely (see RFC 1912).

3) The IP you send mail out with also needs to allow inbound port 25 access

  • I can only think that this myth originated from the anti-spam technique of checking if the domain name specified in the MAIL FROM (the sender domain) field have any infrastructure to support inbound mail. This test will not check to see if the connecting IP allows inbound SMTP, it will use the domain name to do a DNS lookup of the MX records to see if they exist, and sometimes will also try to connect to the MX to see if it accepts connections. The idea behind this method is to give weight to the domain name belonging to a legitimate sender. It is not as commonly used as other methods of anti-spam but the point here is that the sending IP does not need to accept inbound SMTP at all. The important thing is to make sure you have valid MX records in place that accept mail for your domain.

4) You need to setup SPF for your domain for reliable mail delivery

  • If you do not want to use SPF records for your domain (which are used to tell other servers the locations you permit mail from your domain to originate from), it will have no negative consequence for mail delivery. In other words, you don’t need a SPF record for reliable mail delivery. However, the presence of a SPF record may help add weight to the mail being legitimate and can help others when they decide if your email is a SPAM message or not.

5) You need to setup a PTR record for your domain for reliable mail delivery

  • PTR (or rDNS) records are setup for a IP address. The namespace is to allow you to query for an IP address and the answer you receive is a PTR record. It is not possible to setup a PTR record for a domain because a domain is not an IP address.

Inbound Mail (The MX record) requirements

Assuming you do not use a hygience server and wish to setup your mail servers so that mail from the outside world is delivered directly to your servers, you need to make sure you have MX records publishing for your domain name. The MX record needs to be setup with the hosting company who look after your public DNS records (those for your public domain name such as

The fastest and easiest way to find out what your MX records are is to use the command prompt and a DNS query tool of your choice, such as nslookup or DIG. I will use nslookup in this example as we are talking about Exchange and nslookup ships as part of the Microsoft operating system.

Open command prompt and type the following (replacing with your domain):

nslookup -q=mx

now, you should receive a response which looks similar to this:

nslookup -q=mx

Non-authoritative answer: MX preference = 10, mail exchanger = nameserver = nameserver =

(you may not be provided with the nameserver details, but should definitely have the MX record result as above).

Note the preference there, it should be a positive number above O (a priority of O can cause issues with some sending servers)

Now you should check that the mail exchanger ( points to your external IP address, you can do this by simply pinging the name from the command prompt and seeing what IP is resolves to. Now assuming you have port 25 open and directed to the mail server you are good to go.

Outbound Mail Requirements

There is a lot more to consider with DNS when you are sending outbound mail, and if you don’t check this, you may find yourself with outbound mail delivery problems.

The Reverse DNS (or PTR) record

It is true that the IP address you use to send outbound mail MUST have a reverse DNS record and this reverse DNS record should refer to the primary domain name you use to send mail (its fine if you use multiple domain names when sending mail). To check if you have a rDNS record in place, you first need to find out what your outbound mail IP is. The most reliable way of doing this is to take a look at the headers of an outbound email. You should see in the headers where the email leaves your company and gets accepted by the receiving end. You should note the IP address that is used.

Once you have the IP address, it is very easy to check the rDNS, simply run a ping from the command prompt with the -a switch.

ping -a

Make sure you use your public IP address here, and not the internal IP.

You will need to speak with the people who have been delegated the DNS responsibility for your IP address’s PTR record and this will in most cases be your ISP.

You should also make sure that you have a matching ‘A’ (aka hostname or subdomain) record in your domain DNS zone (contact your domain hosting company) that matches the PTR record you have created. This allows for a forward-confirmed rDNS (where the PTR for an IP has a corresponding ‘A’ record configured in the domain zone that also points to the IP).

The HELO\EHLO hostname

Not strictly DNS data, but certainly related.

When a Mail Transfer Agent (MTA) such as Microsoft Exchange starts a SMTP conversation with another MTA, it will use a ‘HELO\EHLO’ hostname as a greeting. Some MTA’s will check this hostname to see if it matches the rDNS entry. If they do not match, the mail may be rejected. For this reason it is important that the Send Connector is using the correct FQDN to send mail. You can clarify what this is by using the Get-SendConnector as below:

Get-SendConnector | ft Id*,fq*

This will show you the FQDN used and the Identity of each connector.

You can use the Set-Sendconnector to set this to the public rDNS.

Set-SendConnector <Identityname> -Fqdn <>

It’s as simple as that. (you can use the Exchange Management Console if you prefer, Org config –> Hub –> Send connectors)

Sender Policy Framework (SPF)

As I mentioned in my list of common myths, SPF is not a requirement for reliable mail delivery and is totally optional. SPF can be a little confusing for the uninitiated. There are two parts to SPF, firstly you can configure your own mail server to ‘check’ SPF data when receiving mail to see if the sender has permitted the sending server to send mail as that domain. Secondly, there is setting up SPF data for your domain name so that others can check that mail they receive is coming from a source you specify as ‘permitted to send as your domain name’

I will be talking about the creation of SPF records in your domain’s DNS zone. As with the ‘A’ record you configured to match the rDNS, you will need to appoach the people who manage your domains DNS records to get a SPF record set up. Every DNS record has a ‘type’ such as ‘A’, ‘PTR’, ‘MX’. The type that is used for SPF is ‘TXT’. TXT records can be used for other purposes as well, but are the type that SPF is designed to check for. There is a plethora of ways that you can configure your SPF record to identify which servers are permitted to send mail for your domain, the easiest ways are by providing IP addresses, or if you use the same server to send and receive mail, you can just specify the ‘MX’ record.

To specify a list of IP addresses that are allowed to send mail using your domain:

“v=spf1 ip4:  ip4: ~all”

To specify the server that is referenced in your MX record as the only server permitted to send you can use:

“v=spf1 mx ~all”

You might be wondering what the ~ is before all, and this just means “treat this list as authorised, but if you see mail coming from somewhere else, it MIGHT still be legitimate, but you should mark it as suspicious”. You can use a hyphen ‘-‘ which means “If it isn’t on the list, you should reject it outright”, but I wouldn’t recommend this as there are still issues with SPF such as when mail is forwarded from another server and you will find using a HARDFAIL such as ‘-‘ will cause legitimate mail being refused.

There is a handy tool you can use to help you create the SPF record – see : and answer the questions to assist you with the record creation. You will then need to apply this to your zone file with the help from your domain hosting solution provider.

External References – SMTP Request for Comments publication – TTL lookup – RFC1912 – Common DNS Operational and Configuration Errors – RFC 4408 – Sender Policy Framework

Posted in Transport | 4 Comments »

How to prevent self sending spam email spam from yourself to yourself?

Posted by shauncroucher on February 17, 2010

It’s irritating when you get spam that looks like is has come from you or from someone else (or fake person) in your organisation.

There is a way in Exchange 2007 / 2010 to prevent this from happening. It’s crude but somehow pleasing. I can’t take credit for this as I came across it when roaming around the forums.

Basically you can use the following command to remove a transport permissions from the anonymous logon account that all unauthenticated sessions will use during the session with Exchange.

Get-ReceiveConnector “My Internet ReceiveConnector” | Get-ADPermission -user “NT AUTHORITY\Anonymous Logon” | where {$_.ExtendedRights -like “ms-exch-smtp-accept-authoritative-domain-sender”} | Remove-ADPermission


Posted in AntiSpam, Transport | Leave a Comment »

Change port used by Exchange 2007 or 2010 send connector when using smarthost

Posted by shauncroucher on February 16, 2010

A lot of people are having trouble finding where they can change the port used to send outbound mail to their smarthost provider.

Some smarthost providers will only allow you to connect to ports other than port 25. Godaddy are a good example of this, where the relay service they offer their customers typically  operates on port 3535

The bottom line is that you have to configure the port used by a send connector at the Exchange Managment Shell. It cannot be done using the Exchange Management Console.

It’s easy enough.

To find the ports used by all your send connectors along with the smarthost used just open the shell and type:

Get-SendConnector | ft Id*,Sm*s,po*

Now, to send the port to something different just run Set-Sendconnector. So if the connector is called “OutboundMail” and you want it to use port 3535 it would be:

Set-SendConnector “OutboundMail” -port 3535


Posted in Transport | 1 Comment »

Exchange 2003 to Exchange 2007 transition migration using Exchange management shell cmdlet commands

Posted by shauncroucher on January 6, 2010

E2000\2003 – E2007 Transition ‘maximising EMS’

 Document Purpose

The purpose of this document is to run through the steps necessary to fully transition Exchange 2003 to Exchange 2007 maximising the use of the Exchange Management Shell (EMS).

Where it is easier to use the Exchange Management Console (EMC) I will show the steps using this tool.

Test Environment Used

  1. The Flexible Single Master Operation (FSMO) role holders were not changed or migrated from Windows 2003.
  2. The Exchange 2003 server is installed on the server hosting all 5 FSMO roles. This is not best practice in a production environment, but will suffice for the purposes of this document. Note here that you cannot run the ‘/Prepare switches’ prerequisite tasks on a computer that has Exchange 2003 installed. This may mean you need to promote a new DC to run the initial AD preparations.
  3. Single forest \ single domain environment
  4. The Exchange 2007 server introduced will be a 2008 DC for the domain and will be running Windows 2008 operating system. Note in a production environment it is best practice to not install Exchange 2007 on a Domain controller
  5. The Windows 2008 AD preparation commands have been run to upgrade schema in order to allow the introduction of a Windows 2008 DC. Includes adprep /forestprep  /domainprep etc


Active Directory and Environment Preparation


  1. Check Exchange 2003 is running in Native Mode by opening the Exchange System Manager, right click the ‘Organisation’ –> properties.


  1. Check the server holding the schema master role is running at least Windows server 2003 SP1. The schema master also needs .NET framework 2.0 and Powershell v1.0 installed.
  2. All DC’s should have the same ‘locale’ as the OWA Client (see
  3. The Domain functional level should be Windows 2000 minimum.
  4. You should run the Exchange Best Practices Analyser (ExBPA) Exchange 2007 Readiness check to ensure the environment is ready for Exchange 2007.

Exchange 2007 Specific Preparation Switches

The following ‘prepare’ commands will automatically be performed on the introduction of the first Exchange 2007 installation. I list them here because this document focuses on using shell commands for the transition, and I believe this also gives more control over each step and therefore the transition as a whole. Use the from the Exchange 2007 installation media for these tasks. Use the freely downloadable 32bit version of Exchange 2007 to update the schema on a 32 bit schema master computer.

If you are installing Exchange SP2 to run the switches you will need Windows Installer 4.5 installed

Note you cannot run these commands on a computer running Exchange 2003. The setup program will notify you there is a previous version of Exchange server already running.

1. /PrepareLegacyExchangePermissions

2. /PrepareSchema

3. /PrepareAD

The ‘PrepareAD’ switch should be run in the root domain. This will create a new Administrative group and routing group for Exchange 2007. It will also create the ‘Microsoft Exchange Security Groups’ (for use with Exchange 2007) OU in the root domain.

Before /PrepareAD:

After /PrepareAD:  

4. /PrepareDomain or /PrepareAllDomains

/PrepareDomain can be run for each domain that has an Exchange 2007 server implementation. You can run /PrepareAllDomains to run the tasks automatically on all domains within the forest.

Installing Exchange 2007 ‘Critical Three’ Prerequisites

The following commands can be run from the Windows 2008 command prompt to install all the necessary prerequisites for the three minimum critical Exchange 2007 roles we will be installing for this scenario – Mailbox, Client Access and Hub Transport. For other switches please see the references section at the end of this document.

ServerManagerCmd -i PowerShell

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 RPC-over-HTTP-proxy

Installing Exchange 2007 ‘Critical Three’

From the command prompt run the following command from the Installation media source: /m:install /role:M,H,C /enablelegacyoutlook /legacyroutingserver:MACHESTER

In this example, the legacy Exchange 2003 server is called MACHESTER. You must specify this so that a routing group connector is setup to allow for mail flow between the legacy routing group and the Exchange 2007 routing group that is created for legacy interoperability only.

In this example, I have also supplied the switch /enablelegacyoutlook. This will allow for Outlook 2003 and earlier clients to still use the Exchange organisation. Omit if all clients are Outlook 2007 and above.

Once Exchange 2007 is installed you should use the E2007 EMC or EMS for configuration of organisation wide settings, not the E2003 ESM.

E2003 Recipient Policies –> E2007 Accepted Domains & Email Address Policy

The installation will find entries from the Exchange 2003 Recipient Policies and attempt to import them into Exchange 2007. There are two sections in Exchange 2007 ‘Accepted Domains’ and ‘Email Address Policies’. You should check that you have ALL the accepted domains listed in Exchange 2007 first. You may find you need to create any that have not been imported.

From the Exchange Management Shell run the following:


This will show you all domains on the Exchange 2007 system. If any are missing add them here using New-AcceptedDomain. (see references for commands) or use the EMC –> Organisation Config –> Hub Transport –> Accepted Domains


This will show you the email address policies imported from Exchange 2003. If you get any errors shown here such as:

WARNING: The SMTP address template ‘’ is invalid because it references a domain that is not an accepted domain.

Ensure the domains are listed as an Accepted Domain. This can happen if the domain is not ticked in Exchange 2003 Recipient Policies prior to transition. (ticking the domain tells Exchange 2003 to populate user objects with an SMTP proxy address for the domain).

If you try to open the Email Address Policy using the EMC, you will get a prompt as below:

This is because EAP’s generated from legacy systems need to have their filters upgraded.

Use the EMS command as below:

Get-EmailAddressPolicy | ?{$_.RecipientFilterType -eq “Legacy”} | ft Name,Rec*Type

This command will return the name of all EAP’s that require updating.

You can run the upgrade on all these EAP’s automatically by running the following (note you will no longer be able to manage these using E2003 after running the command):

Get-EmailAddressPolicy | ?{$_.RecipientFilterType -eq “Legacy”} | Set-EmailAddressPolicy -IncludedRecipients AllRecipients

Note: Check that all the domain names you need applied to recipient objects are listed in the email address policy. If you had any that generated errors earlier (added as Accepted Domains), you may need to add them in the Email Address Policy too.

Replicating Public Folders (PF)

There are a few different ways to move the public folders content from the Exchange 2003 server over to Exchange 2007. For the purposes of this document we will use the shell script MoveAllReplicas.ps1. This will move the PF content from Exchange 2003 to Exchange 2007.

Folders that are not created by users and do not hold ‘user created’ content are known as system folders or NON_IPM_SUBTREE data folders. Most importantly, to support Outlook 2003 and earlier clients you will need to replicate the SCHEDULE+ FREE BUSY system folder and the OFFLINE ADDRESS BOOK system folder. Both are public folders and this information will be needed to support legacy Outlook 2003 and older clients.

Note that you should already have the public folder structure (or hierarchy) in the Exchange 2007 database, this replicates automatically. You can check that the folder structure is in place by using the Exchange 2007 Public Folder Management tool (if you have at least SP1 installed) or by using the shell.

Get-PublicFolder \ -recurse | ft Name,Replica

If you see the structure you are good to go with the MoveAllReplicas.ps1 task which will move the data from the Exchange 2003 to the Exchange 2007 server.

From Exchange 2007 EMS:

cd $exscripts

MoveAllReplicas.ps1 -server MACHESTER -newserver THREEROLE

One of the easiest and clearest ways to see the status of the PF replication is to monitor the public folder instances until all are moved over to the Exchange 2007 database. You can see Public Folder Instances for both servers using the Exchange 2003 ESM.

You can also evaluate the current replica list of all NON_IPM_SUBTREE PF’s by using the shell command. Below is the list prior to running the MoveAllReplicas.ps1 command:

Get-PublicFolder \NON_IPM_SUBTREE -recurse  | ft Name,Replicas

Once all the Public Folder Instances have been moved to the Exchange 2007 server, you can dismount the Exchange 2003 public folder and test that users are still able to see Free\Busy info. Once satisfied (and you have a backup of course?!) you can delete the E2003 public folder database using the Exchange 2003 ESM and then follow the prompts to configure existing E2003 mailbox users to use the Exchange 2007 Public folder database.

Move Mailboxes from Exchange 2003 Mailbox Store to Exchange 2007 Mailbox Database

There is a straightforward command to move the legacy mailboxes to Exchange 2007. The Move-Mailbox cmdlet. Run this and specify your tolerance for message corruption etc during the move process.

Get-Mailbox <SERVERNAME> | Move-Mailbox -TargetDatabase <NAME OF TARGET DB> -BaditemLimit <NUMBER> -MaxTreads 10

Note the -Maxthreads which will allow you to move more than the default 4 mailboxes at a time. This is something that is not possible using the Management Console. If used, you can specify the number of mailboxes to move simultaneously.

Confirm the cmdlet and the mailboxes should now move over to the new database. The Move process can also be performed just as easily using the Exchange Management Console if you prefer.

You should find that once the process completes that you have no mailboxes that show as ‘Legacy Mailboxes’, they should all show as ‘User Mailboxes’

E2003 SMTP Connectors  –> E2007 Send Connectors

All the public folders and mailboxes are now hosted on Exchange 2007 so it is time to remove the server from mail transfer responsibilities. At this time, the mail will be flowing from the outside to the Exchange 2003 server and then relayed onto the Exchange 2007 server. We will be looking at having the mail travel directly to the Exchange 2007 server.

Receive Connector

You will need to make sure that the server that will be responsible for accepting internet mail is configured to allow ‘Anonymous users’. By default, it will not accept anonymous connections and therefore cannot be used for accepting internet mail.

To check this using the Exchange Management Shell you can use the following command:

Get-ReceiveConnector | fl Identity,PermissionGroups

If it does not display ‘AnonymousUsers’ for the Default Connector (or another connector you have setup for Internet mail) then you will need to set this. It is generally easier to do this using the console, so drop into the console, and then navigate to Server Config –> Hub transport –> Receive Connector –> Default –> Properties –> Permission Groups –> Select Anonymous users.

You can leave any other group ticked if you still wish to allow for outside authentication or legacy server authentication. This may be a security risk for SPAM attacks so do so with caution. The minimum required to accept inbound mail is ‘Anonymous Users’

Once this is done, you can direct port 25 traffic to the Exchange 2007 server. Test this using your favourite email client or by running a telnet test on port 25 (see

Send Connector

You should ensure that you have a send connector configured for outbound delivery. You can use the Get-SendConnector cmdlet to see if you currently have a send connector configured.

You should get a connector returned which shows that it is responsible for AddressSpaces SMTP:* and Enabled TRUE. If you do not get this then I would advise creating one through the Exchange Management Console. Navigate to Organisation Configuration –> Hub Transport –> Send Connector –> New send connector. Set up a Internet type connector with address space of * and either use DNS if you send directly or use smarthost if you currently use a smarthost for your delivery. You can refer to your current Exchange 2003 SMTP connector to see if you have a smarthost configured, to do so open Exchange System Manager –> Connectors –> SMTP connector – if you see a connector here that relates to outgoing mail or SMTP, then this may be responsible for outgoing mail. Go to properties and the front page will show if you have a Smarthost entry. If you do, you are using a smarthost. If this is blank, go to step 2.

2) Next, check your SMTP bridgehead does not specify a smarthost entry. Open Exchange System Manager -> Servers –> [SERVERNAME] -> Protocols -> SMTP –> Default SMTP virtual server –> Properties –> Delivery –> Advanced –> Smarthost.

If there is an entry here, you are using a smarthost. If it is blank then you are using DNS.

OK, now we have a send connector configured, disable SMTP on the Exchange 2003 server by going to a command prompt and typing:

net stop SMTPSVC

Test if you are able to send an outbound mail to an outside address.

You can now remove the routing group connector that was automatically created to allow mail flow between the two routing groups. To do so use the Remove-RoutingGroupConnector.

Use the Get-RoutingGroupConnector, and you should see routing group connectors responsible for the Exchange 2003 routing group and Exchange 2007 routing group. You can use the following command to remove these connectors from the organisation:

Get-RoutingGroupConnector | Remove-RoutingGroupConnector

De-commission the Exchange 2003 server

You are now in a position to de-commission the Exchange 2003 server. You may wish to leave your Exchange 2003 in place for a period of time to allow your Outlook clients to automatically adjust to the re-homing of their mailboxes. Once you are happy this has taken place you can decommission.

Although Exchange 2007 does not use Recipient Update Services (RUS), you will still need to transfer this to the Exchange 2007 server before you can decommission the server. To do so, navigate to Recipient Update Services and for both entries (Enterprise and the domain) go to properties and select the Exchange 2007 server from the Exchange server browse button.

Now you can use Add Remove Programs (Start –> Run –> appwiz.cpl) to access the Exchange 2003 setup program and remove Exchange 2003 from the organisation completely. Note that you may require the installation media to complete the removal process.

Copyright Shaun Croucher 2010

References – Transition Exchange 2003 – 2007 Guide – OWA issue locale – Preparing AD for Exchange 2007 – Installing Exchange 2007 Prerequisites using shell commands – New-AcceptedDomain cmdlet – EAP and Filter Upgrades – Free\Busy and Availability Info – Move PF Replicas – Move Mailboxes – Telnet test port 25

Posted in Client Access, Global\General, Mailbox\Recipient, Public Folder, Transport | 1 Comment »

Creating a custom DSN \ NDR message and associate with a transport rule in Exchange 2007

Posted by shauncroucher on November 10, 2009

On several occasions just lately I have been asked about how to setup a custom NDR and associate this with a transport rule.

It’s actually quite simple to achieve this using Transport Rules alone, but with the GUI, you only have enough space for a small sentence. That’s not always sufficient for the needs of the Exchange Administrator.

So, a quick how-to on creating a Delivery Status Notification to use as the “Send bounce message to sender with enhanced status code” Transport rule action.

1) You need to first setup a custom DSN using New-SystemMessage. The Custom DSN needs to have a status code  in the range 5.7.10 – 5.7.999

New-SystemMessage -DsnCode 5.7.100 -Language En -Internal $false  -Text “Your longer message goes here”

2) Setup a new Transport rule with the conditions of your liking and then for the transport rule action, don’t worry too much about the text field, as this will be displayed at the bottom of email, it will not form the mail text of the message. It is importan to make sure the Enhanced status code you enter on the rule  matches the custom DSN (in the example 5.7.100) code.

Voila! The End result is that the text found in the custom DSN will show to the user who gets trapped by the Transport Rule.


References: – Associating a DSN Message with a Transport Rule – New-SystemMessage


Posted in Transport | Leave a Comment »

Exchange 2007 allow relay authenticated users or printers or scanners or other device

Posted by shauncroucher on October 29, 2009

The Microsoft Exchange development team have documented the procedure for allowing an internal server to relay through Exchange. I won’t be covering this in any more detail as I believe the article is complete and I wouldn’t be able to add any extra value.

However, I would like to include a couple of useful cmdlet’s that I have used a few times to add specific relay rights for users who authenticate to the receive connector from outside the organisation.

First of all, you need to make sure that the external users have a way of authenticating to the appropriate receive connector. In the ‘Permissions’ tab, ensure Exchange Users is selected and also ensure that the Authentication tab has an authentication mechanism they can use (such as Basic Auth)

Allow authenticated users to relay using

Get-ReceiveConnector “RECEIVECONNECTORID” | Add-ADPermission -User ‘NT AUTHORITY\Authenticated Users’ -ExtendedRights “ms-Exch-SMTP-Accept-Authoritative-Domain-Sender”

Allow authenticated users to relay using

Get-ReceiveConnector “RECEIVECONNECTORID” | Add-ADPermission -User ‘NT
AUTHORITY\Authenticated Users’ -ExtendedRights “ms-Exch-SMTP-Accept-Any-

CAUTION: Make sure you only do this for Authenticated Users and not Anonymous logon, because you can easily turn your server into an Open Relay using these commands with the wrong group.

As always,  make sure you have a good, complex password policy if you are allowing authentication to your Exchange server.


Posted in Transport | 3 Comments »

Basic SMTP Telnet test exchange 2007 send connector send port 25

Posted by shauncroucher on October 26, 2009

This test is designed to TEST ‘outbound’ mail. That is, mail that you are trying to send to external recipients from your organisation. It is important to run this test from the Exchange server if possible to mimick the steps your exchange server goes through as accurately as possible.
Note you cannot use backspace or delete when using telnet, if you make a spelling mistake, start the command again after the error is generated.
Note you should use < > around email addresses as some email servers will not accept email addresses unless they are enclosed in <   >
Step 1

Use to find the MX record of the mail server you wish to test.

So to find the mailserver accepting email  for, type in the MX Lookup box.
make a note of the hostname (or one of the multiple hostnames) returned as we need this for Step 2.
Step 2

Note: If you are using Vista or Windows 2008 telnet is not enabled by default. See this excellent article on petri for details on how to enable Telnt on Vista or Windows 2008.  

Log onto your Exchange server and open up a command prompt.

Type the following:
[Wait for 220 response]
[Wait for 250 response]
[Wait for 250 response]
[Wait for 250 response]

[Wait for 354 response]
This is a test message
(note the dot on its own to end the session)
You should now get a message that the email has been queued for delivery.

Screenshot of how this conversation should look:

Screeshot Telnet Windows SMTP test

Screenshot of a telnet session to a server and submit SMTP message

Posted in Transport | Leave a Comment »

Managing message size limits in Exchange 2007 using powershell

Posted by shauncroucher on October 11, 2009

The lists I have given below show the most common message size limits, however there are some attachment and header limits that the commands may not show you, so follow the links at the bottom of this article for further informationif you still have problems.

NOTE: Always include the qualifier ‘MB’ when using the management shell to specify message size restrictions.

NOTE: is the MASTER reference article for size restrictions for Exchange 2007 and most of the information below is plucked from there. The idea of this article is to extract and simplify some of the commands to get and set the settings.

Global Settings

Scope: RTM Only. Transport setting will change this automatically in SP1

Note: If the values found here and the values found using ‘get-transportconfig | fl M*ze’, the lowest value takes precedence.

Global Settings stored in Active Directory (access using ADSIEdit)
Configuration –> Services –> Microsoft Exchange –> [DOMAINNAME] –> Global Settings –> right client
Message Delivery –>
Check the settings below. They are in KB
msExchRecipLimit (default 5000)
submissionContLength (default 10240) (MaxSendSize)
delivContLength (default 10240) (MaxReceiveSize)

Transport Setting

Scope: Organisational limits for ALL EX2003 / EX2007 servers in the entire organisation.

To show current settings:
get-transportconfig | fl M*ze

To Alter:
Set-TransportConfig -MaxRecipientEnvelopeLimit -MaxReceiveSize MB -MaxSendSize MB

Also check there are no Transport Rules to check the Attachment size of messages.

Connector Limits

Scope: Will affect all messages using the specified connector. Either Send,Receive or Foreign.

To retrieve current settings:

get-ReceiveConnector | ft Id*,M*ze
Get-SendConnector | ft Id*, M*ze
Get-ForeignConnector | ft Id*, M*ze

To Alter:

Set-ReceiveConnector “” -MaxMessageSize MB
Set-SendConnector “” -MaxMessageSize MB
Set-ForeignConnector “” -MaxMessageSize MB

‘Server Specific’ Limits and Outlook Web Access (OWA) limits

Scope: Hub/Edge servers with Transport Rule AND Client Access Servers for the OWA restrictions.

Check there are no transport rules that have ‘server specific’ attachment size over restrictions

CAS servers provide OWA for users to access mail using a web browser. The underlying engine is ASP.NET.

ASP.NET uses the maxRequestLength setting to determine the maximum amount of data that the Web browser can submit to the Client Access server
The setting can be found in the web.config file.

See for instructions on changes needed here.

‘Multiple Sites’ and ‘E2000 \ E2003 Co-Existence’ Settings

Scope: Will affect messages using the site links and the routing group connectors for delivery. The settings themselves
DO NOT affect least-cost routing decisions.

* Note that Exchange 2007 RTM does not support site link or routing group connector size limits and routing loops
may occur if they are set. SP1 and above does support size limits though.

Active Directory site links:

Get-AdSiteLink | ft Name,M*ze
Set-AdSiteLink “Site link name” -MaxMessageSize MB

Routing Group connectors:

Get-RoutingGroupConnector | ft Name,M*ze
Set-RoutingGroupConnector “Name of routing group connector” -MaxMessageSize MB

‘Users and Groups’ Settings

Scope: All the above is for Transport level restrictions, but you need to check the MaxMessageSize setting for the user mailbox/contact and
also the groups they may belong to.

Get-Mailbox “name of mailbox user” | fl M*ze
Get-MailUser “name of user” | fl M*ze
Get-MailContact “name of contact” | fl M*ze
Get-DynamicDistributionGroup “name of dynamic dist” | fl M*ze
Get-DistributionGroup “name of dist” | fl M*ze
Get-MailPublicFolder “name of public folder” | fl M*ze

Manually SET a limit (if ‘unlimited’)

Some exchange administrators have reported that the limits indicate ‘unlimited’ in one or more of these location, and once they change to a value (such as 100MB), the problems disappear. If you are unsure, I would recommend setting a limit rather than leaving as ‘unlimited’.

References: – Exchange 2007 Message Size Limits – Managing Message Size Limits – How to Modify Exchange 2003 Global Message Size Limits in Exchange 2007 RTM – Message Routing in a Coexistence Environment – How to Configure Message Size Limits for Internal Routing – How to Manage Maximum Message Size in Outlook Web Access

Posted in Mailbox\Recipient, Transport | 8 Comments »

Create UC SAN Private CA issued certificate to replace self signed certificate Exchange 2007

Posted by shauncroucher on September 20, 2009

This guide is intended to help you setup your own Certification Authority, and issue a UC certificate for Exchange 2007 testing purposes \ lab environments.

It also uses powershell cmdlets wherever possible, rather than using the Windows 2008 or Exchange 2007 GUI interfaces.

When and why you shouldn’t use this guide

The reason I say this should be used for lab environments is because you really should use a commercial and trusted third party supplier of SSL certificates with Exchange 2007, it will save you a lot of time and aggravation over using a ‘Private CA’ certificate process. The problem with self signed certificates and Private CA issued certificates is that they are NOT TRUSTED by client devices, and so for the devices to use SSL successfully you have to import the SSL certificate or add the CA to the list of ‘trusted root certificates’. This can be achieved using a GPO for domain joined PC’s (this is outside the scope of this document) or you have to manually install the certificate on non-domain devices – PC’s and mobile devices alike.


Windows 2008 Standard

Exchange 2007 (tested to work this SP1 and SP2)

Step 1 – Install the root certification authority role:

You will need to install the server role called ‘Active Directory Certificate Services’.

Go to ‘Server Manager’ –> ‘Add Roles’ wizard –> Choose ‘Active Directory Certificate Services’ –> Next –> Choose ‘Certification Authority’ only (don’t need the other role services) –> Enterprise –> Next –> Root CA –> Next –> Create a new private key –> Keep all defaults here (2048 length / RSA Sha1 key) –> Keep Common Name as default –> Next –> Valid for 5 years should be fine as this is just for testing, change if you wish –> Next, Finish

You should now have a Certification Authority from which you can process certificate requests. Next is on to creating the certificate request for exchange 2007.

Step 2 – Create the UC \ SAN certificate request

I would highly recommend navigating to the Digicert website and making use of their ‘free to use’ tool for creating a Exchange 2007 UCC cmdlet.  (at time of writing this could be found at

All in all you will need to include the ‘fully qualified domain name’ as specified for external access. The server NetBIOS name and distinguished name for internal access PLUS the autodiscover reference (autodiscover is a tool used for automating the configuration of Outlook 2007 clients and providing the URLs necessary for the availability service etc, this is outside the scope of this document).

So, if you wish your external users to access the service using and your internal domain name is domain.local with a server name of ‘server’ then you would want the following as SAN names:



Note: Make sure you include the common name of the certificate as a ‘Subject Alternative Name’ as well. In the example this is

Alternatively you can use the New-ExchangeCertificate cmdlet as below:

New-ExchangeCertificate -GenerateRequest -Path c:\domain.csr -KeySize 2048 -SubjectName “c=GB, s=TheState, l=TheCity, o=TheOrgName, ou=TheDeptName,” -DomainName, server.domain.local, server, -PrivateKeyExportable $True

Note that we are using the -GenerateRequest here which basically tells exchange to create a ‘request’ for a CA to process rather than creating a self-signed certificate. This is an important distinction.

Then we use the ‘certreq’ command to import the request file and generate us a certificate. (Note that you could try this by using the ‘Certification Authority’ directly but will be prompted with an error, because standalone CA’s do not use certificate templates – see For this reason, we can bypass the problem by using either the web enrollment OR the certreq.exe command as below.

certreq.exe -submit -attrib “CertificateTemplate:WebServer” c:\domain.csr.

This will generate a .cer file for us to import into Exchange.

Step 3 – Process the certificate request file

Using the generated .cer, go into Certificate Authority MMC (Start –> Search –> type ‘Certification Authority’) –> Go to issued –> Go to certificate -> Open –> Details –> Copy to file –> Cryptographic message syntax standard -PKCS #7 Include all certificates in the path –> Export –> Export as C:\domain.p7b.

Now with the .p7b you can use this with the Import-ExchangeCertificate and Enable-ExchangeCertificate commands.

Step 4 – Importing the certificate and attaching the relevant services

Open up Exchange management shell and type:


This will show you all the certificates on the system with their associated thumbprint. The thumbprint of the certificate uniquely identifies it. Each certificate will have a unique thumbprint even if all other details are the same.


Import-ExchangeCertificate -Path C:\domain.p7b

Once the certificate has been imported, you can attach the certificate to the relevant services.

The services are as follows:

IMAP – For secure IMAP services

POP – For secure POP services

UM – For Unified messaging

IIS – For autodiscover \ owa \ oab and other web related services

SMTP – For TLS communication

None – To set a certificate to have no associated services.

Use Get-Exchangecertificate command and record the thumbprint for the new certificate. you can right click shell window –> Mark –> Highlight thumbprint –> Hit Enter to place the thumbprint in the clipboard.

Enable-ExchangeCertificate -Thumbprint <your thumbprint> -services IIS, POP, IMAP, SMTP,UM

That is all that is required on the server side. You should now be able to run Get-Exchangecertificate and see all services attached.

Step 5 – Importing the ‘certificate authority’ to client devices

There are a number of ways to install the certificate to devices. The method describes below works for me and should work for you.

On the server –> Go to IE –> Internet Options –> Content –> Certificates –> Go to Trusted Root Certificate Authority –> Export –>

Cryptograpyhic Message Syntax Standard (.P7B) + Include all certificates in the path –> Export.

Then on the computers you need to TRUST the ‘certificate authority’ certificate, simply IMPORT this certificate into Trusted Root Certification

Authority using Internet Explorer Import command (make sure it is imported into Trusted Root Certification Authority when prompted by Import routine).

For mobile devices, copy the file to the Windows Mobile device, and then using the phone, select the certificate file and allow this to import.


After this you should be able to go to the URL for OWA and not get ANY certificate warnings.

You should be able to use Outlook Anywhere without any certificate warnings, and Activesync with SSL should work fine too.

As long as you have created the public DNS record, autodiscover will work too when it returns the https:// URL’s.

Feedback always welcome. Hope you found the article useful.

Based on information found in the following articles: – Active Directory Certificate Services Step-by-Step Guide – Understanding the Self-Signed Certificate in Exchange 2007 – Replacing the Exchange 2007 Self-Signed Certificate – You may receive a “The request contains no certificate template information” error message when you submit a CSR to an enterprise CA”– Enable-ExchangeCertificate

Posted in Client Access, Transport | 6 Comments »