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


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 (http://www.interact08.com). 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 (http://msexchangeteam.com/archive/2008/03/12/448421.aspx)

- 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:

Setup.com /PrepareAD /OrganizationName:TechReady

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

Setup.com /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:

Node1

Address: 10.1.1.101
Mask: 255.255.255.0

Node2

Address: 10.1.1.102
Mask: 255.255.255.0

10.1.1.1 labhsv-xcl001r1
10.1.1.2 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.

ScriptSettings.csv:

Descriptive Name (from file)

 

 

Description

 

 

Example

 

 

ProductKey

 

 

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

 

 

12345-12345-12345-12345-12345

 

 

GCServer

 

 

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.

 

 

labhsv-dc001

 

 

FirstPFServer

 

 

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.

 

 

labhsv-xhb001

 

 

FSW.csv:

Descriptive Name (from file)

 

 

Description

 

 

Example

 

 

HTName

 

 

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.

 

 

labhsv-xhb001

 

 

CMSName

 

 

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

 

 

labhsv-xmb001

 

 

Share

 

 

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.

 

 

fsw-labhsv-xmb001

 

 

ClusterAdmin

 

 

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.

 

 

clus.admin

 

 

ClusterInfo.csv:

Descriptive Name (from file)

 

 

Description

 

 

Example

 

 

CMSName

 

 

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

 

 

labhsv-xmb001

 

 

ClusterAdmin

 

 

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.

 

 

clus.admin

 

 

ClusterAddr

 

 

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

 

 

192.168.0.182

 

 

CMSAddr

 

 

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

 

 

192.168.0.183

 

 

Node1ReplName

 

 

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.

 

 

labhsv-xcl001r1

 

 

Node1ReplAddr

 

 

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

 

 

10.1.1.1

 

 

Node2ReplName

 

 

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.

 

 

labhsv-xcl001r2

 

 

Node2ReplAddr

 

 

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

 

 

10.1.1.2

 

 

SCRInfo.csv:

Descriptive Name (from file)

 

 

Description

 

 

Example

 

 

SCRName

 

 

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

 

 

labhsv-xsc001

 

 

SourceCMS

 

 

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.

 

 

labhsv-xmb001

 

 

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


Comments (16)
  1. Apoc says:

    This is what I have been looking for for the last 12 months :o)

  2. Thanks, Apoc, for the comment!  Glad this is going to help you out!!

  3. Joseph Nguyen says:

    Boomer Sooner!  Very cool.

  4. dhunt says:

    Great resource ! Thanks for the effort

  5. 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.

    Thanks!

    -Chris

  6. 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 – rgillies@microsoft.com – I can get a bit more detailed.

  7. RobK says:

    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?

  8. 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!)

  9. RobK says:

    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…:)

  10. 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.

  11. Wolfgang Zerzawy says:

    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!

    thanx,

    zacky

  12. 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!

  13. Dustin Lema says:

    Hi Robert!

    I’m waiting with baited breath for the 2008 scripts….do 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 @ comcast.net

    Thanks!

  14. Dustin,

    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!!

  15. Dustin Lema says:

    Robert,

    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 @ comcast.net.

    Take Care>>>Dustin

  16. Thanks, Dustin!  Gimme a week or two and I’ll see what I can do!

Comments are closed.

Skip to main content