With that many CA's and that many ADC's deployed, you're likely not going to have enough hours in the day to find your data. Yann, I'm sure I'm not telling you something you don't already know, but the level of complexity you have likely translates that you won't be able to pinpoint this the way you want to.  It's much more likely that, even with the political issues and delays, you'll finish the migration long before you've got a satisfactory answer.  You have way more variables than is conducive to the troubleshooting your boss wants done.
 
That said, if you really really really want to get the troubleshooting done, you might want to suggest a change freeze for 7 days while you watch the ADC do it's work (and probably stabilize).  That's 7 days of no change in either 5.5 or Active Directory.
 
joe is correct in that the ADC was not intended to do what you describe.  I've seen it do what you describe and do it quite well, but it's not meant for that duration. MIIS' IIFP is a better fit for that type of work and for that duration.
 
My guess is that some admin likely made a change to something, and didn't realize the impact it would have on the group in question. It could also be a 5.5 troubleshooting endeavor that whacked that user that would otherwise seem totally unrelated. 
 
The troubling part is that you're trying to prove it was not there. That tells me that you likely have a situation where one is saying one thing and another is saying that's not so. You're trying to prove that no change took effect and an admin made a mistake and didn't add the user, but instead is being touchy about the change and blaming their issues on the migration even though it technically is no longer a migration but a way of life :)   That's a slippery slope you're travelling on.
 
Best of luck Yann.
Write if you need anything.
 
 
Al


 
On 5/29/06, joe <[EMAIL PROTECTED]> wrote:
If you ask MSFT, they will tell you that the ADC was not really designed to run that long. For something like that they would have (or if you got the good Enterprise Exchange MCS guys) recommended going to some sort of metadirectory product that is robust and has good error handling. In one of the companies I worked with we took half a year or so to do the migration and were told that was way over the length of time the ADC should be running. It is a product to get you over a hump, not something to stay running on. We only had 3 ADCs and less than 20 CAs and it was a big PITA.
 
The date after the value indicates the last change to that value. So if it says PRESENT 06-15-2006 it means that it was added on June 15 2006 and hasn't changed since.
 
 


From: [EMAIL PROTECTED] [mailto: [EMAIL PROTECTED]] On Behalf Of Yann
Sent: Monday, May 29, 2006 5:22 PM
To: [email protected]
Subject: Re: [ActiveDir] [OT] Active Directory Connector: member issues.

 
Hi Al,
 
We have around 300 CAs localizd in 7 ADCs Servers.
The migration e5.5 to e2k3 started last summer 2005 and will be ended (hope it will) in june 2007. We can not hurry for political reasons ;(, so i have to maintain the 2 databases as consistent as possible. So unfortunately tshoot ADC is my first goal in this situation.
 
I will follow tomorrow your advices.
But for a first tshoot, can repadmin /showobjmeta, as I stated earlier, prove that no modification to the user DL membership has occured since the date mentioned after "member"?
 
This is the whole command.
 
repadmin /showbjmeta mydc "dn_of_the_problematicDL_in_myAD" and i see that the user in question has this information:
PRESENT "dn_of_the_user"
                 member 06-15-2006 13:04:26
 
Thanks again.
 
Yann

Al Mulnick <[EMAIL PROTECTED]> a écrit :
The issue is not terribly uncommon.  It's one of the joys of having two directories joined like this. The absolute best way to deal with this is to hurry up and get off of 5.5 as fast as you possibly can. Things like this occur and it's barely worth your time to troubleshoot it.  The complexity of your setup dictates that the troubleshooting time will be magnitudes longer than with a single system.
 
Anyway, if you suspect that the users are being removed, turn on auditing on Active Directory for modifications, turn up the diagnostic logging on the ADC itself, and turn up the logging on Exchange 5.5.  This will help you to narrow down the source system next time this occurs.  Once you find out what the source system is, you can refine the troubleshooting that much more.
 
Be sure to increase the size of your logs and be sure to scrape them off to some other repository so that wrapping won't cause you to miss the event.  MOM is a great tool for this for what it's worth.
 
To reduce the possibilities, you may want to reduce the number of possible input vectors i.e. reduce the number of users with administrative abilities to modify these groups. And if it's the same groups each time, focus on those :)
 
I know that what I'm suggesting is politically difficult. See the beginning of my email to see my thoughts on this.
 
Al

 
On 5/29/06, Yann <[EMAIL PROTECTED]> wrote:
Hello all,
 
I have an issue where member(s) of distribution list (DL) in exchange 5.5 disapear and this state is replicated via my Connection Agreement to my AD2k3.
I have not seen this on my own but some adminitrators (always the same guys :( ) frequently complain to my boss that some users disapear and so are not able to receive mail sent to this DL. They usually resolve this issue by putting those users back in the DL.
So my boss urges me to resolve this issue ASAP !
I know that there was no issue possible but for my safety ;o) I'd like to give my boss with some proofs.
 
So is there a way to track possible user disapearing from a DL in e5.5/AD/ADC ?
 
In active Directory, i used repadmin /showbjmeta mydc "dn_of_the_problematicDL_in_myAD" and i see that the user in question has this information:
PRESENT "dn_of_the_user"
                 member 06-15-2006 13:04:26
 
FYI: The admin stated that user(s) disapear around the 06-20-2006.
Is the info  from repadmin tells me that the user is a member of the DL since 05-15-2006 13:04:26 and since that date, the user has never disapeared ?If yes can i considered this as a proof that those admins lies ?
The replication planning of my Connection Agreement between e5.5<->AD is set to "always".
 
Thanks very much for help,
 
Yann
 
 
 

Faites de Yahoo! votre page d'accueil sur le web pour retrouver directement vos services préférés : vérifiez vos nouveaux mails, lancez vos recherches et suivez l'actualité en temps réel. Cliquez ici.



Yahoo! Mail réinvente le mail ! Découvrez le nouveau Yahoo! Mail et son interface révolutionnaire.


Reply via email to