Add/remove e-mail addresses using Exchange Management Shell

Adding or removing e-mail addresses from mailboxes using the Exchange Management Shell in Exchange 2007/2010 isn`t a straightforward task, and are a common question in many Exchange/PowerShell-forums. PowerShell MVP Shay Levy has posted an excellent post on how to accomplish this using the Update-List cmdlet in Windows PowerShell 2.0.

To make this easier for Exchange administrators with less PowerShell experience, I decided to create two PowerShell advanced functions, which are available here.

Add-EmailAddress

image

Remove-EmailAddress

image

As you can see, the Remove-EmailAddress accepts either –EmailAddress or –EmailDomain as parameters. Only one of the two can be specified. The –EmailDomain parameter removes all e-mail addresses containing the specified domain. Note that the PrimarySMTPAddress are never modified by either of the two functions. Also note that the functions require Windows PowerShell 2.0, since we are leveraging the Update-List cmdlet.

If you are running Exchange Server 2007 SP2, it is supported to install Windows PowerShell 2.0 (more info here).

To use the functions, you might use one of the following options:

Update 22.11.2010: Shay Levy has posted another blog-post on this topic: Managing email addresses in Exchange 2010. The technique used there are quite different (hash tables), so as you can see, PowerShell offers many different ways to accomplish the same task. What you choose is of course up to you.

Getting an overview of all ActiveSync devices in the Exchange-organization

In Exchange 2007, we can get use the Get-ActiveSyncDeviceStatistics to retrieve statistics for a specific ActiveSync-device. We must supply either a device identity or a mailbox name. In Exchange 2010, the same cmdlet exists, but we also got a new useful cmdlet; Get-ActiveSyncDevice. This cmdlet lists all devices in the organization that have active Microsoft Exchange ActiveSync partnerships.

To provide a way to list all ActiveSync devices in the Exchange organization that works against both Exchange 2007 and Exchange 2010, Ive created a script named Get-ActiveSyncDeviceInfo.ps1. The script outputs each device as an object, making it easy to work with the results. You might i.e. export all devices to a CSV-file by piping the results to Export-Csv.

You might also create graphs based on the results, like I demonstrated in a previous blog-post.

Im aware that the script could be more effective, using Get-CASMailbox and a server-side filter to sort out only mailboxes that got the property HasActiveSyncDevicePartnership set to “true”. However, Ive experienced that this property isnt reliable. Several mailboxes that does have the HasActiveSyncDevicePartnership set to true doesn`t have an ActiveSync devices associated. You might want to use this approach anyway in larger organizations, although I chose to skip it and rather loop through all mailboxes.

Exchange Server 2010 Cross-Forest migration

In Exchange Server 2010 we can move mailboxes between forests when a forest trust are in place. This can be accomplished using the New-MoveRequest cmdlet from the Exchange Management Shell as well as from the Exchange Management Console. Note that remote mailbox moves from legacy Exchange versions only can be accomplished from the Exchange Management Shell.
Before any move requests can be made there are some preparation that needs to be done in the target forest. The users from the source forest must be created in the target forest as mail-enabled users with some specific attributes. The mandatory attributes in addition to several others are described in this article on the Exchange Server TechCenter.

Microsoft has published a sample script, Prepare-MoveRequest, to assist with the preparation in the target forest. The script will create new mail-enabled users in the target forest with the required attributes from the source forest. While this works quite well, many administrators wants to use alternate methods such as Active Directory Migration Tool (ADMT) or Microsoft Identity Lifecycle Manager (ILM) to preserve additional attributes. Especially SIDHistory and passwords are common.
When these tools are used, the Prepare-MoveRequest script got a parameter named –UseLocalObject which tells the script to convert the local object to the required mail-enabled user. While this might work fine depending on the environment, weve seen several administrators reporting problems when using the Prepare-MoveRequest script after ADMT-migration. When the script doesnt find or match any local user due to some missing attributes it rather creates new mail-enabled users. There are no switch to disable the creation of new users if a local object to use arent found. I did a test in a lab-environment trying to use Prepare-MoveRequest with the –UseLocalObject parameter to prepare an ADMT-migrated object. This resulted in a new user being created with some random numbers added to the displayname and samaccountname.

image

As an alternative to using the Prepare-MoveRequest sample script Ive created another PowerShell-script named Invoke-MoveRequest, available from here. This script are intended for scenarios where the user objects are already migrated using e.g. ADMT. Note that you must exclude Exchange-attributes when using ADMT, otherwise attributes like msExchHomeServerName which we dont want to be migrated will come along. Using this script we will migrate the necessary Exchange-attributes.

The script will do the following:

  1. Copy the attribute Mail from the source object to the target object
  2. Copy the attribute mailNickname from the source object to the target object
  3. Copy the attribute msExchMailboxGUID from the source object to the target object
  4. Set the attribute msExchRecipientDisplayType to –2147483642
  5. Set the attribute msExchRecipientTypeDetails to 128
  6. Copy the attribute msExchUserCulture from the source object to the target object
  7. Set the attribute msExchVersion to 44220983382016
  8. Copy the attribute proxyAddresses from the source object to the target object
  9. Set the target objects attribute targetAddress equilent to the source objects  mail attribute
  10. Set the attribute userAccountControl to 514
  11. Run the Update-Recipient cmdlet on the target mail-enabled user to set LegacyExchangeDN and other default Exchange-attributes
  12. Create a new move request
  13. Enable the target object and unset “User must change password on next logon”

The attributes copied and set are according to the list of mandatory attributes in the TechNet-article mentioned above. The mandatory attributes like DisplayName who not are added to the script are already migrated by ADMT. I also considered adding the LegacyExchangeDN from the target object as an X500 address to the source objects proxyaddresses to keep mail-flow between the forests after migration, however, it turns out that this are taken care of by the New-MoveRequest cmdlet.
All variables in the “Custom variables”-section on the top of the script must be set before running. The script are set up to process all users in a specified Organizational Unit in the source domain, however, you may customize this for your needs by e.g. using a CSV-file or setup some filtering using the Where-Object cmdlet. You may also copy additional attributes mentioned in the TechNet-article.
The computer you
re running the script from must have the Exchange Management Tools for Exchange Server 2010 and the free Quest PowerShell Commands for Active Directory.

The script needs additional functionality regarding logging and error-handling, Ill update this post when Ive done so. Feel free to further enhance the script yourself, and please let me know in the comments below if you have any suggestions.

Update 19.08.2010: Since my writing the Exchange team have posted an excellent post on Exchange 2010 Cross-Forest Mailbox Moves on their blog.

Installing Exchange Server 2007/2010 Update Rollups

Have you ever tried to install an Exchange Server Update Rollup which ended with an error message?

I recently did some troubleshooting on installing Exchange Server 2010 Update Rollup 3 and picked up some experiences I would like to share, in addition to provide some general guidelines for installing Exchange Update Rollups.

The installation may fail when installing either manually by downloading the installation package or by using Windows Update. Afterwards event 1024 are logged to the application log stating that the installation failed with the error code 1603:

image

This really doesnt help much, and in addition to the failed installation all Exchange-related services are now stopped and disabled, leaving the server offline.

Start by restoring the service-state. First, enable and start Windows Management Service using an elevated Windows PowerShell prompt:

Get-Service Winmgmt | Set-Service –StartupType Automatic; Get-Service Winmgmt | Start-Service

Then run the ServiceControl.ps1 located in the Exchange bin-folder and the pass it the argument “AfterPatch”:

image

The server should now be restored to an operational state. Next, download the Exchange Update Rollup if you havent done that in the first installation attempt. Next, retry the installation from the elevated PowerShell promt using msiexec with the /lv parameter:

msiexec /lv c:tempex-ur3-install.log /update C:tempExchange2010-KB981401-x64-en.msp

This will instruct the Windows Installer service to log verbose output from the installation to the file specified. After the installation fails you will see an event with event ID 1023 logged to the Application log:

image

Next, open the log-file and look through it for error messages. The output in this file are really verbose, so you might want to ask for assistance in the Exchange Software Updates Forum on the Exchange Server TechCenter.

In my recent troubleshooting incident I found the following in the log-file:

image

This indicates that the servicecontrol.ps1 script failed to run correctly. As stated in KB-article 981474 this is caused by the defined PowerShell execution polices. For the installation to succeed, oddly enough, any execution policies must be temporarily undefined.

To see if any PowerShell execution polices are defined on the system, run Get-ExecutionPolicy –List:

clip_image002

In this case, an ExecutionPolicy was defined both locally and in a Group Policy Object. I first cleared the Group Policy setting and then the local setting using the following command:

clip_image003

Execute gpupdate /force and verify that all the ExecutionPolicies are set to “Undefined”:

clip_image005

Redo the steps described above to restore service-state and retry the installation. In this case the installation now succeeded:

image

At the end I will provide some general guidelines for installing Update Rollups in Exchange Server 2007/2010:

  1. Use elevated Administrator-privileges when running the installation either from Windows Update or by manually downloading the installation file.
  2. Verify that all Execution Policies are set to “Undefined”.
  3. Uninstall any interim Exchange hotfixes installed since the last Update Rollup.
  4. Verify that the ExchangeSetupLogs directory are present on the system-drive. The installer uses this directory for saving service-state information.

Please leave a comment below if you got any further guidelines. I will update this blog-post if I gather more information regarding installing Update Rollups.

Exchange ActiveSync relationships and server migrations

Ever wondered what happens with ActiveSync relationships on mobile devices when you replace the Exchange server published to the internet?

1. If you move a mailbox from Exchange 2003 to Exchange 2003 or to Exchange 2007 RTM, you have to recreate the partnership manually.

2. If you move mailbox to Exchange 2007 SP1, there is no need to re-create the partnership manually.

3. Please note the certificate should be the same. Otherwise, you will encounter issues with certificate in Exchange ActiveSync.

For more information on how to re-create the partnership manually, see this article on the Exchange Teams blog.

In previous versions of Microsoft Exchange Server, if you moved your mailbox to an upgraded server (such as Exchange Server 2003 to Exchange Server 2007 RTM) re-creating the partnership was required. However, if you move your mailbox to an Exchange Server 2007 with Service Pack 1, the new Sync State Upgrade feature is built into Move Mailbox and will allow you to continue synchronizing your device without resetting your partnership.

For more information on the Move-Mailbox cmdlet, see this article on TechNet.

In Exchange 2007 Service Pack 1 (SP1), if you move a mailbox to which a mobile device is synchronized using Exchange ActiveSync, the sync state of the mailbox is updated automatically during the move. You do not need to perform any additional steps, and the user does not need to again sync the device after a mailbox move.

Although you don't move mailboxes, if you add a CAS server and users use the CAS server to maintain their Exchange ActiveSync access, you need to note the following:

In order for your users to continue to synchronize their mobile devices via Exchange ActiveSync with their mailboxes hosted on Exchange 2003 mailbox servers, you will need to ensure that Integrated Windows Authentication is enabled on all of the Exchange ActiveSync virtual directories (Microsoft-Server-ActiveSync) on Exchange 2003 mailbox servers.

For more information on how Exchange 2003 mailboxes are maintained after the Exchange 2007 CAS role are introduced in the environment, please see this article on the Exchange Teams blog.

Shared Address Space in Exchange 2007

In some scenarios there might be a need to configure a so called “Shared Address Space” in Exchange. E.g. a POP3-connector software might be configured to download messages from a POP3-server and deliver them to specific Exchange mailboxes.
If the Exchange users also want to have the external domain as “Reply to”-addresses and/or added as SMTP-addresses on their mailboxes, the domain must be added as an Accepted Domain in the Exchange Organization. When configuring this, it`s important to configure the domain as the correct type of domain:

image

If configured as the default type “Authoritative Domain”, Exchange think it is the only messaging system being responsible for that domain. This would result in Non Delivery Reports if users tries to send messages to users in the affecting domain, who does not reside in the local domain. In the “Shared Address Space”-scenario, the correct type of domain is “External Relay Domain”. When choosing this, Exchange will first check the local domain to try to locate recipient address. If not found, the message will be routed through the Send-connector closest to the remote domain (usually the internet-connector with the address space *).

This article on TechNet explains the scenario in further detail.

Exchange Circular Logging in SBS 2008

While studying for exam 70-653 (SBS 2008, Configuring) I got aware of the fact that Circular Logging in Exchange 2007 are enabled by default in Small Business Server 2008. When the “Configure server backup”-wizard are run,  Circular Logging are automatically disabled afterwards.

For those using a 3rd party backup software this means that Circular Logging must be manually disabled. This is a real gotcha which should be stated clearer for SBS admins in my opinion.

Like Ive configured in one scenario, backup are set up on a separate server using 3rd party backup software. Still the “Windows SBS Console” shows a warning stating that “Backup is not configured”. I contacted Microsoft support asking if it is possible to disable this warning, which it turned out to not be. I think there should be an option for choosing that the integrated Windows Server backup (which cant backup to tape drives like NTBackup did) will not be used in the “Configure server backup”-wizard, in addition to giving the option whether to disable Circular Logging.

Hopefully this will be implemented in a future SBS Service Pack :)

Outlook Web Access not working after applying an Exchange 2007 Update Roll-up

Ive just installed Update Roll-up 7 for Exchange 2007 SP1, and afterwards the Outlook Web Access showed a blank page and there was a yellow exclamation mark in the bottom left corner, which stated “syntax error on line 6 of login.aspx”.

I first tried the solution Microsoft provided in this support forum thread, although it didnt work for me.
I had to re-create the OWA Virtual directory.

I accomplished this using these two PowerShell commands from the Exchange Management Shell:

image

image

Actually the Microsoft Exchange Team stated the following reminder in the blog post regarding Update Roll-up 7:

“And finally, from the installation perspective, a friendly reminder that the roll-up installer will overwrite any OWA script files if required to ensure proper operation of OWA. So if you have customized the logon.aspx page or other similar OWA pages, you will need to redo any customization after installation of the roll-up.”

My recommendation would be to backup the C:Program FilesMicrosoftExchange ServerClientAccessOWA folder before installing an Exchange 2007 Update Roll-up.