Solved

Do I need to keep the .local email address in AD or in the Recipient Policy for any reason?

Posted on 2006-11-10
24
444 Views
Last Modified: 2010-03-06
This is for Exchange 2000 on Windows 2000 servers. I want to delete these .local email addresses from all user accounts in AD so there is no chance that a .local email address is used when an employee sends an email to external recipients and cc’s an employee and a .local email address ends up getting sent out across the Internet making it impossible for those external recipients to reply to those employees who’s .local email address were used instead of their .org email address.

So, I just want to know what the .local addresses are used for and what, if any, consequences there would be if I deleted the .local addresses altogether from the Exchange Recipient Policy.

I’ve actually already deleted the .local email address from the recipient policy a few weeks ago and that solved the problem. But the .local addresses were added back into the Recipient Policy by another admin because he was/is under the impression that a local application needs the .local addresses. I think I’ve proved that the application in question can use the .org email addresses just fine.

One person on EE suggested deleting the .local addresses from the Recipient Policy and said that his company always sets up new domains without the .local addresses. I can see that if you don’t set up a domain with the .local suffix (or whatever it’s called) then there is no reason to be concerned with deleting the .local addresses from the Recipient Policy, if it even exists in such a case. But another person yesterday suggested that I should not delete the .local address from the Recipient Policy because if the domain was built with the .local suffix then removing the .local address form the Recipient Policy could cause Exchange or AD to fail in some ways.

After I deleted the .local address from the Recipient Policy a few weeks ago, I did not notice any problems with Exchange or AD. So I’m curious now as to exactly what these .local addresses are used for and what am I going to mess up if I delete the .local address from the Recipient Policy. Thanks.
0
Comment
Question by:WineGeek
  • 14
  • 5
  • 4
24 Comments
 
LVL 104

Expert Comment

by:Sembee
Comment Utility
What is the AD's DNS domain?

Is it domain.local or something else?
If it is domain.local then you need to leave it in place.
If it is something else (domain.com for example) then you can remove it.

Never remove the domain that matches the internal DNS domain of the AD.

Simon.
0
 

Author Comment

by:WineGeek
Comment Utility
Thanks Simon. That makes sense. Here's the thread for that question I mentioned:

http://www.experts-exchange.com/Operating_Systems/Windows_Server_2003/Q_22034641.html

0
 

Author Comment

by:WineGeek
Comment Utility
Yes, the DNS Forward Lookup Zone is xxxx.local.
0
 

Author Comment

by:WineGeek
Comment Utility
So why isn't Exchange doing what I'm telling it to do? I've unchecked the .local entry in the Recipient Policy but it's still sending out .local email address across the Internet instead of using the person's .org address. But only on some, not all employees, and I can't see any difference between the ones that work correctly and the ones that dont. This is very frustrating........
0
 
LVL 104

Expert Comment

by:Sembee
Comment Utility
The poster who gave you that advice isn't a regular in the Exchange Server topic area. As you yourself pointed out, that is one of the first times that it has been mentioned doing that and it is not something that I would recommend.

I am waiting for clarification on policy, but I have asked if I can reopen a question and post a correction, as while you can get away with removing the address, it can cause problems later on, particularly with OWA and mobile access.

The zone wasn't really what I was asking for.
If you right click on My Computer and choose Properties, then click on Computer Name, it shows the domain - as domain.tld. If its is domain.local then you should not remove the domain.local from recipient policies.

Remember that you don't see everything within Exchange and it is built in SMTP. With the close integration of Exchange and the AD, there is no knowing what else is happening underneath.

Simon.
0
 
LVL 104

Assisted Solution

by:Sembee
Sembee earned 200 total points
Comment Utility
The email address that goes out on user emails is the DEFAULT email address on their account, which is in bold when you look at the email addresses tab.

If you have deselect the .local domain in recipient policy, enable it again, but make sure that it is not the default domain. It just needs to be listed, it doesn't have to be the default.

Then make recipient updates services run again and see if it updates the user accounts with the correct domain as the default.

Finally, also check the user accounts to ensure that the option to allow recipient update services to update the email addresses automatically is enabled. It is on the email addresses tab on the properties of the user in ADUC.

Simon.
0
 

Author Comment

by:WineGeek
Comment Utility
Yes, the domain is xxxx.local. I'm going to re-enabe the .local address int he recipient policy and re-run the recipient updates service. I've already goone through every single user account property page to ensure that the recipient update service is being applied to email addresses for all user accounts. Thanks Simon.
0
 

Author Comment

by:WineGeek
Comment Utility
Hold everything - I think it might actually be working correctly now. I'm getting different results fby sending test emails from different employees' Outlooks. Contacts - vs. Global Addressbook sort of stuff happening ..... maybe.......
0
 

Author Comment

by:WineGeek
Comment Utility
Never mind.... it's not working.
0
 

Author Comment

by:WineGeek
Comment Utility
Now I'm getting really frustrated. How many damn variables are in this email equation? This doesn't need to be rocket science. When I sit down and send myself a test email from an employee's Outlook 2000, it's using the correct .org email address on the employee I'm cc-ing, but it's using the .local address when I send myself a test email from another employee's Outlook cc-ing the same employee. What am I missing? I don't think it's a Contacts vs. Global Addressbook issue, at least I"m ttryint to eliminate that as a possible culprit now....
0
 
LVL 38

Expert Comment

by:Hypercat (Deb)
Comment Utility
The various responses to this question above are confusing to me, so I'm going to address your answer from the beginning to the end.  You do NOT need the .local addresses.  All you need in your Recipient Policy is the email address format that will be used by your organization for both external and internal email - they can and should be one and the same.

For the recipient policy to work correctly, you need to be sure of two things: (1) your recipient policy lists the correct domain name for your SMTP addresses; and (2) your users' properties in AD Users and Computers are set to be updated automatically.  (Well, you also need to be sure you have a global catalog server available and set up properly, but that's not part of your question.)  When you remove a recipient policy, it does not necessary remove the addresses from the user accounts that were already affected by the policy. So, you may have to go in and manually remove the ".local" addresses from your users' accounts. If users have more than one email address, the one that is used as the default (the one that shows as the return address when you send email) is the one that is in BOLD letters in their user account.  You can change this by highlighting one of the addresses and click the "default" button on the Email addresses tab in the user properties.

So, to summarize, you should have only one recipient policy in place, and it should be set to apply the correct public domain name for your organization, not the ".local" name.  And, you may have to manually remove the ".local" addresses from your user accounts after you get rid of the recipient policy that is creating them.  Also, once you remove the recipient policy, you need to go to the Recipient Update Services object in ESM and tell it to Update now to apply the policy change (right-click on the RUS object and click "Update now" or "Rebuild").  At this point, because of the confusion, you may want to tell it to completely rebuild the addresses instead of just doing an update.

Hope this helps!

0
What Is Threat Intelligence?

Threat intelligence is often discussed, but rarely understood. Starting with a precise definition, along with clear business goals, is essential.

 

Author Comment

by:WineGeek
Comment Utility
hypercat,

The internal domain with these servers is xxxx.local. the recipient policy has 3 entries in it:

[ ] smtp     @xxxx.local
[ x] SMTP    @ xxxx.org (This is set as the default email address)
[ x] X400     c=us;a= ;p=xxxx;o=Exchange;

as you can see, the .local entry is not checked, which is supposed to prevent .local addresses from being used or created. But this is obviously not working. I actually just did what you suggested regarding rebuilding the recipient update services so I'm waiting to see if that did anything. I don't know exactly how long it takes for it to update but there are only about 120 users in AD in this domain.

Regarding yoru comment: "Well, you also need to be sure you have a global catalog server available and set up properly, but that's not part of your question"

how do I verify this catalog server is in place?
0
 
LVL 38

Expert Comment

by:Hypercat (Deb)
Comment Utility
Having the .local object unchecked does not prevent the .local addresses from being used if they have already been created.  It only prevents them from being created when RUS runs.  So, if they've already been created earlier by RUS (i.e., that checkbox was checked at one time in the past), you need to go into AD Users and Computers and check your actual user accounts to make sure that the addresses have been removed.  Simply unchecking that box will not remove them - although doing the Rebuild may do the trick. Still, I would double-check at least a few user accounts that you knew had a .local address to make sure.

As for the global catalog question, you would know if it was not, because your RUS would not work at all.  If you look at the RUS in Exchange System Manager, you will see a server name listed as the Domain Controller - this server must be acting as a global catalog server in order for the RUS service to operate properly.  If you only have one DC, then it is obviously a GC also.  If you have more than one DC and want to know for sure, you need to open AD Sites and Services, expand your site and server name and right-click on the NTDS Settings object.  Go to the properties of this object and you'll see a check box for "Global Catalog" on the General tab.

Cheers!
0
 

Author Comment

by:WineGeek
Comment Utility
Simon, thank you for your input and I agree with what you're saying about how the reply to address should be determined by which email address is set as the primary address on the email tab of the properties dialog box for the user accounts. It is set that way but it's still not working, which is my problem obviously. I've double-checked all these settings; primary email address, recipient policy, RUS, and I have yet to resolve this problem. Ugh....
0
 
LVL 104

Expert Comment

by:Sembee
Comment Utility
I am still seeking clarification on the role of the .local email address and recipient policy. Little early yet to get everything I need from Microsoft.

Have you tried removing the .local email address from the user account? I don't mean from recipient policy, but from one account individually. After removing it, test again.

Simon.
0
 

Author Comment

by:WineGeek
Comment Utility
Sorry, don't mean to rush you Simon; I certainly appreciate your efforts. I'm going to go test it by removing the .local from a user account. As if this wasn't enough of a headache, after futher testing, it appears that it is pulling the correct reply to email address (user@xxx.org instead of user@xxx.local) when I test it from the in-house IT administrator's Outlook 2000, so I'm also trying to figure out what that clue is telling me as well. But for now I just want to stick with confirming whether or not I can delete these .local addresses altogether because that would solve all my problems.
0
 
LVL 104

Expert Comment

by:Sembee
Comment Utility
I have no idea when I will receive confirmation either way from Microsoft.

The behaviour of Outlook isn't really an issue here, what is more of a concern is when the message goes out. By removing the address from the user's account you can see whether the email address is being stamped on the account correctly. If it is not, or you start seeing different results then you may have a replication issue and it depends which domain controller Exchange is talking to. Remember that email address information isn't stored by Exchange, but in the AD.

Simon.
0
 

Author Comment

by:WineGeek
Comment Utility
Just an update to this scenario for now: Yesterday I manually deleted all .local email address from the Email Addresses tab in the user account properties dialog box for all users in AD. So all users now have only a .org and that X400 email address listed. In the Recipient Policy I left the .local entry listed but unchecked, and the .org entry is checked plus the X400 entry is still there and checked as well. So far so good.
0
 
LVL 38

Expert Comment

by:Hypercat (Deb)
Comment Utility
That should resolve your issue, WineGeek - as I said, changing the recipient policy doesn't get rid of the ones that are already there.  But, as you have it set now, they will not be recreated so you should be OK. If I were you, to avoid possible future confusion, I would simply delete the .local entry in the recipient policy completely.

Deb
0
 

Author Comment

by:WineGeek
Comment Utility
Thanks Deb. Are you a cat person too? Cats rock. :)

Anyway, after all of this research I've been doing on this problem, I'm beginning to better understand the seperation between an email address and a logon account in Active Directory and I believe the recipient policy is only concerned with email addresses and not the <username>@xxx.local address, which is not an email address even though it looks like one. Instead it's simply the logon username for the internal workings of Active Directory..... or at least that's my best guess at this point. Thanks for your input.
0
 
LVL 38

Accepted Solution

by:
Hypercat (Deb) earned 300 total points
Comment Utility
Cats do indeed rock.....and roll ;-)

Yes, you are beginning to understand, and what you've got is about 75% of it - there does not need to be any connection, as a matter of fact, between the AD username and the email address name (which is called an "alias" BTW).  And as you've already discovered, Exchange is dumb and will make up an email address out of whatever you have entered in two different places:  (1) in the AD user account, whatever you put in the "Alias" field on the Email General tab is used as the first part; and (2) in the ESM, whatever you put in the recipient policy as the SMTP domain is used after the @ symbol.

The part of the AD user name after the @ symbol (in your case, the domain name plus ".local") corresponds to whatever was used as the internal domain name (not the NetBIOS name but the FQDN) when the AD domain was created.

Rrrrrrowrrr!!
0
 

Author Comment

by:WineGeek
Comment Utility
Got it... thanks!

Now, it's time for my mid-day nap........  :)
0
 

Author Comment

by:WineGeek
Comment Utility
I'm going to close this for now.
0

Featured Post

How your wiki can always stay up-to-date

Quip doubles as a “living” wiki and a project management tool that evolves with your organization. As you finish projects in Quip, the work remains, easily accessible to all team members, new and old.
- Increase transparency
- Onboard new hires faster
- Access from mobile/offline

Join & Write a Comment

Check out this infographic on what you need to make a good email signature that will work perfectly for your organization.
Scam emails are a huge burden for many businesses. Spotting one is not always easy. Follow our tips to identify if an email you receive is a scam.
In this video we show how to create a Contact in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: First we need to log into the Exchange Admin Center. Navigate to the Recipients >> Contact ta…
In this video we show how to create a Resource Mailbox in Exchange 2013. We show this process by using the Exchange Admin Center. Log into Exchange Admin Center.: Navigate to the Recipients >> Resources tab.: "Recipients" is our default selection …

762 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

Need Help in Real-Time?

Connect with top rated Experts

13 Experts available now in Live!

Get 1:1 Help Now