Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 189
  • Last Modified:

Mystery AD User Account

Very often when a user creates a meeting request and invites several attendees, they get an automated response stating that one of the attendees could not be reached, now here's the strange bit.....it's always the same user name, they are never even invited to the meeting, and......this particular user left the company months ago and the account no longer exists in AD.

How can I track down where this account is being found??

Here is the message we get:
The following recipient(s) could not be reached:

      < user name removed for obvious reasons :) > on 2/10/2009 10:41 AM
            The e-mail account does not exist at the organization this message was sent to.  Check the e-mail address, or contact the recipient directly to find out the correct address
0
BrianFord
Asked:
BrianFord
  • 11
  • 5
  • 5
1 Solution
 
lamaslanyCommented:
It is possible that one of the actual recipients has a rule forwarding mail to the non-existant user.  This may be either a client-side or server-side rule.
0
 
lamaslanyCommented:
Are you able to send a test invite to the same recipients to see if you can duplicate the problem?
0
 
BrianFordAuthor Commented:
yep, I think I have narrowed it down to one particular recipient and I can replicate the issue, I have checked all the server side security and mail delivery options and there is no sign of the mystery account, I will check the client side rules shortly
0
Get your Disaster Recovery as a Service basics

Disaster Recovery as a Service is one go-to solution that revolutionizes DR planning. Implementing DRaaS could be an efficient process, easily accessible to non-DR experts. Learn about monitoring, testing, executing failovers and failbacks to ensure a "healthy" DR environment.

 
BrianFordAuthor Commented:
I've checked the client side rules and there's nothing there either, this is very strange :(
0
 
lamaslanyCommented:
What version of Outlook are you using?  Which email server software?
0
 
BrianFordAuthor Commented:
Sorry, Outlook 2003 with Exchange Server 2003
0
 
lamaslanyCommented:
Do you get the same problem if you send the invite using OWA?  (rules out Outlook...)
0
 
BrianFordAuthor Commented:
Yes, I tried though OWA and get the same issue, I have chacked all the groupd that the valid recipient belongs to and I don't see any reference to the invalid recipient
0
 
lamaslanyCommented:
Does the valid recipient have any additional SMTP aliases?  (grasping at straws now!)
0
 
MesthaCommented:
0
 
BrianFordAuthor Commented:
Thanks, I did check the delegates and the invalid account was not there, so this could be the problem, I will carry out the procedure in the above and see if that fixes it :)
will update you shortly :)
0
 
BrianFordAuthor Commented:
I tried the procedure above but unfortunately it didn't work :(
I looked for adsiedit.msc to scan but I can't find that either, just not my day :(
0
 
MesthaCommented:
ADSIEDIT isn't installed on the servers by default. You need to install the Windows Support Tools to get adsiedit.msc on the machine.

-M
0
 
BrianFordAuthor Commented:
Thanks,
I've installed the tools and ran ADSIEDIT, unfortunately the search did not find the roque account :(
0
 
MesthaCommented:
There will be a reference in there somewhere. Exchange doesn't forward messages on its own. IF you have rules out rules and a forward then it can only be a delegate.

How did you search? If you went looking for the rogue user name then that would probably fail. You need to look at the properties of the user who receiving the original message and go through each attribute. Its called something like msdelegate - something like that.

-M
0
 
BrianFordAuthor Commented:
thanks Mestha,
look at the Attribute Editor for the valid recipient and the only refernce to delegstes in there where Public Delegate & Public Delegate BL, both of the were <not set>
I checked every entry that had a value and could not see any other reference :)
hey, if this was easy everyone would be doing it :)
0
 
MesthaCommented:
Have you tracked down which user needs to be invited to generate the error?

-M
0
 
BrianFordAuthor Commented:
yes, I can reproduce it everytime, I've checked just about every attribute/security/delegation etc.. that I can find :(
0
 
MesthaCommented:
There has to be a reference somewhere.
You have been through the account in Outlook carefully?
Do you have more than one domain controller? Have you checked adsiedit against both DCs?

-M
0
 
BrianFordAuthor Commented:
good point, we have a secondary DC, I will check against that also (probably tomorrow now when I get back in the office :)
I agree it must be there somewhere.
Thanks for your help with this
0
 
BrianFordAuthor Commented:
I've searched everywhere I can to find this delagation, but still no joy, it's very frustraing,  I'm certainly not an expert in this field so perhaps I'm missing something, here's what I've done so far:
Used the add/remove delagates procedure described above
Searched through all the attributes for the valid account using adsiedit.msc taking particular notice to publicDelegates and publicDelegatesBL attributes
And the roque name just doesn't show up any where :( I'm at a loss
0

Featured Post

VIDEO: THE CONCERTO CLOUD FOR HEALTHCARE

Modern healthcare requires a modern cloud. View this brief video to understand how the Concerto Cloud for Healthcare can help your organization.

  • 11
  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now