Showing posts with label Exchange. Show all posts
Showing posts with label Exchange. Show all posts

Tuesday, November 18, 2014

Missing mailbox / Distribution list in Offline Address Book

You might experience this error during an Offline Address Book generation cycle:

Index : 94460
EntryType : Warning
EventID : 9327
Message : OALGen skipped some entries in the offline address list ‘\Global Address List’. To see which entries are affected, event logging for the OAL Generator must be set to at least medium.
- Default Offline Address List
Category : OAL Generator
CategoryNumber : 13
ReplacementStrings : {\Global Address List, Default Offline Address List}
Source : MSExchangeSA

After you set the event log level for the OAL Generator to at least medium, eg. by using this EMS command:
Set-EventLogLevel ‘MSExchangeSA\OAL Generator’ -level Medium
You start seeing these errors:

Index : 94454
EntryType : Error
EventID : 9325
Message : OALGen will skip user entry ‘user1′ in address list ‘\Global Address List’ because the SMTP address ” is invalid.
- Default Offline Address List
Category : OAL Generator
CategoryNumber : 13
ReplacementStrings : {user1, \Global Address List, , Default Offline Address List}
Source : MSExchangeSA

As we can see from the error in the Event Log, OAL Generator claims that the SMTP address ” (blank) is invalid. This is not surprising, as a blank address can not be used for anything.
I have discovered one reason for this error, there might be more. If the user’s primary SMTP address does not match the value in the mail attribute in Active Directory, this error is generated. This happens if you change the primary SMTP address in EMC. EMC does not update the address in the mail attribute. To see if you have any recipients in your organization that have a mismatch between these two values, run these EMS commands:

get-mailbox -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto

get-distributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto

get-dynamicdistributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ft –auto

This should be possible to do with Get-Recipient as well, but I cannot make it work. Get-Recipient always return every recipient in the organization.

To remedy this situation, these EMS commands may be of interest:

get-mailbox -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-Mailbox $_ -WindowsEmailAddress $_.PrimarySMTPAddress }

get-distributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-distributiongroup $_ -WindowsEmailAddress $_.PrimarySMTPAddress}

get-dynamicdistributiongroup -resultsize unlimited | where { $_.WindowsEmailAddress -ne $_.PrimarySmtpAddress } | ForEach { Set-dynamicdistributiongroup $_ -WindowsEmailAddress $_.PrimarySMTPAddress}

You should probably test these commands with the –whatif parameter added to the Set cmdlets.
A good pointer as to which recipients have a mismatch between these values, are those recipients who no longer have their Email addresses updated by a recipient policy. You can quickly list which recipients are in this state:

get-mailbox -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto

get-distributiongroup -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto

get-dynamicdistributiongroup -ResultSize unlimited | where { $_.EmailAddressPolicyEnabled -eq $false } | ft –auto

Also recipients who are targets of E-Mail address policies (EAP), but where those policies have not been applied, are candidates for this error.

Lastly, you cannot set the mail attribute if a recipient is a target of an EAP.
Remember to set the Event Log level back to it’s original value after you have finished troubleshooting:

Set-EventLogLevel ‘MSExchangeSA\OAL Generator’ -level lowest

Tuesday, September 9, 2014

Managing Distribution Groups with hidden membership (when hideDLMembership is true)

There are situations in messaging environments where we want to manage distribution groups through Outlook client and want to ensure that its membership is visible to none but the distribution group owner. In legacy versions of Exchange it was quite straight forward, but Exchange 2010 presents little complexity that can be easily overcome by following a workaround.

Exchange Server 2010

With Exchange Server 2010, things change a little bit. Two aspects that need to be considered - RBAC & Address Book Service.

Let's go by an example.

We have mailbox-enabled users Jeff Oscar , Kevin Pascal, Laura Qunitero, Mike Ruth and Noel Swan on Exchange Server 2010.

We have a distribution group - Escalation Services, Noel Swan being the distribution group owner.

If the distribution group owner has mailbox on Exchange 2010, then even he can’t see the membership details, if hideDLMembership attribute is set to TRUE.

It’s something like below.

In addition, if the owner attempts to modify the membership of the distribution group through Outlook, following message pops up (even though the check box “Manager can update membership list” is selected).

So, for both issues the reason(s) there are couple of different workaround(s).

In Exchange 2010, with the introduction of RBAC, we have to perform some additional steps to ensure that the owner can modify the membership (even with the check box “Manager can update membership list” selected.).

The steps are documented in KB 982349 “Changes to the distribution list membership cannot be saved" error message when you try to remove members from an Exchange Server 2010 distribution list”

Solution 1: If you just want to enable the owner to modify the distribution group membership (with membership hidden for owner as well), then just run following commands - (i) to create a new role group, (ii) add Noels as member, (iii) and verify the membership.

[PS] C:\>New-RoleGroup DistributionGroupManagement -Roles "Distribution Groups"


[PS] C:\>Add-RoleGroupMember DistributionGroupManagement -Member Noels
[PS] C:\>Get-RoleGroupMember DistributionGroupManagement

Noel Swan

Now, the distribution group membership can be modified by the owner via Outlook client (obviously only additions, as s/he can't see the membership).

Solution 2: If you want to enable the owner (a) to view distribution group membership (b) to modify distribution group membership through Outlook client, then just hard code the Outlook client to talk to closest GC, by following the KB 319206 “How to configure Outlook to a specific global catalog server or to the closest global catalog server”.

HKEY_CURRENT_USER\Software\Microsoft\Exchange\Exchange Provider
On the Edit menu, click Add Value, and then add the following registry value:

Value name: DS Server
Data type: REG_SZ (string)
Value data: FQDN of the global catalog server

And, one more interesting aspect that I would like to mention.

If, following conditions are true..
The check box for "Manager can update membership list" in Active Directory Users and Computers is not selected on the Distribution Group property.
Distribution Group owner has been provided appropriate RoleGroupMembership [ RBAC "DistributionGroups"].

[ These will be the most likely situations when the distribution group and distribution group owner are created via Exchange Management Console in Exchange Server 2010 environments.]

Then, the result as observed by Distribution Group owner via Outlook client will be as follows.

Without "DS Server" registry key --

a. Will not be able to see membership in Outlook client.

b. But will be able to add members to the distribution group via Outlook client

With the "DS Server" registry key --

a. Will be able to see membership in Outlook client.

b. But will not be able to remove/add members to the distribution group via Outlook client.

So, the solution -- ensure that the check box "Manager can update membership list" is selected, if you want the distribution group owner to see & modify the membership.

Friday, July 18, 2014

Exchange 2010 Health Check Report

This script is a fast and efficient way of checking if you have any severe issues with your Exchange 2010 setup.
All credits to go to the scripts original author at ExchangeServerPro

All that is need is to download the file from the link above.

The command line in PowerShell to run the script is as follows

Single Server
.\test-ExchangeServerHealth.ps1 -reportmode $true -sendemail $true -server <Exchange Server Name>

Entire Organization
.\test-ExchangeServerHealth.ps1 -reportmode $true -sendemail $true -server *

Servers Starting with perhaps a site with Server Prefixed with "SIN"
.\test-ExchangeServerHealth.ps1 -reportmode $true -sendemail $true -server sin*

The PS script can be downloaded from the link below

The Test-ExchangeServerHealth.ps1 script is run from the Exchange Management Shell. You can use a few builtin parameters to control what it does.
Perform a health check of a single server

Set to $true to generate a HTML report. A default file name
is used if none is specified.

Allows you to specify a different HTML report file name than
the default. Implies -ReportMode

Sends the HTML report via email using the SMTP configuration
within the script. Implies -ReportMode

Only sends the email report if at least one error or warning
was detected.

Writes a log file to help with troubleshooting.
If you use the report mode you’ll get a HTML file containing the health check results, and/or an email to your designated address if you also use the send email option.
For the email functionality to work please update these variables in the script to suit your environment.

# Modify these Email Settings

$smtpsettings = @{
 To =  ""
 From = ""
 Subject = "Exchange Server Health Report - $now"
 SmtpServer = ""

Thursday, April 24, 2014

Mass Import IP for Exchange Receive Connector

There are times when you are required to add many IPs addresses to the receive connector on Exchange 2010. This IPs are required to enable the exchange server to relay emails for alerts etc.
The powershell script below is something that is found from the community that is extremely useful

Copy the below and save it as a ps1 file

Simple Powershell script that can bulk import remote IP ranges from a text file in a determined Exchange Receive Connector.
The Import of the Remote IP ranges maintains the original values which are already present on the Selected Connector.
None - execute directly from the Exchange Management Shell


Exchange 2007
Exchange 2010
Exchange 2013
function Select-FileDialog
param([string]$Title,[string]$Directory,[string]$Filter="Text Files (*.txt)|*.txt")
[System.Reflection.Assembly]::LoadWithPartialName("System.Windows.Forms") | Out-Null
$objForm = New-Object System.Windows.Forms.OpenFileDialog
$objForm.InitialDirectory = $Directory
$objForm.Filter = $Filter
$objForm.Title = $Title
$objForm.ShowHelp = $true
$Show = $objForm.ShowDialog()

if ($Show -eq "OK")
return $objForm.FileName
function get_RecConnector{
$RecConns = Get-ReceiveConnector | Select -ExpandProperty Identity
$Count = 0;
Write-Host "Bulk Import of Remote IP Addresses for Exchange Receive Connectors" -ForegroundColor Green
Write-Host "Version 0.1" -ForegroundColor Green
Write-Host "" -ForegroundColor Green
Write-Host ""
Write-Host "Detected Receive Connectors: " -ForegroundColor Cyan
Write-Host ""
foreach($Connector in $RecConns){

Write-Host $Count "." $Connector -ForegroundColor White
$Count ++

Write-Host ""
$Choice = Read-Host "Please select the Receive Connector that you wish to work with."
Write-Host ""
import_RemoteIPRanges $RecConns[$Choice]
function import_RemoteIPRanges{
$FileName = Select-FileDialog "Open IP Range Text File..."
$IPs = Get-Content $FileName

foreach($IP in $IPs){
Write-Host "Adding IP Address :" $IP " to "$ConnectorID -ForegroundColor Cyan
$Rcnn = Get-ReceiveConnector "$ConnectorID"
$Rcnn.RemoteIPRanges += $IP
Set-ReceiveConnector "$ConnectorID" -RemoteIPRanges $Rcnn.RemoteIPRanges

Write-Host ""
Write-Host "Script Completed." -ForegroundColor Yellow

How to use

Before you use the script you should ensure that you have all of the IP addresses that you wish to add to a particular Receive Connector stored within a text file.

Each host should appear on a separate line. You can also use the CDIR address notation for an entire subnet if you wish to allow all hosts in a range to relay (for example add a line for .

1) Open the Exchange Management Shell, navigate to the directory where you have downloaded the script file and type:

<path>.\<FileName of th3 ps1 file you saved earlier>.ps1

2) You will then be presented with a list of all the detected receive connectors that the script has located. Choose the connector via its numerical identifier (the numbers on the left hand side).

3) You will then be prompted to locate your IP Range text file which you created earlier – browse to it and then click on the “Open” button.

4)The script will then process each host entry and add it to the selected Receive Connector.

5) After the script has completed – if you check the [ Network –> Receive Mail from remote servers that these IP addresses ] in the Exchange Management Console, you should see that your addresses have been added.

Wednesday, April 16, 2014

Tuesday, April 15, 2014

Outlook 2010 Crashes opening meetings

Here's a scenario we recently had reported: Machine running Outlook 2010 installs KB 2553248, and now Outlook crashes when they try to open meetings that were created using Exchange Web Services (EWS).
Here's the few other scenarios where Outlook crashes:

1) Create a Meeting request using EWS and send it to yourself. When you receive it in Outlook 2010 as a No Response Required meeting request, just selecting the meeting request crashes Outlook.
2) Opening the meeting in the Organizer's Calendar crashes Outlook.
3) If the attendee sends an acceptance, selecting the acceptance in the Explorer crashes Outlook.
4) Dismissing reminders crashes Outlook.

The issue is happening because there was a change made in Outlook which caused it to crash when it encounters a Time Zone property on a meeting which does not have a name. If we use MFCMAPI to dump out the properties of a Meeting we can see the problem is with PidLidAppointmentTimeZoneDefinitionStartDisplay.
 Notice that szKeyName is null.

<property tag = "0x80380102" type = "PT_BINARY"> <NamedPropGUID>{00062002-0000-0000-C000-000000000046} = PSETID_Appointment</NamedPropGUID> <NamedPropName>id: 0x825E=33374 = PidLidAppointmentTimeZoneDefinitionStartDisplay, dispidApptTZDefStartDisplay</NamedPropName> <Value>cb: 76 lpb: 000000000000000000000000000000000000000000000000000000000000000000000000000000</Value> <AltValue><![CDATA[............>...A...............ð...........................................]]> </AltValue> <SmartView><![CDATA[Time Zone Definition: bMajorVersion = 0x02 (2) bMinorVersion = 0x01 (1) cbHeader = 0x0006 (6) wReserved = 0x0002 (2) cchKeyName = 0x0000 (0) szKeyName = (null) cRules = 0x0001 (1) TZRule[0x0].bMajorVersion = 0x02 (2) TZRule[0x0].bMinorVersion = 0x01 (1) TZRule[0x0].wReserved = 0x003E (62) TZRule[0x0].wTZRuleFlags = 0x0002 = TZRULE_FLAG_EFFECTIVE_TZREG <Value>04:00:00.000 PM 5/5/2012</Value> <AltValue>Low: 0x1FE4C000 High: 0x01CD2AD8</AltValue> </property>

Fortunately, the fix is now available and included in the June 2012 CU for Office 2010.

If you're running into this issue you have a couple options:
1) Uninstall KB 2553248 (obviously).
2) Fix the Exchange Web Services code so that new meetings that are created do not crash Outlook.

What do I need to do to fix the existing code? The change is simple:

For Exchange Web Services Proxy code, remember to specify the Time Zone Name along with the Base Offset:

DateTime startTime = new DateTime(2012, 05, 05, 8, 00, 00, DateTimeKind.Unspecified); appointment.Start = startTime; appointment.End = startTime.AddHours(4); appointment.StartSpecified = appointment.EndSpecified = true; TimeZoneType tzUSMST = new TimeZoneType(); tzUSMST.TimeZoneName = "Atlantic Standard Time"; tzUSMST.BaseOffset = "PT4H"; appointment.MeetingTimeZone = tzUSMST;
For Exchange Web Services Managed API provide the TimeZone like below:

appointment.StartTimeZone = TimeZoneInfo.FindSystemTimeZoneById("Atlantic Standard Time");

Thursday, September 20, 2012

How to recover user mailbox data from deleted mailboxes using Recovery Storage Group (RSG) in MS Exchange 2003 via

The Recovery Storage Group (RSG) is a feature of Exchange Server 2003. In certain situations it removes the requirement of building up an additional recovery server in order to recover mailbox data (to recover public folder data, the recovery server is still required). However, when we restore the backup into RSG, we are unable to use the ExMerge utility to extract data from the mailboxes that have been deleted from the original mailbox store.

Overview of the Recovery Storage Group
Prior to Exchange Server 2003, if you wanted to recover some mailbox data from the backup, you needed to set up a separate Active Directory (AD) forest on a recovery server and restore the backup into this recovery computer. With the RSG feature, this additional recovery server is not required to recover data from a mailbox store in scenarios where both the following conditions are true:

• The logical information in AD about the storage group and mailboxes remains intact and same as before the recovery. That's to say, the mailbox you want to recover must not be deleted or purged from the system, or moved to another mailbox store.
• You want to recover data from a single mailbox, a single database, or simultaneously a group of databases within a single storage group. The database added into RSG must be from a server within the same Administrative Group; furthermore, after we add a database into RSG, we can then only add databases from the same Storage Group.

After you create a RSG and add databases to it, you can either restore online backup sets or copy offline database files to the RSG (please note that enough disk space is necessary for the recovered database in RSG). Then you can use the Exchange Server 2003 version of the Microsoft Exchange Mailbox Merge Wizard (Exmerge.exe) utility or the Recover Mailbox Data Wizard to extract data from the recovered databases in the RSG to the mailbox in the original regular storage group.

How a Recovery Storage Group links back to the original regular storage group
The RSG uses the following two AD attributes to link back to the original regular storage group:

• The msExchMailboxGUID attribute (see Figure A). When a mailbox is created, this attribute is generated as a unique value that distinguishes it from all other mailboxes. The value remains the same for the lifetime of the mailbox. The ExMerge utility uses this attribute to match the mailbox in the RSG to the one in the original regular storage group. When you delete a mailbox, the mailbox attributes will be removed from the AD user account; when you purge a mailbox that has been deleted, the mailbox (and its GUID) is removed from the database. In these two scenarios, ExMerge will fail to extract data from this mailbox in the RSG.

Figure A: The msExchMailboxGUID attribute

• The msExchOrigMDB attribute (see Figure B). This attribute is set on a database in the RSG. It specifies the distinguished name of the original database where the RSG was created, and it will verify if the mailbox you want to recover is still located in the original mailbox store. If the mailbox has been moved to another mailbox store, ExMerge will fail to extract data from the mailbox.

Figure 2: The msExchOrigMDB attribute

So, what is the problem?
As described above, you will encounter problems when you try to use ExMerge to extract data from mailboxes in the RSG under the following situations:
• The mailbox has been moved to another mailbox store
• The mailbox has been deleted or purged from the system

You may encounter the following error message when you try to use ExMerge to retrieve a list of mailboxes from a RSG:
An error was encountered with one or more users when retrieving the list of mailboxes homed in the selected databases on server 'ServerName'. Please refer to the log file, 'ExMerge.log', for more information.
And from the ExMerge log, you may see the following error:
[14:13:08] Error! Cannot identify the user with the msExchMailboxGuid C\03\96f\5D\B1\3BD\81\99\1F\91C2\5B7. The legacyExchangeDN is /O=ORGNIZATION/OU=SITE/CN=RECIPIENTS/CN=USER.

Problem Resolution
Depending on the scenario, you can use different methods to recover the data:

Scenario 1: The mailbox has been moved to another database
In this scenario, we can use the following two methods to recover the data from the mailbox.
Resolution: Move the mailbox back to the original database or modify the msExchOrigMDB attribute
The most efficient method in this scenario is to move the mailbox back to the original database where the RSG was created. Then ExMerge should work fine to retrieve the mailbox list and to extract the data from RSG.
If you are unable to move the mailbox back for any reason, you can modify the msExchOrigMDB attribute on the RSG database and point it to the database that you moved the mailbox to.

To do this, please follow the steps below:
1. Start the ADSI Edit utility. This is included in the Windows 2000 and 2003
Support Tools: click Start -> Run, type adsiedit.msc and press Enter.
2. Locate the mailbox store that you moved the mailbox to. To do this, expand the
following the containers:
Configuration Container [YourServerName.YourDomainName.YourTopLevelDomain]
CN=Microsoft Exchange
CN=Administrative Groups
and then click CN=YourStorageGroup.
3. In the right pane, right-click the database object and click Properties.
4. Locate the distinguishedName attribute.
5. Right-click the value that is in the "Value(s)" box and click Copy.
6. Click Cancel.
7. Locate and click the RSG database object in the
CN=Configuration,DC=YourDomainName,DC=YourTopLevelDomain container.
8. In the right pane, right-click the RSG database object and click Properties.
9. Locate the msExchOrigMDB attribute.
10. Click Clear.
11. Right-click an empty area of the Edit Attributes box and click Paste.
12. Click Set and click OK.
13. Quit ADSI Edit.

For more information, refer to the following Microsoft TechNet article:
How to Change the msExchOrigMDB Attribute Using ADSI Edit

Scenario 2: The mailbox has been deleted from the database, but not yet purged
Resolution: Reconnect the deleted mailbox to the original or a new user account
When a mailbox is deleted but not yet purged, it becomes an orphaned mailbox in the Exchange server database and is available in the Deleted Mailbox Dumpster (before the retention time expires). Under this situation, you can reconnect the deleted mailbox to the original user account and then recover the data.
If you cannot reconnect the mailbox to the original user (for example, you have created another mailbox and associated it with the original user account), you can just create a new user account (with no mailbox enabled) and then reconnect the orphaned mailbox to this newly-created user. This will work because the msExchOrigMDB attribute does not change on the mailbox even if we associate it with a new user account.

Scenario 3: The mailbox has been purged (permanently deleted) from the database
Resolution: Create a new storage group, or modify the msExchMailboxGuid attribute on a user to point to the mailbox we want to recover data from

If you are running Exchange Server 2003 Enterprise Edition, you can create a new regular storage group and copy the recovered database from RSG to this new storage group. You can then directly extract the mailbox data from the new storage group. For more detailed information see the following Microsoft Knowledge Base article:
You receive an error message when you use the Exmerge tool

However, you cannot use this method on an Exchange Server 2003 Standard Edition because you are limited to one storage group in this edition. In this situation, you can directly modify the msExchMailboxGuid attribute on another mailbox to represent the one you want to recover (according to the principle of the msExchMailboxGuid attribute introduced above).

To do this, please follow the steps below:
1. The GUID shown in ExMerge log is in a different format than the actual
msExchMailboxGuid attribute. So first of all, you need to convert this GUID in
the ExMerge log into a format that contains 16 units with each unit having 2
hexadecimal numerals. Let's take C\03\96f\5D\B1\3BD\81\99\1F\91C2\5B7 as an

i. For units like C\ and 03\, only 1 or 2 characters, leave it as is.
ii. For units like 96f\, 3 characters, split into 2 units: 96 and f.
iii.For units like 91C2\, 4 characters, split into 3 units: 91, C and 2.
iv. Following the rule described above, convert the original GUID into:
C 03 96 f 5D B1 3B D 81 99 1F 91 C 2 5B 7.
v. Then, for each single character, replace it with its ASCII code. So the GUID
is: 43 03 96 66 5D B1 3B 44 81 99 1F 91 43 32 5B 37. (You can visit to check the ASCII code.)

2. Start the AD Users and Computers snap-in, and create a new user with the same name and same organizational unit (OU) as referred to in the ExMerge log.
3. Start the ADSI Edit snap-in: click Start menu -> Run, type adsiedit.msc and
press Enter
4. Expand the Domain container, and expand the OU container which stores the new user (for example, CN=Users).
5. Highlight the newly-created user account in step 2 and open its Properties.
6. Locate the msExchMailboxGuid attribute.
7. Click Clear.
8. Copy the converted GUID: 43 03 96 66 5D B1 3B 44 81 99 1F 91 43 32 5B 37.
9. Right-click an empty area of the Edit Attributes box and click Paste to override with "43 03 96 66 5D B1 3B 44 81 99 1F 91 43 32 5B 37" (without quotation marks).
10. Click Set and click OK.
11. Quit ADSI Edit.
12. Run ExMerge again and connect to the RSG. This time we should see the mailbox
we want to recover. Follow the ExMerge wizard to extract the data.

In Exchange Server 2003, there is a feature called Recovery Storage Group (RSG) which helps you to easily recover data (including messages, mailboxes or an entire database) without building up an extra recovery computer. However, due to the working mechanism of RSG, you cannot directly recover a deleted or purged mailbox. The above is some ways to workaround this limitation

Thursday, August 16, 2012

A meeting update message or a meeting cancellation message from an Exchange 2003 user is not delivered to external attendee

It was brought to my attention that there is a random issue when a user cancels a meeting and some of the attendees are not notified via a cancellation. Upon digging further, the users that are not receiving these cancellation are found to be external users.
Conversation with the IT folks in these users' companies are that their messaging infrastructure is running on Lotus Notes and Exchange 2007.
The issue has been found to be that of the below and the procedures listed can be used to check if the issue is affecting your Exchange 2003 setup.
When sending meeting changes or cancellations to another mail server outside of your exchange 2003 organization messages get stuck in the queue and if the diagnostics logging of the MSExchangeTransport component is set to maximum, the following warning is logged:
Event Type: Warning
Event Source: MSExchangeTransport
Event Category: Exchange Store Driver
Event ID: 327
If an administrator tries to open the message in the Exchange System Manager console, the administrator may receive the following error message:Unable to open for delivery
To verify this is the issue follow these steps on the message that is stuck.
  1. Launch MFCMAPI and select OK. (MFCMAPI can be downloaded from
  2. Choose Session –> Logon –> Display Store Table
  3. Select the proflle used to open the mailbox
  4. In the returned items look for the row that has "Mailbox – <username>" and double click to open the row
  5. In the new "Mailbox – <username>" window expand the Root – Mailbox folder
  6. Expand the IPM_SUBTREE (or the mailbox) folder
  7. Open the calendar folder by double clicking on it.
  8. In the new "Calendar" window navigate to the appointment item (you can sort by Subject by clicking the Subject column)
  9. Right click the appointment item and choose "Display Recipient Table" from the menu
  10. In the recipients table scroll to the right until you can view the column named "PR_RECIPIENT_TRACKSTATUS"
  11. Note the number value for each recipient and this will indicate their tracking status on the item.
  12. If the value is 0 then it means that the tracking status is not available.
The solution
A hotfix is released by Microsoft to correct this issue as the KB below

Friday, March 16, 2012

Missing Outlook Calendar Entries .. X-files???

There will be times that we encounter issues that user reports that certain calendar entries / invites that goes missing.
Usually, we will look into the usual suspects of
1)      - Someone (Perhaps a delegate) change the time
2)      - Blackberry
3)      - Different outlook version used by a manager and delegate

But if nothing is found, it could be another case of X-files
Now here’s the life server, I chanced upon a tool, CalCheck, that was created by one of Microsoft Escalation engineer .
The below is an extract of what this tool will do

Download CalCheck from the Microsoft Download Center.
This utility works with:
§  Microsoft Office Outlook 2003
§  Microsoft Office Outlook 2007
§  Microsoft Office Outlook 2010 (32-bit)
§  Microsoft Office Outlook 2010 (64-bit)
§  Microsoft Exchange Server 2003
§  Microsoft Exchange Server 2007
§  Microsoft Exchange Server 2010
Important: The 64-bit version of this tool is only for use with the 64-bit version of Microsoft Outlook 2010.
The download is a ZIP file - just unzip it in an empty directory, open a command window in that directory, and run it.

What CalCheck does
The Calendar Checking Tool for Outlook (CalCheck) is a command-line program that checks Microsoft Outlook Calendars for problems. The tool opens an Outlook profile to access the Outlook Calendar. It performs various checks, such as permissions, free/busy publishing, delegate configuration, and automatic booking. Then each item in the calendar folder is checked for known problems that can cause unexpected behavior, such as meetings that appear to be missing.
As CalCheck goes through this process, it generates a report that can be used to help diagnose problem items or identify trends.
Checks performed
The following Calendar-specific checks are performed and logged in the report:
§  Permissions on the Calendar
§  Delegates on the Calendar
§  Free/Busy publishing information
§  Direct Booking settings for the Mailbox or Calendar
§  Total number of items in the Calendar folder
The following item-level checks are performed and logged in the report:
§  No Organizer email address
§  No Sender email address
§  No dispidRecurring property (causes an item to not show in the Day/Week/Month view)
§  Time existence of the dispidApptStartWhole and dispidApptEndWhole properties
§  No Subject for meetings that occur in the the future or for recurring meetings (a warning is logged)
§  Message Class check (a warning is logged)
§  dispidApptRecur (recurrence blob) is checked for time on overall start and end times, not for exceptions
§  Check for Conflict items in the Calendar
§  Check for duplicate items, based on certain MAPI properties
§  Check if over 1250 recurring meetings (a warning is logged) and 1300 recurring meetings (an error is reported); 1300 is the limit
§  Check if you are an attendee and you became the Organizer of a meeting
§  Check meeting exception data to ensure it is the correct size
Server Mode
You also have the option to run CalCheck in Server Mode. In Server Mode, CalCheck attempts to open all mailboxes on the Exchange server and perform the checks listed in the "Checks Performed" section of this article. Server Mode generates a CalCheckSvr.log file, which lists the mailboxes that have errors. Additionally, CalCheck generates a separate CalCheck__.log file for each mailbox. This log file shows more mailbox-specific detail.
To use Server Mode, you must use a messaging profile associated with an account that has permissions to all of the mailboxes on the specified Exchange server. To run server mode, use the “-S” command-line switch.
Running to check a single mailbox/calendar:
If you don’t specify a profile on the command line - then you will be prompted to choose a profile as in the above screenshot.
Once you have chosen your profile - the tool will run - and you will see similar output as long as everything is successful:
Looking at this window shows you that there is a CalCheck.log, and where to go and find it. Opening that will show some info like the following:
02/17/2012 05:09:20PM Calendar Checking Tool - Version 1.0
02/17/2012 05:09:20PM ====================================
02/17/2012 05:13:45PM Opening mailbox: Mailbox 02/17/2012 05:13:45PM /O=Org/OU=OU/cn=Recipients/cn=Mailbox
02/17/2012 05:13:45PM Local time zone: Eastern Standard Time 02/17/2012 05:13:45PM Successfully opened the Calendar folder. 02/17/2012
05:13:45PM Processing calendar for Mailbox
02/17/2012 05:13:46PM Successfully located and opened the local free busy message for this mailbox.
02/17/2012 05:13:47PM Publishing 2 month(s) of free/busy data on the server.
02/17/2012 05:13:47PM Resource Scheduling / Automatically accept meeting requests is disabled.
02/17/2012 05:13:47PM ====================================
02/17/2012 05:13:47PM Delegates for this mailbox:
02/17/2012 05:13:47PM ===========================
02/17/2012 05:13:47PM No delegates are set.
02/17/2012 05:13:47PM ===========================
02/17/2012 05:13:47PM Permissions on this Calendar:
02/17/2012 05:13:47PM =============================
02/17/2012 05:13:47PM Default: None
02/17/2012 05:13:47PM Manager: Reviewer
02/17/2012 05:13:47PM Coworker1: None
02/17/2012 05:13:47PM Coworker2: Reviewer
02/17/2012 05:13:47PM Coworker3: Reviewer
02/17/2012 05:13:47PM =============================
02/17/2012 05:13:48PM Found 1404 items in the Calendar. Processing...
02/17/2012 05:13:48PM WARNING: No Subject on this item. You may want to add a Subject to this item.
02/17/2012 05:13:48PM Properties to help investigate this reported item: 02/17/2012 05:13:48PM Subject:
Location: No subject on recurring item
Start Time: 01/11/2011 10:00:00PM
End Time: 01/11/2011 10:30:00PM
Last Modifier: Mailbox
Last Modified Time: 02/04/2011 02:48:08PM
Is a recurring appointment: true
Sender Name: Mailbox
Sender Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox
Organizer Name: Mailbox
Organizer Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox
Recurrence Start: 12:00:00.000 AM 1/11/2011
Recurrence End: 12:00:00.000 AM 2/1/2011
Recurrence End Type: End After X Occurrences
Number of Exceptions: 0x0000

02/17/2012 05:13:50PM ERROR: Detected a duplicate item in the Calendar. Please check this item.
02/17/2012 05:13:50PM Properties to help investigate this reported item:
02/17/2012 05:13:50PM Subject: Doctor appointment
Location: Doctor’s Office
Start Time: 03/04/2012 04:30:00PM
End Time: 03/04/2012 06:00:00PM
Last Modifier: Mailbox
Last Modified Time: 08/01/2011 06:29:05PM
Is a recurring appointment: false
Sender Name: Mailbox
Sender Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox
Organizer Name: Mailbox
Organizer Address: /o=Org/ou=OU/cn=recipients/cn=Mailbox
For problem items that are found - the report gives you information you can use to go and find the problem items so you can remove it, recreate it, or if possible - fix it, etc.
Command Switches - and what they do
CalCheck [-P ] [-M ] [-S ] [-A] [-F] [-R] [-V] [-No] CalCheck -?

-P Profile name (If this parameter is not specified, the tool prompts you for a profile)
-M Mailbox DN (If this parameter is specified, only process the mailbox that is specified)
-S Server name (Process the complete server unless a mailbox is specified)
-A All calendar items are output to CALCHECK.CSV
-F Create a CalCheck folder, and move flagged error items to the folder
-R Put a Report message that contains the CalCheck.log file in the Inbox
-V Verbose output to the Command Prompt window
-No To omit a calendar item test
The No parameter works with "org" to omit the “Attendee becomes Organizer” test and works with "dup" to omit duplicate item detection
-? Print this message
Some additional tips about specific switches:
“-M” You must use the legacyExchangeDN for the mailbox, and the profile you use must be for a mailbox that has permission to open that other mailbox.
“-A” Will create a CSV file that includes all calendar items - one in each row. There will be several properties listed for each item that can be used to look for problems not detected by the tool:
You can view all items in the Calendar by opening the CSV in Excel. You can sort and filter items based on things like start time, subject, recurring items, etc. This can be useful for finding problems that can’t be detected by CalCheck, or that currently aren’t looked for by CalCheck. If you find a problem item in the CSV, you can open the Calendar and put it into Category view to get a similar view of the Calendar in Outlook.
To do this, in Outlook click the View tab, click the Change View drop down, and choose By Category. This will give a view of the Calendar like the following:
This view shows all the items in the Calendar as a list - similar to looking at emails in the Inbox folder. You can sort on things here like Subject, Location, Start, and End. This can be used to find the problem item in the Calendar folder when it is difficult or impossible to find in the normal Calendar view.
“-F” Will create a CalCheck folder in your folder list, and will move items marked as an Error to that folder:
Items can easily be moved back to the Calendar, or can be deleted from here if not needed, or corrected if possible and then placed back in the Calendar. The general rule of thumb would be to recreate the item and delete the item that was moved out to the CalCheck folder.
“-R” Will create a mail message in the Inbox folder with the CalCheck.log file attached to it. This is useful when running the tool in Server mode - as each user will get their report in their Inbox:
“-No” There are two of these: “-No org” and “-No dup”:
The “-No org” will omit the check for the “attendee becomes the organizer of the meeting” check. Part of this check uses the legacyExchangeDN of the mailbox. If the legacyExchangeDN has changed for any reason - like a migration - then this test will give errors for items that may not really be in error. The error that is logged by CalCheck will show both DNs. Here is an example:
12/21/2011 05:27:25PM ERROR: dispidApptStateFlags is 1, but the address for this mailbox does not match the organizer address.
12/21/2011 05:27:25PM Check to ensure the Organizer Address is correct, and whether or not this user should be the organizer.
12/21/2011 05:27:25PM Organizer Address: /o=Org1/ou=admin group 1/cn=recipients/cn=user1
12/21/2011 05:27:25PM DN for this user: /o=Org2/ou=admin group 2/cn=recipients/cn=user1
12/21/2011 05:27:25PM See KB 2563324 for additional information:;EN-US;2563324
12/21/2011 05:27:25PM Properties to help investigate this reported item: 12/21/2011 05:27:25PM Subject: Test
The mailbox here is the same actual mailbox - but because the legacyExchangeDN changed - it is marked as an error.
The “-No dup” will omit the duplicate item detection - as this test creates an in-memory list of items and tests each item against that list. This can slow the process down a bit due to the extra processing and memory usage.
What CalCheck does not do
§  CalCheck is a reporting tool only. It will not automatically modify or “fix” any items. It will move items detected as error items to the CalCheck folder if the “-F” switch is used, but otherwise no changes will be made to any items.
§  CalCheck only works against Calendars located on an Exchange server. It will not work against other servers, such as IMAP or POP3, etc.
§  CalCheck can’t find every kind of corruption that can possibly happen to a Calendar item. However - it can find many known problems that can be knocked out without having to spend time combing through a Calendar and/or contacting a help desk.