Hmmm.... This is interesting. You're saying that your client-visible data is less reliable than your Active Directory data? Really? Is that perception echoed by your end users? If not, I think you may want to rethink that approach.
Mail, mailnickname, etc are all very important to Exchange operation; changing them would open the door for problems in your implementation, some of which you may not see immediately. However, alias field is not guaranteed unique for what it's worth. It's RDN is unique in that path, but the only fields that are guaranteed to be unique in a 5.5 directory are the X.400 and SMTP addresses. Outside of that, any field out there can be duplicated in a separate RDN. One thing that may help is to change your thinking on what you are about to do. You are NOT merging two directories. You are joining two directories. There's a subtle yet important distinction that will help you better understand what's important to you and what's not. For example, if you join directories, you are in essence making one larger directory. If you merge them, it indicates a one time update of both and then getting rid of one. You are not doing a one timer here. When you join directory services, you have to decide which is authoratative for which attributes. In the case of ADC, the default is to assume that 5.5 is authoratative for mail-related attributes. Why? Likely because it's more disruptive to the end user population to change the GAL. Since the GAL is built on mail-related attributes, it makes a LOT of sense to go down this path. My advice? Fix your BAS 5.5 directory attributes prior to joining the two directories. Don't let the ADC be the bad guy else you'll be chasing that forever and a day. The ADC purpose is to help you join the directories in support of upgrade, not to fix years of bad processes and dirty data. If you try to use it that way, you may not be very happy with the results. That said, you can modify what the ADC will consider 5.5 authoratative for. The reason why you would do this is to prevent 5.5 from overwriting good data. Since it's a join and not a merge :) it will the authoratative attributes will also overwrite the 5.5 entries. But you can control which attribute is considered authoratative if you know what you're trying to accomplish and it's impact. I don't advise changing the alias attribute to anyone I've done this for because it's not seen by the regular Active Directory admins anyway unless they have the Exchange dll's loaded or they're looking via some other method outside of ADUC. It's non-consequential for anything other than a mailer. The attribute that usually gives the most heartburn is the display-name <--> displayName join and you can find information about how to properly map this change in KB's. -AJM -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner Sent: Monday, August 09, 2004 8:39 AM To: [EMAIL PROTECTED] Subject: RE: [ActiveDir] adc replication Bill, thanks for prompt reply on this one. as per previous post we are looking for a one-off hit of replication from 5.5 directory to facilitate the "mail-enabling" of AD users who have entries in 5.5 directory. there is no intention to replicate the AD directory to 5.5 based on a rapid move of mailboxes to a ex2k3 server, where as you say we are in a native mode of operation. the proposal of not merging the alias attribute data is not borne out of a specific reason NOT to do it, but more an approach of merging to the AD only where explicitly required. this is also based on a tenet that the Ex 5.5 directory has data that is already in the AD and which is generally of a "lower quality" than the AD i suppose this then comes down to an understanding of the requirement for the mailnickname attribute. as i remember (all those years ago) the Alias attribute could be used by an Outlook client as the data to supply when setting up the profile. not too sure of other applications that used it / mailnickname attribute. Thanks GT On Mon, 9 Aug 2004 07:51:39 -0400, "Brown, Bill [contractor]" wrote: > > Graham, > > If I remember my E55 correctly - and I think I do - then the ALIAS in > E55 has a one-to-one relationship with a mailbox. There can not be > duplicate ALIASes in E55. I do believe that the same holds true in > AD. This is easily proved out in the test bed. Assuming that you are > going to setup a two-way ADC - you can assign which way you want the > first replication to go. From Exchange to AD - or from AD to > Exchange. And yes, ALIAS [in E55] > does go mailNickname in AD. > > I mean the entire process of putting up the ADC would be to insure > that AD and E55 are working with the same information - until such > time as you can remove all of the E55 components in the Exchange > organization and proceed to a native mode of operation. Unless you > are drastically changing your Exchange system - I can not understand > why you would not want the E55 ALIAS > in AD... > > R/Bill > > -----Original Message----- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] On Behalf Of Graham Turner > Sent: Monday, August 09, 2004 7:30 AM > To: [EMAIL PROTECTED] > Subject: [ActiveDir] adc replication > > dear all, further to earlier item on impact on the AD directory > following ADC synchronization. > > have been through the Exchange 5.5 directory and found the attributes > that 'map' to the mailbox properties. > > am quite comfortable about disabling the merging of most attribute > data using the Default ADC > > one that i am less comfortable with is the merging of the alias > (attribute UID ?) value into the AD > > from the schema map file this looks to be mapped to the "mailnickname" > attribute in AD > > can anyone confirm whether this is in fact a correct interpretation of > the attribute mapping and if so perhaps a view on the impact of NOT > merging this data into the AD ?? > > TIA > > GT > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ > > > List info : http://www.activedir.org/mail_list.htm > List FAQ : http://www.activedir.org/list_faq.htm > List archive: > http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/ List info : http://www.activedir.org/mail_list.htm List FAQ : http://www.activedir.org/list_faq.htm List archive: http://www.mail-archive.com/activedir%40mail.activedir.org/
