Posts from 2012

Deploying Server Core 2008 R2 for Hyper-V: Network Teaming

In our deployment, we are using servers with Intel network adapters, so the first thing is to install the manufacturer driver package because this enables the ANS (Advanced Network Services) functionality such as Teaming.

The new version of the Intel driver for Server 2008 R2 includes a command line utility for managing networks in Server Core known as ProsetCL, which operates with a syntax not too dissimilar from PowerShell.

The commands from ProsetCL I will be using in this post are:

  • ProSetCL Adapter_Enumerate
  • ProSetCL Team_Create

The full Intel documentation for ProsetCL can be found at http://download.intel.com/support/network/sb/prosetcl1.txt.

With all of the adapters nicely named from the previous post Deploying Server Core 2008 R2 for Hyper-V: Network Naming, this part is actually pretty easy.

The first step is to run an export of the current network adapters to a text file with ipconfig /all > C:Adapters.txt. Once you have this open the file with Notepad.exe C:Adapters.txt.

With the text file open, in the command line window, navigate to the directory C:Program FilesIntelDMIXCL which is where the ProsetCL utility is installed. You could register the directory into the PATH environment environment variable if it makes your life easier, but I didn’t do this personally.

Execute the command ProsetCL Adapter_Enumerate. This will output a list of the network adapters on the server into the command line. Sadly, the Intel utility and Windows order the network adapters differently which is why the text file is needed to marry the two up.

Once you have figured out which adapters need to be teamed together to form your various Client Access, Management, Heartbeat, CSV and Live Migration networks, you are ready to proceed.

You need to know at this point what type of teams you want to create also. The Intel adapters and utility support the following team types:

Team Type Team Function ProsetCL Shorthand
Switch Fault Tolerance Two adapters are connected to independent switches, with only one adapter active at any one time. In the event of a switch failure, the standby link will become active allowing communication to continue. SFT
Static Link Aggregation Two or more adapters are teamed in an always active manner. This mode allows you to achieve a theoretical speed equal to the sum of the speed of all the adapters in the team. To be used when LACP (Link Aggregation Control Protocol) is not available on your switch infrastructure. SLA
LACP (Link Aggregation Control Protocol) Similar to Static Link Aggregation, however the network adapter and the switch to which it is connected negotiate the aggregation using the LACP protocol. 802.3AD
Adapter Load Balancing Two or more adapters are teamed together, whereby the utility forces traffic to be routed out of each port in turn, equally sharing the load across the ports. ALB
Adapter Fault Tolerance Allows two or more ports to be connected in a team whereby the ports may have differing connection speeds (Eg. 1Gbps for the Primary Active adapter and 100Mbps for the Failover adapter). AFT

For full details and a more detailed explanation of each teaming mode, refer to the Intel ANS page at http://www.intel.com/support/network/sb/cs-009747.htm

Now that you know which adapters to be teamed together and which teaming mode you want to use for each, it is time to create the teams.

Enter the command as follows:

ProsetCL Team_Create 1,2 MAN_Team SFT

In this example, a team will be created using ports number one and two (the numbers as referenced by the previous Adapter_Enumerate command) with a team name of MAN_Team for the Management network using the Switch Fault Tolerance mode.

Following the command, you should receive a prompt that the team was successfully created. A new network adapter will now be present if you execute the ipconfig /all command named, sadly, Local Area Connection.

Assuming you named all your adapters from the default name using the previous post, the adapter will always be called Local Area Connection with no trailing numbers. If you run the netsh interface set interface name command after creating each team, it makes it much easier to name the teams as you go rather than doing them in a batch at the end.

In the next post, I will describe configuring the network binding order to ensure the correct cluster communication occurs out of the correct adapter.

Deploying Server Core 2008 R2 for Hyper-V: Network Naming

Currently, I am heavily involved in a project to deploy a new infrastructure project for a new branch office. In this office we are deploying a network in a box (pod) style configuration consisting of networking, storage array, fibre channel switching and last but not least, a pair of servers to operate a Hyper-V Cluster running on Windows Server 2008 R2 Server Core.

In this series of posts, I will share some of the things I have found, learnt and discovered on my journey to deploying the Server Core Hyper-V Cluster. This first post focuses on networking as this is the first thing that needs to be configured on the hosts before you can progress into anything else, and also is the most fundamental operational component of the Hyper-V role.

Luckily for us, Server Core still has Notepad which makes working with some of these commands much easier.

For things, first, run ipconfig /All > C:Adapters.txt to pipe a list of all of the adapters Windows can see to a text file along with their current configuration. The most important element here are the names. By default, all of the adapters are named Local Area Connection with a trailing number. For identification purposes, I wanted a naming convention for them all so in the event of a cable or port failure we could easily identify which port was at fault.This will also make identifying the adapters for the purpose of setting up the teams easier.

Open the text file with the command Notepad.exe C:Adapters.txt and identify which adapters in the text file map to the physical adapters on your server. The easiest way to connect all of the adapters to a physical network and then one by one, disconnect an adapter, re-run the piped ipconfig command and see which adapter has changed its link state.

Once you have identified an adapter, use the following command to name it:

netsh interface set interface name=”Local Area Connection” newname=”SL1-P1-MAN1”

My naming convention consists of SL1, which identifies which PCI slot the port is based on, P1 which identifies the port within that slot and finally MAN1 which tells me that it will be the first port in the Management team once configured.

Repeat these steps until all of your networks are named then sit back and be safe in the knowledge that if a problem occurs with one of your ports once your server is in the wild, you will be able to easily guide your on-site technician to the correct port.

Error Launching AD RMS Console

Early last week, I encountered a problem with logging in our AD RMS (Active Directory Rights Management Services) production environment which is preventing us from generating reporting and RMS usage statistics. After speaking with Microsoft Premier Support we determined that our AD RMS Logging database was missing some of the stored procedures required to generate the reports.

I decided to do an install of AD RMS in our test lab environment so that I can simulate the reinstallation process to resolve the problem as Premier Support have recommended and I ran into a wierd issue.

Once the installation of the AD RMS role successfully completes, you will natrually try and launch the AD RMS console to check your new installation, however that won’t work. Doing so will result in a HTTP 401 Unauthorized error. To resolve the problem, you need to log off the server and then log on again. This will then grant you the necesarry tickets to access the AD RMS console and manage the new installation.