Here's a bug that I came across: Create a user in ADUC Give them a mailbox in EMC or EMS Check ADUC and you'll see the user has an email address (test@companyabc.com) Now change the email address in ADUC to something like different@companyabc.com Both of the email addresses will accept emailfor theuser, but both don't show up in EMC or EMS. Jeff Guillet, MCSE:Messaging

When you say "both don't show up in EMC of EMS" are you saying these users are not returned in the mailbox view or by running get-mailbox? Or do you mean that the Email Addresses property is not appearing... Thanks, ~vivek

Hi Vivek, I'm saying that the new email address in ADUC doesn't show up as an email address in Exchange. For example, user companyabc\test1 is created in ADUC and given a mailbox using EMC (or EMS). The user gets a single primary SMTP address of test1@companyabc.com. The user's email address is changed on the General tab in ADUC to different@companyabc.com. Output from EMS(Get-Mailbox test1 | fl emailaddresses) shows: EmailAddresses : {SMTP:test1@companyabc.com, X400:c=US;a= ;p=companyabc;o=Exchange;s=User1;g=Test;} You see the same thing in EMC (obviously, since it's using the same data). However, if email is sent to either test1@companyabc.com or different@companyabc.com, it will be delivered to the mailbox as if different@companyabc.com is a secondary SMTP address. -=-=-=- On a side note, I REALLY don't like the E2K7 administrative model, where mailbox management is supposed to be separate from user management. Admins now have to use two or three tools (ADUC/EMC/EMS) to completely provision a user. Reminds me of theExchange 5.0/5.5 days. Admins have had this capability since Exchange 2000, why take it away now? Oh, and the "ADUC is managed by a different group and we don't control their code" argument that I heard at TechEd doesn't work for me. You all work for the same company, right? Besides, if these two tasks (user management / mailbox management) are now completely separate, why can Exchange administratorsperform usermanagement and provisioning using EMC???

I've seen this behaviour. I think what Jeff means is that you can have 1 email address for the EMS, and a completely different address shown in the ADUC interface. This is for the same user. So changing the email address in EMS will not change it in ADUC. Not sure if this is the correct behaviour?

Thanks for the explanation and report, I will have someone take a look at this to see what is going on. On the ADUC and EMC side---got it, we've actually gotten both sides of the feedback (love it, dislike it) and the call was really based on a lot of research (feedback, cost savings, split permissions, integration withother exchange scenariosand so on and an analysis of how customers uses the current toolsets). Anyway, its one of things that is new and will take some folks some time to get used to. Since its not changing any time soon---I would appreciate it if we can focus on making it better in EMC, for example optimizing the find dialog boxes and reducing cost further. Not to say that you can't vent about it though :) Thanks again for your feedback, ~vivek

One possibility is that you're changing the "Windows email address" (ie -"Mail" property in the AD) on the Exchange 2003 side. This is the email address that is visible on the "general" tab of the mailbox when you're in AD Users & Computers console. It's not really connected to Exchange, even though it says it's the email address in ADUC, although I believe Exchange 2003 will use it as a secondary email address and accept inbound mail to it if the email makes it through routing. Double-check if the "WindowsEmailAddress" property visible in EMS is what's being changed here. I wasn't able to reproduce the behavior you describe by changing the actual "proxyAddresses" values through in Exchange 2003 ADUC. When I made a change to the email address on the "E-mail Addresses" tab, the change immediately appeared in Exchange 2007 EMC on the "E-mail Addresses" tab (and in the EMS as the multivalued "EmailAddresses" property).

Evan, It is the "Mail" attribute that I'm describing, which correlates to the "WindowsEmailAddress" property in EMS. I thought I was being clear, but I guess not. Let me describe it again. -=-=-=-=-=-=-=-=-=- TestUser@companyabc.comis created in the domain with a mailbox using the same SMTP email address. If I update the E-mail property to NewAddress@companyabc.com on the General tab in ADUC, the following behavior occurs in these three enviroment scenarios: Exchange 2003 environment, from a computer with AdminPak and ESM installed Both the mail and proxyaddresses attibutes are updated to the new value (according to ADSIEdit) Email to TestUser@companyabc.comfails with an NDR Email to NewAddress@companyabc.com is successfully delivered Exchange 2003 environment, from a computer with ONLY AdminPak installed (no ESM) Only the mailattibute is updated to the new value (according to ADSIEdit) Email to TestUser@companyabc.comis successfully delivered Email to NewAddress@companyabc.com fails with an NDR Exchange 2007 environment, from a computer with AdminPak and EMS installed Only the mailattibute is updated to the new value (according to ADSIEdit) Email to TestUser@companyabc.com is successfully delivered Email to NewAddress@companyabc.com is successfully delivered The real problem here is that the AD administrators are able to add an SMTP address to a user object and the Exchange administrators will not know about it and cannot change it unless they have appropriate rights in AD. It also presents difficulty when troubleshooting an email routing or tracking issue. Jeff Guillet, MCSE:Messaging

Wasn't able to reproduce this for the Exchange 2007 behavior listed... I created a user with ADUC, provisioned a mailbox with EMS, and then modified the E-mail address via ADUC. I confirmed via Monad that the ProxyAddresses list is the same but now the WindowsEmailAddress attribute has been changed via PowerShell. Mail submitted to this new e-mail address does not deliver to the mailbox, it is not resolved and goes to connector choosing instead. I'll follow up to see if this is a Beta 2 problem, but can you confirm that the repro I outlined is correct?