Category Archives: Exchange Server

Determining free space in Exchange Mailbox Databases using PowerShell

Exchange Mailbox Databases (EDB files) increase in size automatically when required, but they never decrease in size without administrator intervention. Exchange does its best to use up the free space inside the database, the so called white space, but that is not always possible. Because of this you are left with database files that just continue to increase in size as data is added to them, even if a fair amount of free space is available inside the database file. So sometimes you have to take the database offline and manually defragment it using eseutil.exe. By doing this your databases will be defragmented and a new file created which does not have any white space in it. This new file will be automatically moved to the location of your old file that will be deleted. So how do you determine when it is time to defragment your databases, and how do you know how much your files will decrease in size?

The first question is up to you to decide but the second can be easily answered by a PowerShell cmdlet:

Get-EventLog -LogName Application -New 1024 | where { $_.EventID -eq 1221 -and $_.TimeGenerated -ge [DateTime]::Now.AddHours(-24) } | ft TimeGenerated,Message -Wrap -auto

I also have a script that does some formatting of the results, making it easier to export to CSV or XML e.g.

   1: $colResults = @()

   2: $events = Get-EventLog -LogName Application -New 1024 | where { $_.EventID -eq 1221 -and $_.TimeGenerated -ge [DateTime]::Now.AddHours(-24) }

   3: $events | ForEach `

   4: {

   5:  $objEvent = New-Object System.Object

   6:  $objEvent | Add-Member -type NoteProperty -name Date-Time -value $_.TimeGenerated

   7:  $objEvent | Add-Member -type NoteProperty -name Database -value $_.ReplacementStrings[1]

   8:  $objEvent | Add-Member -type NoteProperty -name "Free Space (MB)" -value $_.ReplacementStrings[0]

   9:  $colResults += $objEvent

  10: }

  11: $colResults | Sort-Object Database | ft -autosize

Happy defragmenting!

Exchange 2007 Anti-Spam updates and the Automatic Updates client

Exchange 2007 uses the Windows Operating System Automatic Updates Client as a proxy to download it’s anti-spam signatures and reputation lists. The Exchange component responsible for this is the Microsoft Exchange Anti-spam Update service (witht he somewhat confusing description The Microsoft Forefront Security for Exchange Server anti-spam update service.) This service is referred to in the Exchange documentation as the Microsoft Forefront Security for Exchange Server Anti-spam Update service, again, somewhat misleading. The content retreived by the service is data only, no executable binaries are downloaded.
To configure how Exchange gets it’s updates you use the Enable-Antispamupdates cmdlet. This cmdlet has a parameter called -MicrosoftUpdate which can opt the computer in to Microsoft Update and also set the mode of how updates are retreived. The mode set through this cmdlet applies to all content from MU, not just Anti-spam updates and reputation lists. The frequency of the anti-spam updates, however, are set with the -UpdateMode parameter and applies to anti-spam and reputation data only. The -MicrosoftUpdate parameters takes one of the following values:
  • RequestDisabled This value disables Automatic Update.
  • RequestNotifyDownload Automatic Update notifies you when new updates are ready for download.
  • RequestNotifyInstall Automatic Update downloads updates and notifies you when they are available for installation.
  • RequestScheduled This value sets download and installation of updates according to the configuration of the Automatic Update on the computer.

If you run the Get-AntispamUpdates you may see another value, Configured, for the MicrosoftUpdate parameter; like this:

UpdateMode                  : Disabled
LatestContentFilterVersion  : 3.3.4604.600
SpamSignatureUpdatesEnabled : False
LatestSpamSignatureVersion  : 3.3.4604.600
IPReputationUpdatesEnabled  : False
LatestIPReputationVersion   : 3.3.4604.001
MicrosoftUpdate             : Configured

Configred means that the Windows OS Automatic Updates client was already configured for the computer by other means before the Enable-AntispamUpdates cmdlet was run. In other words, when you set the MicrosoftUpdate parameter, you do not configure the Automatic Updates client schedule if you have already configured the Windows Automatic Updates schedule.

Exchange 2007: MSExchangeIS 9554

I encountered this error in the Application log of an Exchange 2007 server:
EntryType          : Warning
EventID            : 9554
Message            : Unable to update Mailbox SD in the DS. Mailbox Guid: 1d8768d9-cd02-4746-9c16-d6a212b4e5ea. Error Code 0x8004010f
Category           : General
CategoryNumber     : 6
ReplacementStrings : {1d8768d9-cd02-4746-9c16-d6a212b4e5ea, 0x8004010f}
Source             : MSExchangeIS
TimeGenerated      : 09.11.2007 12:23:22
TimeWritten        : 09.11.2007 12:23:22
UserName           :
To find the mailbox causing this error you can use the following Exchange Management Shell command:
Get-MailboxStatistics | where { $_.MailboxGuid -eq ‘1d8768d9-cd02-4746-9c16-d6a212b4e5ea’ } |ft displayname,mailboxguid
Change the GUID in the command to match the code you get in the error.
I love PowerShell!

Slow performance in Outlook Web Access when published through ISA Server 2006

I recently had a strange experience at one of my customers. Suddenly the performance of OWA when accessed through their ISA 2006 server was horrible. Using OWA to read messages was possible, but creating a new message with an attachment was impossible. The operation would hang with the message Uploading you attachments indefinitely. After a looking at all the logs, the ISA policies and the IP settings I checked the speed and duplex settings on the NICs. We had recently switched the NICs in this server to troubleshoot another issue. We switched the Internal NIC for the External NIC, by switching the IP addresses and the cabling. I had evidently forgotten about the speed and duplex settings on the NICs, because the Internal card was now set to 100Mbps/Full Duplex and the Extrenal was set to Auto. The settings should have been switched with the rest of the config. After I set the Internal card to auto and the External card to 100Mbps/full everything started working again. Funny how a setting like this can have such an impact. I thought that once the speed and duplex settings were negotiated with the switch it was no longer relevant. There are known issues with mismatched speed/duplex settings.

Recovering hidden items in ExBPA

The Exchange Best Practices Analyzer is a great tool to check your Exchange setup. You get a lot of excellent guidance about various aspects of Exchange, presented as items of different severity. In the results list of a scan you can select to hide items that you do not want to be alerted about the next time the tool is run. A couple of times I have pressed the wrong choice in that list and subsequently hidden items I wanted to investigate. I could not find a UI to recover those hidden items and that prompted me to try to find out by myself. Turned out it was very easy.

The items you have suppressed are stored in the registry. The path is:


The key is called SuppressionData and has a string data type. All the items you have suppressed are listed in this key and you can recover them by deleting individual ones or all of them. The values are comma separated.

Here is a sample of the data in SuppressionData (data modified for readability):

C:>reg query HKCUSoftwaremicrosoftexchangeexbpa /v SuppressionData


In the ExBPA you can select to hide an item for a particular instance or for all instances. The choices in the UI are “Do not show me this item again for this instance only” and “Do not show me this item again for all instances” respectively. Which choice you make is reflected in the registry by appending the name of the instance you were working with to the name of the item. In the above sample the fDisclaimerWithoutException value will hide the disclaimer exception item for all instances, while the fMaxMsgOutgoingNotSet item is hidden only for the TEST-ORG organization.

After you have manipulated the SuppressionData value in the registry you have to restart ExBPA for the changes to take effect.

Exchange 2007 Autodiscovery and Kerberos

The Exchange 2007 Autodiscover feature is one of the great imporvements in Exchange 2007. Using Autodiscover, clients can automatically configure their email settings. Outlook 2007 uses Autodiscover through Active Directory, searching for a Service Connection Point (SCP) that identifies all the Client Access servers in the organization. The SCP object, in turns, contains the URL that is to be used in contacting the CAS server to retreive the configuration information. The URL points to a virtual directory called Autodiscover in IIS on the CAS server the SCP objet belongs to.
Autodiscover also works outside the organization. Outlook 2007 and Windows Mobile 6 devices are hard-coded to contact either https://autodiscover.<your email domain>/autodiscover or https://<your email domain>/autodiscover.
Sometimes you want to use the same FQDN for the Autodiscover URL both inside and outside of your organization. This is achieved using the Set-ClientAccessServer cmdlet and its AutoDiscoverServiceInternalUri parameter. There is no external Autodiscover URI parameter, because the external URL will always be the same; autodiscover.<your email domain>.
You have to be careful changing the internal name. After Outlook 2007 finds the URL from the SCP in Active Directory it contacts the URL and authenticates to it using your username and password. The authentication method used is Kerberos. If you change your Autodiscover URL to something with a host name different from the host name of the actual CAS server you will not be able to get the configuration information from the Autodiscover service. You will fail with an Access Denied message, because you cannot successfully authenticate. The reason for this is Kerberos.
When using Kerberos authentication you request and receive a series of tickets from Domain Controllers to access a resource. These tickets are bound to the name of the server hosting the services you want to access, through something called a Service Principal Name (SPN). An SPN is comprised of the service being offered, eg. HTTP or HOST, and the name of the server. A computer’s valid SPNs are listed in the servicePrincipalName attribute on it’s computer object in Active Directory.
If you change the FQDN name in the Autodiscover URL Kerberos will grant a ticket with the wrong SPN and you will be denied access. The soultion to this is to use the SETSPN.EXE utility from the Windows Support Tools to add the new names.
Eg. setspn.exe -A HOST/
After doing this you can reset IIS with the iisreset /noforce command and successfully use your new Autodiscover URL.

Yet another (unannounced) Transporter Suite update

A new version of the Transport Suite for Lotus Domino has appeared on the Microsoft download site:
The vesion number is listed as 08.01.0223, and the file size of the transporter.msi file has also changed. Like last time this was not announced and no information exists about what changes have been made.
I am in the middle of a migration project and this is very frustrating. The Trasnporter team should provide updated release notes when htey change their bits. This is the worst version control, or lack thereof, I have ever seen in a professional product.
UPDATE: A recent KB article sheds some light on one of the changes in this newest version of the Transporter Suite. It is a change to fix the problem with foreign language characters not being displayed correctly after a mailbox has been migrated. The KB article is called Foreign characters in e-mail messages are not displayed correctly after you use Microsoft Transporter Suite for Lotus Domino to migrate a mailbox to Exchange Server 2007 and is available here:

Exchange 2007 Edge servers and Microsoft Networking services

I had an interesting experience today. I was setting up an Exchange Edge server for a customer. After configuring the TCP/IP settings I proceeded to the Exchange Management Console to enter the server’s product key. I had already prepared the server earlier, installing Exchange and all required patches. But when I selected Properties on the Edge server this error popped up:

An error happened while accessing registry of the specified server: “<server FQDN>“. The error
message: “The network path was not found.”
It was running the command ‘get-exchangeserver –Status –Identity ‘<Administrative Group GUID>

I thought this was very strange since I was managing the server locally and not over the network. I remembered that Exchange has a history of requiring the Remote Registry service for various management and installation operations, even if you are managing a server locally and installing Exchange from the console. That service was running, so that was not it in this case. But then it struck me, if Exchange requires the Remote Registry service when performing local operations, it follows that it uses the network redirector to access itself, and in turn the server service to communicate with the Remote Registry service. I immediately brought up the configuration settings for my network card and found the cause of the error. Earlier when I had configured the TCP/IP settings I had removed the bindings for Client for Microsoft Networks and File and Printer Sharing for Microsoft Networks. I did that because these services were not needed for a server that was only supposed to communicate using SMTP, LDAP and RDP, or so I thought. After enabling the bindings again the error disappeared and the server is now functioning normally.

It seems strange that Exchange depends on using the Remote Registry service to perform local operations, especially on an edge server where enabled services should be kept at a minimum. I believe that it lets the programmers implement only one way of administering Exchange; through the Remote Registry service. Otherwise they would have to create two interfaces, one for remote admin and one for local.

Update to Microsoft Transporter Suite for Lotus Domino

Evidently the Transporter team has released an updated version of the Microsoft Transporter Suite for Lotus Domino. I can find no updated release notes or any information about any changes. Then only evidence of an update is the size of the installer and the version reported by the management console.

Old version:


New version:


The old Transporter.msi file has a size of 8638 KB and the new one has a size of 8685 KB, in Explorer.

You are not allowed to update your current installation, but rather have to uninstall your old version first. Seems strange to me.

You can download the new version from this link:

Another peach of circumstantial evidence appears on this page; the publishing date is 05.04.2007. The original version of Transporter was released on 15.02.2007 (Valentine’s Day).

Hopefully more info about what has been fixed/updated will be available soon.

Exchange 2007: Unable to log on to Outlook Web Access “A problem occurred while trying to use your mailbox. Please contact technical support for your organization.”

When you try to log on to Outlook Web Access in Exchange 2007 you can successfully enter you username and password, but when you select your language and time zone and press OK you receive this error:


The complete text of the message reads:

Url: https://<fqdn>:443/OWA/lang.owa
User host address:

Exception type: Microsoft.Exchange.Data.Storage.StoragePermanentException
Exception message: There was a problem accessing Active Directory.

Call stack
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostLocally(OwaContext owaContext, OwaIdentity logonIdentity, CultureInfo culture, String timeZoneKeyName, Boolean isOptimized)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchLanguagePostRequest(OwaContext owaContext)
Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.PrepareRequestWithoutSession(OwaContext owaContext, UserContextCookie userContextCookie)Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.InternalDispatchRequest(OwaContext owaContext)Microsoft.Exchange.Clients.Owa.Core.RequestDispatcher.DispatchRequest(OwaContext owaContext)System.Web.HttpApplication.SyncEventExecutionStep.System.Web.HttpApplication.IExecutionStep.Execute()System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)

Inner Exception
Exception type: Microsoft.Exchange.Data.Directory.ADOperationException
Exception message: Active Directory operation failed on apl-dir4.APL-NET.LOC. This error is not retriable. Additional information: Insufficient access rights to perform the operation. Active directory response: 00002098: SecErr: DSID-03150A45, problem 4003 (INSUFF_ACCESS_RIGHTS), data 0

Call stack
Microsoft.Exchange.Data.Directory.ADSession.AnalyzeDirectoryError(PooledLdapConnection connection, DirectoryRequest request, DirectoryException de, Int32& retries, Int32 maxRetries)
Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADRawEntry entry, DirectoryRequest request, ADObjectId originalId)
Microsoft.Exchange.Data.Directory.ADSession.Save(ADObject instanceToSave, IEnumerable`1 properties)

Inner Exception
Exception type: System.DirectoryServices.Protocols.DirectoryOperationException
Exception message: The user has insufficient access rights.

Call stack
System.DirectoryServices.Protocols.LdapConnection.ConstructResponse(Int32 messageId, LdapOperation operation, ResultAll resultType, TimeSpan requestTimeOut, Boolean exceptionOnTimeOut)
System.DirectoryServices.Protocols.LdapConnection.SendRequest(DirectoryRequest request, TimeSpan requestTimeout)
Microsoft.Exchange.Data.Directory.PooledLdapConnection.SendRequest(DirectoryRequest request, LdapOperation ldapOperation)
Microsoft.Exchange.Data.Directory.ADSession.ExecuteModificationRequest(ADRawEntry entry, DirectoryRequest request, ADObjectId originalId)


This error is caused by incorrect permissions on the user object in Active Directory.


Enable inheritance of permissions on the user’s object. This is done in Active Directory Users and Computers, on the advanced tab of the user object. Select the checkbox “Allow inheritable permissions from the parent to propagate to this object and all child objects. Include these with entries explicitly defined here.”

More info

The option to inherit permissions from parent objects will be removed if the user object is, or has ever been, a member of one of the protected groups in Active Directory. These groups include Administrators, Account Operators, Server Operators, Print Operators, Backup Operators, Domain Admins, Schema Admins, Enterprise Admins and Cert Publishers.

More info here:

XADM: Do Not Assign Mailboxes to Administrative Accounts