Anything for sysadmins!


Event 1007 – MSExchange Mailbox Replication

The Mailbox Replication service was unable to determine the set of active mailbox databases on a mailbox server.<br/>Mailbox server: Exchangeserver.spil.local<br/>Error: MapiExceptionNetworkError: Unable to make admin interface connection to server. (hr=0x80040115, ec=-2147221227)<br/>Diagnostic context:<br/>    ......<br/>    Lid: 15000   dwParam: 0x6BA      Msg: EEInfo: prm[1]: Pointer val: 0x0000000000000000<br/>    Lid: 15000   dwParam: 0x6BA      Msg: EEInfo: prm[2]: Pointer val: 0x985CA8C000000000<br/>    Lid: 16280   dwParam: 0x6BA      Msg: EEInfo: ComputerName: n/a<br/>    Lid: 8600    dwParam: 0x6BA      Msg: EEInfo: ProcessID: 2256<br/>    Lid: 12696   dwParam: 0x6BA      Msg: EEInfo: Generation Time: 2010-09-24 11:32:34:750<br/>    Lid: 10648   dwParam: 0x6BA      Msg: EEInfo: Generating component: 18<br/>    Lid: 14744   dwParam: 0x6BA      Msg: EEInfo: Status: 10060<br/>    Lid: 9624    dwParam: 0x6BA      Msg: EEInfo: Detection location: 318<br/>    Lid: 13720   dwParam: 0x6BA      Msg: EEInfo: Flags: 0<br/>    Lid: 11672   dwParam: 0x6BA      Msg: EEInfo: NumberOfParameters: 0<br/>    Lid: 24060   StoreEc: 0x80040115<br/>    Lid: 23746  <br/>    Lid: 31938   StoreEc: 0x80040115<br/>    Lid: 19650  <br/>    Lid: 27842   StoreEc: 0x80040115<br/>    Lid: 20866  <br/>    Lid: 29058   StoreEc: 0x80040115

This seems to be related to the configuration of the NIC(s) in your Exchange server. I've seen a couple of causes for this problem. Confirm all of them are correct and the issue should be resolved.

  • Using DHCP for one or more NICs. Setting this NIC to static might solve the problem.
  • Setting multiple IP addresses on one NIC. Editing the DNS to only refer to 1 IP instead of both might solve the problem.
  • Having a disabled NIC set to DHCP. Editing the disabled NIC to use static IP might solve the problem.
  • Information Store service is not running. Start the Information Store service.
  • IPv6 is enabled and you're not using it. Disable IPv6.

There are a couple of other possible solutions, but those have not been confirmed to work yet. If you found another possible solution, please comment below!

Interesting read:


Event 2937 – HomeMTA pointing to the Deleted Objects container

Recently I came across the following warning.

 Log Name: Application<br/>Source: MSExchange ADAccess<br/>Date: 23-9-2010 17:06:55<br/>Event ID: 2937<br/>Task Category: Validation<br/>Level: Warning<br/>Keywords: Classic<br/>User: N/A<br/>Computer: exchangeserver.domain.local<br/>Description:<br/>Process powershell.exe (PID=8552). Object [CN=FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042,CN=OU,DC=domain,DC=local]. Property [HomeMTA] is set to value [domain.local/Configuration/Deleted Objects/Microsoft MTA DEL:ceb6fb78-f913-4907-9522-3f2f20e20d1a], it is pointing to the Deleted Objects container in Active Directory. This property should be fixed as soon as possible.<br/>Event Xml:<br/>&lt;Event xmlns=""&gt;<br/>&lt;System&gt;<br/>&lt;Provider Name="MSExchange ADAccess" /&gt;<br/>&lt;EventID Qualifiers="32768"&gt;2937&lt;/EventID&gt;<br/>&lt;Level&gt;3&lt;/Level&gt;<br/>&lt;Task&gt;6&lt;/Task&gt;<br/>&lt;Keywords&gt;0x80000000000000&lt;/Keywords&gt;<br/>&lt;TimeCreated SystemTime="2010-09-23T15:06:55.000000000Z" /&gt;<br/>&lt;EventRecordID&gt;49552&lt;/EventRecordID&gt;<br/>&lt;Channel&gt;Application&lt;/Channel&gt;<br/>&lt;Computer&gt;exchangeserver.domain.local&lt;/Computer&gt;<br/>&lt;Security /&gt;<br/>&lt;/System&gt;<br/>&lt;EventData&gt;<br/>&lt;Data&gt;powershell.exe&lt;/Data&gt;<br/>&lt;Data&gt;8552&lt;/Data&gt;<br/>&lt;Data&gt;CN=FederatedEmail.4c1f4d8b-8179-4148-93bf-00a95fa1e042,CN=OU,DC=domain,DC=local&lt;/Data&gt;<br/>&lt;Data&gt;HomeMTA&lt;/Data&gt;<br/>&lt;Data&gt;domain.local/Configuration/Deleted Objects/Microsoft MTADEL:ceb6fb78-f913-4907-9522-3f2f20e20d1a&lt;/Data&gt;<br/>&lt;/EventData&gt;<br/>&lt;/Event&gt;

The process can be anything related to Exchange. I've seen:

  • MSExchangeMailboxAssistants.exe
  • w3wp.exe
  • Microsoft.Exchange.RpcClientAccess.Service.exe
  • Microsoft.Exchange.ServiceHost.exe
  • ExSetupUI.exe
  • powershell.exe

The object can also change. I've seen:

  • Administrator
  • SystemMailbox.<GUID>
  • FederatedEmail.<GUID>

This probably started because I upgraded Exchange 2010 to SP1. Thanks to Kevin Ca I now know how to correct the issue.

In the Exchange Management Shell do a Get-Mailbox to get the mailbox. Use the -Arbitration switch to get the system mailboxes. Then pipe that to Update-Recipient.

[Powershell]Get-Mailbox Administrator | Update-Recipient[/Powershell]

If you're using the -Arbitration switch you might have to further specify the mailbox. An easy way is:

[Powershell]Get-Mailbox -Arbitration | Where {$_.Name -like "SystemMailbox{E3*" } | Update-Recipient [/Powershell]

Running the Update-Recipient cmdlet on a mailbox reinitializes the HomeMTA value and solves the warning message.


Installing SP1 for Exchange 2010

Just like all the new Microsoft Server installations we start off with the readiness check. During this phase it told me to install several hotfixes. All but one of the hotfixes were downloadable through, but you can use the link in the error message of the readiness check.

Install hotfix Microsoft Knowledge Base article 982867 from
Click here for help...

This computer requires the update described in Microsoft Knowledge Base article 979744 ( Please install the required update to proceed.
Click here for help...

Install hotfix Microsoft Knowledge Base article 983440 from
Click here for help...

This computer requires the update described in Microsoft Knowledge Base article 977020 ( Please install the required update to proceed.
Click here for help...

This computer requires the Microsoft Office 2010 Filter Packs. Please install the software from

After installing these hotfixes and the filter pack I rebooted the server. The readiness check was successful and I was able to start the upgrade.

Depending on the number of languages that need to be installed and the overall system speed your upgrade time might be similar to mine; a whopping 24 minutes (second server took 33 minutes).

I actually had no problems what so ever with the upgrade, although I've read about problem when upgrading to SP1 with Exchange 2010 and TMG installed (this has been patched as of 1 Sep 2010, see interesting reads).

Interesting reads:

Upgrade from Exchange 2010 RTM to Exchange 2010 SP1 -
Exchange 2010 Prerequisites (SP1) -
Exchange 2010 SP1 FAQ and Known Issues -
Problems when installing Exchange 2010 Service Pack 1 on a TMG configured for Mail protection -


Customizing the quota e-mails

Some of you might get comments from users about the Exchange quota e-mails. Not just that the mailbox quota limit is ridiculously low in comparison to Google or any other free e-mail provider, but also about the message being unclear. To solve that Microsoft enabled us admins to set custom text for the quota e-mails. It's not possible to change the sender, quota bar (Exchange 2010) or subject.

To change the message you'll have to create them with the New-SystemMessage cmdlet. The default texts are not accessible with the Get-SystemMessage, but if you want to reset the message back to the default you can use the Set-SystemMessage cmdlet with the -Original switch set to $True. You can use HTML in the text, however I'm not sure if there are any limits as to what HTML tags are allowed.

[Powershell]New-SystemMessage -QuotaMessageType ProhibitSendMailbox -Language EN -Text "Your mailbox can no longer send messages. Please reduce your mailbox size. Use AutoArchive to archive old messages from your mailbox and empty your Deleted Items folder. Contact Office IT if you need help with this." [/Powershell]

The QuotaMessageTypes available are:

  • WarningMailboxUnlimitedSize
  • WarningPublicFolderUnlimitedSize
  • WarningMailbox
  • WarningPublicFolder
  • ProhibitSendMailbox
  • ProhibitPostPublicFolder
  • ProhibitSendReceiveMailBox

Also make sure that you're using the correct Language (EN for english) switch.

Changing a system message can be done by using the Set-SystemMessage. You'll have to use the identity switch to select the system message to change. For the quota messages this is done by putting the language first followed by a backslash and the quota message type (EN\ProhibitSendMailbox).

If you want to get rid of the custom system message you can use the Remove-SystemMessage cmdlet.

Here are some links to help you along with any other questions:


Error sending e-mail to migrated mailbox

During our migration I ran into an error while sending e-mail to a mailbox that was just migrated.

#550 5.2.0 STOREDRV.Deliver: The Microsoft Exchange Information Store service reported an error. The following information should help identify the cause of this error: "MapiExceptionUnconfigured:16.18969:C4000000, 17.27161:0000000094000000000000000000000000000000, 255.23226:00000000, 255.27962:FE000000, 255.17082:1C010480, 0.26937:00000000, 4.21921:1C010480, 255.27962:FA000000, 255.1494:00000000, 255.26426:FE000000, 4.7588:0F010480, 4.6564:0F010480, 0.56333:0B004A66, 4.6372:05000780, 4.6276:05000780, 0.18684:02010480, 4.2199:78040000, 4.2770:05400080, 4.29385:1C010480, 4.8620:1C010480, 255.1750:0F010480, 0.26849:0F010480, 255.21817:1C010480, 0.26297:0F010480, 4.16585:1C010480, 0.32441:0F010480, 4.1706:1C010480, 0.24761:71040000, 4.20665:1C010480, 0.25785:0F010480, 4.29881:1C010480". ##

If the account hasn't properly replicated to all domain controllers, you might get this error. Forcing a replication using the Active Directory Sites and Services fixes the problem. This should trigger automatically, however replication issues might stop or slow this. Running a DCDiag and NETDiag will probably show you some problems.


Send as distribution group

In the Exchange GUI there's no option to provide someone the send-as permission on a distribution group. To do this you'll have fire up the Exchange Management Console.

[Powershell]Add-ADPermission <distribution group> -ExtendedRights Send-As -User <user> -AccessRights ExtendedRight | fl[/Powershell]

User: domain.local\<username>
Identity: domain.local/Distribution Groups/<distribution group>
Deny: False
AccessRights: {ExtendedRight}
ExtendedRights: {Send-As}
IsInherited: False
InheritedObjectType :
InheritanceType: All

You can use the Get-DistributionGroup command to pipe distribution groups to the Add-ADPermission command.

[Powershell]Get-DistributionGroup <distribution group name> | Add-ADPermission -ExtendedRights Send-As -User <user> -AccessRights ExtendedRight | fl[/Powershell]

Note: The settings need to propagate through the Exchange server's cache. This can take up to 2 hours. Until this time when you try to send from the distribution list, you'll get a message back stating that it's not allowed to send as this distribution list. You can force an update by restarting the Information Store, however the mailboxes will be unavailable until the service has restarted.


Migrating a mailbox from Exchange 2007 to Exchange 2010

Moving a mailbox from one forest with Exchange 2007 to a second forest with Exchange 2010 is always scary, even after extensive testing. However you have to do it at some point. Here's what you see at both ends.

Start with the Prepare-MoveRequest.ps1 command:

.\Prepare-MoveRequest.ps1 -Identity &lt;distinguishedname remote user account&gt; -RemoteForestDomainController &lt;remote dc&gt; -RemoteForestCredential $RemoteCredentials -LocalForestDomainController &lt;local dc&gt; -LocalForestCredential $LocalCredentials -LinkedMailUser -TargetMailUserOU &lt;distinguishedname local ou&gt; }

When successful, run the New-MoveRequest command:

New-MoveRequest -Identity &lt;distinguishedname local user account&gt; -RemoteLegacy -RemoteGlobalCatalog &lt;remote dc&gt; -RemoteCredential $RemoteCredentials -TargetDeliveryDomain &lt;domain.local&gt;

This will queue the MoveRequest and if there are no other MoveRequests running, it'll change to InProgress and start moving the data. When it's all done it will show that it's completed.

During the data move the mailbox can remain open. The changes made during the move will be copied afterwards.

After a short while Outlook will presented the user with a dialog: "The Microsoft Exchange administrator has made a change that requires you quit and restart Outlook.". Restart Outlook and see that it's connecting to the new server and forest. Experience shows that it might take a couple of minutes for the connection to the new exchange server to be made.

I've got to say that MS made this process quite unobtrusive! Kudos for that!


Generating a certificate request for Exchange

Certificates are quite important in your Exchange environment. Most of us will have a certificate server that will be used to generate certificates for internal communications. If you have such a server and have to install certificates or renew your certificates, you will have to create a certificate request. To do this you have follow the steps below:

Make sure that you have a list of the alternate URLs that your certificate will be servicing, like: CAS array hostname, AutoDiscover hostname, webmail hostname, common server name, etc.

Do the following for all servers in your farm.

Using the Exchange Management Console

  1. Click on Server Configuration and select a server in the EMC
  2. Click on New Exchange Certificate
  3. Enter a friendly name for your certificate
  4. It's possible to use a wildcard certificate, however I don't recommend this as it loosens the security internally quite a bit!
  5. Check all the options that apply to you. This will generate a list that you'll able to edit later and assign the certificate to services. I've checked the following:
    1. Outlook Web App is on the Intranet
    2. Outlook Web App is on the Internet
    3. Exchange Active Sync is enabled
    4. Exchange Web Services is enabled
    5. Outlook Anywhere is enabled
    6. AutoDiscover is used on the internet (Long URL)
  6. Add all domains on your list in the certificate domains window
  7. Fill out all fields in the Organization and Location window also define a location for the request file

Using the Exchange Management Shell

Edit the following command and execute it in EMS:

New-ExchangeCertificate  -Server 'SERVER1' -FriendlyName 'Your Exchange Certificate Name' -GenerateRequest -PrivateKeyExportable $true -KeySize '2048' -SubjectName 'C=Country code,S="Region",L="City",O="Organization name",OU="Department Name",CN=CAS Array hostname' -DomainName 'server1.domain.local','server2.domain.local',''

You've now generated the certificate request file time to generate the certificate itself.

  1. Go to the URL of your certificate server (http://<servername>/certsrv/) and log in.
  2. Click on Request a certificate
  3. Click on advanced certificate request
  4. Click on Submit a certificate request by using a base-64-encoded CMC or PKCS #10 file, or submit a renewal request by using a base-64-encoded PKCS #7 file
  5. Copy and paste the contents of the request file we generated earlier into the Base-64 encoded certificate request field
  6. Set the certificate template to Web Server (this option might not be available if you're using an account without the appropriate permissions)
  7. Click the submit button to have your request generated.

Download the certificate and import it in Exchange EMS or EMC (Import-ExchangeCertificate). You only have to assign the services to the certificate and you're all done except for testing if it works properly on all services.

Import-ExchangeCertificate -FileData ([Byte[]]$(Get-Content -Path "C:\Path\to\certnew.p7b" -Encoding byte -ReadCount 0)) -FriendlyName "Exchange Certificate Name you've entered with the creation"


Full failover with two Exchange 2010 Servers

Every sysadmin runs into the problem at some time; switching to a newer version of Exchange. Hopefully most of you can migrate to Exchange 2010 within the forest. However sometimes it just makes more sense to setup a new forest with the new version of Exchange, SharePoint, etc. In my case it makes more sense. It takes a lot more work, but in the process I'm able to update all the servers to Windows Server 2008 R2 as well. Having all the servers on the same version of Windows saves me time on management. I'm getting side-tracked! Let's get back to Exchange and the problem at hand: DAG Failover with two Exchange 2010 Servers.

If you haven't read up on the functioning/existence of Database Availability Groups (DAG) and CAS failover of Exchange 2010, you'll probably think that it's a breeze. However that's not the case. The new failover isn't really build on a two server setup. DAG uses Windows' Failover Clustering to provide failover on the Mailbox Database level. This work really well, but comes with one huge disadvantage. Failover Clustering is not compatible with Network Load Balancing (NLB) and NLB is used for failover of the Client Access Server (CAS) role. As an alternative one could use a hardware or software load balancer that load balances TCP/IP traffic, but those don't come cheap, which doesn't really make sense for the smaller shops. But a solution is near!

The solution

After a lot of thinking, discussing and experimenting I came up with a solution. While using the standard Windows Failover Clustering for DAG I can use the Client Access Server Array (


) without NLB for failover of the CAS role. However instead of having NLB switching the active server I'll have to script which server is active. My current default answer for scripting and automation applies here: "Let's PowerShell it!".

First I tried to change the RpcClientAccessServer directly, but that didn't have the right effect. A colleague suggested to use the CAS array and just activate the CAS array IP on the active server. This made a lot of sense as NLB does something similar. So let's go through the steps!

  1. Create a CAS array
    [Powershell]New-ClientAccessArray -Fqdn "name.domain.local" -Site "AD-Site-Name"[/Powershell]
  2. Create the A record in DNS for your newly created CAS array and have it point to an available IP that can be used by both Exchange servers.
  3. Add the CAS array IP on one of the available network adapters of the active server by using the command
    [Powershell]netsh in ip add address "Adapter Name"[/Powershell]

You're not done yet! You can connect an Outlook client to a mailbox. AutoDiscover should now use the CAS array DNS as the connection point. You can check the connection point by right-clicking the Outlook taskbar icon while holding the CTRL button and selecting Connection Status.

If you don't see the right hostname in the server name field, you should check the results of the AutoDiscover. You can use the option Test E-mail AutoConfiguration in the CTRL + right-click menu of Outlook or you can use the website to test you AutoDiscover results. You can use this site to test almost any aspect of your Exchange connectivity. You should get something like the following as a result.

&lt;?xml version="1.0" encoding="utf-8"?&gt;
&lt;Autodiscover xmlns=""&gt;
&lt;Response xmlns=""&gt;


&lt;Server&gt;<span style="background-color: silver;">exchange.domain.local</span>&lt;/Server&gt;
&lt;ServerDN&gt;/o=&lt;domain netbios&gt;/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=<span style="background-color: silver;">exchange.domain.local</span>&lt;/ServerDN&gt;
&lt;MdbDN&gt;/o=&lt;domain netbios&gt;/ou=Exchange Administrative Group (FYDIBOHF23SPDLT)/cn=Configuration/cn=Servers/cn=<span style="background-color: silver;">exchange.domain.local</span>/cn=Microsoft Private MDB&lt;/MdbDN&gt;


The magic script

Time to implement the PowerShell script. The script will take care of the CAS failover by activating the IP on one of the Exchange 2010 servers. The script uses ping to make sure that the other host is still reachable. I've scripted it to check if it can ping the gateway before doing a CAS failover just to make sure that it's not a network-wide issue. It will also check the database copy status (Get-DatabaseCopyStatus) to make sure that the mailbox database has also done its failover to the host running the script.

There are a couple of variables that you need to set in the script before you can run it properly. There should be enough comments in the script to figure it out, otherwise just leave a comment and I'll be sure to answer! You might also want to change the text of the e-mail that is being send in case of failover.

You can download the script here!

There are a couple of settings that you have to edit in the script to customize it for your environment and preferences. I won't go into this any further as it's quite well explained in the script itself. If you do have questions please comment on this post and I'll get back to you as soon as I can.

$Limit = "10" # Ping fails before failover attempt
$Gateway = "&lt;hostname/IP&gt;" # Gateway of this server
$Hostname = "&lt;hostname/IP&gt;" # Hostname of the other Exchange Server
$LocalHostname = "&lt;hostname/IP&gt;" # Hostname of the local Exchange server
$MailTo = "Name &lt;;" # E-mail address where the failover e-mails will be send to
$MailFrom = "Name &lt;;" # E-mail address shown in the from field
$IP = "&lt;IP&gt;" # Failover IP address that will be added to the server (IP of ClientAccessArray FQDN)

Creating the script account

Create a new domain user and add it to the View-Only Organization Management role using the Exchange Control Panel (ECP). You can access the ECP by going to https://<servername>/ecp/. This however doesn't provide it with permissions to allow remote PowerShell. You can grant the permissions by running

Set-User FailMon -RemotePowerShellEnabled $True on the Exchange Management Shell (EMS).

<img alt="" src="" />

Also add the domain user to the local administrators group to give it the appropriate permissions to run the task on the right level.
<h3>Scheduling the script</h3>
To have the task start, you can use the task scheduler. The script can be fired as much as you like, as it will only spawn one instance.

powershell.exe -command "&amp;{C:\Scripts\FailoverMon.ps1}"

Make sure that, while creating the scheduled task, you select an account with the appropriate permissions on your Exchange organization.

I've set my task to trigger (as shown) on startup with a repeat of every 10 minutes.

If you want to know more on how to schedule a PowerShell script, please check here.


When the tasks are scheduled and running on both the servers you can try a failover by shutting down the server which currently has the CAS array IP address. You should see it failover with the DAG and you should also see that the IP address is added to the other server. The client will get a notification on Outlook that the administrator made changes to the configuration and that Outlook need to restart to work properly.


Failback is still a manual process if you want to failback to the previous server. To do so, you'll have to make sure that the previous server is configured with the CAS array IP address and that the DAG indicates that it's healthy. Then it's just a matter of manually removing the CAS array IP address on the server that doesn't need it anymore. Then it'll automatically detect that it's switched servers and the above dialog is again presented to the client. You can use the following command to remove the IP address from the server.

[Powershell]netsh in ip delete address "Adapter Name"[/Powershell]

Edit: Please note that this setup is not supported by Microsoft.
If you still have questions or when it just doesn't work for you, please let me know by commenting on this post.

Update: The script is available again through this link.


Exchange 2010 Remote Powershell

One of the new features of Exchange 2010 is the ability to setup a remote connection to an Exchange 2010 organization without having to install the management tools. However you do have to install the Windows Management Framework Core unless you're on Windows 7 or Windows 2008 R2 where it comes preinstalled. Click here to go to the download page for Windows Management Framework Core.


  • Windows Vista SP1 and higher or Windows 2008 SP1 and higher
  • Windows Management Framework Core which includes:
    • Windows Powershell 2.0
    • WinRM 2.0
  • Permissions to make remote Powershell sessions
  • Exchange 2007 Powershell snapin must be unloaded

To grant remote Powershell session permissions you have to run the following command:

    Set-User -Identity <username> -RemotePowershellEnable $True

To unload the Exchange 2007 Powershell snapin run the following command:

    Remove-PSSnapin Microsoft.Exchange.Management.PowerShell.Admin

Establishing the connection

Let's make a remote connection to our Exchange 2010 organization!

  1. Store the credential in a variable:
    $User = Get-Credential

  2. Store a Powershell session in a variable:
    $Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri "http://<servername>/powershell" -Credential $User
  3. Import the server-side Powershell session to the client side one:
    Import-PSSession $Session

    During this step you'll see a progress bar while the Exchange cmdlets are being imported

You now have a working remote Powershell session with your Exchange 2010 organization!

Closing the connection

When you're done with the session you'll have to remove it. To do so, you can run the following command:

    Remove-PSSession $Session

As you can see, the session has been closed. Don't forget to either exit your local Powershell session or remove the $User variable, as this still has the account stored. If you want to remove the variable, use the following command:

    Remove-Variable User