Building Exchange Server 2007 labs/demos often? This is for you!

Published 05-05-2008 04:04 PM 2,137 Views

Hi! This is my first post to the Exchange Team Blog - hope this is of use! My name is Robert Gillies, and I'm a Senior Consultant in the Federal Civilian Practice of Microsoft Consulting Services. One of my recent projects for one of my customers had to do with automating the install of Exchange 2007 SP1. I went to TechReady (our Microsoft "internal TechEd") in the fall and didn't find anyone who had a good demo script on how to do this type of scripted deployment that could be used for an enterprise customer. That made me think that maybe I should do something that could be presented to help other people that might just need a good starting point for their own installs. No matter how big your organization is, if you want to build Exchange 2007 labs, this can help you!

So - I wrote a script for my customer and trimmed it down for a presentation. I presented this script at the spring TechReady in January, and then April 8th I presented it at INTERACT2008 ( I'm currently scheduled to present this at TechEd Orlando in June as well. Included below is, the script and the CSV files used by the script, and the remainder of this blog entry is a discussion/description of how to configure your own lab so that you can run these scripts on your own.

The goal of this exercise was to have a single script that could be run on a given machine, and based on the server naming convention install the appropriate roles and possibly make some configuration decisions. The customer I am working with for this has a very well defined server naming convention which makes this possible. One possibility for a change would be to have a CSV file that would define the Exchange roles based on what the installation team put into the file as opposed to being strictly name based.

Please note: below procedures and scripts were tested only in lab environments! This script is not officially supported by Microsoft.

Server Naming Convention

The server naming convention that was used for this lab/demo is as follows:

  • First three letters of the machine name defines the role or domain that the server will fill. For this lab, I used "lab" for this role.
  • Second three letter define the location of the servers. Since I live in Huntsville, AL and the local airport three letter code is HSV, I used "hsv" on all servers.
  • A single dash is the seventh character.
  • The next two or three letters define a server functionality. For this lab, the following two and three character codes are used:
    • "dc" is used to denote a domain controller
    • "xet" is used to denote an Exchange 2007 Edge Transport Server
    • "xht" is used to denote an Exchange 2007 Hub Transport Server
    • "xcs" is used to denote an Exchange 2007 Client Access Server
    • "xcl" is used to denote an Exchange cluster or cluster node
    • "xmb" is used to denote and Exchange Mailbox Server (or the Clustered Mailbox Server - CMS - that represents an Exchange Mailbox Server in a CCR cluster)
    • "xsc" is used to denote an Exchange SCR target server
  • The next three characters are a numeric count of servers (remember that we designed for an enterprise deployment - but we probably could have gone with two digits here)
  • The next two characters are only used on cluster nodes
    • "n1" to denote the first node
    • "n2" to denote the second node
    • "r1" and "r2" are used in the Exchange 2007 Service Pack 1 Enable-ContinuousReplicationHostName implementation (used to enable replication on a secondary network)

Using this naming convention, that will give us the following server names in our lab:

  • labhsv-dc001 (The domain controller, global catalog and DNS server)
  • labhsv-xcs001 (CAS)
  • labhsv-xht001 (Hub Transport)
  • labhsv-xet001 (Edge Transport)
  • labhsv-xsc001 (SCR Target)
  • labhsv-xmb001 (Clustered Mailbox Server
    • labhsv-xcl001 (Cluster name)
      • labhsv-xcl001n1 (Cluster node 1)
      • labhsv-xcl001n2 (Cluster node 2)

Lab Diagram

The lab that we will be creating can be represented using this diagram:


Lab Configuration

Now I'll just list out what I did to build these servers so that you can build your own!

- Ensure that all machines in the lab are connected to the same network. If you want to update these machines to the latest patch levels, this network should connect to the Internet.

- Put a base OS load on all servers. My scripts all assume Windows Server 2003 32-bit, but if your favorite virtualization platform supports 64-bit guest OS, then you are welcome to use that. I just got Hyper-V RC0 and have started playing with that, so maybe a future blog entry will discuss the nuances of deploying this lab on Windows Server 2003 SP2 on Hyper-V RC0, just as I'm sure that deploying on Windows Server 2008 is in the future!

  • All servers must have .NET Framework 2.0 installed.
  • All servers must have MMC installed.
  • All servers must have Windows PowerShell 1.0 installed.

- Disable the Scalable Networking Feature Pack (

- DCPromo - I typically allow DNS to be installed by DCPromo process for these simple labs where I'm only going to have a single DC.

- Add reverse lookup zone. This is probably not strictly required - AD works just fine without this, I just like to have it.

- Join all machines to domain except for Edge Transport - remember that Edge is not supported as a member of the corporate forest. Edge also isn't supported in the corporate intranet, but we're just doing a demo here, so we'll let that one slide.

- Update all machines via Windows Update. My scripts all assume Windows Server 2003 Service Pack 2 and all required updates.

- Make sure that the site configuration is set such that our local subnet defines the site. This is most important if you are going to have an expanded lab with multiple sites/subnets.

- Raise the domain functional level to Windows Server 2003 level.

- Raise the forest functional level to Windows Server 2003 level.

- Create Cluster Service Account user (ClusAdmin). Grant user local admin rights on both cluster nodes.

- Log in as the Enterprise Administrator (to ensure Schema Admins permissions. Insert the Exchange 2007 SP1 DVD in the domain controller. Execute the command from the DVD: /PrepareAD /OrganizationName:TechReady

- While still logged in as the Enterprise Administrator, execute the following command from the DVD: /PrepareDomain

- Create Exchange Administrator user (ExchAdmin), set user to be a domain admin (LAB SETTING - this allows the user to be local admin on all machines so he can install Exchange - this user needs to be a local admin on all machines and that can be accomplished in ways other than making this user a domain admin if needed). Remove user from "domain users" group. Add this user to the "Exchange Organization Administrators" group.

- Install IIS on all required servers (including labhsv-xht001, labhsv-xcs001, labhsv-xcl001n1, labhsv-xcl001n2 and labhsv-xsc001). NOTE: No SMTP or NNTP!!!

- Set the domain name on the Edge server to "techready.lab" to match the internal name of the lab.

- Register the IP address of the Edge server in the internal DNS. (DNS is set to secure update only, and this machine is not a member of the domain).

- Install ADAM on the Edge Transport server.

- Network configuration on the CCR nodes:

  • Name the first network "Public Network"
    • This network has DNS and default gateway defined
  • Add the second network to both CCR nodes.
    • Second network adapter should be a "private" network - does not connect to the Internet.
    • Name the second network "Management Network"
    • This network does not have DNS servers or default gateway configured
    • This network does not register itself with DNS
    • This network is set to "Disable NetBIOS over TCP/IP"
    • Manually configure the network on the second NIC as follows:




Mask: labhsv-xcl001r1 labhsv-xcl001r2

NOTE: That says "R1" and "R2" on the end, not "N1" and "N2". This is for the "Enable-ContinuousReplicationHostName" cmdlet where we need unique names for cluster resources to force our continuous replication across our management network.

  • Ensure that the connection ordering is correct. In the "network connections" window, go to the "Advanced" menu, "Advanced Settings" selection. Move "Public Network" to the top, "Management Network" to the second. (Your "most public" network should be at the top, "least public" at the bottom.)

Definition of CSV Files

PowerShell provides a fairly simple way to read data from CSV files. When reading a CSV file in PowerShell, an object is created that represents the file. This object can be "looped through" to examine each line of data, with the first line defining attributes on the object that can be read. For instance, I could read the ScriptSettings.csv file into an object called $ScriptSettings, and then access the product key defined in that file by the variable $ScriptSettings.ProductKey based on the definitions laid out below.

Each of these files is detailed below by describing what each element is. Actual format, as CSV files, is that the descriptive name of each element is in the first line of the file, with the various attributes to be given to the install script on each line below. Take care to ensure that the right attributes line up in the same order as the "header line" in the first line of the file.


Descriptive Name (from file)












This is a product key for Exchange Server 2007 that will be applied to each and every server in the environment









This is the "short name" of a single GC server that will be used on all of the commands in the script that write to the Active Directory.  This will ensure that when we have writes to the AD followed quickly by a read that AD replication delays will not affect execution of our script.









This is the "short name" of the first hub server installed in the organization.  Could be used in the future to facilitate replication of public folders.







Descriptive Name (from file)












This is the name of the hub transport server where the FSW shares will be created.  This was added to allow for FSW creation on two different HT servers in two different datacenters with the same data file.









This is the name (not necessarily the FQDN) of the CMS (Clustered Mailbox Server) for which given FSW (File Share Witness) is being created.









This is the share name that will be created on the HT server and later utilized by the CMS (the specific CMS in this row) as the FSW.









This is the account (in domain\account format) that will be used by the cluster utilized by the CMS in this row as the cluster service account.







Descriptive Name (from file)












This is the name (not necessarily the FQDN) of the CMS (Clustered Mailbox Server) for which given FSW (File Share Witness) is being created.









This is the account (in domain\account format) that will be used by the cluster utilized by the CMS in this row as the cluster service account.









This is the TCP/IP address of the cluster represented by the CMSName that defines this row.






This is the TCP/IP address of the CMS that defines this row.






This is a machine name used by the Exchange cluster to define replication on a secondary network (rather than the primary client-access network).  This name is specific to the first cluster node, and should be the same as the cluster node with the "n" node designator replaced with "r".  For the example here, the cluster node would be labhsv-xcl001n1.









This is the TCP/IP address of the Node1ReplName on this row.






This is a machine name used by the Exchange cluster to define replication on a secondary network (rather than the primary client-access network).  This name is specific to the second cluster node, and should be the same as the cluster node with the "n" node designator replaced with "r".  For the example here, the cluster node would be labhsv-xcl001n1.









This is the TCP/IP address of the Node2ReplName on this row.




Descriptive Name (from file)












This is the name (not necessarily the FQDN) of the SCR target server.









This is the name (not necessarily the FQDN) of the CMS that will act as the source for the SCR replication targeting this SCR target server.






Note that if the lab is built with the machine names and IP addressed defined in the diagram above, the included CSV files will work without changing.

Also note that during execution of the script, it is assumed that the CSV files will be located in the same directory as the script itself.

Execution of the Script

You should deploy this lab in the following order:

  • labhsv-xet001 (not really required in any order)
  • labhsv-xhb001 (required before the cluster nodes)
  • labhsv-xcs001 (in production you need CAS before Mailbox roles)
  • labhsv-xcl001n1 (required before node 2 and SCR)
  • labhsv-xcl001n2
  • labhsv-xsc001

On each server where Exchange will be deployed, follow these steps:

  • Mount your Exchange 2007 SP1 CD
    • Note that SP1 is required for the Enable-ContinuousReplicationHostName cmdlet
  • Open Windows PowerShell
  • Change directory to where you stored the script and CSV files
  • Execute the following command to allow scripts to run:
    • Set-ExecutionPolicy RemoteSigned
  • Execute the script with a command line similar to the following:
    • ./E2K7Install.ps1 installdir:d:

After all that, if you are still with me, you are probably wondering where to get the script and those CSV files? Right here.

Finally, I hope you found this useful. If for whatever reason, you create a tear down Exchange 2007 labs or demos often, this should save you quite a bit of time in the long run!

- Robert Gillies

Not applicable
This is what I have been looking for for the last 12 months :o)
Not applicable
Thanks, Apoc, for the comment!  Glad this is going to help you out!!
Not applicable
Boomer Sooner!  Very cool.
Not applicable
Great resource ! Thanks for the effort
Not applicable
Hi Robert,
Great stuff! Thanks for the post.

One question - How do you "Update all machines via Windows Update. My scripts all assume Windows Server 2003 Service Pack 2 and all required updates." ?

I'm starting to work with MDT and this is one thing I need, but haven't figured out yet.

Not applicable
Boomer Sooner, Joseph!!  Good to see you on the blogs!

Thanks to dhunt for the comment, too!

Chris, the way I handle updates (and I want to reiterate that this just works for me - YMMV, of course) is that I build what I call a "base OS" image in Virtual Server (and recently, I've been using Hyper-V - just upgraded to RC1 and am very impressed with that).  Anyway, I'll build out, say, a 32-bit Windows Server 2003 SP2 machine from an ISO image built with the SP2 bits "slipstreamed" into the main W2K3 bits.  Then, I upgrade that base build using Microsoft Update, add things like "support tools" and PowerShell 1.0 that I want on every server, sysprep the image, make it read only, and then use that as a "parent" image for a differencing virtual disk for all other servers.  You could also get WSUS and use that to keep your various networks up to date, if you need.

Make sense?  If not, feel free to contact me offline - - I can get a bit more detailed.
Not applicable
Great Post but.. since you are using windows 2003 32-bit how did you get clustering to work on 32-bit. I thought clustering was strictly 64-bit business?
Not applicable
RobK - great question.  Wiht the 32-bit bersion of the Exchange bits, you can get clustering to work, and you can mount up to 5 databases.  Also, keep in mind that Enterprise Edition is required for CCR (production/64-bit Enterprise Edition can go to 50 databases).

The two biggest limitations I ran into were the limitation on databases (my customer is going to have 42 databases, so my production install script wants to create 42 SGs and DBs - I had to test with 5) and the fact that you can't license a 32-bit CCR cluster.  When you run the "Set-ExchangeServer" cmdlet with the "-ProductKey" parameter and a valid product key, you will get an error thrown saying you can't license CCR on 32-bit.  You can license all of the other servers, just not the CCR cluster!

This is great because it lets you test even CCR on your 32-bit Virtual PC and Virtual Server labs, but I am looking forward to getting my lab rebuilt on 64-bit Windows Server 2003 on my Hyper-V RC1!!  (That and moving to 64-bit Windows Server 2008!)
Not applicable
Thanks for the reply
I already have my lab running each Exchange 2007 roles on windows 2008 64-bit. The only problem was the cluster piece which now no longer accepts virtual shared disks as this was the case with windows 2003 cluster requirements. The windows 2008 cluster has much more demanding requirements. (had to resort to iSCSI in order to get the cluster going). Hyper-V looks really nice and promising but its not quite ready yet...:)
Not applicable
RobK - Watch for Hyper-V RC1, there are some improvements there.

As for "shared disks" - as I understand it iSCSI is the only way to go wtih that.  One of the big positives for CCR is the removal of the need for shared disks.  That shared disk is a single point of failure, and CCR allows you to remove that from your environment.
Not applicable
This is really essential stuff for each serious Exchange 2007 deployment, You can define the configuration in advance and during "hot" implementation You eleminate many of the misconfiguration or error sources.

we want to hear more from You!


Not applicable
Thanks for the kind words, Zacky!  Summer is a crazy time with Microsoft's year end scramble and vacations and such, but I have a couple of ideas on the back burner.  I have my Windows Server 2008 based script worked out and will be working up a blog entry for that for starters, so watch for that!
Not applicable
Hi Robert!

I'm waiting with baited breath for the 2008 you happen to have them handy now?  I've got all the VMs setup and ready to go as I type this.  Feel free to contact me under a separate cover dplema @

Not applicable

Sorry I didn't get back to you quicker!  I took a long vacation with the family, and now I'm in Seattle at TechReady (our "internal TechEd" at Microsoft).  I've been very disconnected lately, but I'm getting back in the swing now.  I am presenting the Windows 2008 scripts tomorrow morning, and I'll work on the blog entry RSN (RSN = Real Soon Now) to get them posted.  I need to make sure that there is no more cleanup needed before posting.

Thanks for the interest!!
Not applicable

I hope you had a great vacation!  I'd be happy to be a Guinea Pig for you.  Please send a separate email to me at dplema @

Take Care>>>Dustin
Not applicable
Thanks, Dustin!  Gimme a week or two and I'll see what I can do!
Version history
Last update:
‎May 05 2008 04:04 PM
Updated by: