I have a situation in my environment where users are getting NDR's for users who no longer work here and their AD Account / Mailbox has been deleted.
I initially thought it was an issue with personal address books of users containing contacts of the old users. That is not the case. I then thought there may have been an old rule or delegate causing the issue. Apon investigation in the users mailbox, that
appears to not be the case. However after further research, I found that was indeed the issue (an old delegation to a defunct user). The fix is to use MFCMAPI to clear out the hidden rule in the metadata of the mailbox itself.

While it fixes the problem, I have to wonder how many more of these situations exist out there that I dont know about. Some of these issues I have manually fixed are for users who have left the company in some cases YEARS ago, but the end user just dealt
with it for years rather than ask for help.
Is there any way for me to be able to identify these hidden "blank rules" or broken delegations? Since it's in the mailbox metadata, I kind of figure that I wont be able to get to it with powershell.

I am open to suggestions. Thanks in advance,
-Troy

Need to support users over the internet? click here try our remote control online beta

We had this happen the other day. I' pretty sure we remedied it by logging into the mailbox where the notifications were coming from (a shared mailbox) with the Outlook switch "/cleanrules", which cleared up the delegation rules tied to the mailbox,
removing the unnecessary NDRs.
You can also check out the "publicDelegates" attribute on your domain users. The value is set to a delegate's DN. Run a PS script to see who has that attribute populated, and check it against your current user accounts.

There is an amazing pack of free network admin tools. click here to download it

I'm not sure that the /cleanrules switch actually works on these hidden blank rules which dont show up in the client, but I will try that. At the end of the day though, that is not a way to identify who is in this situation and it has the negative effect
of deleting their legitimate rules. I will try your other suggestion as well to try to identify who has the rules.
If anyone else has suggestions, please feel free to chime in.

There is an amazing pack of free network admin tools. click here to download it

Well it worked for us! :)
As for my second suggestion, that would only return who has delegates set and who those delegates are (in the CN=user,OU=department,DC=domain,dc=com format). You can then query the list returned to see if any of them are missing/disabled, which may
cause some issues.
Good luck!

Need to support users over the internet? click here try our remote control online beta

I think the publicdelegatesBL AD attribute will get us where we need to be. I was able to get what I need through powershell. Unfortunately since it's in fully quallified LDAP format, it's going to be a little more work, but hey, it's a start. Thanks for
the advice.

Need to support users over the internet? click here try our remote control online beta

On Thu, 21 Jun 2012 21:02:05 +0000, Troy12n wrote:

>I think the publicdelegatesBL AD attribute will get us where we need to be.


I don't think so. Right idea, but the wron property.

>I was able to get what I need through powershell. Unfortunately since it's in fully quallified LDAP format, it's going to be a little more work, but hey, it's a start. Thanks for the advice.


The publicDelegatesBL contains the name(s) of the mailbox(es) on which
this mailbox has been named as a delegate.

The publicDelegates contains the addresses of mailboxes that ARE
delegates on this mailbox.

If "Mailbox1" had two delegates ("Mailbox2" and "Mailbox3") then:

publicDelegates on Mailbox1 contains "Mailbox2" and "Mailbox3"
publicDelegatesBL on Mailbox2 contains "Mailbox1"
publicDelegatesBL on Mailbox3 contains "Mailbox1"

---
Rich Matheisen
MCSE+I, Exchange MVP
--- Rich Matheisen MCSE+I, Exchange MVP

There is an amazing pack of free network admin tools. click here to download it

Does the publicDelegatesBL attribute only exist with specific versions of AD/Exchange? I ask because I do not have that attribute on any of my users' accounts who are delegates. My domain and forest are at 2003 functional level
and I have added 2008 R2 DCs. I am running Exchange 2003 but have introduced 2010 servers into my domain.

Not trying to hijack the thread; I'm just curious.

Need to support users over the internet? click here try our remote control online beta

On Thu, 21 Jun 2012 21:02:05 +0000, Troy12n wrote:

>I think the publicdelegatesBL AD attribute will get us where we need to be.


I don't think so. Right idea, but the wron property.

>I was able to get what I need through powershell. Unfortunately since it's in fully quallified LDAP format, it's going to be a little more work, but hey, it's a start. Thanks for the advice.


The publicDelegatesBL contains the name(s) of the mailbox(es) on which
this mailbox has been named as a delegate.

The publicDelegates contains the addresses of mailboxes that ARE
delegates on this mailbox.

If "Mailbox1" had two delegates ("Mailbox2" and "Mailbox3") then:

publicDelegates on Mailbox1 contains "Mailbox2" and "Mailbox3"
publicDelegatesBL on Mailbox2 contains "Mailbox1"
publicDelegatesBL on Mailbox3 contains "Mailbox1"


While true, you have to realize my issue is that I am looking for bogus delegations for users who no longer exist. IE: Their AD account has been deleted, so I cant find the publicDelegates attribute on an AD account that does not exist in my AD can I?
By using publicDelegatesBL, I can find these, with a little extra work find who has delegates for deleted users. Which is what is causing my issue.

There is an amazing pack of free network admin tools. click here to download it

Does the publicDelegatesBL attribute only exist with specific versions of AD/Exchange? I ask because I do not have that attribute on any of my users' accounts who are delegates. My domain and forest are at 2003 functional level
and I have added 2008 R2 DCs. I am running Exchange 2003 but have introduced 2010 servers into my domain.

Not trying to hijack the thread; I'm just curious.

I dont know the answer to your question, but I can tell you I am running Exchange 2007 SP3 UR5 in a 2003 forest/domain functional level. Most of my DC's in my forest are 2003, but it happens to be that the majority of DC's at sites containing Exchange
servers are 2008R2.

There is an amazing pack of free network admin tools. click here to download it

On Fri, 22 Jun 2012 13:15:40 +0000, Paul Newell wrote:

>Does the publicDelegatesBL attribute only exist with specific versions of AD/Exchange?


Yes It's been that way forever.

If someone is a delegate on another mailbox (i.e. their DN is present
in the publicDelegates property) then the AD populates their
publicDelegateBL property with the DN of that mailbox.

>I ask because I do not have that attribute on any of my users' accounts who are delegates.


What are you using to look for those attributes?

>My domain and forest are at 2003 functional level and I have added 2008 R2 DCs. I am running Exchange 2003 but have introduced 2010 servers into my domain.

>
>Not trying to hijack the thread; I'm just curious.

Not a problem.

---
Rich Matheisen
MCSE+I, Exchange MVP
--- Rich Matheisen MCSE+I, Exchange MVP

Need to support users over the internet? click here try our remote control online beta

On Fri, 22 Jun 2012 16:46:48 +0000, Troy12n wrote:

>On Thu, 21 Jun 2012 21:02:05 +0000, Troy12n wrote: >I think the publicdelegatesBL AD attribute will get us where we need to be. I don't think so. Right idea, but the wron property. >I was able to get what I need through powershell. Unfortunately since
it's in fully quallified LDAP format, it's going to be a little more work, but hey, it's a start. Thanks for the advice. The publicDelegatesBL contains the name(s) of the mailbox(es) on which this mailbox has been named as a delegate. The publicDelegates contains
the addresses of mailboxes that ARE delegates on this mailbox. If "Mailbox1" had two delegates ("Mailbox2" and "Mailbox3") then: publicDelegates on Mailbox1 contains "Mailbox2" and "Mailbox3" publicDelegatesBL on Mailbox2 contains "Mailbox1" publicDelegatesBL
on Mailbox3 contains "Mailbox1"
>
>While true, you have to realize my issue is that I am looking for bogus delegations for users who no longer exist.


Oh, believe me, I know. I know.

>IE: Their AD account has been deleted, so I cant find the publicDelegates attribute on an AD account that does not exist in my AD can I?

No, but your problem isn't with the presence of the publicDelegates
property on an existing mailbox, it's the *contents* of the
publicDelegates property.

If the delegate's mailbox has been removed the publicDelegates
property is still going to contain the DN of the AD user to which the
mailbox belonged.

When you remove the delegate from the AD the DN will be removed from
the publicDelegates property on the mailbox. The delegate WILL NOT be
removed from the mailbox (note the difference between the
publicDelegate property in the AD and the contents of the mailbox).

>By using publicDelegatesBL, I can find these,

No, I'm afraid you can't. The publicFolderBL property would be on the
AD user that's been removed from the AD (i.e. the missing delegate),
and when the AD user was deleted the contents of the publicDelegateBL
property was used to find all the mailboxes on which that user was a
delegate and then the AD removes the user's DN from the mailbox's
publicDelegates property. At this point the AD is useless for finding
mailboxes that named the deleted AD user as a delegate.

>with a little extra work find who has delegates for deleted users. Which is what is causing my issue.


You can try this:

http://gsexdev.blogspot.com/2006/08/reporting-on-meeting-delegate-forward.html#!/2006/08/reporting-on-meeting-delegate-forward.html


The problem here is that you can't install CDO 1.2 on a machine that
has the Exchange 2003 management tools on it, and you can't install
CDO 1.2 on a client machine that has Outlook 2010 on it.

If you find yourself in that situation you can use another version of
the script that uses Redemption:

http://gsexdev.blogspot.com/2005/10/reporting-on-forwarding-rules-in.html#!/2005/10/reporting-on-forwarding-rules-in.html


I had to fiddle with this one for a bit to make it work. You may have
to, too. But at least you'll be able to get a list of all the rules
that are either a "Delegate-Forward-Rule" or a "Forward-Rule".

---
Rich Matheisen
MCSE+I, Exchange MVP
--- Rich Matheisen MCSE+I, Exchange MVP

Need to support users over the internet? click here try our remote control online beta

...
>I ask because I do not have that attribute on any of my users' accounts who are delegates.


What are you using to look for those attributes?
...

--- Rich Matheisen MCSE+I, Exchange MVP
I used ADSIedit and I used the "Attribute Editor" tab on the user account (both using Windows 7 SP1 RSAT), neither of which showed the "publicDelegatesBL" attribute.

Using ADSIedit on my Windows XP vm, however, I do see that attribute.

So I guess the question now is "How can I query that attribute when 2003 and XP are completely off my domain?". Does anyone know if you can check that attribute another way? Just PowerShell?

Need to support users over the internet? click here try our remote control online beta

On Mon, 25 Jun 2012 13:50:43 +0000, Paul Newell wrote:

>... >I ask because I do not have that attribute on any of my users' accounts who are delegates. What are you using to look for those attributes? ...

>--- Rich Matheisen MCSE+I, Exchange MVP
>
>I used ADSIedit and I used the "Attribute Editor" tab on the user account (both using Windows 7 SP1 RSAT), neither of which showed the "publicDelegatesBL" attribute.

>
>Using ADSIedit on my Windows XP vm, however, I do see that attribute.
>
>So I guess the question now is "How can I query that attribute when 2003 and XP are completely off my domain?". Does anyone know if you can check that attribute another way? Just PowerShell?


I prefer using LDP.exe. I hate squinting at the tiny edit boxes and
fonts that you're forced to use with ADSEDIT. I'll use ADSIEDIT if I
have to, but most of the time LDP is better than "good enough".

---
Rich Matheisen
MCSE+I, Exchange MVP
--- Rich Matheisen MCSE+I, Exchange MVP

There is an amazing pack of free network admin tools. click here to download it

...
>I ask because I do not have that attribute on any of my users' accounts who are delegates.


What are you using to look for those attributes?
...

--- Rich Matheisen MCSE+I, Exchange MVP

I used ADSIedit and I used the "Attribute Editor" tab on the user account (both using Windows 7 SP1 RSAT), neither of which showed the "publicDelegatesBL" attribute.

Using ADSIedit on my Windows XP vm, however, I do see that attribute.

So I guess the question now is "How can I query that attribute when 2003 and XP are completely off my domain?". Does anyone know if you can check that attribute another way? Just PowerShell?


This may seem like a silly question, but do you have any delgates on your mailbox or are you a delegate on anyone else's? The attribute will obviously not be populated unless you were.

What you describe about XP showing one thing and 2008/Vista/7 showing something different does not surprise me. All sorts of silly shennanigans have been happening like that since first using Win7, that's why my primary admin box is still XP. That and certain
tools no longer work on 7.
I try to primarily use powershell when possible, it's quicker, especially when you know the name of the attribute you are looking for.

Need to support users over the internet? click here try our remote control online beta

Yes, I'm a delegate to a shared mailbox. I also checked out the accounts of users who I know are delegates of managers, and managers who I know have delegates. I can see the publicDelegatesBL attribute with the 2003 Support Tools' ADSIedit, but
not the Windows 7 RSAT ADSIedit (or the "Attribute Editor" tab in ADUC).
The publicDelegates attribute, however, can be viewed/edited by all three tools.

Odd...

There is an amazing pack of free network admin tools. click here to download it

Yes, I'm a delegate to a shared mailbox. I also checked out the accounts of users who I know are delegates of managers, and managers who I know have delegates. I can see the publicDelegatesBL attribute with the 2003 Support Tools' ADSIedit, but
not the Windows 7 RSAT ADSIedit (or the "Attribute Editor" tab in ADUC).
The publicDelegates attribute, however, can be viewed/edited by all three tools.

Odd...

Sounds like a bug to me. I just replicated your issue on my Windows 7 box. The attributes show up fine in XP/2003 but not Win7/Win2008R2.
The attributes do show up from Win7 when running powershell. Get-Aduser -identity %myuseraccount% -properties * |ft samaccountname, publicdegates, publicdelegatesbl
Hey Microsoft, how about someone register this as a bug!
At any rate, back to my initial issue which prompted me to go down this path. I verified that the publicdelegates and publicdelegatesbl do not show the users who had these broken delegations. I had to go in with the MFCMapi tool to identify and remove these
blank rules. Now back to the "how to identify them". I will try the script mentioned, but I dont think that will do it, as it is keying of these attributes which I have found are immaterial to my issue.

Need to support users over the internet? click here try our remote control online beta

On Tue, 26 Jun 2012 12:47:35 +0000, Troy12n wrote:

>
>
>... >I ask because I do not have that attribute on any of my users' accounts who are delegates. What are you using to look for those attributes? ...

>--- Rich Matheisen MCSE+I, Exchange MVP
>
>
>
>I used ADSIedit and I used the "Attribute Editor" tab on the user account (both using Windows 7 SP1 RSAT), neither of which showed the "publicDelegatesBL" attribute.

>
>Using ADSIedit on my Windows XP vm, however, I do see that attribute.
>
>So I guess the question now is "How can I query that attribute when 2003 and XP are completely off my domain?". Does anyone know if you can check that attribute another way? Just PowerShell?

>
>This may seem like a silly question, but do you have any delgates on your mailbox or are you a delegate on anyone else's? The attribute will obviously not be populated unless you were.


Sadly, the AD isn't the overriding authority -- the (hidden) rules in
the mailbox are.

While it's true that the publicDelegates/publicDelegatesBL should be
populated, it's easy enough to depopulate them and still leave the
mailbox contents undisturbed.

>What you describe about XP showing one thing and 2008/Vista/7 showing something different does not surprise me. All sorts of silly shennanigans have been happening like that since first using Win7, that's why my primary admin box is still XP. That and
certain tools no longer work on 7.
>
>I try to primarily use powershell when possible, it's quicker, especially when you know the name of the attribute you are looking for.


.. . . and you know what the attribute's called in the Powershell
object, and whether the property's been exposed at all. Not being able
to access the "description" property on a user object's always been a
problem for me. :-)

---
Rich Matheisen
MCSE+I, Exchange MVP
--- Rich Matheisen MCSE+I, Exchange MVP

Need to support users over the internet? click here try our remote control online beta