So back last year I talked about using Powershell to do stuff with Active Directory. At the time I thought it was imminent I would have to run some scripts to change some stuff in AD.
The occasion I was looking at at the time hasn’t materialised yet but something similar came up today to be worked on. We have to redirect some user’s email addresses as part of a Google Apps migration to forward from Exchange to the new Google Apps account.
In this case I am employing two steps:
1. Create mail contacts in Exchange for the new email addresses.
Firstly I exported the mailboxes from the Exchange Management Console which gave me a TSV file. Opening this in Excel I changed it to CSV and it has the following columns with typical data
Name,EmailAddress,NewEmail,NewAlias
John Smith,j.smith@old.domain.nz,jsmith@new.domain.nz,JohnSmith|new-domain-nz
Then my script looks like this
$staffaddresses = Import-CSV “C:Usersp.dunforddocumentsstaffaddresses.csv”
foreach ($staffaddress in $staffaddresses)
{
$ContactName = $staffaddress.Name + ” (new.domain.nz)”
$DisplayName = $staffaddress.Name + ” (new.domain.nz)”
$proxyAddresses = “SMTP:”+$staffaddress.NewEmail
$Alias = $staffaddress.NewAlias
New-ADObject -Name $ContactName -DisplayName $DisplayName -Type contact -OtherAttributes @{‘mail’=$staffaddress.NewEmail;’proxyAddresses’=$ProxyAddresses;’mailnickname’=$Alias; ‘targetaddress’=”SMTP:”+$staffaddress.NewEmail}
}
So basically we are calling a standard function, New-ADObject and setting some attributes. This causes the object to be created in Active Directory. The OtherAttributes parameter is the useful one that contains a whole lot of attributes you need to set to create a mail-enabled contact and set its email address to something useful. Actually this is all the special ones like department or location that aren’t exposed as standard parameters.
As noted in the previous article, this can be run on a workstation (rather than a DC) provided that it has RSAT installed.
We are using Import-CSV here to pipe in the CSV list for the contacts.
2. Set up the forwarding in Exchange to the new email address
Whereas the Exchange Management Console will only let you set forwarding based on a contact object, in a script you don’t have this limitation. Because it uses a contact, EMC sets ForwardingAddress based on that contact. But usually with Office365 I have used ForwardingSMTPAddress instead, which just uses the actual email address. Apparently these properties are mutually exclusive and if you set ForwardingSMTPAddress in a script then you get a warning if ForwardingAddress is set as well. Presumably ForwardingAddress takes precedence.
The relevant cmdlet in this case is Set-Mailbox. You have to give it a name in order to find which mailbox you want to change, and then the relevant parameters for forwarding are
-SetForwardingSMTPAddress
This is the email address you are forwarding messages to. It should be prefixed with “smtp:” (EMS will automatically add this if you omit it).
-DeliverToMailboxAndForward
Set this to True to have the message copied to the Exchange mailbox and forwarded as well. If set to False then the message is forwarded without being copied to the Exchange mailbox.
I use this Cmdlet quite often with Office365 to set up forwarding because that wasn’t an option in 365’s admin interface (unlike the Exchange Management Console). Note that this time you need to run it in the Exchange Management Shell on the Exchange server.
If you are using Exchange on-premises (as opposed to hosted Office365) then you may need to set up a remote domain to allow automatic forwarding otherwise this may not work.
So far our forwarding isn’t actually working – this is just an example but there is something else going on with our configuration that isn’t allowing the forwarding to work at the present.