Tag Archives: 2007

How Do You Handle Automated Notifications in Your Enterprise?

Recently, we had an outage due to heat in some of our switch closets.  Not only did this generate a lot of alarm traffic for IT Systems…but it also generated a lot of alarm traffic for HVAC and even other systems as well.  In the end, we sent out so many automated notifications (emails) to pagers and cell phones that we got rate controlled and then subsequently blacklisted due to the massive volume of emails heading out of our SMTP IP Address.  This blacklist meant that email was brought to a screeching halt in the enterprise.  I had to have our Network Team fail us over to our secondary SMTP IP Address in order to get mail flowing again.  This of course, meant we were no longer using our primary network circuit and there were some DNS hiccups…and really, we didn’t need anything else to make the IT department look bad…DNS was the icing on the cake.

So my question to all the Email Administrators out there is…how do you handle automated notifications in your enterprise?  Do you have secondary SMTP servers with different IP Addresses that you use to send out automated notifications?  Do you use the same Exchange server but filter traffic using Exchange and virtual SMTP Servers to an external smart host?  How do you do it?

I hope someone has some examples for me and I appreciate any help you can give…we’re just venturing into territory I haven’t been in before and it’s always good to get perspective of those who have been there already.

Email Shows Delivered in Message Tracking But Not in User Inbox

This almost ranks right up there with my Ghost Delegates head scratcher of an issue.  Now we’re talking about ghost messages.  In my case, an automated system was sending out a notification email to a user in our enterprise environment.  I could track the message through our SPAM Firewall showing the hand-off (RECEIVE stamp) of the message to our Exchange 2007 Transport Server and then a DELIVER notification of the message being placed inside the mail store.

In other words:  The message was actually being delivered into the user inbox…but they never appeared there to the end user.  No pop-up notification of a new message in Outlook 2010 on the desktop.  Nothing.

So how do we troubleshoot this problem?  Luckily, I approached this the correct way right away so I saved myself tons of time and I’m going to share with you how I did it.

Where to Start – Cache Corruption

First and foremost, we use Outlook Cached Mode in our environment.  My first thoughts were that the cache file had become corrupt.  I’ve seen in the past where a user has not been able to send or receive email to individual distribution groups or they are unable to update an appointment…just really odd singular stuff like this.  So I backed up the user .ost file by closing Outlook and Windows Search tool and renaming it to username.ost.bak.  Then just startup Outlook and it thinks this is the first time it is starting up…so it re-establishes the .ost from scratch.  If there is any corruption, it will be inside of the old .ost file.

For some of you, this might fix your issue.  For me, it was back to the drawing board.

Second Step – Establish Where the Problem Exists

The second step is to isolate the problem.  Does it exist on the server or is it a problem with Outlook?  You can do this by shutting down Outlook and using Outlook Web Access (OWA).  Is the message delivered in OWA or to a mobile device when Outlook is closed?  If the answer is no, then the issue is NOT an Outlook issue.  If yes, congratulations…your issue is an Outlook Issue.  Switch it away from cached mode and try using Online mode…this should fix any issues you have.  Unfortunately, for my user, the issue did not go away…the message still did not show up.  This tells me the issue has to be server side.

Third Step – Check Spam/Junk Folder & Verify Message Delivery

The next step is to check spam folders and junk folders to make sure that the message isn’t getting held up there.  I made sure to whitelist the email address on both the client and the server side of things and I tested again.  Nothing was going into the spam folders.

I also wanted to make sure, not only with deliver stamps from Exchange, but with absolute proof that the mail message was being delivered.  You can do this by adding yourself as a journal recipient on the user account.  It is my understanding that Journal receipts process before the filters/rules/spam processing do inside an inbox.  So we can prove with 100% certainty that the message is arriving in the user mailbox by adding yourself as journal receipt and watching the mail come in.  This should also tell us that it absolutely is a rule that is the culprit versus anything else.

To do this, open up the Exchange Management Console and right click the user that is having a problem.  Choose properties.  Go to the Mail Flow Settings tab and choose ‘Delivery Options’.  Click ‘Properties’ and under the ‘Forward To’ section, choose yourself.  Don’t forget to check ‘Deliver message to both forwarding address and mailbox’ or your user won’t any mail.  In my case, after I chose these options and had a test message sent out…I received the email in MY inbox but the user still didn’t.  So, we now have 100% absolute proof that the message is making it to the inbox and that the user has a rule that is preventing it from being viewed.  Let’s see how we can fix this issue in the next step.

Fourth Step – Mail Rules

I know the issue isn’t existing on the client side (Outlook) but I went ahead and started Outlook using the /cleanrules flag from a command prompt.  This is supposed to clean out any mail processing rules from the end user.

[box type=”warning”] USE CAUTION! This will remove ALL rules from the user mailbox and the end user should be aware that they will need to recreate any that were previously in place.[/box]

In my case, the user had on 2 rules which were disabled and thus, even with the clean rules switch enabled…the problem was not fixed.

What to do now?  I knew something was grabbing the message from the inbox BEFORE it could synchronize to Outlook.  So I decided to check the rules in OWA to see if there was a difference (there shouldn’t be).  Upon looking in OWA, I found 3 rules present instead of 2.  All three were disabled.  This was different than the 2 disabled rules I found inside of Outlook.  When I looked at the rule, it was taking the ‘ghost message’ from the automated system and moving them to the ‘Inbox’…so there was some kind of loop.  They were arriving in the inbox, and then marking themselves as read and moving themselves to the Inbox again…somehow, they were disappearing from view when this happened.

I figured now it would be a simple case of deleting the rule right?  Exchange had other ideas.  I couldn’t delete the rule…and as I said, it was disabled but somehow still working.  I realized this was going to require more tools than I had on hand.

Last Step – Pesky Rules Managed by MFCMapi Tool

The last effort I could use on this problem is to look and see what was going on with the MFCMapi Tool.  This tool is available from Microsoft Codeplex and is a small executable that allows you to see a bit more going on in a mailbox than what you could normally see using standard tools.

On the client machine where Outlook is installed (the user who’s rules you want to change) open up MFCMapi.exe and choose the profile the user selects when opening their email.  This should give you something similar to the following screenshot:

mfcmapi

Open the rules section by going to QuickStart > Inbox Rules:

mfcmapi2

Search for the rule that you want to delete.  In my case, since all the rules were disabled already…I could delete all 3 rules.  Your situation may be different…the screenshot is actually my inbox rules so there are quite a few more than 3.  However, I was able to delete the rule using this interface where I couldn’t delete it from OWA and I couldn’t see it via Outlook.

mapi3

After deleting the rule, the emails began to show inside the user inbox and the mystery of the disappearing mail messages was solved.  I treated myself to some Scooby Snacks and Old Man Winters would have gotten away with it if it weren’t for those meddling kids.

Hopefully, this helps you out.  It is by no means a comprehensive troubleshooting guide…it’s just one that I often use to figure out where the issue lies.  I start with the client and move on to the server eliminating possible culprits along the way.  If you have any feedback or questions, please let me know in the comments section below.  Thanks for reading!

[box type=”info”] Side Note:  Interestingly enough, you can use this tool, MFCMapi.exe, to remove ghost delegates as well which is something I’ve spoken about in the past.  To do this, use MFCMapi.exe on the client PC where the delegate issue exists and look for the rule whose PR_RULE_PROVIDER is SCHEDULE+ EMS Interface and delete it.  Then have he user remove all delegates and then add back the ones they want.  Things will be magically repaired.[/box]

 

User Appears in “All Users” list but not in Global Address List (GAL)

GAL vs All Users

Ever had a new user appear in the “All Users” Address list that you can access via your Address Book but that DO NOT APPEAR inside the Global Address Book (GAL)?

These are most likely users that have only recently been added…because the minute that Exchange does it’s standard maintenance window, it will most likely update.   But what if, like me, you need to have it update right away due to something like a BlackBerry server?

Through trial and error, I’ve found out WHY the user is not put into the Global Address List right away and how you can force it there.  Please note that I’m using Exchange 2007 with a separate CAS, HT, and Mailbox Server.  First, let’s go over what is happening and why it is and then we’ll go over how we can force the OAB (Offline Address Book) or GAL to update with these users.

What is Happening and Why?

So, you added Joe Smith to the company and you’ve right-click updated the “All Users” address list so he can be included in distribution lists and so that he receives emails on dynamic distribution lists.  Then you right clicked the OAB and selected ‘Update’.  Excellent!  Welcome to the company Joe!  But wait, Joe is not appearing inside the GAL/OAB you just updated!  Why is this problem happening!?  If you’re using the web distribution of the offline address book, the Exchange Client Access Server waits for a ‘polling time’ to arrive before it updates…just like any standard DFS (distributed file system) in Active Directory.  The default time is 480 minutes and of course, we don’t want to wait that long.  You can read all about how OAB via DFS works by visiting this link about Exchange polling times and OAB distribution.

Now that we know it isn’t working by design, how do we fix it?  We manually force it to poll.  We do this through the Exchange Management Shell:

update-filedistributionservice -identity Servername

Make sure you substitute in your Client Access Server where the OAB is distributed with ‘servername’ above.  A warning will appear if you do not have Unified Messaging installed on your server.  If you don’t, it is safe to ignore that warning.

After you’ve forced the update, manually download the address book in any Outlook client and the user will magically appear in the Global Address List.  Hope this helps someone…I know it took me a while to figure out what was happening.

Delegate Management of Distribution Groups

owner of group

Ever wanted to stop managing a distribution group because you get 90 million requests every other day to add someone or remove someone from said group?  Ok, maybe not 90 million but it has to be close to 80 million right?  Sometimes you will run across a distribution group that changes its membership frequently.  The best solution I’ve found is to find a point of contact for that group who will be able to manage the membership.  This means less requests to you in the future.

Normally, what I do is add the person as the ‘owner’ under the properties of the distribution group.  While this does nothing to give the person rights to the group, it does allow me to remember which member of the group is the point of contact.  In the example above, I added Scooby Doo as the owner of the 4th Floor NAs (nursing assistants) distribution group.  This allows me to remember the person (or cartoon dog) I am granting write permissions to manage the group to.

Next you have to do some powershell magic to grant write permissions to that very same person:

Add-ADPermission -Identity:'Group Display Name’ -User:domain\username -AccessRights ReadProperty, WriteProperty -Properties 'Member'

Now, if you wanted to grant permissions to a group of people…you might not be able to add an owner…but you can fill out the ‘notes’ section shown in the picture above and drop yourself a line to remember which Active Directory group has permissions to write membership of the group.  The command here would be:

Add-ADPermission -Identity:'Group Display Name’ -User:'Display Name of Permissions Group’ -AccessRights ReadProperty, WriteProperty -Properties 'Member'

I know this has been covered in countless other blogs and other nooks and crannies of the interwebs…I’m sure I’m not telling anyone anything new.  Please remember though that this blog is not only a tool for people to find on the internet…but also a knowledge repository for myself.  I can find the things that are most useful to me simply because I write about them.  I know where to look after I blog about them…and I can guarantee that this blog will be up indefinitely since I host it myself.  That’s more than I can claim for most blogs/resources of information out there covering these topics…most blogs dry up after a few years.

Hopefully, this information will help a few searching souls out there looking to decrease their distribution list management burden.  Thanks for reading!

Find Number of Mailboxes per Database with Powershell

I previously posted about how to count total number of what I thought was mailboxes on any given server…and today I realized that when I used the command from that post I was coming up with a number just a bit too high for what I was looking for.  I did some research and found out that this command finds any entry for any recipient on the server you’re running it and reports back.  For example, I have just over 2000 objects in Recipient Configuration in the Exchange Management Console (EMC).  This is reported back if I use that command.  What I really wanted to know though was how many users mailboxes I have per database.

Of course, powershell is the easiest way to accomplish this.  Powershell is POWERFULL…but sometimes you just need to do simple things with it and instead of having a simple powershell command, you have a complex one.  It’s not the fault of powershell of course…it’s just how things happen to work.  Just the same, here is the command that you can use to get a nice readout of how many users you have in each database:

Get-MailboxDatabase | Select Server, StorageGroupName, Name, @{Name="Number Of Mailboxes";expression={(Get-Mailbox -Database $_.Identity | Measure-Object).Count}} | Format-Table -AutoSize

Please note this command is for a single mailbox server environment…if you have clustered or multiple mailbox database servers the command will probably be different.  Breaking down the command…with Get-MailboxDatabase we’re selecting all databases in our environment.  Next we’re selecting a few columns of data…server, storage group name.  Next we’re selecting a column titled Number Of Mailboxes and we’re defining an expression.  The expression grabs the identity of the single database and then does a count of each individual mailbox…it then returns that value under the name “Number Of Mailboxes”.  The last bits format the table and autoresize it to fit on your powershell screen.

You could output this to CSV relatively easy as well and you could even incorporate this into a nightly report if you really wanted to.  I know the command isn’t very simple…which is odd considering that it should be much simpler to find out the number of people on a single database.  If there are easier ways to do this…I haven’t found them.  You can use EMC to select the column and then sort and highlight the number of people for a quick and easy way…but I prefer powershell.  I hope this helps someone out!  I know it is a command I can’t live without!

Dear Microsoft, Public Folders

Dear Microsoft,

Public Folders are way to hard to manage in Exchange 2007/2010.  Adding/Removing folders is a pain the neck; even if I’ve got the right permissions, I still don’t have the right permissions.  Please fix this immediately.

Yours Truly,

Teknologist

PS:  Do something about getting Local Continuous Replication (LCR) in 2010 too?  Thanks!

Powershell Recipient Count for Exchange 2007

The other day I wanted to get a quick count of how many recipients I had in the enterprise.  Of course, I wanted to be able to run a powershell command instead of going into the EMC.  I fooled around with the Get-MailboxStatistics command until I got what I wanted and figured it would be a nice little one liner to share:

Get-MailboxStatistics | group MailboxDatabase | format-table count

This is a very simple command that just outputs the count (number) of recipients you have on a given exchange mailbox server.  Of course, if you have more than one server you’ll need to specify that inside the command.  Since I only have one, it’s pretty simple.

UPDATED:  Please note that this returns ALL recipients…not just mailboxes (as I thought when I initially posted this).  That means contacts, distribution groups, etc.   For a way to find how many user mailboxes you have in each database check this post.  Thanks for reading!

Why You Can’t Trust Mobile Device Reports

The Problem

Let’s say you’re an exchange administrator and you use EAS (Exchange Active Sync) to plug smart phones into your Exchange environment.  You’re probably one of the many out there who do this…I do it in my environment.

Then you stumble across a handy powershell script that will allow you to query your environment for mobile phones that have synched on user accounts and report back the last successful synch as well as any phone details that are reported.  I found this one somewhere (can’t remember):

$devices = @()
$mailboxes = Get-CASMailbox -ResultSize:Unlimited | Where-Object {$_.HasActiveSyncDevicePartnership -eq $true -and $_.ExchangeVersion.ExchangeBuild -ilike "8*"}

foreach ($m in $mailboxes)
{
$devices += Get-ActiveSyncDeviceStatistics -Mailbox $m.Identity
}

$devices | Export-Csv DeviceStats.csv

You get a nice little list of stuff right?  This should be every single EAS enabled account that has a phone synching with Exchange right?  Wrong. It absolutely is NOT an accurate list of phones that have synched with your Exchange server.

When I executed that powershell scriptlet above on my system it reported back quite a few phones…but my phone, a HTC Evo, was not on the list.  In fact, my account wasn’t reported on the list.  This despite my device synching just fine every 15 minutes.  The integrity of this ‘report’ has been challenged.  So what’s the deal?

Workaround Solution

A quick investigatory glancing at google brings little results…However, I did notice when using the EMC to highlight my account and going to ‘Manage mobile device” I was in for a suprise….because that link wasn’t there on my account.  That’s right, “manage mobile device” is missing on my account.  This despite having Active Synch enabled under the ‘mailbox features’ tab on my account and despite having my device pair up with Exchange in 15 minute intervals.

Searching google for this problem yeilds much better results.  It seems that a flag embedded for a value in Active Directory doesn’t toggle correctly OR isn’t added into AD at all (perhaps bad replication).  Either way, it means you’ll be whipping out trusty adsiedit.msc (per the forum thread linked to above).  The setting that needs toggled is “msExchMobileMailboxFlags” which should be set to 1.  After setting this, you’ll be able to manage the mobile device AND your synch will be picked up by the powershell report above.

The Real Crux

The real crux of the matter is that this toggle shouldn’t have to be set at all and regardless if it is set or not, powershell should be able to report if a device is synching with Exchange.  There is a reason why RIM is #1 when it comes to businesses and smartphones…it’s because you can have 100% accountability for what is on your network at any given time.  With Exchange 2007 and above, it is unfortunately, much like a ring toss at a circus…sometimes you get a ring on that bottle and win a stuffed giraffe but other times you’re going home without plush pals.

Microsoft has a problem here because you can’t trust your own powershell queries.  If it doesn’t work for this individual area (phones, EAS) then what else doesn’t work?  Do we call into question the entire integrity of all powershell commands and commandlets?  What do you think?  I know this workaround is pretty silly on a huge environment with multiple user containers in AD or even mutlipe forests.  Is the workaround something that is tolerable or should Microsoft do more to fix this broken part of their product?

Exchange 2003 to 2007 Global & Universal Groups

I hit a snag that was a result of my conversion from Exchange 2003 to Exchange 2007.  The snag was with global groups.  The problem is that global groups cannot be expanded by Exchange…so if you have a distribution list that is a member of a global group it will be grayed out in the Exchange Management Console and you will not be able to edit it.  You also won’t be able to right click and convert it to universal because it will give you the error of:

A global group cannot have a universal group as its member

So what to do?  How does one convert this group to a universal one?  The problem doesn’t lie with the group  itself but with the membership of the groups.  In order to convert one, you have to convert them all.

The EXPTA blog has an excellent post regarding what is going on with solutions to boot:

As you may know, Exchange Server 2007 and Exchange Server 2010 force you to create all new distribution groups as universal distribution groups.
The reason for this is that Exchange 2007/2010 requires a local Global Catalog (GC) server in the Active Directory site where Exchange resides to query for group expansion. A GC can expand domain local, global, and universal groups. However, domain local groups (and sometimes global groups) can only be expanded within the domain local scope. If the GC is a member of the companyabc.com domain, it will be unable to expand a domain local group in the sales.companyabc.com subdomain.

I’m going to be posting how they solved their problem for posterity but you can head over to the EXPTA blog for the full post which contains much more meat than this post will.

To solve the problem, query the groups and look at how many you have that are global.  Just open up a command window on a domain administrator account and remember that this command may take a while on a large enterprise:

dsquery group -limit 0 | dsget group -samid -scope -secgrp > Groups.txt

Next run the command to convert the global groups to universal.  There are no adverse problems that will result from this…the conversion doesn’t mess with permissions.

dsquery group -limit 0 | dsmod group -c -q -scope u

You WILL have to run this 2nd command many, many times.  See, each time it cycles through the groups it finds the top level one it has not converted and converts it to universal…there may be 3 more subgroups that need converted but it won’t convert them until the parent is a universal.

For more explanation, see the EXPTA blog link above and hopefully this helps someone out!

How to Fix Ghost Delegates and List Delegates in Exchange 2007

The Problem of Ghost Delegates

There is a problem with Microsoft Exchange 2003 and delegates.  When users are deleted, their delegate or send on behalf attributes are not deleted with them.

This problem has been around since Exchange 5.5 and possibly before and it’s REALLY annoying.  Microsoft has a hotfix available for Exchange 2003…but the problem is, you have to know WHICH mailboxes the fix needs to be run on.  Top that off with my environment actually being Exchange 2007 and NOT 2003 and one might discover an even larger problem.

Let’s backtrack and define the problem with a little story:

Say you work for Acme Corp which has 1500 employees in a single forest environment running Exchange 2007.  John Smith, an employee of 10 years at your corporation has left for greener pastures over at Emca Corp.  John was a delegate with send rights on Frank Doe’s mailbox as he was Frank Doe executive assistant for almost all of those years.

When HR notified your Active Directory administrator that John Smith had left, they promptly disabled and later deleted the user…this may have happened while you were still using Exchange 2003.

Now you have a problem…John Smith has left the company and was a delegate on Frank Doe’s mailbox.  When someone sends an invitation to a meeting with Frank Doe or mail to a group that Frank Doe is a part of…they may get an Non Delivery Notice (NDR) similar to the following:

Smith, John
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

_____

Sent by Microsoft Exchange Server 2007

This glitch is EXCELLENT for annoying users everywhere!  It’s also a potential problem as someone could mass email Frank Doe and potential generate a NDR in addition to each email they send.  If they were to identify a few more people who may have had this problem, the possibility of having twice the amount of email generated and thus, twice the amount of email traffic, is something that large corporations may not want to have in their existing Exchange environments.

Microsoft realized that they had a problem on their hands and released a fix that you apply to mailboxes that suffer from the ‘ghost delegate’ “feature”.  Great right?  This fix is of course for Exchange 2003…so if you’re using that, you’re set.  You still will need to know a major detail before proceeding though:

  1. How many mailboxes have this problem? (usual response)

Therein lies the major problem.  How do you identify which mailboxes have old ghost delegate cruft still floating around generating NDR’s all over the place?  Especially in smaller environments where EVERYONE was a delegate of everyone else?

It’s impossible.

You can try to identify which mailbox has the problem but you would have to use the process of elimination…not a very time saving process and definitely not something I want to do (imagine visiting 50+ users!).  Instead,  I elected to identify all current users with delegates on their mailbox because chances are that the ghost delegate was once a delegate of these identified users.  I plan on cross referencing these users with a distribution list that is generating the NDR to properly identify the problem.  So, onward with how to identify the potential problem with a powershell query.

Identifying Problem Mailboxes with Powershell

Search the web, I’ve found many different ‘solutions’ to this problem with none of them getting things exactly how I needed them to be.  Some of the solutions would run a query and return information that was valuable…but not valuable enough.  Other queries should have worked but didn’t.

I’m by no means a powershell expert so I’m absolutely sure this little scriptlet can be improved.  It does the job though by returning anyone who has a delegate and listing who each delegate is.  So without further fanfare, the powershell command:

Get-Mailbox -resultsize unlimited | Where {$_.GrantSendOnBehalfTo -ne $null} | select Name, @{Name='GrantSendOnBehalfTo';Expression={[string]::join(";", ($_.GrantSendOnBehalfTo))}} | Export-CSV C:\SendOnBehalfTo.csv -noTypeInformation

Let’s break this command down.  The first portion Get-Mailbox -resultsize unlimited retrieves all user mailboxes and doesn’t limit to 1000 as is default with Exchange 2007.  We pipe this command into the next one with the ‘|’ symbol.  Here we use a conditional Where and select the attribute GrantSendOnBehalfTo returning only mailboxes from the first part of the command where said attribute is NOT null or empty.

Next, out of these mailboxes that don’t have the GrantSendOnBehalfTo attribute as empty, we select the Name of the user.  Now we should be able to stop here, however, we’re working with a string attribute here and returning Name will return a Multivalued property instead of the proper DN or user name we’re looking for (something like this Microsoft.Exchange.Data.MultiValuedProperty`1[Microsoft.Exchange.Data.Directory.ADObjectId] ).  To get what we need, we have to join the Multivalued property (string) with the results from the first half of the query.  To do this we create a commandlet and use the join command to bind the first part of our command to the multivalued property and translate that property into something readable for us.

It’s in the string conversion section that most people get frustrated with.  I know I got frustrated with it and used a portion of a commandlet for allowing a user or group to only accept messages from certain mailboxes…I just adapted that string conversion and join for my own purposes.  Like I said, I’m not extremely fluent in the ways of the powershell script…I just know that adapting it worked.

Identifying the Problem Mailboxes with Active Directory Queries

Of course, after spending 6-8 hours constructing my query in powershell I found a simple little tool from Joeware.net called “ADFind” that allowed me to execute a simple AD query and output all of the same information into a much more readable format than my powershell command.  If you’d like to do the same thing, head over to the ADFind page, enter your email and download the tool.  Extract it to your desktop and then open a command prompt and change directory to your desktop.  Next, enter a proper AD query with the adfind.exe prepended:

AdFind.exe -default -f "&((homeMDB=*)(publicdelegates=*))" publicdelegates > C:\delegates.txt

The output from Joe’s tool is MUCH nicer than what I was able to accomplish using powershell.  I’m sure someone will be able to take what I did with powershell and improve on it…but when there are handy tools like joeware provides, what need is there?

Implementing the Microsoft Fix

The ‘official’ fix from Microsoft is to install a hotfix if you’re running Exchange 2003.  Supposedly, Exchange 2007 doesn’t suffer from this problem…but there is a caveat there.  If, like me, you’ve upgraded from an Exchange 2003 environment that suffered from this problem…you migrate the problems with it!  So, I have an Exchange 2007 environment suffering from ghost delegates and NDR’s.

How to remedy this?  There are 3 directions provided.  The first from Microsoft is to go inside the tools >> options menu in Outlook and delete the delegate.  The problem with ghost delegates is that they aren’t there…which renders this fix completely useless.  The second solution is to launch Outlook with the /cleanrules switch.  The third solution out there is to use the MFCMapi Editor on the user mailbox that has the problem, find the hidden bits, and delete them.  The problem with this solution is most people AREN’T comfortable with editing the profile inside a snap-in…it’s much like using ADSIEdit to edit AD manually and can be overwhelming.

Examining the 3 options, it’s obvious that /cleanrules switch is probably the easiest to implement.  The problem is that it will delete ALL rules from the mailbox and if you have users who have been around for quite some time it means tons of rules.  The other problem is that it has to be run manually on EACH mailbox.  This of course is bad if you have an elaborate delegate system.

When we identified who has delegates with our queries above, we most likely found a culprit for who is having the problem and generating the NDR.  For me it was rather easy because I cross referenced my list of those with delegates with a distribution list.  When one of the unit secretaries sent email to this distribution group, it would also generate the dreaded NDR.  This means that a member of the distribution group has a ghost delegate.  Cross referencing gave me a list of 6 people to run the /cleanrules switch on versus the over 50 delegate mailboxes from the queries above…a much smaller number to visit.

I hope my confusing process can help someone out there and please improve on anything you see here…as I said, I’m by no means an expert…I just like to document my learning process to help others and also to remind myself of the fixes I find :)  Thanks for reading!

Fowler, Carol
The recipient’s e-mail address was not found in the recipient’s e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

 

_____
<!–[if !supportLineBreakNewLine]–>
<!–[endif]–>

Sent by Microsoft Exchange Server 2007

1 2