Master Exchange 2007

powershell, automation & more…

Archive for the ‘cmdlets & scripts’ Category

How to send an email message using Powershell

Posted by shauncroucher on June 3, 2010

Using powershell to send an email using SMTP


A question was posed recently in an online forum asking to fix a script used for sending email using powershell.

It got me thinking about how useful it could be to have  a script build and send an email based on the results of a script.

Note that if you are using powershell v2, there is a built in command called Send-MailMessage which allows you to do this natively without the need for a function. See

For powershell v1, below is a simplified and easy Function you can include in a powershell script to email you. You can call the function at various stages of your script or build a log and send at the end of the script.

Whatever email system you use, it will be important that you have the relevant permissions in place to either submit mail to local recipients or relay to external addresses. If we are talking about Exchange 2007/2010 the easiest way will be to create a Receive connector specifically for the script and set to ‘Externally secured’ and use the source IP to restrict access to it. This will allow trouble free relay. You can set the port to 26 and then amend the script to read $smtpclient.port=26

** Ensure you never allow unauthorised access to an ‘Externally Secured’ receive connector! **

The script function can be placed anywhere in your script, you could place this at the bottom of your scripts if you like:

Function EmailResults

Param ($Subject, $Body)
$message = New-Object Net.Mail.MailMessage
$message.From = “”
$message.Body = $Body
$message.Subject = $Subject

        $smtpclient = New-Object Net.Mail.SmtpClient(“NAME_OR_IP_OF_SMTP_SERVER”)

Now, to call the function and send an email message simply supply the subject and body of the email and then call the function as below:

$Subject = “Subject of the message goes here”
$Body = “Body of the message goes here”
EmailResults $Subject $Body


Posted in cmdlets & scripts | Leave a Comment »

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 »

Default Authentication Settings Exchange 2007 IIS Application & Virtual Directories

Posted by shauncroucher on November 9, 2009

You can find these settings in IIS7. Select each Virtual Directory and then IIS section –> Authentication. Listed are the VD’s that are enabled by default with a vanilla install of Exchange 2007.

Note these settings are from Exchange 2007 Standard SP2 Installation, but should be the correct settings for all versions of Exchange*.


SSL Settings:

All the Virtual directories are set to Require SSL with 128bit except for OAB that DOES NOT require SSL and RpcWithCert which DOES NOT require 128bit (it DOES require SSL though).

* Unchecked on SBS 2008 at this time.


Posted in Client Access | Leave a Comment »

Exchange 2007 and Windows 2008 R2

Posted by shauncroucher on November 5, 2009

Yesterday, Microsoft revealed that they are planning to release an update in the future to support Windows 2008 R2 as a platform to install Exchange 2007.

This is great news for many. Read the blog posting by the Exchange team here:


Posted in Global\General | Leave a Comment »

Exchange 2007 Physical edb database size too large reduce size move mailbox offline defrag

Posted by shauncroucher on November 3, 2009


There is a myth that the only way to deal with an oversized *PHYSICAL* edb file in Exchange 2007 is to run an online and then offline defrag.

This is not true. You can use the Move-Mailbox method on a new database to effecively reduce the size of the database holding your mailboxes. The great thing about this method is that neither an online OR an offline defrag is required, so you can achieve the desired effect on the spot, perhaps after deleting (or Disable-Mailbox’ing) a whole bunch of mailbox enabled users.

Whilst it is true that you will never change the physical size of a database without doing an offline defrag, you can deal with an oversized database by deleting it. Stay with me.

The method is as follows:

1) If you have deleted item retention configured on your Exchange 2007 server inform your users to check their ‘Recover Deleted Items’ using OWA or Outlook. This is the message dumpster location where deleted items get sent when they have been emptied. The items will remain accessible until the retension period has passed. The next step will make the Dumpster unavailable.

2) Create a new Storage Group and Database (you can just create a new database if you prefer, but it’s generally good practice to try keeping 1 database to 1 Storage group.

3) Use the Move-Mailbox cmdlet, or the Move Mailbox management shell facility to move ALL the mailboxes from the original oversized database to the new database.

4) If you are dropping the original database, once all mailboxes have been moved, restart the Microsoft System Attendant to ensure the system mailboxes get recreated

5) Remove the original database files and log files.

Voila. You now have a mailbox database that does not inclue the white space (mailboxes and deleted items in the dumpster) and you will be left with a mailbox database that is smaller than the original.

Note that this process also includes no downtime for the users and no risky offline defrag. Granted, offline defrag will normally run without causing a problem, but because it operates on the database page by page, there is a chance that data loss will occur. It is far far better to use this Move-Mailbox approach.

Move-Mailbox command syntax would be as follows:

Get-MailboxDatabse “Name of Mailbox Database” | Move-Mailbox -TargetDatabase “Name of Target Database” -confirm:$false


Posted in Mailbox\Recipient | 2 Comments »