?
Solved

Is the attribute LegacyExchangeDN used in Exchange 2010

Posted on 2012-08-23
18
Medium Priority
?
8,562 Views
Last Modified: 2012-10-15
All our users are on Exchange 2010 and have been migrated for some time now. We started out with Exchange 2003, then migrated to 2007 and now 2010. My concern is this. While looking at a users attributes using ADSIEdit, I noticed that just about all our users have a LegacyExchangeDN that matches our 2003 Admin Group. This is because they were all on 2003 at one time before being migrated to 2010. I still have that 2003 Admin Group and one server in the environment. I keep it there to run a Free/Busy sync app with one of our partners. I plan on eventually removing that final 2003 server in the near future but I am concerned because just about everyones LegacyExchangeDN points to the DN of that Admin Group. Whats going to happen when I decommission that final 2003 server and delete the Admin Group? Will my users experience problems because their LegacyExchangeDN points to a path that is no longer valid?
0
Comment
Question by:osiexchange
  • 7
  • 6
  • 4
  • +1
18 Comments
 
LVL 6

Assisted Solution

by:page1985
page1985 earned 525 total points
ID: 38327798
LegacyExchangeDN is still used in Exchange 2010.  This attribute is used by Outlook for tying contact items in the users contacts to matching contact items in the GAL (sometimes users add GAL entries to their personal contacts).  Additionally, this attribute is used for Free/Busy lookups and Federation requests.

In Exchange 2010, the LegacyDN is not so much a path anymore as an identifier.  It must be unique, but it does not need to point to a valid path.

There are some cases where a legacyExchangeDN can cause Free/Busy lookups to fail, but not changing the DN when you perform a migration will not cause this unless additional tampering is done (such as deleting the old Exchange Administrative Group(s) from the old environment).
0
 

Author Comment

by:osiexchange
ID: 38327819
OK, thanks. Looks like I will need to contact Microsoft support on this one. I would think it would be OK to eventually remove the 2003 Admin Group after decommissioning the server but I should check with them. In all the migrations I have done, I never remember going back to the users mailbox and "updating" the LegacyExchangeDN to match the new Admin Group after they have been migrating nor do I ever remember reading about it as a step after migrating from one platform to another. Not sure what you mean by the last comment. Are you saying there could be issues if I delete the legacy 2003 Admin Group?
0
 
LVL 33

Accepted Solution

by:
Exchange_Geek earned 525 total points
ID: 38327953
Not sure if you guys have read about E2010 design change, so here it is

one simple change was made such that all mailbox-related MAPI connectivity goes through the RPC Client Access service on the Client Access server role. To facilitate this abstraction layer, changes were made such that the database objects are no longer child objects of Mailbox servers. A new property was added to the Mailbox database, RPCClientAccessServer, which defines the legacyExchangeDN that should be used to access the particular database. This property takes a FQDN as its value. To ensure that you have high availability and fault tolerance in the event a CAS fails, this value should be the FQDN of a load-balanced CAS array. This load-balanced FQDN is what we refer to as an RPC Client Access Server array.
Ref: link

So, what is the remedy?

What you'd need to do is
1) Get familiar with ADSIEDIT and powershell
2) Export data of all the user's legacyExchangeDN to a csv format, something of this sort
Get-Mailbox | Select-Object Name,legacyExchangeDN | Out-File LED.csv
Verify results.
3) Next, using powershell modify the legacyExchangeDN of all the users
Get-mailbox | set-mailbox -legacyExchangeDN: NewDN
4) Next, add X500 address on all the users having the OLD legacyExchangeDN part of it.

That's it - you do not require to do anything else.

Regards,
Exchange_Geek
0
Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

 

Author Comment

by:osiexchange
ID: 38329138
I think the LegacyExchangeDN they refer to is the attribute of RPCClientAccessServer, a FQDN that is mapped to the databases for access. Ours is outlook.domain.com and that name is load balanced across all 3 CAS servers we have with a hardware load balancer. I don't see what this has to do with the legacyExchangeDN attribute of a user.
0
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38329153
ah my bad - but the steps provided should be of help to you.

Regards,
Exchange_Geek
0
 

Author Comment

by:osiexchange
ID: 38329374
Not sure I want to get into modifying the LegacyExchangeDN of every user if I don't have to. My only concern was the old 2003 Admin Group from whence these users originated and if there would be issues if I deleted this Admin Group. Everything I have since read indicates the LegacyExchangeDN is just a value that needs to be unique for each user but not necessarily tied to a specific Exchange Admin Group. We have 3 versions of Exchange in our environment right now. 2003, 2007 and 2010 so I have users with 2003 LegacyExchangeDN, as well as 2007 and 2010 as their mailboxes were created on the newer platforms. I think I will just leave well enough alone.
0
 
LVL 6

Expert Comment

by:page1985
ID: 38329864
Do not delete the old admin group.  You do not need to modify any LegacyExchangeDNs, but deleting the old administrative group would orphan the legDNs resulting in Free/Busy issues.  Keep in mind that public folder based Free/Busy lookup relies on the Admin Group and LegDN.  If you disable public folders as a Free/Busy point and use only the Availiability Service, then you will not have any issues.

Also keep in mind that clients older than Outlook 2007 cannot function without public folders for Free/Busy.
0
 
LVL 6

Expert Comment

by:page1985
ID: 38329869
As for Exchange_Geek's comment, he/she is correct if you are performing a migration of mailboxes to a new Active Directory forest.  This step is not necessary when performing an upgrade in the same Active Directory environment.
0
 

Author Comment

by:osiexchange
ID: 38337812
Thanks page1985. We have no Outlook clients older than 2007. We use the Availability service exclusively for free/busy and do not publish FB to public folders so that is not a concern for me. If that is the only issue, then I think I can safely remove the Old Admin Group when the time comes.
0
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38337848
@osiexchange: thanks for posting your feedback, help me understand for what reason are you wanting to remove an AD object? Is it causing issues OR do you have any app that would affected if the AG is still into existence?

Regards,
Exchange_Geek

BTW - my profile and my birth certificate states I'm a guy, so it's a he :)
0
 

Author Comment

by:osiexchange
ID: 38337887
Neither of those. Its a legacy AG that was put in place by the first install of Exchange years ago. There is only one server left in this AG and that will go away soon. I figured after that, there is no reason to keep it because it will be empty.
0
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38338048
@osiexchange: the best method is to shut the box for at least a week to find if the box does cause issues, reminds me of what my granny used to tell me

"Remember: Breaking something is the easiest of all tasks, the tough part is to join what you've broken"

so, play it safe (just as many of those ADs say) and shut the box and wait for those cranky user-phone calls.

Regards,
Exchange_Geek
0
 

Author Comment

by:osiexchange
ID: 38338071
I don't know what you mean by shut the box. It's and Admin group. Either it's there or it's not so either I delete it or I don't. When I remove the final server, all I will have left is an Admin Group with a few empty containers below it.
0
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38338099
Well, i meant was - if you haven't removed the E2003 box yet - then just shut it for a week, shutdown the server for a week - that's it.

If you're present environment can survive with no issues with E2003 server shut down, that means you do not need the E2003 environment anymore.

You can go ahead and remove E2003 by restarting post-1-week waiting time.

Regards,
Exchange_Geek
0
 
LVL 6

Expert Comment

by:page1985
ID: 38338138
I understand the desire to keep the directory clean of old objects, but as someone who has worked for Microsoft in their Las Colinas location supporting Exchange 2010, I can tell you that the official recommendation if you contact Microsoft Professional Support Services is to leave the legacy Administrative Group in place.  Deleting it will potentially cause more problems than it can fix.

The only thing you should do with the AG is, once you completely decomission all servers from it, run the Exchange Best Practices Analyzer.  Likely, BPA will point out one or more properties of the old AG that need to be updated to point to new objects in the new 2010 environment.
0
 

Expert Comment

by:evegter
ID: 38484986
hi, if your org originates from exch 2003 then your public folder hirarchy is still registered under the old 2003 admin group. you must move/migrate that. plenty of whitepapers/blogs how to do that too.
did you phase all 2003 servers by now?
0
 

Author Comment

by:osiexchange
ID: 38497415
I still have one 2003 server left but that will go away over the next few months. From what I have been reading here, I may just leave the Admin group in place after decommissioning that server. It sounds like there may be too many things tied to it.
0
 
LVL 33

Expert Comment

by:Exchange_Geek
ID: 38497599
Thank you for listening to us.

Regards,
Exchange_Geek
0

Featured Post

Get your Conversational Ransomware Defense e‑book

This e-book gives you an insight into the ransomware threat and reviews the fundamentals of top-notch ransomware preparedness and recovery. To help you protect yourself and your organization. The initial infection may be inevitable, so the best protection is to be fully prepared.

Question has a verified solution.

If you are experiencing a similar issue, please ask a related question

The main intent of this article is to make you aware of ‘Exchange fail to mount’ error, its effects, causes, and solution.
As much as Microsoft wants to kill off PST file support, just as they tried to do with public folders, there are still times when it is useful or downright necessary to export Exchange mailboxes to PST files. Thankfully, it is still possible to e…
how to add IIS SMTP to handle application/Scanner relays into office 365.
Whether it be Exchange Server Crash Issues, Dirty Shutdown Errors or Failed to mount error, Stellar Phoenix Mailbox Exchange Recovery has always got your back. With the help of its easy to understand user interface and 3 simple steps recovery proced…
Suggested Courses
Course of the Month15 days, 9 hours left to enroll

850 members asked questions and received personalized solutions in the past 7 days.

Join the community of 500,000 technology professionals and ask your questions.

Join & Ask a Question