Microsoft makes its own calendar UNDO!

 

Finally Microsoft does something to fix the terminated user problem of ghost meetings.

Remove-CalendarEvents -Identity user@domain.com -CancelOrganizedMeetings -Confirm:$false -verbose

Arm yourselves with knowledge!

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

Terminated with extreme prejudice

You know the scenario -- people in your organization are coming and going all the time. When they come in you have a handle on it. When they go, well, that's a different story.

In particular, Exchange has a nasty habit of letting them leave the building but linger on in broken meetings.

We've been working on the problem and we got asked about it yesterday, so I figured it was a good time for a running commentary.

Let's create a user called Elvis Morrison.

Elvis enters the company sets up a few meetings and, in the way of all flesh, is downsized or leaves for greener pastures. When he leaves this is what his calendar looks like:

We can delete Elvis from Active Directory in a few seconds:

But if we just delete him then his meetings will linger (with no way to cancel them). So in the Conference Room 222 calendar, Elvis is still very much alive!

He's also still in end user calendars.

Now, if we wanted to cancel all of Elvis's meetings BEFORE we deleted him from Active Directory, that would be easy. Just run our tool and click Test2: Report/CancelMtgs

You get options like

Let's say we want to cancel them.

And let everyone know why.

And it tells us what's going on.

BUT let's say users have been being deleted for a while or we deleted Elvis before removing his meetings. We can STILL clean out the resources (we can do the users, too, but let's focus on the rooms and resources).

Let's say we're looking to clear out the cruft from Conference Room 222.

Put in the Room ID and click
It will find all instances of Elvis's recurring meetings in it (as well as any other broken meetings, but I happen to know the only ones in there just now belong to Elvis)

And it creates a separate report

To get rid of them (you can edit the report to remove the ones you want to keep) click


Going into the calendar for Room 222 means it now looks like this, cleaned of the broken meetings Elvis organized.

The more astute among you will recognize there are some additional subtleties to this, but I'll save those for another blog posting.

Editorial addition (Sept 14, 2008)

The "Export Mailbox" cmdlet will archive all Elvis's data to a PST, but it does NOT cancel his meetings. See this discussion.

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.