Hi,I am having a problem with changing the default SMTP address of a mail enabled user with an external e-mail address.I have created a new policy that points to three test users with a new primary address and a couple of secondary addresses.When I apply the policy, the secondary addresses are populated correctly, but the primary address does not change.I can see in the event logs the Proxy Generation entry that shows the correct policy being assigned to the user with the supposed correct SMTP address however this is the only address that doesn't change.Please help?RgdsLee

On Tue, 26-Jan-10 12:52:15 GMT, ilmaestro7 wrote:>Hi,I am having a problem with changing the default SMTP address of a mail enabled user with an external e-mail address.I have created a new policy that points to three test users with a new primary address and a couple of secondary addresses.When I apply the policy, the secondary addresses are populated correctly, but the primary address does not change.I can see in the event logs the Proxy Generation entry that shows the correct policy being assigned to the user with the supposed correct SMTP address however this is the only address that doesn't change.Please help?RgdsLee If the user objects are just "mail-enabled" then they use thetargetAddress property to send the e-mail. The targetAddress andprimary SMTP proxy address must be identical.Since the mail-enabled users have addresses outside your email systemyou really don't want to have any policy changing those addresses. Allthe RUS will do is manage the addresses in the Recipient Policy as ifthey were secondary SMTP proxy addresses.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich,Thanks for the reply.The reason the users are mail enabled is part of a test we are using prior to moving our students to an exchange hosted solution from a linux based system they use at the moment.All our accounts are created in a novell based environment and a connector is then used to populate AD with mail enabled users. We require Exchange to populate the primary and Target address with a microsoft live address that they have assigned to us. My question then, is there actually a way of populating the target address via recipient policy?RgdsLee

On Wed, 27-Jan-10 10:50:43 GMT, ilmaestro7 wrote:>Hi Rich,Thanks for the reply.The reason the users are mail enabled is part of a test we are using prior to moving our students to an exchange hosted solution from a linux based system they use at the moment.All our accounts are created in a novell based environment and a connector is then used to populate AD with mail enabled users. We require Exchange to populate the primary and Target address with a microsoft live address that they have assigned to us. My question then, is there actually a way of populating the target address via recipient policy?RgdsLee Is there a way? Sure. Directory synchronization. By itself, Exchangehas no knowledge of what the correct address in another domain mightbe. But if the address isn't in any directory you have access toalready you're kinda stuck.You could, if you think it's managable, create a LDIF file and use theaddresses from the external system to populate the mail,targetAddress, and proxyAddresses properties in your AD.Since you're using Exchange 2003, the use of Powershell and theExchange 2007 cmdlets are possible (at least not without modifyingyour schema), but you could use a small script that uses ADSI tomanage this.---Rich MatheisenMCSE+I, Exchange MVP --- Rich Matheisen MCSE+I, Exchange MVP

Hi Rich,I kind of thought that would be the answer.I was hoping that there would be a way of stamping both the target and primary via a recipient policy with an address that exchange was non authoratative for. I didn't really want to give the other team that much control of producing e-mail addresses, but I dont really want to go down the road of scripting something that they could easily populate. As long as the RUS does the rest of its checks ok, then I suppose I will have to live with that.Cheers for your help Rich.RgdsLee