Delegates / Proxy Migration in Exchange 2007 sp1

One thing we notice is that folks sometimes want to have their Proxies (Meeting Maker term) or Designates (Oracle Calendar Server term) migrated into Exchange 2007 as Delegates (Outlook term).

For Exchange 2007 before sp1 you were out of luck. For Exchange 2003 you only need to use CDO 1.21 with documented memory leaks. Those of you for whom we have migrated Proxies know this is why the process to migrate proxies takes almost as long as the process to migrate your calendar data. And annoyingly CDO 1.21 is not supported at all in .NET code.

For E2K7 sp1, Microsoft documentation gives you the impression this is possible using only Exchange Web Services. DeVa expands on this a bit in Adding delegates in Exchange Web Services (sp1).

However, our direct experience with a recent client migration to E2K7 sp1 and Glen (whom we cannot praise too much) confirm that setting permissions via Exchange Web Services is insufficient. You also need to set permissions on the Schedule+ NON_IPM_SUBTREE.

Wait you say -- this is 2008 and I just saw the word "Schedule+" appear in print, like it was... 1992 or something. Is this possible?

Rest assured, it is mos def.

In fact at least one user has reported a problem and documented a solution in in this data structure during a migrating from Exchange 2003 to Exchange 2007. Microsoft seems to have picked up on this in KB 945602.

For those of you who want a fuller story on how Delegates relate to the Free/Busy folder, thank Ximian for their work in reverse-engineering and publishing the results (which they did for E2K3).

So the end result here: be really careful writing scripts to set Delegates for calendar functions in Exchange 2007 and make sure you take into account the NON_IPM_SUBTREE in addition to the documented EWS code.

And, this being Exchange, there are additional complications because .... well.... because Exchange is clearly built by committee. So if you have BOTH Outlook 2003 and Outlook 2007, and use Delegate (and I'll bet the answer is "yes" all around), you need to check out KB 924470. While you're at it -- these also give you some idea how funky basic Delegate functioning is in E2K7: KB 950794, KB 918797, KB 932207, and KB 942418.

Does it work or not? This is so convoluted we're not sure. If any of you have feedback let us know.

Shared Calendars in Exchange 2007 sp1

Let's say you used a group calendar in Meeting Maker or Oracle and wanted to migrated that into Exchange. The idea being that any user in a group could post and view calendar data (like vacations or help desk schedules, events, that kind of thing).

Prior to E2K7 sp1 your only option was to migrate it into a user calendar or resource calendar and then make share it.

In a minimally-documented feature you can actually migrate the calendar data to a Shared Mailbox.

But wait you say -- you've been through the Mailbox Wizard, and there ain't no "Shared Mailbox" in it:

That's because you can only create it in the Exchange Management Shell.

So to create a shared mailbox for the former Market Department Group calendar, you might use the following

[PS] c:\New-Mailbox -alias DeptCal -name "Marketing Department Calendar" -database "Mailbox Database" -org Users -shared -UserPrincipalName DeptCal@YOURDOMAIN.com

THEN it will show up in the Exchange Management Console!

What do you do with it now?
Well, not much.... yet.
This is a disabled account. We need to add user access to it, and this brings us into the dreaded world of Permissions.
First, create a security group (via Active Directory Users and Computers) in your domain called "Marketing Department Security Group" and add the users you want to access the calendar. And in our friend the Management Shell, grant that group full mailbox permissions:
[PS] c:\Add-MailboxPermission DeptCal -User:'Marketing Department Security Group' -AccessRights:FullAccess
We're not done yet. You will need to add "Send-As" permissions to the group as well. Those of you doing migrations are really used to this.
[PS] c:\Add-ADPermission "Marketing Department Calendar" -User:'Marketing Department Security Group' -ExtendedRights:Send-As -AccessRights:ReadProperty, WriteProperty -Properties:'Personal Information'
Users in the Group now have full rights to that shared calendar.
So in OWA just pass the DeptCal email address and use your own credentials to log in (please do not send me posts about my Certificate Error, it's a test server for gosh sakes).


SO in Meeting Maker if you have had a group calendar, map and migrate it into a USER calendar and then CHANGE it post-migration to a shared calendar using the "Type" command.
e.g.,
[PS] c:\Set-Mailbox DeptCal -Type:Shared
and set up your Security Groups.
Why not just create a Shared mailbox in Exchange and migrate into that? The account is Disabled -- we won't be able to re-create data in it with full fidelity. Create it as a User and then change it to Shared and you'll be happier with the results.

Need some Exchange Calendar applications or utilities developed for your enterprise-sized organization? Contact us.

UNDO Capability field-proven

You know, it had to happen.


We've been talking about how we have our own UNDO capability and that it hasn't needed to be used in the field since a Dutch MM 6.0 server mistakenly got inserted with an East Coast USA time zone.


Well, owing to an unfortunate bug we had to remove an entire insertion of a few thousand users a couple of weeks ago.


Good news: the UNDO worked fine. And we ran UNDO in parallel and the data was out in way less time than it took to put in.


Better news: their insertion re-ran this weekend without a hitch.


Bad news: Like the recent Incredible Hulk movie we need to re-set the "days since last incident" counter.