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

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.

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.

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!

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.

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

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.

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.

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.

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

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

... >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?

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

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...

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.

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

So there is really no way to find these hidden rules in the mailbox except to manually check them using something like MFCMapi? If at the end of the day, that's the answer, that sucks. But at least my wild goose chase is over. "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. :-)" Yes, but in regards to ADSIEdit not showing values correctly, it's obviously a bug and should be fixed...

On Mon, 2 Jul 2012 13:18:33 +0000, Troy12n wrote: >So there is really no way to find these hidden rules in the mailbox except to manually check them using something like MFCMapi? Did you read my other answer that gave you a link to some of Glen Scales scripts to automate this task? >If at the end of the day, that's the answer, that sucks. But at least my wild goose chase is over. > >"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. :-)" > >Yes, but in regards to ADSIEdit not showing values correctly, it's obviously a bug and should be fixed... Remind me of what you're referring to. The AD correctly shows the publicDelegates and publicDelegatesBL. The AD has no idea about what's in the mailbox. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

On Mon, 2 Jul 2012 13:18:33 +0000, Troy12n wrote: >So there is really no way to find these hidden rules in the mailbox except to manually check them using something like MFCMapi? Did you read my other answer that gave you a link to some of Glen Scales scripts to automate this task? >If at the end of the day, that's the answer, that sucks. But at least my wild goose chase is over. > >"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. :-)" > >Yes, but in regards to ADSIEdit not showing values correctly, it's obviously a bug and should be fixed... Remind me of what you're referring to. The AD correctly shows the publicDelegates and publicDelegatesBL. The AD has no idea about what's in the mailbox. --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

If you look in attribute editor in Windows 7 ADSI Edit, it does not show the attributes, but if you do in Server 2003/XP ADSI Edit it does.

On Tue, 3 Jul 2012 20:59:57 +0000, Troy12n wrote: >If you look in attribute editor in Windows 7 ADSI Edit, it does not show the attributes, but if you do in Server 2003/XP ADSI Edit it does. Another reason to use LDP.exe, I suppose. Using ADSIEDIT.msc on a Win7 machine I can see the publicDelegates property but not the publicdelegatesBL. Maybe they did that becasue you can't edit a property that's a back-link? --- Rich Matheisen MCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP