We started investigating the rights delegated for the Help Desk Associate and found that the Associate indeed has all the required rights to unlock user accounts as specified in the KB article

http://support.microsoft.com/kb/279723.

Just delegating the user with appropriate permission should help here correct? Well, it did not in this case.  Our research led us to the following KB article that explains the issue and the need for a Hotfix to resolve the issue.

Unlocking a user account fails when using ADAC or the Unlock-AD Account cmdlet in Windows 7 or Windows Server 2008 R2 even if sufficient permissions are granted

http://support.microsoft.com/kb/2577917

As indicated in the KB Article, the issue is due to fact that ADAC and Unlock-AD Account cmdlet require permissions to the UserAccountControl but the delegated rights were assigned to the lockout Time attribute.

Prior to Windows Server 2008 R2, Active Directory Users & Computers (ADUC) is used to unlock an account In the Account Properties window as shown below:

You will notice from the screenshots below of the attributes using PowerShell, that when using ADUC, the attribute lockout Time is changed, but the UserAccountControl is left unchanged.

Attributes when the User Account was locked:

Attributes when the User Account was unlocked using ADUC: 

The KB article also provides the workarounds to either use ADUC or grant additional permissions to the user account to use ADAC or Unlock-AD Account. If you considering the later, it is important to understand that it provides extra permissions in addition to unlock Account. The KB 305144 provides details on how UserAccountControl attribute can be used to manipulate other user account properties.

Not familiar with the Calendar Repair Assistant you say? A good place to start is here. In a nutshell, the Calendar Repair Assistant (CRA for short) runs within the Microsoft Exchange Mailbox Assistant service and is designed to repair calendar inconsistencies between organizers and attendees. As of Exchange 2010 SP1 the CRA is throttle based and performs the following four step process:

1. Detects inconsistencies The CRA uses the organizer's copy of the calendar item as a master copy for all meeting items. The assistant compares the attendee's calendar item with the organizer's calendar item for inconsistencies. The only exception to this rule is when the assistant compares the attendee's and organizer's response status. The assistant assumes that the attendee's response status is the correct one, and, if necessary, updates the organizer's tracking information.

2. Determines if inconsistencies were intentional If an inconsistency is detected, the CRA determines whether the attendee intentionally introduced the inconsistency. For example, an attendee can introduce an inconsistency by deleting the meeting request and not notifying the organizer. If the assistant determines that the attendee didn't introduce the inconsistency, it corrects the problem. If the assistant can't determine if the inconsistency was intentional, it performs no further action.

3. Corrects inconsistencies The CRA corrects inconsistencies on the Mailbox server on which it runs. However, if the organizer's mailbox is on a different server than the attendee's mailbox, the assistant reads from other Exchange 2010 Mailbox servers to compare the calendar items. The assistant doesn't overwrite the recipient's calendar information. Instead, it merges the information so data isn't lost. In addition, the repair update messages are moved to the recipient's Deleted Items folder.

4. Sends a calendar repair update message if a correction was made Calendar repair update messages are sent to users whose calendar items were updated by the CRA. Instead of sending the message to the user's Inbox, the assistant sends the message to the user's Deleted Items folder. By doing so, a record of the repair is kept in the mailbox without causing user confusion. If the user is experiencing calendar inconsistencies, you can advise the user to look in the Deleted Items folder for troubleshooting purposes. The assistant only sends repair update messages if the issue is fixed.

Now let’s return to the customer in question. In theory the CRA should have compared the attendees calendar, found that there was an inconsistency, determined that it was not intentional, and then placed the item on the attendee’s calendar and then sent an email into the attendee’s deleted items folder with a notification that the change has been made.

Our first troubleshooting step was to look in the deleted items folder for the notification that an item was repaired. Nothing was there. Following that we ran the following Exchange Management Shell command to verify that the CRA had not been disabled for that user Get-mailbox username | fl CalendarRepairDisabled the output from that command is below.

So we could see here that the CRA was enabled for the user in question.

Next we decided to look at the CRA logs to see if it logged the event at all. By default you can find the CRA log files <Exchange installation path>\v14\Logging\Calendar Repair Assistant. In our case there were no log files at all in this location!

At this point I asked the customer if they had made any changes to the CRA. They said they had not, so we ran the following command via the Exchange Management Shell Get-mailboxserver severname | FL *calendar*. The output is below.

You can see above the default settings for the CRA. The CalendarRepairMissingItemFixDisabled was set to False so they had not disabled the CRA, and the default logging location had not been changed so it appeared that they had not made any changes. I then noticed the top three entries. I expected the CalendarRepairSchedule to be {} since the CRA now is throttle based and does not run on a schedule, however the first two entries CalendarRepairWorkCycle, and CalendarRepairWorkingCycleCheckpoint should not be empty if the CRA is running as expected.

The CalendarRepairWorkCycle parameter specifies the time span in which all mailboxes on the specified server will be scanned by the CRA. For example, if you specify seven days for this parameter, the CRA will process all mailboxes on this server every seven days.

Calendars that have inconsistencies will be flagged and repaired according to the interval specified by the CalendarRepairWorkCycleCheckpoint parameter. For example, if you specify one day for this parameter, the CRA will query every day for new mailboxes that require processing.

As an example if the WorkCycle is set to seven days, and the WorkCycleCheckpoint is set to one day, the CRA will process all mailboxes on the server every seven days, and every day it will repair any calendar items it has flagged in its current queue as needing repair.

In this customer’s example both values were blank meaning that the CRA was not running at all. After further investigation, we found that even though the CRA is enabled by default for all mailboxes on a particular mailbox server, it is NOT running by default. So in this case we ran the following Exchange Management Shell command on EACH mailbox server Set-MailboxServer –Identity servername –CalendarRepairWorkCycle 7.00:00:00 –CalendarRepairWorkCycleCheckpoint 1.00:00:00.

When the CRA is working properly and an item is repaired, you will see entries like this in the CRA logs.

In the above example you can see the steps that the CRA takes in validating the calendar item, comparing the items on the attendee’s calendar to the organizer’s calendar, and then deciding whether it should be fixed or not, and then the confirmation that it has sent the fix to the attendee’s calendar.

From the attendee’s point of view, they will receive a message similar to the below example in their Deleted Items folder. It also places the item back on the attendee’s calendar as “tentative”.

If you would like more information regarding Exchange 2010, Calendaring best practices, and other topics related to Exchange 2010 PFE offers many workshops, chalk talks, and other services that can address your needs. Talk to your technical account manager for more details. In the meantime, go back to your Exchange organization, double check your Exchange Calendar Repair Assistant, and make sure you are getting the functionality you expect from it.

As an Exchange administrator, you need to know what tools are available, where to find them, what they do and when you should use them. Without knowing what’s available and where to find them, the rest doesn’t matter. With this in mind, we wanted to create a post listing common Exchange tools important to an Exchange administrator with links for an easy way to get them when you need them.

One thing I like to have my customers do is to have a core set of tools that we include in the Exchange Server build process. This allows us to have them available whenever we need them. Without doing this, we sometimes have to go through management approval or change control procedures depending on the companies processes. You probably know what it’s like waiting for these to happen while you’ve got a task you’re trying to complete. While you’re looking through this list, I’d encourage you to come up with a list of core tools that you include in future server deployments.

The link for most of the tools is a link to Bing.com with the first result being a download link at the time of publishing this post. We decided to do this instead of direct links to avoid linking to an older version or outdated site as updates become available.

Here’s the list.

Tool	Notes
Bginfo	Generates customized desktop background images.
CalCheck	Checks for known issues in Outlook calendar items.
Error Code Lookup (err.exe)	Lookup numerical error codes from many different products.
Exchange 2010 Server Deployment Assistant	Takes input about your environment and generates customized instructions you can use to upgrade to Exchange 2010.
Exchange 2010 Visio Stencil	Exchange Viso shaps.
Exchange Client Network Bandwidth Calculator	Helps predict bandwidth requirements for a specific set of clients.
Exchange Mailbox Server Role Requirements Calculator	Excel spreadsheet used when planning mailbox server design.
ExFolders (previously PFDavAdmin)	Access public folder and mailbox information. Ability to import and export.
ExLogAnalyzer	Analyze message tracking logs
ExMON	See near real time information about resources individual users are consuming.
ExPDA	Performs and overall readiness scan of your environment prior to an Exchange 2010 deployment.
ExPerfWiz	PowerShell script that automates the creation of performance monitor collection settings.
ExRCA (Remote Connectivity Analyzer)	Test Exchange connectivity from the internet. Tests Autodiscover, ActiveSync and more.
Log Parser	Powerful command line tool to parse text based logs (like IIS logs) and other types of logs.
Log Parser Studio	GUI for Log Parser that has useful log parser queries built in and allows easy creation and management of queries.
MAPI Editor (MFCMapi)	Tool to access mailboxes and see things Outlook doesn’t.
Microsoft Active Directory Topology Diagrammer	Create a diagram of AD and includes Exchange objects.
Network Monitor	Captures network traffic for analysis
OAB Integ	Checks for issues that may cause OAB generation problems.
OABValidate	Checks OAB files and Active Directory information to check for potential OAB related problems.
Outlook Configuration Analyzer Tool	Analyzes an Outlook profile looking for common configuration issues.
PAL	Automatic analysis of performance monitor log files and outputs a HTML report.
Performance and Threshold Counters for Exchange Server 2010	List of performance monitor counters and thresholds. Useful if an automatic monitoring system is not being used.
PortQryUI	Checks TCP & UDP port availability.
Process Explorer	Shows information about which handles and DLLs processes have opened or loaded.
Process Monitor	Collects information about running processes. Shows file system access, registry access and process/thread activity.
Process Tracking Log (PTL) tool	Analyze message tracking logs to look for situations like message loops and other issues.
PST Capture	Used to discover and import PST files.

There you have it! We hope you find this useful. If you have tools you think would be valuable to add to the list, let us know.

If you want to get some personal exposure to most of these tools and learn about when you would use them, we have a one day Chalk Talk available that covers tools and troubleshooting scenarios. Check with your Technical Account Manager for more information.

The complete details of the Microsoft Support Lifecycle can be found at http://support.microsoft.com/lifecycle/. The different phases of the Support Lifecycle are shown below.

We wanted to provide you with some of the updates related to Exchange and Outlook support that can help you plan for Messaging Services Life Cycle. The complete list can be found at http://support.microsoft.com/lifecycle/search/

The key takeaways that we want you to be aware of are:

Microsoft Exchange Server 2003 support ends on April 8, 2014.

Microsoft Exchange Server 2007 moved from Mainstream Support to Extended Support on April 10, 2012. The final update rollup release under standard support for Exchange 2007 is Update Rollup 7 for Exchange 2007 Service Pack 3

Microsoft Exchange Server 2010 Service Pack 1 support will end on January 8, 2013. Customers should upgrade to the latest service pack and update rollup

Microsoft Office 2007 Enterprise, Professional, Professional Plus and Standard move from Mainstream Support to Extended Support on October 9, 2012

Microsoft Windows Vista Business, Business N and Enterprise moved from Mainstream Support to Extended Support on April 10, 2012

Microsoft Windows XP Support ends on April 8, 2014.  Custom Support will be available for customers who need additional time to migrate to a supported product

Exchange 2010

Products Released	General Availability Date	Mainstream Support End Date	Extended Support End Date	Service Pack Support End Date
Exchange Server 2010 Enterprise	11/9/2009	1/13/2015	1/14/2020	10/11/2011
Exchange Server 2010 Service Pack 1	8/23/2010	Not Applicable	Not Applicable	1/8/2013
Exchange Server 2010 Service Pack 2	11/28/2011	Review Note	Review Note
Exchange Server 2010 Standard	11/9/2009	1/13/2015	1/14/2020	10/11/2011

Exchange 2007

Products Released	General Availability Date	Mainstream Support End Date	Extended Support End Date	Service Pack Support End Date
Exchange Server 2007 Enterprise Edition	3/8/2007	4/10/2012	4/11/2017	1/13/2009
Exchange Server 2007 Service Pack 1	11/29/2007	Not Applicable	Not Applicable	10/12/2010
Exchange Server 2007 Service Pack 2	8/24/2009	Not Applicable	Not Applicable	7/12/2011
Exchange Server 2007 Service Pack 3	6/7/2010	Review Note	Review Note
Exchange Server 2007 Standard Edition	3/8/2007	4/10/2012	4/11/2017	1/13/2009

Exchange 2003

Products Released	General Availability Date	Mainstream Support End Date	Extended Support End Date	Service Pack Support End Date
Exchange Server 2003 Enterprise Edition	9/28/2003	4/14/2009	4/8/2014	5/25/2005
Exchange Server 2003 Service Pack 1	5/25/2004	Not Applicable	Not Applicable	1/8/2008
Exchange Server 2003 Service Pack 2	10/19/2005	Review Note	Review Note
Exchange Server 2003 Standard Edition	9/28/2003	4/14/2009	4/8/2014	5/25/2005

Office 2007

Products Released	General Availability Date	Mainstream Support End Date	Extended Support End Date	Service Pack Support End Date
2007 Microsoft Office Suite Service Pack 1	12/11/2007	Not Applicable	Not Applicable	7/13/2010
2007 Microsoft Office Suite Service Pack 2	4/28/2009	Not Applicable	Not Applicable	1/8/2013
2007 Microsoft Office Suite Service Pack 3	10/25/2011	Review Note	Review Note
Home and Student 2007	1/27/2007	10/9/2012	10/10/2017	1/13/2009
Office Basic 2007	1/27/2007	10/9/2012	10/10/2017	1/13/2009
Office Enterprise 2007	1/27/2007	10/9/2012	10/10/2017	1/13/2009
Office Professional 2007	1/27/2007	10/9/2012	10/10/2017	1/13/2009
Office Professional Plus 2007	1/27/2007	10/9/2012	10/10/2017	1/13/2009
Office Standard 2007	1/27/2007	10/9/2012	10/10/2017	1/13/2009
Ultimate 2007	1/27/2007	10/9/2012	10/10/2017	1/13/2009

Note: Support ends 12 months after the next service pack releases or at the end of the product's support lifecycle, whichever comes first. For more information, please see the service pack policy  http://support.microsoft.com/lifecycle/#ServicePackSupport

Some of the Proactive Offerings that we can help you, attain operational health and transition to a supportable Exchange environment are

Exchange Server 2010 Migration Readiness Assessment

Microsoft Risk and Health Assessment Program for Exchange Server

Workshop - Exchange Server 2010: Transitioning from Exchange 200x

Chalk Talk - Exchange Server 2010: Upgrading from Exchange 200x

Chalk Talk - Exchange Server 2010: Using Exchange Pre-Deployment Tools

WorkshopPLUS - Exchange Server 2010: Administration and Troubleshooting

If you need more information on the next steps to achieve Operational Excellence for your IT and help planning with the Service lifecycle, check with your TAM on we can help you move to a supportable state with our Proactive Services http://www.microsoft.com/microsoftservices/en/us/support_premier_proactive.aspx

Meeting Forward Notification (MFN) is processed by either the Exchange Calendar Assistant or Outlook and the organizer’s meeting is automatically updated to include the new attendee.  Now, when the organizer sends out a meeting update, the new attendee gets the update too.

When a meeting is forwarded by one of the attendees using Outlook 2010, several things happen:

• Outlook displays an InfoBar message to let the attendee know that a MFN will be sent to the meeting organizer.
• Outlook forwards the meeting to the new attendee.
• A meeting forward notification is sent to the meeting organizer (in most situations).

Depending on the client of the organizer, the Exchange version of the attendee forwarding the meeting, and the organization membership of both parties, the meeting forward notification can either be sent by Exchange or Outlook, or neither product.

The following outlines a few scenarios where MFNs are sent by different sources, or not sent at all.

• If the Organizer is using Outlook 2010

AND the attendee who forwarded the meeting is in the same Organization as the Organizer

AND the attendee is using Outlook 2010 in Exchange 2007 or Exchange 2010

THEN the MFN will be sent by Exchange

• If the Organizer is using Outlook 2010

AND the attendee who forwarded the meeting is in the same Organization as the Organizer

AND the attendee is using Outlook 2010 in Exchange 2003

THEN the MFN will be will be sent by Outlook 2010

• If the Organizer is using Outlook 2010

AND the attendee who forwarded the meeting is in a DIFFERENT Organization than the Organizer

AND the attendee is using Outlook 2010 in any version of Exchange

THEN the MFN will be will be sent by Outlook 2010

• If the Organizer is using a non-Outlook client

AND the attendee is using Outlook 2010 in any version of Exchange

THEN the MFN will be will not be sent

If Outlook sends the MFN, you will find a copy of the MFN in the Sent Items folder of the attendee that forwarded the meeting.

However, if Exchange sends the MFN, the MFN is not in the Sent Items folder of the attendee forwarding the meeting.

There are some scenarios where a meeting forward notification is not sent by Outlook when the attendee forwards the meeting to another user.  In this situation, the InfoBar of the forwarded meeting does not include the text indicating a meeting forward will be sent.

Outlook makes the determination not to send the meeting forward notification by first analyzing the Global Object ID value of the meeting.  Outlook parses this value to see if the organizer is using an Outlook client. 

Depending on the version of Exchange hosting the mailbox for the meeting organizer, the organizer’s experience varies slightly.

Mailbox hosted on Exchange 2007 (or later)

If the organizer’s mailbox is on Exchange 2007 or Exchange 2010, they will see the best experience because the Exchange Calendar Assistant processes the meeting forward notification. When the Calendar Assistant processes the MFN, the following events take place:

• The organizer’s meeting is updated to include the user to which the meeting was forwarded by the attendee.
• Meeting exceptions are created for recurring meetings where the user was forwarded only one instance in the series.

In this example, Exchange 2007 User2 is the meeting organizer and Exchange 2007 User3 is the meeting attendee that forwarded the meeting request to Exchange 2007 User4. With Exchange Store tracing enabled, you can see the Calendar Assistant processes the meeting forward notification and updates the organizer’s meeting to include the new attendee.

Now, when the meeting organizer opens the meeting on their calendar, the new user is automatically included in any meeting updates sent by the organizer.

This keeps all relevant attendees up-to-date on the meeting.  In earlier versions of Outlook, the user to which the meeting was forwarded usually is not included on the organizer’s calendar item.

Mailbox hosted on Exchange 2003 or non-Exchange mailbox

The Calendar Assistant does not exist for an Exchange 2003 mailbox. Therefore, the meeting forward notification is processed by Outlook. This can occur during any of the following events:

• The sniffer process is called when the MFN is processed by the cached mode incoming item pipeline
• MAPI-idle sniffer time
• The organizer views the MFN in the Reading Pane
• The organizer opens the MFN in the inspector window

When Outlook processes the MFN, the following events occur:

• The organizer’s meeting is updated to include the user to which the meeting was forwarded by the attendee.

Meeting exceptions are created for recurring meetings where the user was forwarded only one instance in the series.

Out of date Meeting Forward Notifications

In some scenarios, the MFN received by the organizer is out-of-date.  When this occurs, the MFN includes a button that the organizer can use to send a meeting update to the attendee who was forwarded the out-of-date meeting invite.

Outlook uses the Sequence property value (0x813E0003) on the meeting to determine if the meeting forward notification is out of date.

When the organizer clicks Send Meeting Update, the meeting invitation includes the very latest details on the meeting.

This ensures the newly added attendee’s calendar is up-to-date.

Registry settings to manage the meeting forward notification features

There are two policy settings available to control the meeting forwarding notification features in Outlook 2010.

Prevent Outlook from sending a meeting forward notification:

Use the following registry data to control the sending of meeting forward notifications by Outlook 2010.

Key:  HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Options\Calendar

DWORD:  DisableOlkSendingMtgFwdNotifs

Values:

  0 (or missing DWORD) = Outlook sends an MFN (default)

  1 = Outlook does not send an MFN

Note:  The DisableOlkSendingMtgFwdNotifs registry value is only used when Outlook is responsible for sending MFNs. If Exchange is responsible for sending the MFN, this registry value has no effect on Outlook. Also, there is no way to stop Exchange from sending an MFN.

Hide the Send Updated Meeting button

Use the following registry data to control the display of the Send Updated Meeting button in an out-of-date MFN viewed in the Reading Pane by the organizer.

Key:  HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Outlook\Options\Calendar

DWORD:  HideSendLatestVersionButton

Values:

  0 (or missing DWORD) = Outlook shows the Send Updated Meeting button on an out-of-date meeting forward notification

  1 = Outlook does not show the Send Updated Meeting button on an out-of-date meeting forward notification

Wow, not only you are generous Mrs. Proactive, you can write. I am certain though that readers will appreciate your attention to details. Thanks!

Did you know that starting the last weekend in October, Russia will no longer observe “Daylight Saving Time” (DST) and will effectively remain on “summer time”?

If you're interested (or concerned) about this, visit M3 Sweatt's blog for details on a webcast on the change and steps Microsoft is taking to mitigate any issues that might come up because of the it: http://blogs.msdn.com/b/mthree/archive/2011/09/12/dstconf-091211.aspx

Be quick, the webcast is scheduled for September 15, 2011, 10:00 am to 11:30 am Pacific Daylight Time.

For more information on the changes in Daylight Savings Time around the world and its impact on Microsoft products, you can visit the main DST webpage: http://microsoft.com/time.

Remember it's "Spring Forward, Fall Back"….

Because of the history of the latest rollups that have been released, many have decided to wait and not deploy this rollup at this time.  While that is certainly understandable, we felt that it might be useful to provide a brief synopsis of each of the fixes that are included in this rollup.  By taking a few minutes to read the items below, you may find some reasons why it might be a good idea to roll out the fix now. 

Some fixes included in Rollup are below:

• Slow network or replication issues after you change the number of virus scanning API threads in Microsoft Exchange Server 2010
  The Exchange Server Analyzer (formerly known as ExBPA) recommended that the VSAPI threads be bumped up higher than they should have been which could lead to network performance issues or replications issues.
  
• A device that uses Exchange ActiveSync cannot access mailboxes in an Exchange Server 2010 environment
  There was an issue with the way the Exchange 2010 CAS server would proxy requests to an Exchange 2007 server.  In some cases it would wait for a request to be completed when it did not need to and would submit additional requests that were not necessary.
  
• Journal reports are expired or lost when the Microsoft Exchange Transport service is restarted in an Exchange Server 2010 environment
  This fixes a scenario where a journal report could be lost and never reach its intended destination.  
  
• You cannot use the GetItem operation in EWS to retrieve properties of an email message in an Exchange Server 2010 environment
  This fixes a scenario where EWS was not handling attachments correctly. 
  
• The columns in the .csv logging file are not lined up correctly when you perform a discovery search on a mailbox in an Exchange Server 2010 environment
  When doing a discovery search on a mailbox and exporting the results to a .csv file the columns would not line up correctly because of how we handled the subject line that had special characters.
  
• The columns in the .csv logging file are not lined up correctly when you perform a discovery search on a mailbox in an Exchange Server 2010 environment
  Same as the item directly above except the cause is a comma being in the display name.
  
• "There are no items to show in this view." error message when you try to view a folder by using Outlook in an Exchange Server 2010 environment
  This fixes another case in which this would happen that was not fixed previously in the fix mentioned here: http://support.microsoft.com/kb/2500648
  
• Extra.exe crashes when it performs RPC activity checks against an Exchange Server 2010 server
  This fixes a crash that would happen when running Microsoft Exchange Troubleshooting Assistant (Extra.exe) and selecting the “Collect Exmon Data” check box.
  
• You cannot delete a mailbox folder that starts with a special character in its name by using Outlook in an Exchange Server 2010 environment
  The title says it all…
  
• "ChangeKey is required for this operation" error message in Outlook for Mac 2011 in an Exchange Server 2010 environment
  Moving an item and then changing the category of the item using Outlook for Mac 2011 would throw the above error when the client synchronized the changes with Exchange 2010.
  
• The "Test-OutlookConnectivity -Protocol HTTP" cmdlet fails to test the Outlook Anywhere connectivity in an Exchange Server 2010 environment
  The Test-OutlookConnectivity cmdlet includes several tests including one for RPCProxy Authentication. This part of the test could fail even if you specified the switch RPCProxyAuthenticationType.
  
• The copy or move operation on a folder that contains subfolders does not work as expected after you install Update Rollup 4 that is dated June 22, 2011 for Exchange Server 2010 SP1
  This includes the fix that was the reason Update Rollup 4 was re-released.  In other words, if you had installed the original RU4 that was dated June 22, 2011 and never installed the updated one, then RU5 would resolve this as well.
  
• You cannot save attachments in an email message by using OWA if the subject line contains special characters in an Exchange Server 2010 environment
  This would happen when using Internet Explorer 7 with OWA Premium.  It doesn’t affect  IE8 or IE9 or OWA Light.
  
• A RBAC role assignee can unexpectedly run the Add-ADPermission command on an Exchange Server 2010 server that is outside the role assignment scope
  Exchange 2010 now verifies the scope when Add-ADPermission is run.
  
• Mailbox users who are migrated by using ILM 2007 cannot use the Options menu in OWA in an Exchange Server 2010 environment
  Update-Recipient did not stamp the Default Role Assignment Policy and when a migrated mailbox user would click on the Options in OWA they would get a “Sorry! Access denied” error.
  
• Certain client-only message rules do not take effect on email messages that are saved as drafts in an Exchange Server 2010 environment
  Some client-side rules don’t work when your Outlook client is in online mode.
  
• The inline contents disposition is removed when you send a "Content-Disposition: inline" email message by using EWS in an Exchange Server 2010 environment
  This fixes an issue where a message sent using Exchange Web Services through Exchange 2010 may end up with some of the message missing or added as an attachment when it should not have been.  Outlook 2011 for Mac is a client that can use Exchange Web Services.

We in Premier Field Engineering know what it is like to have to make decisions that may affect hundreds of thousands of mailboxes because many of us used to be in your shoes before joining Microsoft.  Hopefully the information above will help a little more with your decision.

As always, feel free to ask questions below or email us using the "Tell us!” link above.

The classic question of how to handle message size limits comes up very often and ever changing technology in pursuit of improvement never stays the same. This adds to the confusion of understanding the limits and the way they are applied across the organization. Also, it becomes challenging when you need to provide an exception.

Consider this example:

You have Exchange 2010 servers coexisting with Exchange 2003 servers. You have the Maximum Recipient per message limit set to 5000 in Global Limits and it is set to 2500 in Organizational Limits.

A user comes up to you and presents a business need that requires him to be able to send a message to 3000 company employees at once.

Now this is an interesting scenario. First of all, how can you have two different limits for the same parameter in the same Exchange organization? How can Exchange 2003 allow different limits than 2010? The answer is in where it is stored in Active Directory.

Exchange 2003 uses “Global Limits”. The configuration for maximum recipients per message is stored in msExchRecipLimit attribute. Exchange 2007 introduced the term “Organizational Limits”. Since then, the same maximum recipients per message limit configuration is stored in MaxRecipientEnvelopeLimit attribute. This caused limits to conflict if configured separately. Until Exchange 2007 SP1, the only way to correct that was to change Global Limits from Exchange System Manager (Exchange 2003) to match Organizational Limits set using Exchange 2007 management tools. Exchange 2007 SP1 introduced a unified method of changing the limits. If you use Exchange 2007 tools to set organizational limits, the cmdlets will also update Global limits to match the organizational limits being set.

If I haven’t lost you already, going back to our scenario, now we know the limits are different. We also know what our user needs, but we don’t know where the user mailbox exists. Now why would that matter?

That’s because Exchange 2010 handles messages differently than Exchange 2003. It is described in detail in “Understanding Message Size Limits” on TechNet. In brief, Exchange 2003 treats each member of an expanded distribution list as one recipient. Exchange 2010 treats a distribution group as one recipient. This change was implemented to avoid the partial message delivery scenarios that may occur in Exchange 2003.

Now that we are armed with even more information, what can we tell our user?

If his mailbox happens to be on an Exchange 2003 server, you are looking at limit of 5000 recipients per envelope. This also includes members of expanded distribution groups that may be on the email recipients list. This should be enough to meet user’s requirements.

If, however, his mailbox is on Exchange 2010, your organizational limits are in effect, which happens to be less than user requirements, even if you count each Distribution Group as single recipient. On top of that, Exchange 2010 also implements Connector Limits, Server Limits and User Limits. Because we’re questioning maximum recipients, if the user is sending email through Outlook, Connector Limits won’t apply, and neither will Server Limits. If the user is sending email through an application that uses Receive Connector on Exchange 2010 Hub Transport servers, Connector Limits will apply. If the user is sending email using an application that uses the pickup directory on the Hub Transport servers, Server Limits will apply.

So how do you know which one will take effect in the end? Well, that is explained in “Understanding Message Size Limits” as well. But I will spell it out here in brief. As a message enters the Exchange 2010 environment, it gets evaluated at every stage of message processing. Depending on how it enters the environment, it will be affected by applicable limits as I explained above. If Connector Limits are in effect and are more restrictive than your Organizational Limits, they will take effect.

So… Will your user be able to successfully send an email to 3000 recipients ever? Or you will tell him to break up his message into smaller chunks?

Well, you are in luck. There is one exception to the “most restrictive” approach as spelled out in the message size limits article. And that is (drumroll please) per user configuration! If you were to set the user’s mailbox properties to a limit that meets their needs, you will make that user happy. I’m not saying that would always be a good thing for your environment or not, but only you can judge that!

And if your head hurts, I’ve done my job right.

In short, there are scenarios where folders moved or copied from one location to another using Outlook may end up in the Recoverable Items Folder.  The recommendation from the Exchange Team is that you request the Interim Update if you have already installed this.

Please go to the Exchange Team Blog for any updates.

Ok, that was sarcasm. And not very well done, at that. Actually, I hate this error because it’s so vague, and because at least half the time I’ve seen it, the faulting method doesn’t actually contain the code that caused the root problem. It just happens to be where everything finally blew up. And in fact, that was the case here.

So that you don’t have to keep thinking to yourself, “Would you please just get to the point!?”, I’m going to give the solution, then the cause, and then I might go a little into the process of how we got there.

The Solution

There are a few possibilities (as always):

1. Try turning off Verbose logging. This one doesn’t seem to always work, but in certain instances it does. Apparently, if Verbose logging is turned on, SharePoint uses one of the utility methods that we found had the bug related to using StackFrame and StackTrace.
   Now, to be clear: having Verbose logging turned on will not always cause this error. So, you may in fact find that in your code, you don’t have this problem at all. And hey, lucky you! In our brief testing, having Verbose logging turned on for some categories worked fine, while others resulted in the appearance of our friend the “Object reference” error. As the saying goes, YMMV.
   
2. Don’t do it. Find an alternative. I hate that this is the answer, but we actually tried option number one and initially got it to work. With further testing, however, we hit the same error again, but this time caused by a separate utility method that did basically the same thing with StackTrace and StackFrame as the first method. And that was with Verbose logging turned off.

That’s it; really. You may get it to work, and please, please, please: if you did encounter this error and still found a way to make the WCF call work (well, the instantiation, actually; we had no trouble getting the WCF call to go through), please let me know how you did it.

Here are two alternatives:

1. Use the SharePoint 2007 web service API, which is pretty robust.
   
2. Use a standard web service hosted inside a SharePoint web app.

In this customer’s case, they wanted to do some special configuration magic that would have been much more difficult without the special configuration file they’d designed. So, they opted for creating a web service hosted inside one of the SharePoint web apps (I’m not going to give too many specifics about their architecture, but the point is that this option worked.) As I said, however, the SharePoint 2007 web service API is fairly robust. With some planning, you will probably be able to accomplish everything you want just by making use of it. A quick search on Bing will locate some really helpful resources for you, but for those pressed for time J, here are some samples:

• Automate Web App Deployment with the SharePoint API (MSDN Magazine; Ethan Wilansky, Paul Olszewski, Rick Sneddon)
• Getting Started With SharePoint Web Services (InfoQ; Trent Swanson)
• SharePoint 2007 Web Services (Tony Testa’s World; Tony Testa)
• Inside SharePoint - Extending Office Applications with Web Services (TechNet; Pav Cherny)

The Cause

There is a documented bug in SharePoint 2007 with one of the utility methods. The method itself seem innocuous enough: all it does is list out the stack when asked using the .NET StackTrace and StackFrame objects. Unfortunately, due to various factors—most of which I’m not privy—these .NET objects may not be instantiated.

I think (and this is just presumption, which is why I italicized those two words) that StackTrace and StackFrame being null may be related to the fact that most SharePoint 2007 .NET code is just a series of wrappers for unmanaged COM code. Thus, I’m guessing (again, notice the italics) that the StackTrace and StackFrame objects are not instantiated in all circumstances. I mean, they’re not as fundamental as, for instance, the Object class. But I digress. Plus, I’m right at the edge of what I know and what I blatantly don’t, and if I tread any further, that will become painfully obvious.

In any case, due to some strangeness in how the SharePoint classes get instantiated when called by a WCF service, the StackTrace and StackFrame objects don’t get instantiated, but a couple of SharePoint utility methods that use them do get called. And since those utility methods don’t take into account the fact that StackTrace and/or StackFrame might not have been instantiated, they call methods on the null objects, causing the “Object reference…” error to be thrown.

Other Things We Tried

• We started by making sure the WCF call was making it to the endpoint. Once we established that, we knew we would/should be able to rule that piece out. Besides, the error was happening in the SharePoint code, after a considerable amount of other code had already been called and run.
  
• We noticed that the HttpContext and SPContext objects were null, and thought that might have something to do with it. We created context manually by creating an HttpRequest.
  
• Since the error was happening inside custom feature-related code, we tried adjusting the settings to not activate any features. We still got the error, but now we could see it actually happening in the SharePoint utility class. This was almost more confusing, since our first thought was, “That doesn’t make any sense—it’s just a method in a utility class that displays StackTrace information. I guess the lesson here is not to overlook what’s right in front of you.

One of the oddest things was that we initially didn’t find any mention of this bug on the web. Actually, my customer was the one that found a brief mention of turning off Verbose logging while searching archived forum postings. This led us to search our internal bug database, where we found the SharePoint bug documented.

And just in case you’re hoping this might be fixed in SharePoint 2007, I’ll let you know that this particular bug was marked, “Postponed”. On the plus side, it is confirmed as fixed in SharePoint 2010.