none
Add additional SMTP address to all users in Exchange 2010 SP1 RRS feed

  • Question

  • I am trying to find a script that will allow me to add an additional email address to everyone in the company in the format of:

    firstname.lastname@domain.com

    I do not want this to be the default address (so email policy won't work), and I don't want to lose the addresses already assigned to the account.

    I have found a lot of questions similar to this one in the forums, and one that seems to be exactly what I want, but it might be dated as it isn't working when I save it as addaddress.ps1 and then run it from the Exchange Management Shell. 

    The script I found that is supposed to to exactly what I'm looking for was found in this post:

    http://social.technet.microsoft.com/Forums/en-US/bd96d066-fd45-4395-bfb5-ab907396d8a3/exchange-2007-ps-command-to-add-firstnamelastnamemydomaincom-smtp-address?forum=exchangesvrgenerallegacy

    It is as follows:

    get-mailbox -OrganizationalUnit "OU=Users1,DC=mydomain,DC=COM"
    -resultsize unlimited | foreach {
    $e=(get-mailbox $_.identity).emailaddresses
    $e += ("{0}.{1}@mydomain.com" -f $_.firstname,$_.lastname)
    set-mailbox $_.identity -emailaddresses $e

    }

    The problems is that when I try and run this, I get error that a pipeline is already executing.

    Can someone help me out? 

    I'm running Exchange 2010 Sp1

    I tried posting this over in the Exchange forum, but someone suggested that I post it over here instead.  On that forum they kept directing me to Email Address policy (which will change the default email address).

    Monday, January 27, 2014 3:11 PM

Answers

  • It's similar to what Mike posted earlier. 

    I prefer to establish variables for the info I want.  You could skip the $first and put it inline in the set command, but it doesn't make a difference.  I think it's just easier to read and understand this way.

    $targets = get-aduser -filter * -searchbase "ou=...." 
    
    foreach ($user in $targets) 
    { 
      $first = $user.givenname 
      $last = $user.surname 
         Set-ADUser $user -add @{proxyaddresses="$first.$last@domain.com"} 
    }

    You should run this in PowerShell 3.0, PS 2.0 doesn't handle this syntax as well.

    - If you have found any of my posts to be helpful, or the answer, please mark them appropriately.  Thank you.



    Chris Ream


    • Edited by Christopher Ream Tuesday, January 28, 2014 5:15 AM
    • Marked as answer by BradjRay Tuesday, January 28, 2014 11:59 PM
    Tuesday, January 28, 2014 5:12 AM

All replies

  • The problems is that when I try and run this, I get error that a pipeline is already executing.

    If the message says you can't do another pipeline, then don't do another pipeline.

    So instead of this:


    get-mailbox -OrganizationalUnit "OU=Users1,DC=mydomain,DC=COM" -resultsize unlimited | foreach {
      $e=(get-mailbox $_.identity).emailaddresses
      $e += ("{0}.{1}@mydomain.com" -f $_.firstname,$_.lastname)
      set-mailbox $_.identity -emailaddresses $e
    }

    Do something like this instead:


    $mailboxes = get-mailbox -OrganizationalUnit "OU=Users1,DC=mydomain,DC=COM" -resultsize unlimited
    foreach $mailbox in $mailboxes {
      $e=(get-mailbox $mailbox.identity).emailaddresses
      $e += ("{0}.{1}@mydomain.com" -f $mailbox.firstname,$mailbox.lastname)
      set-mailbox $mailbox.identity -emailaddresses $e
    }
    

    Bill

    Monday, January 27, 2014 3:21 PM
    Moderator
  • Hi,

    Here's an adjustment. Based on what I was finding, there isn't a firstname/lastname property returned by Get-Mailbox, so I've added in Get-ADUser to get this information. You'll need to have the AD module available to use in the EMS for this to work:

    Import-Module ActiveDirectory
    
    $mbxs = Get-Mailbox SomeTestMailbox
    #$mbxs = Get-Mailbox -OrganizationalUnit "OU=Users1,DC=mydomain,DC=COM"-ResultSize unlimited 
    
    foreach ($mbx in $mbxs) {
    
        $userDetails = Get-ADUser $mbx.SamAccountName
        $e = (Get-Mailbox $mbx.Identity).EmailAddresses
        $e += ("{0}.{1}@mydomain.com" -f $userDetails.GivenName,$userDetails.Surname)
        Set-Mailbox $mbx.Identity -EmailAddresses $e
    
    }

    I've left in my testing line to work on a single mailbox. Once you're happy with the results, you can uncomment the line to get all mailboxes in the specified OU.


    Don't retire TechNet! - (Don't give up yet - 12,575+ strong and growing)

    Monday, January 27, 2014 3:26 PM
  • This absolutely can be scripted but I would like to point out that this is going to be a "Point In Time" solution.  Any new accounts your create will have to have this manually added or you'll have to run a modified version of the script to either only target new accounts, or ignore accounts that already have the setting.

    You mentioned you do not want to change the defaul address policy but you should create a new one.  They can work in an accumlative manner and it'll do exactly what you're looking for automatically.


    Chris Ream

    • Proposed as answer by jrv Monday, January 27, 2014 9:05 PM
    Monday, January 27, 2014 4:10 PM
  • Do not script this.  As Christopher notes - use policy.

    ¯\_(ツ)_/¯

    Monday, January 27, 2014 9:05 PM
  • My issue is that there are several hundred users that have a non-standard reply to addresses. We do not want these reply to addresses changed. Is there a way to create an email address policy that get applied, but doesn't change their default email address?  Everything I looked into showed that an email policy had to have a default address, and if it got applied to a user, it would update the reply to address.  I do intend to update our default email address policy so that this format gets applied to new users created, but I need a way to add an additional address matching the new format to existing mailboxes that have request non-standard reply to email addresses. 

    I'm going to be onsite at this client tomorrow and I plan to follow Mike Laughlin's script.  I'll of course test it on our test account first, and if it goes well I will apply to the entire company.

    I appreciate the reminder that the Email Policy needs to be updated for future users, but unless I'm missing something about how the Policies work, I think I'm going to need a script to add an additional SMTP address if I don't want to touch their existing reply to addresses.

    I'll report back tomorrow how it goes, thanks everyone for the input.

    Tuesday, January 28, 2014 12:59 AM
  • An adder policy will not change the existing policy.

    The reason there is not CmdLet to do this is because it is not standard.  It is intended that you use policy.  Using a script endangers the whole system because any mistake with addresses can completely disable the mailbox.  A script run against hundreds of mailboxes can pretty much disable the whole server.

    Post in the Exchange forum for assistance on using address policies to manage groups of mailboxes including how to update the addresses.


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 1:27 AM
  • For cases where you may only need to add one odd address this is how to do it:

    http://technet.microsoft.com/en-us/library/bb123794.aspx

    Read all o the instructions and warning carefully.

     


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 1:42 AM
  • If the addresses that you want to keep are already being set by the default policy, then this is what you need to do:

    1) RECREATE A NEW POLICY that matches the default domain policy.  When you get to the last setup of the creation wizard.  SELECT DO NOT RUN. (The reason we do this is so that we can apply a priority to this policy.  The default will lose by default and the 'Set as Reply' will change.

    2) Create your new policy that you want to create that will add the email addresses to the scope you want.  You will be setting the 'Set as reply' address here as you thought, but don't worry, it won't matter. Also, set this as DO NOT RUN.

    3) Set the priorities in the order you want them.  The lowest number wins.  so you need to make your DEFAULT REMAKE as your Priority 1.  The new one will be 2.

    4) Select your pri 2 policy and say "Apply..."

    ** All of this works, I just did these exact steps in my lab to ensure I'm not lying to you **

    This is all you need to do to make this work. This is what Exchange was designed to do.  Running a script in this situation is not the right thing to do, whether it works or not.  And since you said you'll be 'on site with this client' tomorrow, I assume you're a consultant and this isn't your network.  That's some pretty bad business.  If you don't KNOW you're right.  Do not go make changes.  Who cares what Mike, Chris and JRV said.  This is your decision.  Good luck!!!

    - If you find my posts helpful, please mark them appropriately.  Thank  you.


    Chris Ream

    • Proposed as answer by jrv Tuesday, January 28, 2014 4:25 AM
    Tuesday, January 28, 2014 2:34 AM
  • Actually, now that I've taken a few more minutes to think about it.  Consider this:

    When you make a new policy, it will add addresses and change the Set As Reply, but it won't remove addresses.  So BEFORE you create the new policy, it would probably be better to query and note all the accounts that have the 'old' or 'abnormal' preexisting email addresses.  Then when you create and apply the policy, it will change their reply to, but it won't remove it.  Then you can script back in the Set As Reply.

    Technically, there will be no outage.  The mailbox will still receive mail on the 'other' address.  The most risk you have is that any messages sent in the timeline of making these changes may have the wrong reply-to address, which really doesn't matter anyway.  The display name will be right.  Any future attempts to reuse the 'wrong' address will still work.

    There's really no down side to this.  There's probably 30 ways to get this done, but the two I've offered are better than what you're currently planning to do.

    Okay. Do what you will :)


    Chris Ream

    • Proposed as answer by jrv Tuesday, January 28, 2014 4:24 AM
    • Unproposed as answer by jrv Tuesday, January 28, 2014 4:25 AM
    Tuesday, January 28, 2014 3:00 AM
  • I agree completely with Chris.  I thought about posting the scripting solution and hoped you would read the whole resource carefully.  Using a scripting solution is a potentially dangerous step and completely unnecessary.

    I didn't post a solution because this should be in the Exchange forum as it is truly an Exchange issue.  It is also important for Exchange Admins to know how to best manage address lists and address generators.  They are very powerful and can be subverted by scripts and manual edits.

    I am a big believer in top-down policy.  Windows AD and Exchange have been designed to support business policy enforcement.  This should always be your first choice.


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 4:24 AM
  • Chris - I think your first method was better althoughusingscript to analyze the addesslists first would be a good step incase more manualor scripted changes have been made. I prefer enforced addresses and the use of one policy if additive lists are not used or needed.


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 4:27 AM
  • I agree that policies are safer and better, but they don't allow for the same level of customization in environments where they customer specifically doesn't want a predictable email address format.

    I originally posted my request in the Exchange Admin forums, and when we hashed out that a Email Address policy wouldn't work for my intended purpose (the custom reply to addresses being the primary obstacle) I was told to post in this forum for help getting the script correct.

    This second method you mentioned might be worth looking into as it would work, but seems overly complicated.  It might not be a bad idea to record current reply addresses no matter what I end up doing.

    My situation is that on every account that is currently a non-standard reply-to address, they have removed the "automatically update email addresses based on email address policy" check mark to ensure that the custom reply-to address doesn't get changed.  I'm sure this can be fixed, but it's another step to take it away, and to put it back again.

    So if I use policies my procedure would be:

    1. Export existing reply-to addresses

    2. Do something to force the policies to apply to everyone that currently has the checkmark to apply policies, unchecked

    3. Apply new policy

    4. Use a script to put original reply to addresses back in place

    5. Somehow remove the checkmark again to make sure the new custom reply to addresses aren't lost.

    Otherwise I can just run the script in one step.  Looking at the script above I did see that the script pulls existing addresses, adds my new value to them and then re-writes the entire value.  jrv posted a link to the syntax of adding an additional address, I think it might be much safer to use the add syntax, instead of re-writing the entire value.

    Would something like this be safer?

    Set-Mailbox "Dan Jump" -EmailAddresses @{add="dan.jump@northamerica.contoso.com","danj@tailspintoys.com"}

    Could a script be written that used the add function?  This seems a lot safer than to re-write the entire value.



    • Edited by BradjRay Tuesday, January 28, 2014 4:47 AM spelling, credit to jrv
    Tuesday, January 28, 2014 4:30 AM
  • I do appreciate the time and thought you guys have put into my predicament. I don't want to seem ungrateful while resisting the use of policies in this instance. I really would use policies, I just don't see how they can be applied to my situation without at some point using a script (either to restore custom reply-to addresses or adding the new address). Policies work great when you have a logical format,  just not so much when things are random.

    Obviously the real problem is the company policy, but that's a political battle I can't do very much about.

    The first option wouldn't work as their reply-to addresses aren't currently controlled by a policy, so re-applying the policy after using the additive policy would create the exact problem I'm trying to avoid.

    Your second solution should work in my situation, but it also uses a script to change the default addresses back to what they were before we started, wouldn't that expose me to the same amount of script risk as using a script to add the address in the first place?



    • Edited by BradjRay Tuesday, January 28, 2014 4:45 AM Spelling
    Tuesday, January 28, 2014 4:40 AM
  • I just tried that command and had to make a minor change.

    set-mailbox <user> -emailaddresses @{add="SMTP:newaddress@domain.local"}

    This command failed because of an existing address policy I have in place.  I then applied the -emailaddresspolicyenabled $false switch.  Still failed due to too many primary addresses.

    You may want to just try this instead with the AD module:

    Set-ADUser <username> -add @{proxyaddresses="newjunk@somewhere.com"}

    On a side note, according to your last reply, I think you misunderstood how to export current email addresses and reapply them as defaults.  I still feel either of the other options are better.  Especially because of the 'point in time' reference I made before.  This new policy the customer has come up with will now have to be a manual addition for each creation.  I still put pressure on using the system as designed.  This might be an easier solution right now, but it won't be an easier solution down the road.  Do more now, for less later.


    Chris Ream

    Tuesday, January 28, 2014 4:49 AM
  • You have a good point about the point in time. I should have mentioned that we have already updated the existing email address policy that applies to all new users as the are created. This script is mostly being done to add the correctly formatted address to the existing users that are no longer tied to a policy because of their custom reply-to address.

    I like your idea to use:

    Set-ADUser <username> -add @{proxyaddresses=newjunk@somewhere.com}

    How would I write the script to get it to process through the entire AD?  (I'd of course want to be able to test it on a specific test OU first).


    • Edited by BradjRay Tuesday, January 28, 2014 4:56 AM
    Tuesday, January 28, 2014 4:55 AM
  • You have a good point about the point in time. I should have mentioned that we have already updated the existing email address policy that applies to all new users as the are created. This script is mostly being done to add the correctly formatted address to the existing users that are no longer tied to a policy because of their custom reply-to address.

    I like your idea to use:

    Set-ADUser <username> -add @{proxyaddresses=newjunk@somewhere.com}

    How would I write the script to get it to process through the entire AD?  (I'd of course want to be able to test it on a specific test OU first).


    No you need to use the smtp.  If it is upper case it specifies that that is the primary address. TO change the primary there is an Exchange command.  Add the new primary with lowercase smtp and use CmdLet to set primary. I can't, off the top of my head, remember the CmdLet format to set primary.  You will have to look it up.

    I tried to connect to my test server but there is a network issue that keeps hanging the connection.  I think Cablevision is having a meltdown tonight.

    set-mailbox <user> -emailaddresses @{add="smtp:newaddress@domain.local"}

    LOWERCASE!


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 5:05 AM
  • OK

     set-mailbox <user> -emailaddresses @{add="smtp:newaddress@domain.local"}

     set-mailbox <user>-PrimarySmtpAddress newaddress@domain.local

    I am pretty sure that you have to do it in two steps.


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 5:08 AM
  • It's similar to what Mike posted earlier. 

    I prefer to establish variables for the info I want.  You could skip the $first and put it inline in the set command, but it doesn't make a difference.  I think it's just easier to read and understand this way.

    $targets = get-aduser -filter * -searchbase "ou=...." 
    
    foreach ($user in $targets) 
    { 
      $first = $user.givenname 
      $last = $user.surname 
         Set-ADUser $user -add @{proxyaddresses="$first.$last@domain.com"} 
    }

    You should run this in PowerShell 3.0, PS 2.0 doesn't handle this syntax as well.

    - If you have found any of my posts to be helpful, or the answer, please mark them appropriately.  Thank you.



    Chris Ream


    • Edited by Christopher Ream Tuesday, January 28, 2014 5:15 AM
    • Marked as answer by BradjRay Tuesday, January 28, 2014 11:59 PM
    Tuesday, January 28, 2014 5:12 AM
  • Ahhh.  Schooled again ;) 

    I knew that tidbit.  Totally forgot though.  Thanks.


    Chris Ream

    Tuesday, January 28, 2014 5:18 AM
  • Ahhh.  Schooled again ;) 

    I knew that tidbit.  Totally forgot though.  Thanks.


    Chris Ream

    What does this refer to?


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 5:26 AM
  • Capital vs Lowercase.  It slipped my mind and that's why my tests were failing.  Good catch.

    Chris Ream

    Tuesday, January 28, 2014 5:29 AM
  • Capital vs Lowercase.  It slipped my mind and that's why my tests were failing.  Good catch.

    Chris Ream

    I thought that but wasn't sure.  This is why this can be dangerous.  With some CmdLets or direct ADSI we can set two or more with uppercase.  This will cause havoc.  That issue may have been fixed in 2010 but I have never tested that theory.  In 2003 this could make a server unresponsive make the mail fail delivery until fixed.  It drovemenuts all one weekend until I realized that the addresses were bad.  I used policy to reset everything.

    Sometime it would be worth testing if we can add an address and make it primary all in one step.

    Note that the address is called "Promary" or "Default".  I have not sen any docs referring to it as "ReplyTo" although it will initially be used as the "From" address.

    If you need custom"ReplyTo" b this si set per message in the client and can be latered in Outlook by recipient address.  Thissi the better and correct way to handle custom replyto addresses.  Different recipints can have different replyto addresses and lists can beset the same way.


    ¯\_(ツ)_/¯

    Tuesday, January 28, 2014 5:47 AM
  • Thanks a lot.  I was able to get this done today.  I was able to refer specifically to the comments about locking up a mail server to convince them to stick with the Email Policy and abandon their unique non-policy setup.  They still have their unique addresses as secondary SMTP addresses, but they now all are using an email policy with standard reply-to addresses.  I did export the list before we started so that I could go back through and put them back if needed, but I think we finally convinced them to stick with a policy.

    It made a world of different being prepared to do exactly what they asked for, but warning them that we shouldn't do it that way (as opposed to not being prepared to do what they asked for and convincing them to do something else).

    I'm glad that in the end we were able to do it the way that everyone recommended in the first place.  I really appreciate everyone time to helped out.

    Tuesday, January 28, 2014 11:59 PM