RSS Subscription 168 Posts and 2,769 Comments

Archive for March, 2008

Exchange 2007 SP1 SCC using Server 2008 StarWind iSCSI – Part 2

Welcome to Part 2 of this article series. In Part 1, we started off by discussing the goal of this lab. That goal is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 SP1 Failover Clustering. We first discussed what the lab setup is going to be using VMware Workstation, and then proceeded to the configuration of RocketDivision’s StarWind iSCSI Target software. We then went into Exchange 2007 and did the initial iSCSI Initiator connection to our iSCSI Target.

In this Part, I will be preparing our Cluster Nodes by installing any prerequisites needed prior to the cluster formation and Exchange 2007 SP1 installation. When that is complete, we will continue with our iSCSI configuration by adding our LUNs to the Cluster Nodes, partitioning these LUNs, formatting these LUNs, and ensuring that shared disk storage is working as intended.

Part 1

Part 2

Part 3

Part 4

Prerequisite Installation on Cluster Nodes (NodeA and NodeB)

Downloading XML Files for prerequisite installation

To prepare your server for Exchange installation as well as Cluster installation, there are a number of prerequisites that are needed on each node. The Microsoft Exchange Team presented several XML files which allow you to install the necessary prerequisites for each type of node; whether that may be a standalone Client Access Server, Hub Transport Server, Mailbox Server, Clustered Mailbox Servers, or a Unified Messaging Server.

There is also an XML file for the Typical Installation which includes the Hub Transport Server, Client Access Server, as well as a Mailbox Server Role. Instead of reinventing the wheel, head on over to the blog article that explains these XML files. You can visit that blog entry here which is based of the Technet article here. To download these XML files, go to the following URL here. Save them somewhere on your hard drive (files will be stored on C:\ on both Cluster Nodes) and transfer the following XML files to each Cluster Node:

  • Exchange-Base.xml
  • Exchange-ClusMBX.xml

Because part of the assumptions are that you have already deployed a Client Access Server as well as a Hub Transport Server, I will not detail the installation process for each of these roles. That can be explained by reading the URLs provided just above.

Installing prerequisites using XML files

The prerequisite installation on both nodes will be identical. Log on to to each cluster node (order is of which cluster node is done first is irrelevant), and open the Command Prompt.

Once in the Command Prompt, we will use the first XML, Exchange-Base.xml, which checks for the following tools and installs if not currently installed:

  • RSAT-ADDS – Active Directory Domain Services Remote Management Tools which includes LDIFDE and other Directory Services Tools
  • PowerShell

To install these tools using the Command Prompt, type the following command: ServerManagerCMD -ip C:\Exchange-Base.xml

You will need to ensure the server is rebooted prior to running the Exchange-ClusMBX.xml prerequisite installation. Once the server is back up, proceed to opening the Command Prompt again. Once in the Command Prompt, we will use the second XML, Exchange-ClusMBX.xml, which checks for the following tools and installs if not currently installed:

  • Failover Clustering
  • Web-Server Role (Internet Information Services 7.0)
  • Web-Metabase
  • Web-Lgcy-Mgmt-Console
  • Web-ISAPI-Ext
  • Web-Basic-Auth
  • Web-Windows-Auth

To install these tools using the Command Prompt, type the following command: ServerManagerCMD -ip C:\Exchange-ClusMBX.xml

Adding LUNs to Cluster Nodes (NodeA and NodeB)

In Part1, we used each cluster node’s iSCSI initator to establish connectivity to our StarWind iSCSI target. This exposed both iSCSI target’s, but the LUNs were not added to either of the Exchange Cluster Nodes. In order to do this, it is imperative that you only have one Exchange Cluster Node up at any given time until Clustering is installed.

The reason for this is because data could be lost or corrupted if both disks are fighting for disk access at the same time. Once clustering is installed on at least one node, you can bring up the second node as the clustering service will prevent disk control to the node who is not considered the Active Cluster Node. The process of installing Clustering is as follows:

Setting up shared disks (Node A)

In Part 1, we left off exposing the iSCSI targets to both Cluster Nodes. Now that each node’s iSCSI Initiator can see these targets, let’s begin setting up the shared disk. To proceed, ensure that Node A is turned on and Node B is turned off to avoid lost data and/or corruption. By taking a look at Disk Management (Start > Administrative Tools > Server Manager > Disk Management), we will see that no shared disks have currently been added to Node A.

Let’s go back to the iSCSI Initiator (Start > Administrative Tools > iSCSI Initiator). Taking a look at the targets, we can see that both are set to Inactive.

For each iSCSI Target, click the “Log on…” button and place a check mark in the “Automatically restore this connection when the computer starts.” Click OK to Continue.

You will now see that both iSCSI Targets have been Connected (Activated) on Node A.

Go back into Disk Management (Start > Administrative Tools > Server Manager > Disk Management). We now see that two new shared disks have currently been added to Node A.

We will want to bring both of these disks Online. You can do this by Right-Clicking Disk 1 > Choose Online. Do the same for Disk 2.

Now that both disks are Online. We will want to Initialize these disks. You can do this by Right-Clicking Disk 1 > Choose Initialize.

When Initializing Disk1 and Disk 2, choose the following options. Click OK to Continue.

Now that we have Initialized both Disk 1 and Disk 2, we will partition both those disks as a Simple Volume and format both volumes as NTFS (I hope nobody still uses FAT!). You can do this by Right-Clicking the unallocated space for Disk 1 and Disk 1 > Choose New Simple Volume. This will bring you to the Welcome to New Simple Volume Wizard. Click Next to Continue.

You will now have to specify the Volume Size. In this example, we are specifying the Volume Size for our database volume. You will need to do these steps on the Quorum volume as well. Choose the maximum allocatable space available. Click Next to Continue.

Assign the drive letters accordingly. The drive letter D will be for the Database volume and the drive letter Q will be for the Quorum Volume.

Note: You may have to change the drive letter for any CD-ROM, DVD-ROM, or any other volume that may be installed on your system to use the drive letter you want. You can read here for more information on how to change a drive letter.

For larger servers, you may want to use Volume Mount Points instead of Drive Letters if you would be using more than 26 volumes. Volume mount points are also good for LCR implementations as you can easily switch the target path of the Mount Point if 1 location becomes corrupt. Click Next to Continue.

You must finally format the volume. I would give the volume a name, such as Database or Quorum. I would also choose Quick Format. Quick Format prevents a chkdsk being run on the disk prior to a format. Click Next and then Finish to Complete this Process.

When completing this process on both disks, your Disk Management MMC should look similar to the following image.

As an optional but recommended step, I would recommend opening both volumes and creating a .txt file. This will allow you to verify after adding both disks to Node B, that the shared functionality is properly working.

Verifying Disk Configuration (Node B)

We will now need add the fully partioned and formatted disks to Node B. Shut down Node A followed by booting up Node B once Node A has finished shutting down. In the case of this lab, a VMware pause will suffice if you successfully added the clustering option when you created your iSCSI Target within StarWind.

If you forget to choose the Clustering option, you will receive a Connection Error message when attempting to log on to the target. You can do one of two things. The first being is to shut down Node A completely to release the connection to StarWind (not recommended). The second option is to delete the iSCSI target, re-create it within StarWind with the Clustering option enabled. Then go back onto both Nodes, exposing the Target to both nodes, set up the shared disk on Node A and go through the disk initialization, partitioning, and the formatting process explained above. This is recommended since we will need to simulate a Cluster environment in future Parts to this article series.

By taking a look at Disk Management (Start > Administrative Tools > Server Manager > Disk Management), we will see that no shared disks have currently been added to Node B.

Let’s go back to the iSCSI Initiator (Start > Administrative Tools > iSCSI Initiator). Taking a look at the targets, we can see that both are set to Inactive.

For each iSCSI Target, click the “Log on…” button and place a check mark in the “Automatically restore this connection when the computer starts.” Click OK to Continue.

You will now see that both iSCSI Targets have been Connected (Activated) on Node B.

Go back into Disk Management (Start > Administrative Tools > Server Manager > Disk Management). We now see that two new shared disks have currently been added to Node B. Unlike when we did this with Node A, we can see that the disks are formatted and partitioned, but are not online.

Because the disks are not online, we will want to bring both of these disks Online. You can do this by Right-Clicking Disk 1 > Choose Online. Do the same for Disk 2.

After the disks have been brought online, they will most likely be using different drive letters than you assigned on Node A. Because of this, you must assign the drive letters to match the same letters you used on Node A. The drive letter D will be for the Database volume and the drive letter Q will be for the Quorum Volume.

Note: You may have to change the drive letter for any CD-ROM, DVD-ROM, or any other volume that may be installed on your system to use the drive letter you want. You can read here for more information on how to change a drive letter. When completing this process on both disks, your Disk Management MMC should look similar to the following image.

If you performed the optional but recommended step of adding a .txt file to both volumes to ensure shared disk communication was working, now would be the time to open both volumes (both D:\ and Q:\) to see if the .txt files are there. If you do indeed see the .txt file, shared disks is working as intended. If you do not see the .txt file, troubleshooting shared disks will need to ensue.

Summary

Well folks, that is all for Part 2 of this article. To recap on what was included in Part 2 of this article series, we first started off recapping what was included in Part 1 of this article and what the goal of this lab is for. It is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 Failover Clustering.

In Part 1, we left off at exposing the iSCSI LUNs to our Exchange 2007 Cluster Nodes. In Part 2, we prepared our Cluster Nodes by installing any prerequisites needed prior to the cluster formation and Exchange 2007 SP1 installation. When that was complete, we continued with our iSCSI configuration by adding our LUNs to the Cluster Nodes, partitioned these LUNs, formatted these LUNs, and ensured that shared disk storage was working as intended.

For Part 3, I will detail the following:

  • Form the cluster, beginning with the Node A followed by Node B
  • Configure the cluster networks
  • Configure the cluster quorum
  • Validate the failover cluster
Share

ZIP Package of UM Test Phone + DLL Files

Microsoft has provided a UM Test Phone that allows you to test UM functionality without having a real PBX installed. The guide for setting this up is located here. Part of the guide is for obtaining the .exe for the UM Test Phone as well as obtaining all the .dll files needed to ensure the UM Test Phone works. That information is located here. This can be a little time consuming gathering all the necessary files required. Since I did that, I figured I would package up the umtestphone.exe file as well as the .dll files so you, the reader, do not have to bother with this.

I just want to stress that I take no responsibility for anything that goes wrong from you running this in your environment. I suggest using it only in a segregated test environment to ensure that if something does go wrong, it does not affect production. You use the contents of the provided packaged file at your own risk.

Update (11/25/2009): The UM Test Phone works fine against Exchange 2010 UM as I just tested it.  The UM Test Phone does not work on Windows 7 even with Windows Compatibility Settings configured on the executable.  You can use Windows XP Mode with a bridged NIC.  Windows XP Mode will use your computers audio speakers and things will work well.  I’m not sure if the application works on Windows Vista as I have never tested it on Windows Vista.

Here is a screenshot of the contents of the zip file opened in WinRAR:

You can download the packaged .zip file here.

Share

Exchange 2007 SP1 SCC using Server 2008 StarWind iSCSI – Part 1

Now that Exchange Server 2007 SP1 and Server 2008 is RTM, I thought it would be nice to create an article on how to use Server 2008’s built in iSCSI Initiator software to connect to an ISCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 Failover Clustering. The ISCSI software that will be used is RocketDivision Starwind. This article is to guide you through the entire process from setting up the ISCSI Target Software, preparing Server 2008 for Exchange 2007, installing Exchange 2007 in a SCC Failover Cluster, and managing your SCC Failover Cluster.

Part 1

Part 2

Part 3

Part 4

Lab Setup

Guest Virtual Machines

One Server 2008 Enterprise (Standard can be used) RTM/SP1 x64 Domain Controller which contains the Starwind ISCSI Target software. Exchange 2007 SP1 will be installed with the Hub Transport Server and Client Access Server roles.

Two Server 2008 Enterprise (Enterprise required) RTM/SP1 x64 (x64 required) Member Servers where Exchange 2007 SP1 will be installed with the Mailbox Server role for Failover Clustering

Assumptions

  • You have a domain that contains at least one Server 2003 SP2 Domain Controller (DC).
  • You have configured the IP settings accordingly for all workstations to be on the same subnet including the public NICs for both Failover Cluster nodes. I have provided the IP scheme of my lab below, but this will vary depending on your needs and VMware configuration.
  • You have an existing Exchange 2007 Hub Transport Server as well as a Client Access Server. For the sake of this lab, I will installing the Hub Transport Role as well as the Client Access Server Role on our DC. This is not a recommended practice for production, but for this lab, we will do so to consolidate and conserve resources. This article does not go over the installation or configuration of these roles.

Configuration of VMware Workstation for Failover Cluster Nodes

There is no official VMWare support for Server 2008 at the time of writing this article. The latest version and build is VMWare 6.0.2 build-59824. There is currently “experimental” support which you will see when specifying the Operating System as you create your Virtual Machine. Through my experiences writing Part 1, I did not encounter any real issues related to Windows Server 2008 and VMware Workstation 6.0.2 build-59824.

SCC Failover Clusters using Node Majority with File Share Witness Quorum are supported, but Node Majority with Disk Witness Quorum are preferred. For this lab, we will be using the Node Majority with Disk Witness Quorum. One of the new features of the Disk Witness Quorum, is that it essentially the Quorum Disk from Windows Server 2003 with added benefits. All nodes within the cluster gets a vote, but with the new Disk Witness Quorum model, the Quorum Disk gets a vote as well. So essentially, if your Quorum Disk goes down, your Cluster is still operational.

Processor: 2

Memory: 848MB

Network Type Public NIC Network Address Translation (Used so Virtual Machines get an IP Address without taking up IP Addresses at a client’s site while still being granted Internet access through NAT functionality)

Network Type – Private NIC – VMnet9 (Shared with Node2)

Virtual Disk Type – System Volume (C:\): VMware SCSI 18GB

Virtual Disk Type – Exchange Database/Logs (D:\): iSCSI 1GB

Virtual Disk Type – Disk Witness Quorum (Q:\): iSCSI 500MB

Note: The Virtual Disk for the Exchange Database and Disk Witness Quorum will be created within Windows as part of the ISCSI initiation process and will not be created in the VMware properties. Also, in a production envirnonment, depending on your design, you will most likely expose separate LUNs to separate your Database and Logs due to various reasons such as performance, recoverability, etc. For the purpose of this lab, we will allow for the database and logs to co-exist on the same LUN for reasons of consolidation.

Configuration of VMware Workstation for Domain Controller/Hub Transport Server/Client Access Server/StarWind

Processor: 2

Memory: 1112MB

Network Type Network Address Translation (Used so Virtual Machines get an IP Address without taking up IP Addresses at a client’s site while still being granted Internet access through NAT functionality)

Virtual Disk Type – System Volume (C:\): VMware SCSI 20GB

IP Addressing Scheme (Public Subnet)

IP Address – 192.168.119.x

Subnet Mask – 255.255.255.0

Default Gateway – 192.168.119.2

DNS Server – 192.168.119.150 (IP Address of the Domain Controller/DNS Server)

IP Addressing Scheme (Private Cluster Heartbeat Subnet)

Node A: IP Address – 10.10.10.60

Node B: IP Address – 10.10.10.61

Subnet Mask – 255.255.255.0

Preparation of Cluster Nodes (NodeA and NodeB)

Network Interface Card (NIC) Configuration

First thing we will want to do is configure the IP Configuration of both the Public and Private NIC.

We will want to rename our public NIC connection to Public and our heartbeat NIC connection to Private. To do so, go to Start > Right-Click Network > Properties.

This will bring up the Network and Sharing Center which presents a list of tasks to you on the left-hand side of the Window. Click on Manage Network Connections.

Now you will be presented with the Network Connections window. This is where you can modify the network properties for each NIC in your server. For your public connection, rename your Local Area Connection to Public. Likewise, for your private heartbeat connection, rename your Local Area Connection to Private. After you have done this, it will look something similar to the following:

Part of the assumptions earlier in this article as that you have a properly configured TCP/IP Network where all nodes are properly connected to the TCP/IP Network. Because of this, I will skip the Public TCP/IP Configuration and proceed to configuring the Private Heartbeat NIC. A quick note though – When configuring the Public NIC, I would remove IPv6 but leave both Link-Layer options checked.

Double-Click or Right-Click > Properties on the Private NIC to begin configuration.

Uncheck the following:

  • Internet Protocol Version 6 (TCP /IPv6)
  • Link-Layer Topology Discovery Mapper I/O Driver
  • Link-Layer Topology Discovery Responder

Select Internet-Protocol Version 4 (TCP /IPv4) and press the Properties button. For NodeA, the only TCP/IP configuration we will need, is the IP Address and Subnet Mask. NodeA’s IP configuration will be 10.10.10.60/24 while NodeB’s IP configuration will be 10.10.10.61/24.

Go into the Advanced NIC configuration settings by clicking the Advanced button. From there, you will navigate to DNS tab and de-select “Register this connection’s addresses in DNS.”

Select the WINS tab and de-select “Enable LMHOSTS lookup” and configure the NetBIOS setting to “Disable NetBIOS over TCP/IP.”

Once you are done configuring the Advanced settings, press OK three times and you will be back at the Network Connections screen. From here, choose Advanced and select Advanced Settings

.

You will be presented with the Binding Order for your current NICs. Ensure that the Public NIC is on top by selecting Public and pressing the green up arrow key on the right-hand side of the dialog.

Rename Computer and Join to Active Directory Domain

Windows Server 2008 will automatically assign the computer a random computer name. Because of this, we will change the computer name, join the computer to the Active Directory domain, followed by a reboot. To do this, use the GUI as you normally would in previous versions of Windows, or you can use PowerShell by proceeding with the following steps:

Enter the following lines of code (code thanks to justaddcode.com) separately in your PowerShell console (PowerShell must first be installed by opening a Command Prompt and typing ServerManagerCmd -i PowerShell). Once PowerShell is installed, you can open a PowerShell window by navigating to Start > All Programs > Windows PowerShell 1.0 > Windows PowerShell or by clicking on Start > Type PowerShell in search field:

$comp = get-wmiobject Win32_ComputerSystem

$comp.Rename(“NodeA”)

$comp.JoinDomainOrWorkgroup(“Shudnow.net”,”domainPassword”,”MYDOMAINdomainAdmin”,$null,3)

Shutdown -r

If you are making these changes on NodeB, ensure that you enter NodeB in the PowerShell code.

Reboot the Cluster Failover Node to complete configuration changes.

Starwind ISCSI Target Configuration

RocketDivision provides an ISCSI Target compatible for Windows Server 2008. This product is called StarWind. The free version does not provide the capability for more than one node to connect to a target at the same time. I will be using a licensed copy of StarWind to provide you the knowledge needed to fully install a Single Copy Cluster using the Windows Server 2008’s built-in iSCSI initiator.

One thing I want to make you aware of, is that many of us have become accustomed to minimizing utilities to the notification area (system tray) by clicking X. If you do this with StarWind, it will actually close the program instead of minimizing it to the notification area. Also, every time you shut down/reboot, you will have to connect your connection. Your Virtual Disks will still have saved, thankfully. So please be cognizant about this before you continue with your lab.

Once the software is installed on a machine (easy install… no tutorial needed), open StarWind and Right-Click on your default connection and choose Connect.

You will then be presented with a password prompt with the default username of test as well as a default password of test. This is configurable in the Connection Properties.

Once your credentials have been entered and OK has been pressed, you will notice that the previously greyed out Connection is now colored. This will allow you to go enter your Registration information for your connection via the Help drop down.


Now that we have a functional connection, we have to add a device to it to allow our cluster nodes to be initiate an iSCSI connection to obtain iSCSI-connected disks. To do this, Press the Add Device button on the Toolbar. Select the type of Device you wish to use. For purposes of this lab, we will use an Image File device. Click Next to Continue.

Then choose Create New Image. Click Next to Continue.

You will now need to enter the information needed to create the new disk image. The file extension should end with an .img. As you can see from the image below, the image name path might look like something you are not accumstomed to. Click the … button to assist you in selecting the location you would like to create your image. The image name path will automatically be filled in for you. All that will be needed is to fill in the image name.img filename. Finally, specify any additional values you may want such as image size, compression, encryption, etc. Click Next to Continue.

When configuring the following screen, you must ensure you Select “Allow multiple concurrent iSCSI connections (clustering). Click Next to Continue.

Choose a Target Name. This is optional, and if you enter nothing, a default Target Name will be provided. For purposes of this lab, we will specify a Target Name of Server2008SCC. Click Next and Finish to complete the creation process of your disk image.

Once your disk image is created, your StarWind interface should like similar to the following Window.

Repeat the steps above to create one additional image file for your Disk Witness Quorum. This disk should be 500MB in size. You will also need to ensure you change the Target Name for the new Disk Image. For this new Disk Witness Quorum, I have named the Target Name as Server2008SCCQuorum. After you are completed, your StarWind interface should look similar to the following Window.

Exchange 2007 ISCSI Initator Configuration

To begin configuration of the Exchange 2007 Initiator so it can obtain access to the Virtual Disks provided by StarWind, we must first open the iSCSI Initator Console. You will want to do all of the following on both NodeA and NodeB. It is safe to keep both nodes up currently as we won’t actually be exposing any disks to Exchange 2007 until Part 2 of this article series.

Go to Start > Control Panel > Administrative Tools > iSCSI Initator > Click Yes to Continue.

The next option is personal preference. You can choose no if you want to manually configure the firewall. My recommendation would be to Choose Yes to ensure the firewall rules get properly added. Click Yes to Continue.

You will also need to go into the Windows Firewall on the Server which contains StarWind and ensure both a TCP incoming and outgoing Firewall rule is created for port 3260. From my experiences, disabling the Windows Firewall will disable all connectivity with other machines. When I turned off the Windows Firewall, all connectivity to that machine was completely cut off. If anybody knows why this may be, drop me an e-mail. Thanks!

As a side note, one of the things I did do, is log on each server, go into the Windows Firewall properties, and set inbound connections to Allow for the Domain Profile, Private Profile, and Public Profile.

Configuring the Windows Firewall is out of the scope of this article. To learn more about the Windows Firewall, visit the following article:
http://www.windowsnetworking.com/articles_tutorials/configure-Windows-Server-2008-advanced-firewall-MMC-snap-in.html

When you have successfully done the above steps, you can now proceed with the iSCSI Initator Configuration.

To connect the iSCSI Initator to the iSCSI Target, Click Add Portal > Enter IP Configuration for iSCSI Target Server. Click OK to Continue.

This will expose the targets you created within StarWind as shown in the following image.

Summary

Well folks, that is all for Part 1 of this article. To recap on what was included in Part 1 of this article series, we first started off discussing what the goal of this lab is for. It is to showcase Server 2008’s built in iSCSI Initiator software to connect to an iSCSI Target and deploy a Single Copy Cluster (SCC) for Exchange 2007 Failover Clustering. We first discussed what the lab setup is going to be using VMware Workstation, and then proceeded to the configuration of RocketDivision’s StarWind iSCSI Target software. We then went into the Exchange 2007 Cluster Nodes (NodeA and NodeB) and proceeded with the initial iSCSI Initiator connection to our iSCSI Target.

For Part 2, I will detail the following:

  • Install Exchange Cluster Node Prerequisites prior to Cluster formation and Exchange 2007 SP1 Installation
  • Steps required to expose the disks created in Part 1 to both Exchange Cluster Nodes
Share