We're in the process of welcoming new users from a sister forest.
We have separate exchange environments, yet share contact information between us. We have 'contact' objects in our AD for all of their exchange users.
Even after becoming our DOMAIN1 users, they still maintain a separate email identity in DOMAIN2 - this will not change.
As those users move to our domain, we are finding ourselves unable to create new mailboxes for the new accounts - because ARS is validating that the mail alias attribute is unique in the forest. Since we maintain 'contact' information for users in DOMAIN2 in DOMAIN1 - ARS refuses to create the mailbox.
We have a naming standard that has been put in place across these multiple forests. So, the mail alias in DOMAIN2 matches the mail alias ARS is creating for us in DOMAIN1. Hence, the conflict.
Our workaround solution is to delete the 'DOMAIN2' contact object from our 'DOMAIN1', create the new mailbox in our DOMAIN1, and then go back outside of ARS and re-create the contact information - using the same mail alias ... which occurs without error.
We anticipate experiencing this issue with thousands of new users jumping ship from DOMAIN2 in the coming 12 months. But! - we have the uber-annoying onesey-twosey issues now - and would like to have a recommended solution in place before the mass exodus from DOMAIN2 to DOMAIN1.
Searching this site, I found a solution fro the 5X version - mentioned - by Andrey Polevoi here http://communities.quest.com/message/19539#19539
But, I'm hoping there is an updated solution/workaround for creating the exception in policy to ignore non-unique mail alias values found in 'contact' objects. Obviously, we would still want the check in place for uniqueness within the user object type for the domain.
Have you encountered this scenario? What approach have you used to resolve?