I recently experienced an issue when sending e-mails from an Exchange 2003 mailbox to an Exchange 2010 mailbox during a 2003 to 2010 migration. Messages could be successfully sent from Exchange 2010 mailboxes to Exchange 2003 mailboxes but not the other way around, the messages would simply queue on the Exchange 2003 server. After a period of investigation it appeared this issue was occuring due to a smart host not being set against the SMTP connector in the Exchange System Manager on the Exchange 2003 server. To resolve the issue a smart host was configured on the SMTP connector via ESM to be the customers internet service providers upstream mail relay. The steps taken to resolve this issue are detailed below:
1. Connect to your Microsoft Exchange 2003 server and open the Exchange System Manager.
2. In the Exchange System Manager expand Servers -> Server Name -> Connectors.
3. Right click your SMTP connector and select properties.
4. On the general tab check the “Forward all mail through this connector to the following smart hosts” radio button and enter your internet service providers upstream mail relay, for example smtp.myisp.co.uk.
5. Test mail flow between the Exchange 2003 and Exchange 2010 environments.
That’s it, hopefully your migration mail flow issues will now be resolved.
I had a customer inform me over this Christmas period that they were not receiving any inbound e-mail from external sources, even though internal e-mail flow was fine as well as outgoing. I performed a quick inbound e-mail test at testexchangeconnectivity.com to discover that their Exchange 2007 installation on Windows Small Business Server 2008 was producing the following NDR error:
Delivery of the test message failed.
Additional Details: The server returned status code 452 – Insufficient system storage. The server response was: 4.3.1 Insufficient system resources
From looking at the error it can be concluded that this issue was definitely related to system storage. What had actually happened was that free disk space on the Windows system drive had dropped below a 4 Gigabyte threshold and as a result the Exchange Back Pressure feature had disabled inbound e-mail messages, as there was no longer sufficient disk space for the mail submission queue to function. This was further confirmed by reviewing event ID’s 15002 and 15006 in the Windows application event log. As I was struggling to free disk space on the system drive, I decided to move the Exchange Mail Submission Queue database to a separate disk where I had plenty of free resource. To perform this, I carried out the following procedure:
1. On a separate disk volume create a new folder structure, for example, D:\Microsoft Exchange\Queue.
2. Open the Exchange Management Shell and type the following command:
I was recently assisting a colleague with an issue he had experienced with a Microsoft Exchange 2003 to Microsoft Exchange 2010 migration. The migration had completed correctly, however for an unknown reason you could not send e-mail to any mail-enabled public folders, despite whether these were created newley from within the Exchange Management Console or were replicated as a part of the migration. All of the mail-enabled public folder properties were correct, including permissions, and Exchange 2010 Service Pack 1 had also been applied. When e-mailing a mail-enabled public folder from an external network no NDR was produced, however when e-mailing from the internal network the following NDR was returned:
#554 5.2.0 STOREDRV.Deliver.Exception:ObjectNotFoundException; Failed to process message due to a permanent exception with message The Active Directory user wasn’t found. ObjectNotFoundException: The Active Directory user wasn’t found. ##
After performing some research it turned out this is a known problem with Exchange 2010 migrations as detailed here. The issue occurs due to the legacy administrative group (First Administrative Group) being empty following the migration. To resolve this issue perform the following actions:
1. Open ADSI Edit on either a domain controller or your Microsoft Exchange 2010 server.
2. Navigate to the “CN=Servers” ADSI attribute by locating the below path, I have also included a screenshot of the location to help identify the attribute:
3. Right click the “CN=Servers” container and select delete. Click OK when prompted in order to confirm the action. Note: Do not delete the top level container “First Administrative Group”, this is against Microsoft best practices and may have a negative affect on your Exchange organisation.
4. Ensure replication of your Active Directory database has occurred to all domain controllers and then attempt sending an e-mail to one of your mail-enabled public folders. You should now find e-mail makes it way to these folders as expected.
I recently installed my first third party certificate into an Microsoft Exchange 2010 environment. This process is almost identical to how it is performed in Exchange 2007, however the PowerShell commands differ very slightly. Microsoft Exchange 2010 does actually support certificate requests and installations directly through the Exchange Management Console, however I’m not much of a fan of this, it has a slightly clunky feeling to it much like the Small Business Server 2008 implementation of wizard driven certifcate requests and installations.
For this certificate installation I was using a Go Daddy UCC 5 Domain certificate, which is more than adequate for Exchange 2010. You may see Exchange certificates branded as UCC (Unified Communications) or SAN (Subject Alternative Name), these are essentially the same, just different vendors choose to brand them differently. As a rule of thumb, always go for at least a five domain Unified Communications certificate otherwise you will find yourself in a pickle when it comes to adding subject alternative names. The following section of this post details the steps required to generate your CSR and install your certificate into your Exchange 2010 environment.
1. The first step of this process is to generate the CSR that will be used to tell your SSL vendor all about your environment. To make life a little easier, DigiCert have created a web based tool that will compile the required CSR PowerShell command for you, which you can find here.
Hopefully once you have filled out the required fields in the DigiCert tool, you should have something very similar to the below screenshot. Please pay attention to the Subject Alternative Names used and the order that they have been entered in.
Please note that where contoso.com is your public domain name, and where contoso.local is your local domain name. Mail.contoso.com would the public DNS A record that is pointed to your internet endpoint, for example the global IP address of your router or firewall.
2. Once you have filled out of the required fields, click the generate button and then copy the generated PowerShell command to your clipboard. Open the Exchange Management Shell (EMS) on your Exchange 2010 server and paste the copied PowerShell command into the EMS and press return. Once this has completed, navigate to the C:\ drive on your server and open the generated .csr file in notepad. The content of this notepad file is the information you need to submit to your SSL vendor when they request CSR information.
3. When your certificate has been generated, download it from your SSL vendors website onto the root of the Exchange 2010 servers C:\drive. Once this has been performed, we need to action a PowerShell command to both import the new certificate and append this certificate to all Exchange 2010 services. The PowerShell command you need to run is the following:
In the above command, please edit the -Path attribute to read the file location of where you have stored your downloaded certificate.
4. To verify the certificate installation, browse to Outlook Web Access from an external source, so for example to https://mail.mydomain.com/owa and ensure that the correct certificate is being utilised by clicking the padlock icon in Internet Explorer or your preferred browser.
A major part of any Microsoft Exchange transition is the task of moving all public folder content. Sometimes Ive found this to be a migration sticking point, awaiting all of your public folder content to move from one Exchange Organisation to another. One thing I have found that speed’s up the process, are two PowerShell scripts that are supplied “out of the box” with Microsoft Exchange 2010. To benefit from these, perform the following actions:
1. Open the Exchange Management Shell (EMS) and change directory to:
2. The following PowerShell script will add your new Exchange 2010 server as replica on all public folders in your existing public folder database. In the same EMS window you opened in step one, run the following command. Please note, replace the “MyExchange2010Server” entry with the name of your own Exchange 2010 server.
3. Once this command has completed, we can then run a second PowerShell script to initiate the move of all public folder content. To perform this task, in the same EMS window run the following command. Please note, replace the “MyExchange200xServer” and “MyExchange2010Server” entries with the names of your own legacy and Exchange 2010 servers.
Once this command is complete, your public folder content will now start to replicate. You can monitor it’s progress by viewing the “Public Folder Instances” container in Exchange System Manager on Microsoft Exchange 2003 or through the Public Folder Management Console in Microsoft Exchange 2007.
As a note, if you are transitioning to a Microsoft Exchange 2007 organisation, these PowerShell scripts are also available and can be found in the following directory, C:\Program Files\Microsoft\Exchange Server\Scripts.
I was presented with an issue around one month ago that was very interesting. An Exchange 2007 environment where public folders could be seen and used by Outlook clients but could not be viewed in the Public Folder Management Console or be queried through Windows Powershell. This is an extremely poorly documented issue on the internet, and there are many posts on several forums and blogs asking the same question but unfortunately with no resolution. I have found that public folders cannot be viewed in the Public Folder Management Console if one of the following conditions is true.
1. An Exchange 2003 to Exchange 2007 migration has been performed and the public folder hierarchy structure was not moved to the new Exchange organisation.
2. Public folder database corruption has occured and the database has been repaired using ESEUTIL.
If either of these conditions are true, and you cannot view system of default public folders in the Exchange Public Folder Management console you will need to recreate your storage group and public folder database. If you have tried to remove your public folder database following Microsoft TechNet guidelines you will be aware that attempting to remove it’s replica’s using Powershell will not work. To remove the database, perform the following actions:
1. Backup all of your public folders manually. This can be performed by creating a new archive PST on an Outlook client and then copying each public folder to the archive location. In addition, make a note of all e-mail addresses that are associated with mail enabled public folders. This PST will come in handy later if your database has suffered corruption.
2. Open the Exchange Management Console, expand the Organization container and click Mailbox. From the mailbox options, select the Offline Address Book tab, right click the offline address book and select properties. Select the distribution tab and then uncheck “Enable public folder distribution” as shown in the screenshot below. This removes the OAB association with the public folder database we want to delete.
3. In the Exchange Management Console, dismount the public folder database. Navigate to the folder where your database is contained, right click the EDB database file and make a copy of this to an alternate location. If your database is not corrupt, this will come in handy later.
4. Open ADSI Edit, if you are running Windows 2008 this will be pre-installed and can located under the servers Administrative Tools. If you are running Windows 2003 however you will need to download and install the Windows Server 2003 Support Tools from here.
5. In ADSI Edit connect to the configuration Naming Context. When this is displayed expand configuration and navigate to CN=Services -> CN=Microsoft Exchange -> CN=Your Organisation Name -> CN=Administrative Groups -> CN=Exchange Administrative Group (FYDIBOHF23SPDLT) -> CN=Folder Hierarchies. Right click the Folder Hierarchies container and select delete. Click OK to delete all sub objects of this container also. This action removes the heirarchy attribute for the public folder database we want to delete, this attribute will be automatically recreated at later stage.
6. In the same ADSI window, expand CN=Servers -> CN=Your Server Name -> CN=InformationStore. Highlight container CN=Second Storage Group, right click this container and select delete. Click OK to delete all sub objects of this container also.
7. Open the Exchange Management Console and expand the Server container and click Mailbox. You will now notice that your Second Storage Group and Public Folder Database are no longer listed. In the actions pane of the Mailbox window click “New Storage Group” and follow the creation wizard. Once the storage group has been created click “New Public Folder Database” and follow the creation wizard. Please note, if an error occurs during the last step of the wizard relating to mounting the new database, click finish and then manually mount the new database yourself. If your interested you will now see through ADSI Edit that the two containers we deleted earlier have now been recreated.
8. Expand the Organization container and click Mailbox. From the mailbox options, select the Offline Address Book tab, right click the offline address book and select properties. Select the distribution tab and then check “Enable public folder distribution”, in effect the reverse action of step two. If this is not performed any down level Outlook clients, such as 2003, will not be able to utilise the OAB.
9. Now the new database has been created you can attempt to either restore the database you backed up in step 3 or restore the public folders individually from an Outlook client using the PST created in step one. To decide which method you need to use, open the Exchange Management Console, select the Server container and then click Mailbox. Dismount the public folder database, then right click the database and select properties. Place a check next to the ” This database can be overwritten by a restore” option as shown in the screenshot below.
10. Browse to the file location of the new public folder database and then copy the backed up database from step 3 so that the existing database is overwritten. Return to the Exchange Management console and mount the database. If you cannot see public folders in the Public Folder Management Console, your database has suffered corruption. Unfortunately performing integrity, repair and defragment operations through ESEUTIL do not resolve this problem. If the database is corrupt you will need to perform steps 1-9 of this guide again, and then use your PST file to restore the public folders. Please note, if the PST method is used you will need to mail enable any public folders that previously had this functionality again. Public folder permissions however, are kept intact when restoring via PST.
While this is a slightly lengthy process, removing the storage group, database and it’s related Active Directory attributes will resolve this issue.
I’m sure we can all agree that setting global client side mailbox limit’s in Exchange 2007 is a straight forward task to perform. However, I have recently identified on several deployments still running Service Pack 1 that when setting client side limits on a mailbox database, they fail to apply correctly. While this should be a instant change, in some cases the change does not apply at all. To save hours of searching around for a limit you think you might have missed, performing the following will temporarily resolve the issue:
1. Click Start and select Run
2. In the Run dialog box type services.msc
3. In the Services console locate the Microsoft Exchange Information Store service, right click it and select restart. Please note that restarting this service will temporarily dismount your mailbox and public folder databases.
4. Close and reopen Outlook / OWA and the limit warning will no longer be visible.
To completely resolve this issue it is recommended that Exchange Service Pack 2 is applied. I would also recommend applying any outstanding rollup updates, at the time of this entry Rollup Update 4 is the latest release. See below for direct links to these updates.
