Featured Post

How the Sumatra Double-Booking cmdlet works

Free license through 2017 if you qualify and contact us . First: you can always get help at the PowerShell prompt with: get-help Get-suDo...

Wednesday, January 23, 2008

Terminated Users, Broken Meetings, and Exchange 2007

Given the current economic situation we expect that many US corporations will soon be filled with a "right-sized" group of users. This will of course leave rotting corpses throughout the organization and some of them are going to be festering away in your Exchange 2007 store.

We've heard it referred to as the "terminated user" problem and it works like this:

Yorick, a diligent young exec just fresh from his MBA with little experience other than managing his BMW and his credit cards, has been busily setting up meetings with people across all departments. He is now gone but his meetings live on. (Note: We realize this is an idealized scenario. In the real world Yorick would be promoted while people with far more experience but higher salaries and more benefits would be nuked wholesale, but we try not to be bitter.)

So recurring meetings managed by Yorick, which might or might not be relevant anymore, are sitting in calendars across the company.

You the Exchange Administrator would like to get rid of them wholesale, but there's no way of doing this except for logging in as Yorick and manually finding and cancelling all meetings, making sure to send updates. Multiply this hassle by the body count in your reorg.

But it does not need to be like this.

Since as part of our calendar migrations we're creating and deleting meetings ALL THE TIME, we've started experimenting with some tools based off our insertion code that will go through a user's calendar, cancel all meetings they proposed, and automatically send updates to guests.

Problem solved.

We've started with a congruent problem: finding orphan conference rooms from cancelled meetings and built it into our main code via the "Test" button (which those of you in the midst of E2K7 migrations have gotten used to)



To check for orphan conference rooms:

Why are we telling you all of this? Because we're looking for folks who really want the problem solved and are willing to work with some early code to help us work out the best way to invoke and use this in the Exchange environment.

You're going to need to set Permissions for a service account to run this app as you would for a migration -- so be advised of that. But we're more than happy to share this with folks who contact us directly looking to try it out.

Sunday, January 20, 2008

Outlook Meeting Reminders: OL2003 + E2K7 = Confusing

We have some folks migrating into Exchange 2007 keeping their Outlook 2003 calendars, who started to notice some odd behavior with their reminders.

15 Minutes seems to be the magic number for a meeting reminder default when you put Outlook 2003 in an Exchange 2007 environment.

Expect that under a variety of conditions of meetings being proposed to and from OL2003 that the default will be set to 15 minutes on the ATTENDEE's calendar, regardless of where it was set in the meeting ORGANIZER's, and regardless of the ATTENDEE's Default reminder setting.

The situation arises with default settings and reminders if Outlook 2003 is the origination point. We haven't (yet) seen problems with OWA or Outlook 2007.

There are in the support database a variety of problems listed with meeting reminders in Outlook (appointments seem to be working OK, but maybe that's just our eyes glazing over).

Among the classics:

The reminder for the meeting is removed when you accept a meeting request in Outlook 2003 which is based on Rules removing reminders

A reminder for an all day event meeting request is reset to 18 hours when you send the meeting request in Outlook 2003 which is self-explanatory.




Try just hitting the support.microsoft.com and searching for "Outlook reminders".

Saturday, January 19, 2008

findItem and restrictions in EWS code

For those of you Exchange 2007 migrators who wondered why Sumatra needed to put categories in the subject line -- We ran into a bug in Exchange 2007 RTM (Microsoft confirmed fixed in SP1). The same problem showed up in this post involving contacts: http://forums.microsoft.com/TechNet/ShowPost.aspx?PostID=1849174&SiteID=17

Basically: you can't use FindItem with restrictions that use SUBSTRING in an EWS XML query:

<restriction>
<t:contains containmentmode="Substring"
ContainmentComparison="IgnoreCaseAndNonSpacingCharacters">
<t:ExtendedFieldURI PropertySetId="00062008-0000-0000-C000-000000000046"
PropertyId="34100" PropertyType="String"/>
<t:Constant Value="mmConv102659080256Z"/>
</t:Contains>
</restriction>


So in contrast to almost every other release Microsoft has done for Exchange -- SP1 actually IMPROVES the migration process! I feel like Fred Sanford expecting to join Elizabeth imminently.

Friday, January 18, 2008

Exchange 2007: to sp1 or not to sp1?

One of the features clients love about the Sumatra migration technology is our back out strategy: if something goes wrong during a calendar insertion we can selectively remove all the data we put in and do it more quickly than a full Exchange restore.

We do this using keywords.

For Exchange 2007 pre-sp1 because we were under the gun to complete the code for a migration in July, we took a quick path that placed the keyword in the "Subject" line (and created an option to remove these).

For sp1 we no longer insert our keywords into the Subject: line (meaning you get all the benefits of our back out capability without the annoyance of having to remove the keywords).

Bottom line: either pre-sp1 or sp1 will support a calendar migration, but each method requires a different version of the insertion code.

Consult with Sumatra if you need to decide which version to use during your migration.
Update: January 19, 2008: We've confirmed there were some bugs with EWS that the sp1 service pack fixes. We'll blog on it soon.

Wednesday, January 16, 2008

Rate Limiting Steps in an Exchange 2007 migration

We've started to get the question "What's the choke point in a calendar migration into Exchange 2007?"

Keeping in mind that in 2007 we use EWS, you've got to think of the migration as running via HTML. So network efficiency and I/O are the crucial factors.

Russ produced this list of limiting factors (in priority order)

  • Speed of the SAN (Mostly it's I/O bound)

  • Speed of the NETWORK (Next, it's related to how fast HTTPS requests are
    sent/received)

  • Speed of the SERVERS (CAS, then MBX) (Third, how fast the Web Services Requests are PROCESSED)

  • Speed of the 32-bit (Fourth, how fast those requests are GENERATED)

In Exchange 2000/2003, where we used CDO, the horsepower of the individual back end Exchange server played a more crucial role.

Wednesday, January 09, 2008

Categories and Extended MAPI Properties in Exchange 2007

Sumatra used categories and extended MAPI properties to "tag" items that it inserts into Exchange. Sumatra uses this tagging strategy to find (and update) specific meetings. This works well in Exchange 2003, and doesn't work at all in Exchange 2007.



We set these items on messages in the meeting organizer's calendar. But wait--those categories and extended MAPI properties do not get transmitted with a messages in Exchange 2007! A PSS call yesterday confirmed that this behavior is possibly a bug.!?! I'll re-post if we find a solution



Here's the most relevant part of the code that adds categories (using XML):

<t:CalendarItem>
<t:ItemClass>IPM.Appointment</t:ItemClass>
<t:Subject>Russ and Nancy 1 on 1</t:Subject>
<t:Categories><t:String>mmConv102659080256Z!9</t:String></t:Categories>
<t:ExtendedProperty> <t:ExtendedFieldURI PropertySetId="00020329-0000-0000-C000-000000000046" PropertyName="SumatraKeys" PropertyType="String"/> <t:Value>E1D5E39F08206011E39F9218</t:Value></t:ExtendedProperty>

Tuesday, January 08, 2008

Zimbra and Private Activities / To-Dos

In the several Meeting Maker to Zimbra migrations we've done, the issue of what to do with "Private" activities and to-dos always come up.

Since Zimbra pre-version 5 does not have Private capability at the meeting level we've done all of these options:
  • Delete "Private" Activities / To-Dos before they are inserted (clean, easy to understand, infuriating for some users)
  • Pre-pend "PRIVATE:" to the relevant activities (easy to find and the user can deal with them as they will)
  • Separate the "Private" items into a separate database and insert into separate calendars. A little time-consuming all around, but it worked this weekend at a migration in Pennsylvania.

In Zimbra 5 this all becomes moot -- but we want to make sure current clients contemplating a Zimbra migration know their options.

Thursday, January 03, 2008

Exchange 2007 sp1

Our preliminary read on how sp1 has an impact on our insertion code: No problems.

Russ ran an insertion in the test lab with no problems.

We have a field test coming up this weekend and we'll let you know the real world results.