Posts Tagged ‘Exchange 2007’

I’ve been meaning to write this post for a while now but somehow never found the time to do it.

When migrating from SBS2008 to SBS2011 I have come across this issue a number of times now and each time I seem to get caught up in the moment and try to find another way of resolving this issue.

Lot’s of posts about this being a 3rd party connector that has been setup for a photocopier or mail service of some sort etc etc.  None of which is correct.

It’s plain and simple, this is a foreign connector in SBS 2008, and contrary to other posts, it does seem to be there by default, I have checked vanilla SBS 2008 installs and those that have been migrated. I even installed a fresh SBS 2008 in to a virtual machine and it was there too.

This can be confirmed by launching the Exchange Management Shell and running Get-ForeignConnector and if you want more details run Get-ForeignConnector | fl

It’s also part of the Migration guide from SBS 2008 to SBS 2008.

It’s purpose…to receive email addressed to companyweb.  If you check the Exchange Management Console on an SBS 2008 server you will see it listed under Organisation Configuration > Hub Transport > Remote Domains you will see the Windows SBS Company Web Domain.  This is the matching address space.

The purpose…to drop any emails destined for companyweb to a folder ready for pickup by Sharepoint.  By Default this will be C:\Inetpub\mailroot\drop

This functionality is not available in SBS 2011 (or isn’t as far as I can tell) therefore before migration you will need to remove the foreign connector.

To do this, run the following command Remove-ForeignConnector –Identity “Windows SBS Company Web Connector SERVER2008” and then select Y at the confirmation prompt.



Domain Names are a critical part of your Windows Environment.  The DNS (Domain Name System) is a foundation upon which Active Directories and Resources rely upon.  It can be a real problem if you need to go back and change your Domain Name.

So, before building your Windows domain it is important to choose the “correct” domain name.  Wherever possible you need to try and plan ahead, of course you cannot plan for company name changes or, a take over in years to come, because you simply don’t know about them. But….we can plan to be flexible, and we must consider technical and ownership issues at the same time.

Choosing your domain name

Whilst most people believe that the internal windows domain name needs to be something.local this isn’t strictly true.  While it is often easier if the suffix is .local, strictly speaking, it doesn’t have to be.  Let’s consider that point…

Some of the largest enterprises in the world use their external domain name on their internal network.  The most important consideration is that if you use that you actually own

Why is this important? One of the main reasons that this is becoming a problem in recent days is because of 3rd Party SSL Certificates that are used to secure Small Business Server and/or Exchange 2007/2010. One of the default requirements for these systems is using the internal fully qualified domain name of your Exchange Server.

So by way of example let’s say you have an internal domain name of and your external domain name is

When setting up an Exchange 2007/2010 server you would need to request an SSL Certificate that contained the following names:


When you request a certificate with these names in the first thing the Certificate Authority (CA) will do is perform a WHOIS lookup on the names you have requested. Anything will show as your company owning the registration.

However when the CA performs a WHOIS lookup on they find that the registrant of this domain is a different company and therefore send them a request to authorise the name. Worse, if they don’t find a registrant for the domain then it is removed from the certificate request.

Can you see the problem?  If you own then by all means use it in your internal domain name.  If you don’t own it then don’t use it.

This is why most consultants will opt to use the .local suffix on internal domains.  Because when the CA receives a request .local they know it’s not an internet suffix and they will authorise it.

Now what about the dreaded company rename?…..Another common misconception is that when setting up a Windows Domain you must use the domain name for which you want to receive email for.  This is completely untrue.

You can configure Small Business Server and all versions of Microsoft Exchange Server to receive emails for any domain name, regardless of your internal domain name.  So let us now consider calling your internal domain name mydomain.local?

  • It is not linked to a specific company name
  • it will allow you to receive emails for your email domain
  • if you change your company name you don’t need to worry about trying to change the domain name so the new owner (or existing one) doesn’t have to see the old company name day in day out?
  • because it has a .local suffix you will never run in to problems in the future with SSL Certificates


With wider use of SSL certificates and a few common misconceptions created by the industry, it is important to deliberate over your internal domain name selection.  It’s also important to think ahead.

What might be a good idea or even a bit of a laugh now, could come back to bite you in the rear in a few year’s time.  So, be careful and conservative when choosing your name.

I personally like to give my domains something non-descript, because I do a lot of work for small businesses which can and often do get taken over.  I had one company that was bought out twice within the space of 3 years. I also had one company that split in to 2 companies and then both renamed themselves.

It can get messy and especially with Small Business Server where the internal domain name cannot be renamed, it can be impractical to use company specific domain names.

Of course there is always the case where the owner wants this but it’s our job as consultants to advise them why this isn’t a good idea.  And if they still want it then get it in writing 🙂

For purchasing SSL Certificates please visit:

Unlike the latest version of Exchange, 2007 does not have a certificate wizard in the GUI, all the SSL Certificate requests need to be performed and applied via the Microsoft Exchange Shell.

If you are not used to the command line this can be very confusing, even if you are used to the command line this can be fraught with errors in getting the SAN/UCC names correct, adding specific names etc.  Here there is a handy FREE utility that will do all the hard work for you:

The tool will generate SSL requests, create self signed certificates and allow you to fully manage your existing certificates. 

Microsoft have announced the release of Exchange 2007 Rollup 10.

Update Rollup 10 for Exchange Server 2007 SP1 fixes the issues that are described in the following Microsoft Knowledge Base articles:

MS10-024: Vulnerabilities in Microsoft Exchange and Windows SMTP Service could allow denial of service

For full details please see:

This post is going to cover the process involved in specifying a port other than the default port 25 for the Send Connector in Exchange 2007 and 2010

Why would you want to?

Perhaps you have a SPAM or Virus appliance that requires you send it mail on a different port number.  Or your ISP requires that you use a different port when forwarding email to their smarthost.  There are a number of different reasons why you would want to do this, most of them are designed to combat the ever growing SPAM problems.

In previous versions of Exchange this change was fairly straight forward. We would just create a new SMTP Virtual Server and assign it the appropriate port.

With Exchange 2007 & 2010 there is no Graphical User Interface (GUI) to do this for us so we must use the Exchange Management Shell.

We first need to find the identity or name of the send connector.

The name of the Send Connector can be found in the Exchange Management Console under Organisation Configuration > Hub Transport > Send Connectors.  Alternatively you can run the following command in the Exchange Management Shell:

Get-SendConnector | fl

This will display the details of all send connectors.  Look for the line where the identity is specified.  We will need this in the next command.

To make the change to the port number we must run the following command:

Set-SendConnector -Identity “Send Connector Name” -port 28

This command will set the port to 28.

The section of the command identified by the switch -Identity “Send Connector Name” needs to be the name you obtained from the Get-SendConnector command you issued earlier or the Exchange Management Console.

During Exchange 2007 installation, one of the steps that is required is to prepare your existing Active Directory Infrastructure for the Exchange Server installation.  This will need to be done even if you are already using previous versions of Exchange as there are a number of Schema updates required for Exchange to function correctly.

To do this you need to run the following commands: /PrepareLegacyExchangePermissions /PrepareSchema /PrepareAD

One of the processes that these commands performs is the preparation of the required permissions for the Exchange Services in your existing domain.

If these preparatory steps are not performed, then you will see, amongst other errors the “Exchange 2007 error : Process MAD.EXE (PID=1520). Topology discovery failed” this is caused because the Exchange Services don’t have access to the Security log on the domain controllers.

This can very easily be resolved by modifying the Default Domain Controllers Policy.

Using the Group Policy Management Console, locate the Default Domain Controller Policy, right click on the policy and select Edit.

Once you have the Policy Editor open, navigate to Computer Configuration > Windows Settings > Security Settings > Local Policies > User Rights Assignment and locate the Manage auditing and security log setting.

Modify the entry for the groups that have permissions so that the Exchange Server group is included. If you still have Exchange 2003 in your enterprise then you will also need to ensure that Exchange Enterprise Servers is entered here.  The groups should be entered in the format of DOMAIN\Exchange Server and DOMAIN\Exchange Enterprise Servers.

Make sure you use the browse option to find the group as there are no validation checks performed in the user interface, so if the group doesn’t exist or is spelled incorrectly it will still include it.

This issue is not limited to Exchange 2007 and can also be seen in previous and newer versions of Exchange if the preparation tasks are not completed.

For more information on the Exchange preperation tasks please see the following:

Exchange 2003:

Exchange 2007:

Exchange 2010:

One of the most common problems with co-existing Exchange Servers (an organisation consisting of an Exchange 2003 server and an Exchange 2007 or 2010 server) is mailflow between the servers.

When Exchange 2007 or 2010 is installed in an existing Exchange 2003 organisation a Routing Group Connector (RGC) is configured during the installation of the Exchange 2007 / 2010 Exchange server to allow mailflow between the legacy server and the new one.

The way Exchange 2003 servers communicate with other Exchange 2003 servers or Exchange 2007 and 2010 servers is by utilising the Default SMTP Virtual Server.

One of the most common causes of disrupted mailflow is that the Default SMTP Virtual Server has been modified. Either the default port has been changed from the port 25 or a smarthost has been added (Delivery Tab / Advanced Button).

The smarthost configuration in Exchange 2003 should be performed using an SMTP Connector rather than modifying the Default Virtual SMTP Server. The general rule of thumb is to create a new Virtual Server rather than modify the existing one if a different port is required to send to a smarthost or a SPAM/Virus Appliance.

All of these actions can be performed using the Send Connectors in Exchange 2007/2010 so these settings should all be returned to default. This means that the Default SMTP Virtual Server should be using port 25 and should not have a smarthost configured.

Once you have done this mailflow should resume between the different versions of Exchange.


In order to perform a successful migration from Exchange Server 2003 to Google Apps you will require the following:

Once you have signed up for your Premium Google Apps or Education account, the first thing you will need to do is create your user accounts.  This can either be done manually through the control panel by uploading a CSV through the Advanced Tools section.

Once you have created your users there are a few settings that need to be changed in order for the new migration tool to work, these are:

  • Set the Email Migration API (EMAPI) option
  • Enable 2-Legged OAuth

Enabling the Email Migration API (EMAPI) option

This is required to allow the Migration to Exchange tool to access the required API’s so that it will function.  To enable this using the Google Apps Control Panel navigate to Advanced Tools and scroll right to the bottom of the page.  Put a check in the box next to Allow users to upload mail using the Email Migration API. (Administrators always have access to this API.)

Enable 2-Legged OAuth

This is similar to a service account in Exchange that allows you to gain access to all mailboxes using a single login (the administrative account).  To configure this using the Google Apps Control Panel navigate to Advanced Tools and under the section titled Authentication click Manage OAuth domain key.  Put a check in the box labelled Enable this consumer key then click Save Changes.  This will generate an OAuth consumer secret make a note of this because it will be required later.

Performing the Migration

I was shocked at how easy the migration was from Microsoft Exchange 2003 to Google Apps.  It’s as simple as 5 easy steps which I will explain below.

The first step is to create a CSV file of the users that you wish to migrate.  If like me your Google Apps username is the same as your Windows usernames then you simply need to create a file with a list of these usernames.  The same is true if the e-mail addresses are the same, simply create a list of e-mail addresses, 1 per line.

If they usernames or e-mail addresses don’t match then you will need to create a CSV that looks like the following:

user1, google_apps_user1
user2, google_apps_user2
user3, google_apps_user 3

or alternatively,,,

Save the CSV file for reference later.

To start the migration we need to launch the Google Apps Migration tool.  Once you launch the tool click Next on the first screen of pre-requisites and then you will see the screen below.

On this screen you need to enter the NETBIOS name of your Exchange Server and then the SMTP domain you have registered with your Google Apps account.  The SMTP domain may well be the same on your Exchange Server and Google Apps, this is normal in a migration scenario.

Once you have entered the required information click Next.

This screen requires the service account you created earlier, in my case this is the Administrator account.  By default the Administrator user account will not have service account priviledges in Exchange Server 2003.

You will then be required to enter the Consumer key which is normally the domain name you will be migrating to and then the Consumer secret which you would have created in the section above under the heading of Enable 2-Legged OAuth

Once you have entered the required information click Next.

This screen we need to specify the CSV file we created earlier with our list of usernames that will be migrated.  You have an option to select Migrate all data or just new data.

The main reason I can see this being useful is if you want to migrate all the historical data to the new mailboxes on Google Apps, then move the users over to their new mailboxes and then perform another migration for anything that has changed during the cut over period.

Once you have made your choices click Next.

The next screen allows us to specify which data from Exchange will be migrated over to Google Apps.  The Migration tool does seem to perform data moves on all the selected mailboxes at the same time which if you don’t have a lot of bandwidth could cause problems.  If this is the case then the Restrict migration to n users at a time would be a very useful option.  Other than this it’s fairly self-explanatory.

Once you have made your choices click Next.

The next screen simply gives confirmation of what we have already entered, the option to edit these settings and probably more importantly the option to save the settings.  This would be especially useful if you will be performing a migration and then a second to pick up the changes.

When you are ready click Migrate.  This will then start the migration process.

N.B. This process will work with Exchange 2007 running on Windows 2008 & Exchange 2010 only.

You may have reason to send a notification to an external recipient informing them that they have received an e-mail in their internal mailbox.  Why would you want to? There could be a policy in place that prevents forwarding of e-mails or that prevents  the use of mobile devices and you want to alert mobile staff that they need to check their webmail.

To achieve this, you need to do the following:

  • Create a contact with the external email address
  • Create a transport rule that checks messages as they arrive to see if they are sent to the person you want to be notified.  If they are, raise an event in the event viewer.  (I also told the event to use the username of the user in case you wanted to do this for more than one person).
  • Create an on event trigger schedule to send an email to the internal address of the contact you created in step 1

Create contact

Using Exchange Management Console, navigate to User Configuration > Mail Contact and then from the action pane on the right hand side select New Mail Contact. This will start the wizard to create a new contact.

There are 2 options on the first screen.  The first is to create a new contact the second is to mail enable an existing Active Directory Contact.  For this example, we will use the New contact option. Click Next.

Complete the user details, selecting the Active Directory Organisational Unit if required.  Click the Edit button next to Extenal e-mail address and enter the external address you want the notifications to be sent to. Click Next.

The confirmation screen will confirm the information you entered in the previous screen, if you need to change the details click Back, otherwise Click New to create the contact.

Create the Transport Rule

A Transport Rule now needs to be created to raise an event when the Exchange Organisation delivers a message to the mailbox of the user you want notified.

Using Exchange Management Console, navigate to Organisation Configuration > Hub Transport and then from the action pane on the right hand side select New Transport Rule. This will start the wizard to create a new transport rule.

Enter a name for the rule. If you are likely to do this for more than one user then I would suggest entering the mailbox alias or username in the name so that it can be easily identified.  Click Next.

On the condition select the sent to people option in the top box then click the people link in the bottom box and select the internal mailbox you require the notifications for.  Click Next.

On the Actions screen in the top box select log an event with message then in the bottom screen click the message link and enter the message you will have created in the detail screen of the event viewer.  If you will be doing this for more than one user it is important this part is unique. Click Next.

On the Exception screen this is where you would add exceptions to the rule ranging from people sent from, to people/groups sent to.  If you need to add an exception then select one from the list and then click the link created in the bottom box. Click Next.

This screen provides final confirmation of the details entered.  Check the information and if it needs changing click Back and make the required modifications, otherwise  Click New to create the rule.

Create an Event Trigger

In Windows 2008 and Windows 2008 R2 we have the ability to create a scheduled task that runs on a trigger.  One of the triggers available is the On an event trigger.  This is triggered by an event being written to the event logs.

The first thing we need to do in this process is to have an event raised.  Now that the transport rule has been created, send an e-mail to the mailbox you have created the rule for.  This will trigger an event to be raised in the Application log.

Click Start > Administrative Tools > Event Viewer.  Navigate to Windows Logs and then Application log.  There should be an event with an Event ID of 4000 as illustrated below.

Right click on the event in the Application Log list and select Attach task to this event this will start the create task wizard.

Give your task a name and description.  If you will be performing this process for more than one user it is important that the name is unique to make it easy to identify later if you ever need to make changes. Click Next then Click Next on the Event Details page.

On the next screen, the From field must be a valid internal e-mail address (the mailbox doesn’t need to exist) and the To field is the internal e-mail address of the contact you created earlier.

The subject and text fields can be whatever you want them to be.  You also have the option of adding an attachment.  The SMTP Server is the IP address of the Exchange Server that has the Hub Transport role, in my example this was the local server so I have used the loopback address.  Click Next.

The final screen of the wizard is the confirmation of what you have entered on the previous screens.  If you need to make any changes, then press the Back button and make the required changes.

Before clicking Finish check the box that reads “Open the Properties dialog for this task when I click Finish” this will open the event for editing.  Click Finish

Once the task opens on the General tab you need to select the Run whether user is logged on or not.  This will allow the task to run even if no user is logged on to the console.  Select the Triggers tab.  Here you will see the On an Event trigger, highlight this and select properties.  On the following screen check the radio box for Custom and then click the New Event Filter button.

On the New Event Filter dialogue box select the XML tab and paste the code below.  This is where it is important when you created the transport rule to have something unique in the description so that it can be selected here.  This allows you to setup different events for different users.

  <Query Path="Application">
    <Select Path="Application">*[System[Provider[@Name='MSExchange Messaging Policies']]] and *[EventData[Data and (Data="jbloggs")]]</Select>

The majority of the text will stay exactly the same for each event you create for this procedure with the exception of this line: *[EventData[Data and (Data=”jbloggs”)]] this is searching for the text jbloggs in the details of the event log.

Once done click OK on this screen and then OK on the task screen.

This process with then notify an external contact of the receipt of an e-mail in an internal mailbox.