• Standard, which supports a maximum of 5 databases
• Enterprise, which supports a maximum of 100 databases

In many cases the correct license will be installed immediately but in some cases it might be necessary to upgrade to the Enterprise edition. For example when your company buys another company and your Exchange environment will need to host all mailboxes of the employees of the other company which may not fit in your current database anymore. In these cases it might happen that you will reach the maximum of 5 databases which is the maximum of Standard Edition. But is it possible to upgrade to Enterprise in this case?

That was something which I thought was worth trying so I tested it in my lab environment. In the lab environment an Exchange 2010 Server Standard Edition is installed with the maximum of 5 databases. Now I want to add another database which would be the 6th database so this will have as a result that I would need to upgrade to the Enterprise Edition. In the Exchange Management Console you will not find the option anymore to fill in a license key so the only option left is the Exchange Management Shell.

By executing the following command:

set-exchangeserver -productkey 123445-14553-53363-453463

We will tell Exchange to use a new productkey, in this case a productkey for the Enterprise Edition. Just as like upgrading from a trail key to an official key you will need to restart the Information Store service.

Once restarted run the get-exchangeserver cmdlet and you will see you have upgraded from Standard Edition to Enterprise Edition. But is there a way back? No there isn’t. You can only perform an upgrade and not a downgrade. When you try to do this you will receive the following error message:

So don’t change the key before you are 100% sure that’s this is the way to go.

In this case the problem was caused by something else. During the move request a log will be generated and when looking the the log I found the following error:

Warning: Unable to update AD information for the source mailbox at the end of the move.  Error details: An error occurred while updating a user object after the move operation. –> The LdapRecipientFilter “(&(&(&(& (mailnickname=*) (| (&(objectCategory=person)(objectClass=user)(!(homeMDB=*))(!(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=user)(|(homeMDB=*)(msExchHomeServerName=*)))(&(objectCategory=person)(objectClass=contact))(objectCategory=group)(objectCategory=publicFolder)(objectCategory=msExchDynamicDistributionList) )))(objectCategory=user)(vasco-Locked<=sdfasdfsdfasdfasdfasdf)))” on Address List or Email Address Policy “domain.com” is invalid. Additional information: The decimal number ‘sdfasdfsdfasdfasdfasdf’ is invalid or out-of-range. –> The decimal number ‘sdfasdfsdfasdfasdfasdf’ is invalid or out-of-range.

Error details: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f, ec=-2147221233)

As you can see it has some problems updating the AD information for a specific user and to be more specific the problem is caused by the Email Address Policy which has the name domain.com. As the error already tells you there is an issue caused by an invalid value which is configured in the policy.  This policy was created quickly by one of the admins before the migration which was planned in the weekend. Because he don’t want the policy to be applied to the users he provided an invalid value so there would be no match on any user.

So ensure before starting the migration that the Email Address Policies are working correctly and don’t make changes before the migration unless really necessary. In this case we needed to perform two actions to solve the issue:

• remove the mailbox from the specific user
• user must be mail enabled with the correct mail-addresses so it still works in thge co-existence fase

Besides this the policy needs to be corrected or it will need to be removed if it is not necessary anymore.

• not all required Windows Components are installed
• changes have been made in the configuration using IIS

Required Windows Components are missing

The first reason is quite strange as you would expect that the installation of Exchange will check if all required components are in place before starting the installation.

When you forget, for example, the static content item of IIS this may cause the blank screen of OWA. To make it a bit easier you can use the script below to install all required Windows Components on a Windows 2008 server which will become a CAS server:

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

If your planning to use Outlook Anywhere don’t forget to install the RPC over HTTP feature:

ServerManagerCmd -i RPC-over-HTTP-proxy

If all the above components are installed you can start installing Exchange 2007.

OWA virtual directory configuration is corrupted

Making configuration changes using IIS may cause you OWA configuration to be corrupted. So don’t use OWA to make changes but use the Exchange Managment Shell or Exchange Management Console to make configuration changes.

But if you made changes using IIS and OWA does not work anymore how can it be solved? Well there is only one solution, remove the OWA virtual directory and recreate it. This can be done by using the remove-owavirtualdirectory and new-owavirtualdirectory cmdlets.

First step is to remove the old OWA directory:

remove-owavirtualdirectory “owa (Default Web Site)”

This will remove the virtual directory as you can see in the screenshot below:

Once the directory is removed we can create a new one by using the cmdlet below:

new-owavirtualdirectory -OwaVersion “Exchange2007″ -Name “owa (Default Web Site)”

This will recreate the OWA virtual directory and if your lucky OWA will work again. This were just 2 options which might cause this issue. If you got the same issue but the above steps didn’t work contact me so I can add them to this article johan (a) johanveldhuis.nl

The pop3 connector has several options which can be configured, for example the banner which is displayed when making a connection to the server. This message may not be changed very often but when looking at the authentication method or the retrievel settings then you might make some changes to them.

After making the necessary changes you will need to restart the pop3 service, either via the services MMC or via the command net stop MSExchangePop3 followed by net start MSExchangePop3. In an environment where you only have one domain controller this will work. But in an environment where you have multiple domain controllers this might take a while, despite you restarted the pop3 service.

The reason for this? Settings for the pop3 connector are stored in the Active Directory. You can find them in the configuration partition of AD in the following folder:

CN=Services, CN=Microsoft Exchange, CN=Administrative Groups,CN=Exchange Administrative Group  (FYDIBOHF23SPDLT),CN=Servers,CN=CASServer,CN=Protocols,CN=Pop3,CN=1

When you get the properties of the object you will see the settings of the pop3 connector:

So keep in mind that if you change the pop3 settings in an environment with multiple DC’s it might take a while before the changes are applied.

The schema version of Exchange 2007 SP3 is higher than the one from the Exchange 2010 setup. This makes it impossible to install Exchange 2010.

When you have installed Exchange SP3 you will have to wait for a service pack which will extend the schema. Because a lot of people will probably install Exchange 2007 SP3 this may be included in SP1 for Exchange 2010.

Below an overview of the Exchange versions and which schema version they use:

If you would like to know how you can find out which version of AD schema you are using then take a look at the site below:

open

Have fun reading it:

open

(PID 5396, Thread 640) Task New-MoveRequest writing error when processing record of index 0. Error: Microsoft.Exchange.MailboxReplicationService.MailboxReplicationTransientException: Service ‘net.tcp://cas001.lab.local/Microsoft.Exchange.MailboxReplicationService’ encountered an exception. Error: MapiExceptionNetworkError: Unable to make connection to the server. (hr=0×80004005, ec=2423)

Diagnostic context:

Lid: 25922   StoreEc: 0×977      —> Microsoft.Exchange.MailboxReplicationService.MailboxReplicationTransientException: Exception details: MapiExceptionNetworkError (80004005): MapiExceptionNetworkError: Unable to make connection to the server. (hr=0×80004005, ec=2423)

But what is the cause of this error? Well there are multiple causes of this issue. The message MapiExceptionNetworkError tells you that there is a problem connecting to a server. The next question is which server? This can be found on the rule starting with Lid 8856, when looking at the end of the rule you will see the name of the server, in this case EX02.

When looking a little bit further in the log you will see the 0×80004005 error code which might be caused by an authentication problem.

This last option could be easily verified by performing the new-moverequest again and this time with the correct credentials.

But when this does not work which things can cause can you check:

• is the server reachable
• check the firewall settings on both sides
• can you resolve the server on NETBIOS name

I admit the last option is a little bit strange, but in this case caused the issue. On the NIC the default DNS suffixes where registered but not the old one. After adding the old suffix in the TCP/IP configuration the command worked without any issues.

But how does this work? In the OWA directory, which you can find here: Exchange\ClientAccess\OWA, you will find a directory called auth. This directory contains several files which are used for login and logout. But besides these files there are two new files expiredpassword.aspx and exppw.dll.

Before you can use the new functionality you will need to make an adjustment in the registry of the CAS server. Go to the following location in the registry:

HLKM\SYSTEM\CurrentControlSet\Services\MSExchange OWA

Create a new DWORD called ChangeExpiredPasswordEnabled and change the value of the key to 1. This should look the same like below:

During the logon (logon.aspx) a check is done if the password is expired and if this is the case the user will be redirected to expiredpassword.aspx.

Before the user can change his/her password he will first needs to specify the old password. Once the password has change the user will be redirected to his/her mailbox.

I started looking in the event log as, by default, enough information is logged here to see why a move request failed and found the following event:

Mailbox move for ‘xxxxxxxxxxxxxxxxxxxxxx’ (d126705e-af4d-4aca-83c6-0ea443a2ad60) has failed.

SD: O:S-1-5-21-3869603026-3631219241-1903344517-3835G:S-1-5-21-3869603026-3631219241-1903344517-513D:AI(A;OIIO;0x1f0fbf;;;S-1-5-21-3869603026-3631219241-1903344517-3835)(A;CI;0x1fc9ff;;;S-1-5-21-3869603026-3631219241-1903344517-3835)(A;OIIO;0x1208a9;;;S-1-5-21-4230955503-526549450-3057572010-5377)(D;OIIOID;0x1f0716;;;S-1-5-21-3869603026-3631219241-1903344517-2781)(A;CI;0x1208a9;;;S-1-5-21-4230955503-526549450-3057572010-5377)(D;CIID;0xdc916;;;S-1-5-21-3869603026-3631219241-1903344517-2781)

As you can see above it has some problems with the Taken folder. When we had a look at this folder together with the end-user we found out that specific permissions where set in the folders. So we asked if he could remove them on one of the folders to check if that fixed the issue. After the user had done this we were a step further but, as expected, had the same issue with another folder. As it isn’t an option to remove all permissions before migrating the mailbox I decided to contact Microsoft.

After we contacted Microsoft a lot became more clear. During the migration of a mailbox from Exchange 2003 to Exchange 2010 the process will try to regenerate the ACL’s on the Exchange 2010 side. This because Exchange 2010 does use the ACL’s in another way then Exchange 2003. It can happen that the an ACL get’s corrupt which will cause the migration of the mailbox to fail.

The solution: redefine the permissions via Outlook either by removing and adding them again or by changing them to something else and then change them back to the original permissions. Not a really nice solution but you can continue migrating.

Collegue Michel de Rooijave me another tip, try to use PFdavAdmin with this tool it’s possible to fix AC’L's of mailboxes.

Warning: Unable to update AD information for the source mailbox at the end of the move.  Error details: An error occurred while updating a user object after the move operation. –> Failed to find the address type object in Active Directory for address type “SMTP:AMD64″.
Failed to cleanup the source mailbox after the move.
Error details: MapiExceptionNotFound: Unable to delete mailbox. (hr=0x8004010f, ec=-2147221233)

When I looked in the old and new environment I found out that the mailbox both existed in the old and new environment. In this  case you might have a big issue even when the mail is delivered in the Exchange 2003 environment  and the homeMDB attribute is not updated. Updating the attribute may take a while due to AD replication, in this case mail is not delivered in the new mailbox and so mails will not be placed in the new mailbox.

To prevent this issue Microsoft has released a hotfix for Exchange 2003 which can be found on the website below.

open