First Field Migration into Zimbra 7 Accomplished

We ran our first field migration into Zimbra 7 this weekend (out of a Meeting Maker legacy system).

We had early reports of problems with recurring meetings in Z7 migrations, but tested well in advance to make sure that did not happen.  All is well.

Prevent ghost delegates: find (and remove) delegates before terminating user

In a previous post, I outlined a process to find and remove Ghost Delegates from Exchange. (To recap: you turn a delegate a ghost delegate by deleting the account from AD without removing the delegate permissions in Outlook.)

In this post, I'll outline a process that avoids the ghost delegate problem (by finding and removing delegates BEFORE deleting the terminated user's account.) There are two steps: search AD, and then remove the delegates.

The hard part was finding all users that granted delegate rights to the "soon-to-be-deleted-account." I dredged up two "oldies but goodies:" LDIFDE and CSVDE to do a reverse-lookup for a terminated user using the "public delegate" fields:

• PublicDelegates "What mailbox(es) did I give delegate rights to"
• PublicDelegatesBL: "What mailbox(es) am I a delegate of"

Here are both commands:

LDIFDE.EXE -F delegateLDIFDE.TXT -D "OU=TestUsers,DC=myDC,DC=mydomain,DC=com" -L "name,mail,PublicDelegatesBL" -R "(&mail=termuser@mydomain.com)(PublicDelegatesBL=*))"


csvde -f delegateCSVDE.csv -s myDC -l "name,mail,PublicDelegatesBL" -r "(&mail=termuser@mydomain.com)(PublicDelegatesBL=*))"

Note: the LDIFDE command limits the scope of its work to the "OU=TestUsers;" csvde seaches the entire enterprise directory.

Here is an output from LDIFDE, in which we found all of PublicDelegatesBL of "Andre Admin" (it's just Big Boss):

Next, use Glen Scale's powershell code to confirm the terminated user is a delegate, and then remove that user from all accounts he was granted delegate rights. (The following commands were described in a prior post.) Step 7 is where the terminated user is removed as a delegate. I have shown how to display delegates and forwarding rules, just as an FYI.

1. set-ExecutionPolicy RemoteSigned -force
2. import-Module ./Messageops-Exchange.psd1
3. $myCred=Get-Credential -Credential myservice@mydomain.com
4. $newprofile=new-messageops.ewsprofile -identity:myservice@mydomain.com -exchangeversion:exchange2010_sp1 -casURL:https://mycas.mydomain.com -Credential:$myCred
5. Get-MessageOps.MailboxDelegateReport-p:$newprofile -id:bigboss@mydomain.com
6. Get-MessageOps.MailboxDelegateForwardingRules -p:$newprofile -id:bigboss@mydomain.com
7. Remove-MessageOps.MailboxDelegate -p:$newprofile -id:bigboss@mydomain.com -DelegateAddress:termuser@mydomain.com
   

Notes: the "terminated" user is termuser@mydomain.com; the account that granted delegate rights was bigboss@mydomain.com.

I've pulled the URLs and commands into a text file that you can download to simplify typing....

--Russ



p.s.: I tried Exchange Management Shell, using a new Exchange 2010 commandlet: "Get-MailboxFolderPermission." But it was difficult to do a reverse-lookup (i.e., find all users who grated the "terminated user" permissions: I had to type that user's display name correctly or got no hits.... Plus, this commandlet isn't available for Exchange 2007 customers.


Here is how to get Big Boss' permissions:
Get-MailboxFolderPermission -Identity bigboss:\Calendar

FYI, you can set accessrights, particularly editor rights, between "big boss" and "her admin," that you can't do if your end users access their Exchange calendars via OWA (only):

Set-MailboxFolderPermission -Id:bigboss:\Calendar -User:herAdmin -AccessRights:Editor

The Ghost Delegate Exorcist

A Sumatra client called for help - a flood of NDRs were driving their Exchange server to its knees. The problem: a boss granted his admin delegate rights his calendar. Along with that, all calendar-messages were forwarded to to the admin. After the admin left the company, the admin's mailbox was deleted.

All was fine until someone invited the boss to a meeting. The boss received an NDR after the delegate forwarding rule sent that calendar message to the [now deleted] delegate. That NDR calendar message was sent back to the boss which got forwarded to the [still deleted] delegate, which generated another NDR......)

No big deal. They went into the boss' Outlook delegate and tried to remove the delegate, but couldn't -- Outlook reported the delegate was "(not found):"

The delegates are there but you can't delete them. Ghost delegates.....
The root cause: they didn't remove the delegate permissions and forwarding rules before they deleted the admin assistant's mailbox.

In this post, I'll talk about how to rid Exchange of those ghost delegates. In the next post, I'll talk about how to find and remove delegate permissions BEFORE you delete the terminated user's account.

For the curious, Glen Scales blogged about "How to deal with invalid delegates," and "Displaying delegate forward rules." Even better, Glen wrote some powershell code to exorcise our ghost delegate!

Here is what we did to remove the ghost delegates

1. Download and install the Exchange Web Services Managed API
2. Create a sub directory, and copy the Microsoft.Exchange.WebServices dll into the directory; Run Exchange Powershell (as administrator), and change to that sub directory.
3. Set the execution policy, import the module, and create a credential variable (using your service account):
set-ExecutionPolicy RemoteSigned -force import-Module ./Messageops-Exchange.psd1 $myCred=Get-Credential
4. Next, define an exchange profile (as above, we provide our service account with impersonation or full access permissions. See our blog post on impersonation in Exchange 2007 or Exchange 2010), and point to our CAS server directly
   
   
   $newprofile = new-messageops.ewsprofile -identity:mySVCacct@mydomain.com-exchangeversion:exchange2010_sp1 -casURL:https://mycas.mydomain.com -Credential:$myCred
   
   
5. See the list of valid and invalid (ghost) delegates and rules:
   
   
   Get-MessageOps.MailboxDelegateReport -p:$newprofile -id:bigboss@mydomain.com
   
   Get-MessageOps.MailboxDelegatesInvalid -p:$newprofile -id:bigboss@mydomain.com
   
   Get-MessageOps.MailboxDelegateInvalidForwardingRules -p:$newprofile -id:bigboss@mydomain.com
6. Finally, remove invalid forwarding rules, and THEN remove the delegates (in that order!)
   
   
   Remove-MessageOps.MailboxDelegateInvalidForwardingRules.unsupported -p:$newprofile -id:bigboss@mydomain.com
   
   Remove-MessageOps.MailboxDelegatesInvalid.UnSupported -p:$newprofile -id:bigboss@mydomain.com

I've pulled the URLs and commands into a text file that you can download to simplify typing....

-Russ

Migrating Zimbra Calendar to Hosted Microsoft Exchange

We've been getting a lot of inquiries lately from people wanting to migrate calendars out of Zimbra and into Exchange.

A few quick guidelines:

• If you have more than 250 users it is cost-effective to use our full-scale migration technology.  It's completely server-to-server, leaves end-users out of the loop, and has results as though you've been using Exchange calendaring all along.
• For a few hundred users or under, try our Decaf option.  Application here.  Documentation here.  It's a server-side ICS import to hosted Exchange, and right now it's mainly geared towards Oracle Calendar migrations, but we'll open it up to Zimbra users if we see enough demand.

Exchange 2010 to Google Calendar Server-Side Calendar Migrations

You read that right.

Now that we finally have OAuth for Google working (one of our engineers described Google's documentation as having "duplications, contradictions and gaps in between."  I describe it as a "mess") we're inserting calendar data server-side to Google with full-fidelity and no end-user intervention.

Yippee!

We've read the handwriting on the wall and see that there are sites out there looking to bring their calendar data from Microsoft Exchange over to Google and are not thrilled about having to use PSTs to do it (we don't blame you).

If you are contemplating such -- drop us a line.  We want some feedback on how you'd like it implemented.