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)
- labhsv-xcl001 (Cluster name)
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.0Node2
Address: 10.1.1.102
Mask: 255.255.255.0
- Disable strict name checking as per http://support.microsoft.com/kb/281308
- In the file c:\windows\system32\drivers\etc\hosts, on both cluster nodes, add the following lines:
10.1.1.1 labhsv-xcl001r1
10.1.1.2 labhsv-xcl001r2NOTE: 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!