The script are interactive and will perform the following:

• Ask for input for variables (cluster FQDN, operation mode, etc.)
• Create the new cluster based on the variables provided by the user
• Remove the default port rule
• Add port rules for http, https, POP3, RPC, IMAP4, SMTP, MSExchange RPC and MSExchange Address Book Service
• Ask for the addition of additional nodes. Loops through this procedure until the user answers no

Prerequisites:

• Install the NLB-feature (may be accomplished from the ServerManager module in PowerShell by executing Add-WindowsFeature NLB)
• Configure the NLB NIC`s with the approriate name, IP-address and subnetmask (and disable “Register this connection`s addresses in DNS”)
• Manually add the cluster FQDN to DNS
• Configure static ports for the MS Exchange RPC and MS Exchange Address Book Service (see links in the resource section below)
• Eventually, configure your network switches/routers based on the cluster operation mode you choose

Screenshot:

The script are available from here. In a later revision I`m considering adding support for installing the NLB-feature (I dropped it for now since it could only be offered on the server running the script from, not the additional nodes. This can however be accomplished using PowerShell Remoting), setting the dedicated IP-addresses for the NLB NICs and turn off “Register this connection`s addresses in DNS”.

If you don`t want the interactive experience, replace the “Read-Host” sections with the actual variable values.

Please let me know in the comments below if you have any suggestions for improvements.

Related resources

Exchange Server TechCenter: Understanding Load Balancing in Exchange 2010
Exchange Server TechCenter: Load Balancing Requirements of Exchange Protocols
Microsoft TechNet Wiki: Configuring Static RPC Ports on an Exchange 2010 Client Access Server
Bhargav Shukla (MSFT): Script to configure static ports on Exchange Server 2010
Windows Server TechCenter: Network Load Balancing
Microsoft’s Failover and Network Load Balancing Clustering Team Blog: PowerShell for NLB
Kraft Kennedy: Configuring NLB for Exchange 2010 CAS Load Balancing

switch -regex ($displayname.substring(0,1))
    {
       “[A-F]” {$mailboxdatabase = “MDB A-F”}
       “[G-L]” {$mailboxdatabase = “MDB G-L”}
       “[M-R]” {$mailboxdatabase = “MDB M-R”}
       “[S-X]” {$mailboxdatabase = “MDB S-X” }
       “[Y-Z]” {$mailboxdatabase = “MDB Y-Z” }
        default {$mailboxdatabase = “MDB Y-Z” }
    }

The reason for the un-even spreading of letters are that the Norwegian language contains 3 extra letters, and I just assign those as well as other non-letter characters to the last database.

The script are available from here. You may of course adjust the number of databases, the ranges of letters to use, which user attribute to sort against (e.g. lastname) and so on to fit your needs.

Although there are several common approaches to provisioning mailboxes across databases, be aware of the new mailbox provisioning load balancer in Exchange Server 2010. If you don`t specify a database when creating or moving a mailbox, the load balancer will automatically select the database with the least number of mailboxes. Check out this post by Mike Pfeiffer to see this feature in action.

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, we`ve seen several administrators reporting problems when using the Prepare-MoveRequest script after ADMT-migration. When the script doesn`t 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 aren`t 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.

As an alternative to using the Prepare-MoveRequest sample script I`ve 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 don`t 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 object`s  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 object`s 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, I`ll update this post when I`ve done so. Feel free to further enhance the script yourself, and please let me know in the comments below if you have any suggestions.

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:

This really doesn`t 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”:

The server should now be restored to an operational state. Next, download the Exchange Update Rollup if you haven`t 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:\temp\ex-ur3-install.log /update C:\temp\Exchange2010-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:

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:

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:

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:

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

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

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.

Administrasjon av Active Directory med Windows PowerShell

Hva er nytt i Microsoft Exchange 2010

Konfigurer Single Sign-On mot Remote Desktop Services

As I didn`t explore the GUI before making my post about the new beta of Exchange Server 2010 I didn`t notice there is a bug which leads to an error message when using the Exchange Management Console. It displays a few moments after opening the EMC, as well as when trying to click on an item in the navigation tree.

The error looks like this:

—————————
Microsoft Exchange
—————————
Connecting to remote server failed with the following error message : The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. It was running command ‘Discover-ExchangeServer -UseWIA $true’.
—————————
OK  
—————————

I made a post regarding this at the Exchange Server 2010 forums at Microsoft, and Erik Szewczyk gave a quick reply stating this:

“To fix the error open up the IIS Management console and disable anonymous authentication on the PowerShell virtual directory. This is a bug that should be addressed in later builds”

This worked like a charm. In addition when opening the EMC I would recommend you to click on the “Gather Organizational Information” on the right side. It will provide a really nice overview of the Organization, Servers and Recipients:

Exchange Server 2010 Documentation are available on TechNet.

Among the things that can be found there are “What`s New in Exchange Server 2010”, “Exchange 2010 System Requirements” and “Exchange 2010 Prerequisites”.

Also check out the Exchange Server TechCenter which are updated with new Exchange 2010 content, as well as the new Exchange Server 2010 forum.

For those of you who are interested in Exchange Server I would recommend to attend the following E-Learning from Microsoft: Collection 6899: Exploring Features of Exchange Server 2010

I installed the beta version on a virtual machine running on Hyper-V tonight. You can see some screenshots below.

Installation

I started by promoting the server (running Windows Server 2008 x64 Enterprise) as a Domain Controller in a new domain (for testing purposes).
I then installed the prerequisites and started setup.exe:

Administrative tools

After installation the following appeared on the Start-menu:

The structure of the Exchange Management Console are the same as in Exchange Server 2007:

The same are true for the Exchange Management Shell:

Compared to Exchange Server 2007, who got 394 PowerShell cmdlets for administration, Exchange Server 2010 got as many as 638:

Outlook Web Access

The Outlook Web Access are also improved:

The “Options” page:

New “Phone” features (Text Messaging):

When logged on as an Exchange administrator, it`s possible to choose to manage “My Organization” instead of “Myself”. Here Mailboxes, Groups, and External Contacts can be managed.

Reporting:

The beta version really looks exciting, and I`ll post follow-up posts when I explore new features. Stay tuned!