Microsoft Hyper-V Networking and Configuration #3

In this part, I'll continue to try to use a practical Hyper-V Networking example to introduce the concepts. This time, I'll use a more complex example which illustrates the type of networking configuration that is required when it comes to configuring Hyper-V Networking between two or more Hyper-V Hosts.

We will also describe Hyper-V VMBUS and VSP/VSC design, and explain how it improves the communication between Virtual Machines and Hyper-V Parent Partition. You might want to read Part I of this series of articles here if you are not familiar with the terms used in this article. Since this part continues to explain the Hyper-V Networking examples, I recommend reading Part II here if you have not already.

We will discuss the following topics in detail:

• A Complex Hyper-V Networking Configuration Scenario
• Hyper-V Networking VMBUS and VSP/VSC design and how it improves the communication.

Some Terms:

Hypervisor

Hypervisor is a layer of code which runs directly on top of the hardware. It is the lowest thing which owns the hardware and provides access to Virtual Machines running on Hyper-V Server.

Synthetic VM

Synthetic Virtual Machine runs Integration Services Components. Synthetic Virtual Machines use VMBUS and VSP/VSC design to communicate with hardware devices and Virtual Machines.

Emulated VM

An Emulated Virtual Machine is not aware of the VMBUS and VSP/VSC design or components. It communicates with the Parent partition using emulation.

A Complex Hyper-V Networking Configuration Scenario

In referring to the final scenario, I'll assume that you've read Part 2 of this series here, so please do so if you have not done so already because you might get a bit lost otherwise. The scenarios in part 2 deal with configuring Hyper-V Networking on a single Hyper-V Host. It does not explain how to configure Hyper-V networking across two or more Hyper-V Hosts. This is the most complex configuration which will illustrate how to create Hyper-V networking between two Hyper-V Hosts and how to enable communication across Hyper-V Servers.

You will have noticed in the 'Hyper-V Networking Best Practices' section in Part 2 of this article series, which can be found here, that you should not create a Virtual Network Switch for the sake of it, because it increases the overhead for the VMMS.EXE process. This is where I hope that these scenarios, explained here, will prove to be helpful, because you can adapt the other methods explained in this topic to achieve the results as necessary. There is also a checklist provided in Part 2 that you can use before you dig more into the actual details of the configuration.

This part covers the more typical complex Hyper-V Networking configuration that is required in most production environments. This example includes two Hyper-V Hosts, and shows how you can use the methods explained in Part 2 of this article of series to achieve the communication between Virtual Machines running on two Hyper-V Servers whilst minimizing the overhead.

In this configuration example, you have two Hyper-V Servers; Host1 and Host2. There are four departments; Finance, HR, Sales, and R&D. Virtual Machines of these departments are hosted on both the Hyper-V Servers except R&D. The Hyper-v Host1 is running six Virtual Machines. Three Virtual Machines are running on Host2. Two Virtual Machines for Sales, one for Finance, and one for HR departments are running on Hyper-V Host1. One Virtual Machine for the Sales, Finance, and HR departments are running on Hyper-V Host2. Hyper-V Host1 is also running two virtual machines from R&D department. R&D Virtual Machines are running SQL Servers. There are three Physical Servers located on LAN; Server1, Server2, and Server3.

The Virtual Machine running on each Hyper-V Host looks like as shown in below figure, and before configuring Hyper-V Networking:

Requirements:

• Virtual Machines running for the Sales Department should be able to communicate with each other and the corresponding Virtual Machines running on Hyper-V Host2. These Virtual Machines should also be able to communicate with SQL Server 2008 running on Server1. Sales Virtual Machines store data on Server1 and it is very important not to disclose this data to any other department.
• Finance's Virtual Machines need to store data on the Physical Server Server2, and also communicate with the corresponding Virtual Machines on Hyper-V Host2.
• HR Virtual Machines need to access a shared folder called Server that is located on the Physical LAN Server3, and also communicate with corresponding Virtual Machines on HOST2.
• R&D Virtual Machines should not be able to talk to any Virtual Machines or Physical Servers on the LAN. R&D Virtual Machines traffic should not be visible to any other devices.
• Hyper-V Networking should be configured in such a way that there are no communication issues between Virtual Machines running on both the Hyper-V Servers.
• R&D Virtual Machines should be configured to use a dedicated disk from SAN.

The first thing to remember is that two Hyper-V Hosts are required, and the communication should take place between Virtual Machines running on both the Hyper-V Servers except for the R&D Virtual Machines. This is completely different from the scenarios which were explained in the Part 2 here. The requirement clearly indicates that the connectivity to the External Network or Physical LAN is required because three departments except R&D need to access Servers located on the LAN. That means that we need to create an External Virtual Network Switch to achieve these requirements.

You must keep separate the communication for controlling and managing the Parent Partition from the communication between Virtual Machines across Hyper-V Servers. We've already suggested that you must separate the management traffic by adding one more Physical NIC (assuming you have only one NIC added to Hyper-V Host) to the Hyper-V Servers to avoid any communication issues between the Virtual Machines and thereby increasing the overall performance of the Hyper-V Servers.

We must use the method of Hyper-V Virtual Switch and VLAN Tagging that we described in Part 2 in order to get the results we want. Otherwise you will end up creating Hyper-V Network Virtual Switches to achieve each requirement resulting in poor performance on Hyper-V Server.

Figure 1.1 – Hyper-V Networking Configuration across two Hyper-V Servers.

The Figure 1.1 shows the Hyper-V Networking configuration between two Hyper-v Hosts; Host1 and Host2. The requirements have been achieved both by using a Hyper-V Virtual Network Switch and Hyper-V Virtual Network Switch with VLAN Tagging. Both these methods are required to meet the requirements.

You'll also see from the diagram that the Virtual Machines (VM1, VM2, VM3 and VM4) are assigned a different set of VLAN IDs. VM1 and VM2 belong to Sales department. VM3 and VM4 belong to Finance and HR departments respectively. VM1 and VM2 are assigned VLAN ID 2 and 3 and 4 are assigned to VM3 and VM4. All these Virtual Machines are connected to a Hyper-V External Network Switch called Switch A. This Hyper-V Network External Virtual Switch is not configured with any VLAN ID: in fact. it is configured in Trunk Mode.

Tip: A Hyper-V Networking Virtual Switch is referred to as being configured in 'Trunk Mode' when it is NOT configured with any VLAN IDs or left blank.

Switch A, in turn, is mapped to P-NIC1 on the Hyper-V Host1. This enables communication outside of the Hyper-V Host (e.g. Servers connected to Physical Switch A). P-NIC1 on Hyper-V Server is connected to Physical Switch A which is configured in Trunk Mode. Server1, Server2 and Server3 which are configured to use the VLAN IDs based on their departments VMs and are connected to Physical Switch A.

Physical Switch A, in turn, is connected to Physical Switch C which is mapped to P-NIC1 on Hyper-V Host2.

An interesting part of the requirements is the R&D Virtual Machines configuration. Hyper-V Virtual Network Switch B on Hyper-V Host1 is configured as a Private Hyper-V Network Switch to which both R&D Virtual Machines are connected. This enables us to achieve the R&D requirement. For R&D Virtual Machines, we have created a separate Hyper-V Virtual Network Switch. This is actually not required if we assign a unique VLAN IDs to them. A unique VLAN ID 5 can be assigned to these Virtual Machines and connected to Switch A which enables us to block the communications between these two Virtual Machines only. This configuration does not require us to create another Hyper-V Virtual Private Switch to meet the R&D requirement. But this is not the case with R&D Virtual Machines requirement. We have created another Hyper-V Virtual Private Network Switch by keeping the complete requirement in mind (e.g. R&D traffic must not be seen by other Virtual Machines and servers located on the LAN).

Tip: You'll remember from previous about for tagged and untagged traffic.in my previous articles that a packet generated from a Virtual Machine will be sent to all the devices connected to it.

On the Hyper-V Host2, we have three Virtual Machines running (VM7, VM8 and VM9) with unique VLAN IDs assigned to them (2, 3, and 4 respectively). Switch C as Hyper-V External Network Switch is created and mapped to P-NIC1 on the Hyper-V Host2. These Virtual Machines belong to Sales, Finance and HR and are connected to Switch C. Switch C, in turn, is connected to Physical Switch C so that traffic generated by these Virtual Machines can be seen by the Physical Switch C.

Physical Switch A and Physical Switch C are connected to each other to accept/forward any traffic generated by the Virtual Machines on both Hyper-V Servers. As shown in figure 1.1 above, both physical switches are configured in Trunk Mode so they can accept the packets from devices which are configured with VLAN IDs 2,3, and 4.

P-NIC2, which is a physical NIC, on Hyper-V Host1 is reserved for controlling/managing the Parent Partition.

R&D Virtual Machines are running SQL Server 2008. Per requirement stated above, SQL Server database must be configured on a dedicated volume to avoid any performance issues. Thus, P-NIC3 is a HBA NIC which is connected to SAN Device. E:\ and F:\ drives are configured in Parent Partition to be used by R&D Virtual Machines.

You'll have read in the my previous article that both Hyper-V External Network Switches; Switch A and Switch B are not configured with any VLAN IDs. If you assign any VLAN ID on the Virtual Switch, the traffic will be tagged with that VLAN ID and the communication will be allowed only for that VLAN ID Tagged packet.

You should not face any performance issues if you follow the guidelines provided in Part 2 and this section when configuring Hyper-V Networking to achieve any requirements.

The next section explains the underlying components which play an important role in improving the networking performance of Hyper-V Server and Virtual Machines running on it. You will also learn how these components help speed up the network communication between Virtual Machines.

Hyper-V Networking VMBUS and VSP/VSC design and how it improves the communication.

As you know Microsoft Hyper-V Networking is completely different from its competitor; VMWare. Microsoft Hyper-V Networking relies on components called VMBUS and VSP/VSC which are running in the Virtual Machines. VMBUS and VSP/VSC components are part of Integration Services. Integration Services components equivalent to VMWare's VMWare Tools and VPC Additions found in Virtual Server. Explaining Integration Services components in detail is out of scope for this part of this series of articles.

We will learn about the following topics in this section:

• Microsoft Hyper-V Hypervisor
• VMBUS communication Channel and VSP/VSC design

Microsoft Hyper-V Hypervisor

Microsoft Hyper-V runs directly on top of the hardware. There are some facts regarding Microsoft Hyper-V:

• Hyper-V is a hypervisor-based technology.
• Operating Systems execute in partitions
• The Virtualization Stack has direct access to hardware.
• The parent partition creates child partitions through HYPERCALLs APIs.
• Child partitions do not have direct access to Hardware.
• VMBUS is a logical inter-partition communication channel and available only when Integration Services are installed
• Parent partition hosts VSPs. Child Partitions host VSCs.
• VSCs communicate to VSPs over VMBUS to handle device access.
• The hypervisor handles the processor interrupts and redirect to the respective partition
• When a new VM is created in parent Partition, a new Child Partition is created to host that VM.
• Microsoft Hypervisor is a layer of code that runs natively on the hardware. It is the lowest level on system and is responsible for doing the hardware and resource partitioning. Location of drivers and some OS Core Components differs from the VMWare design.
• Drivers exist in the Parent partition and not in the Hypervisor itself. This reduces the size of the Hypervisor.
• Microsoft Hypervisor is 600KB in size.
• It is very secure because no third party code can be injected in it.

VMBUS communication Channel and VSP/VSC design

Microsoft developers have designed unique components for Hyper-V. These are VMBUS and VSP/VSC. VMBUS stands for Virtual Machine BUS. These components play an important role when it comes to provide Virtual Machines access to the hardware. VMBUS functions as communication layer for Virtual Machines.

Figure 1.2 – VMBUS and VSP/VSC Design and communication

A VMBUS is a logical component over which VSC and VSP talks to each other. VSP stands for Virtual Service Provider which is always running in Parent Partition on Hyper-V Server. There are four VSPs running in the Parent Partition serving requests coming from four Virtual Service Clients (VSCs) running in the child partitions. The four VSP/VSCs running are:

• Network VSC/VSP
• Storage VSC/VSP
• Video VSC/VSP
• HID VSC/VSP

VSCs running in Child Partitions will always communicate with VSPs running in Parent Partition over VMBUS communication channel. There is only one VMBUS component running in Parent Partition which talks to the VMBUS component running in Child Partitions.

As you can see in Figure 1.2 above, there are four Virtual Machines created or I should perhaps say four Child Partitions (VM1, VM2, VM3, and VM4). VMBUS is a component which is running in all the partitions to help communicate with the components running in Parent Partition (VSPs). Explaining all VSP components is out of scope of this article. So we will stick to the Network VSP/VSC design and see how it improves the overall Hyper-V Networking performance.

Before Microsoft Hyper-V, Virtual Server dominated the market for a number of years. Virtual Server did not work very well as it operated same as VMWare's GSX Server. In Hyper-V, Microsoft introduced VMBUS and VSP/VSC components which helped Microsoft gain market share on Server Virtualization. The overall goal of Microsoft was to reduce the extra communication layer which was the case with Virtual Server. The VMBUS and VSP/VSC design in Hyper-V reduces the extra communication layer.

There are two types of Virtual Machines which can be operated in a Hyper-V environment; Emulated Virtual Machine and Synthetic Virtual Machine. As shown in Figure 1.2, VM1 through VM3 are Synthetic Virtual Machines and VM4 is operating as Emulated Virtual Machine. A Synthetic Virtual Machine knows that it is running in a Hyper-V environment and knows how to talk to Parent Partition to access hardware. An Emulated Virtual Machine completely relies on Operating System for accessing hardware as it does not have knowledge of VMBUS and VSP/VSC components.

Microsoft and VMWare both provide a set of Virtual Machine components which are recommended to install in the Virtual Machine. They are called Integration Services and VMWare Tools respectively.

VMBUS and VPS/VSC are part of Integration Services. These components are available only once you have installed Integration Services in the Virtual Machine. As shown in Figure 1.2, Integration Services are installed in VM1, VM2, and VM3 but for VM4 the integration Services components have not been installed. So you do not see VMBUS and VSC components in VM4 child partition. Thus, VM4 operates differently. It has got an extra communication layer to communicate with the hardware. Any traffic generated from VM4 for hardware access will be received by the OS component or the Operating System itself. VM4 does not know how to talk to rest of the devices more efficiently. VM4 works same as Virtual Server VM.

As you can see in Figure 1.2 above, there are two Hyper-V Virtual Networking Switches created; vSwitch 1 and vSwitch 2. These Switches are directly connected to the Network Virtual Server Provider in Parent Partition. The VMBUS communication channel handles the requests coming from Network Virtual Service Clients (VSCs) running in Child Partitions and forward the requests to VSPs running in Parent Partition. This communication is more efficient and faster.

In Figure 1.2 above, you can also see something called Third-Party VSC which is running in VM3. VM3 is running a Linux version which is a supported Guest Operating System on Hyper-V environment. Microsoft has designed Integration Services components for non-Windows Operating Systems also. This includes Linux and other non-Windows Operating Systems. A complete list of Guest and Server supported Operating Systems can be found in Part 1 of articles of this series here. The Third-Party VSC knows how to talk to VSP which is running in the Parent Partition.

Tip: An Operating System is called Supported Operating System in a Hyper-V environment if the Integration Services components can be installed successfully.

You cannot think of improving the overall performance of your Virtual Machines running in Hyper-V environment without installing the Integration Services components. This is one of the required components that you must install in Virtual Machines. Integration Services components provides knowledge to Virtual Machines that they are running in a Hyper-V environment and they should utilize VMBUS and VSP/VSC to communicate with Parent Partition and Virtual Machines.

When you install Integration Services, a set of drivers get installed in the Virtual Machines. For Network VSC, the driver which gets installed in Virtual Machine is netvsc60.sys or netvsc50.sys. These drivers have been programmed for Hyper-V Networking and talk to each other to improve the overall networking performance.

Figure 1.3 – VMBUS Communication Channel and VSP/VSC in Virtual Machine

As shown in figure 1.3 – The Synthetic Virtual Machine, once Integration Services Components have been installed, will have "Microsoft VMBUS Network Adaptor" added under the Network Adaptors category in the Device Manager. Emulated Virtual Machine will have the emulated device driver installed. Emulated Virtual Machines emulate a known hardware; Intel 440 BX Motherboard and an Intel 21140-based Network Adaptor.

You can install Integration Services components only if the Guest or Server Operating System is supported by the Hyper-V or Microsoft. For a list of supported Operating Systems, you can read the Part 1 of these articles of this series here.

Below is the comparison between Supported Operating System and Unsupported Operating System in Hyper-V environment and the Hyper-V component which is available.

Microsoft Hyper-V Networking and Configuration #2

The networking configuration or scenarios explained in this 2nd part can be used on Hyper-V running on Windows Server 2008, Windows Server 2008 R2 and Windows Server 2012. Even though there are new changes introduced in the Hyper-V networking on Windows Server 2012, but those changes do not provide significant improvements on "How to" methods when configuring Hyper-V networking configuration scenarios explained in this part of this series. The article focuses more on "how to" achieve a specific requirement/configuration that you have received from your customer, the best way to do it. We also learn why we should just not create Network Virtual Switch to achieve the simple configuration/requirement.

We will also learn networking tagged and untagged traffic, and best practices for Hyper-V Networking.

I recommend reading the first part of this series if you have not already. There are a few terms which I have explained in the first part of this series.

Some Terms:

VMMS.EXE

VMMS.EXE is the main process at the heart of Hyper-V Server. It controls all other aspects such as Virtual Machines (child partitions), Hyper-V Networking, the creation of Hyper-V Virtual Network types and communication between Virtual Machines via Virtual Network Switches.

VLAN Tagged

The VLAN Tagged is a method used by the protocols to tag a packet.

MAC Table

A Table on the Network Switches which has the addresses of all the devices connected to it.

VSP/VSC

VSP is called Virtual Service Provider and VSC is called Virtual Service Client. VSP/VSC design is implemented when Integration Services Component is installed in Virtual Machine.

Hyper-V Networking Best Practices

Avoid creating unnecessary virtual Network Switches on the Hyper-V Host

For VMMS.EXE, the process of ensuring proper communication between Virtual Machines via Virtual Network Switches is an extra overhead. The more switches you have, the worse it gets. Hyper-V allows you to create unlimited Virtual Network Switches but that does not mean that it is a good idea to create a virtual switch for each requirement, because VMMS.EXE must maintain the configuration and communication between Virtual Machines connected to them.

Assign the first two Physical Network Cards for Virtual Machine traffic.

You should separate Hyper-V management traffic from Virtual Machine traffic. A typical Hyper-V Host should have at least the following Physical Network Cards attached to it.

• NIC 1 - Assigned to parent partition for management to the Hyper-V Host.
• NIC 2 - Assigned to parent partition for Storage communication from Hyper-V or Virtual Machine.
• NIC 3 – Assigned to the Virtual Machines for communications with LAN, Virtual Machines on the same Hyper-V Server, or Virtual Machines on the Remote Hyper-V Server.
• NIC 4 onwards – Additional Network Adaptors based on your requirement.

Always select a configuration method for Hyper-V Networking in a particular order of preference.

When you come across any networking requirement that needs to be configured on Hyper-V Server, use the order of preference that I've listed below to achieve the configuration you need. The best way is to use the "Hyper-v Virtual Network Switch and VLAN Tagging" method. Other methods can also be used depending on your requirements, but consider them in this order.

• Hyper-V Virtual Switch and VLAN Tagging Method
• Hyper-V Virtual Switch Method
• Firewall Method
• Different subnet Method
• Another Physical NIC Method (applies when External networking is configured)

Always Team Hyper-V Host Physical NICs

Microsoft does not provide support for teaming Physical Network Adaptors on a Hyper-V Server running on earlier operating Systems except Windows Server 2012. Windows Server 2012 provides built-in NIC Teaming feature to provide load-balancing and fault-tolerance mechanisms for Hyper-V Server and Virtual Machines both.

Note: Virtual Machines must be running Windows Server 2012 Operating System before you can configure NIC Teaming.

Always install Integration Services on Virtual Machines

Microsoft provides an Integration Services Component for Hyper-V Virtual Machines which is equivalent to VMWare tools in VMWare, and VM Additions in Virtual Server. You should install Integration Services on supported Guest Operating Systems to achieve the high-speed communications between child and parent partitions. The Integration Services component implements the VMBus communication channel which has direct access to the Virtual Service Providers running on the Parent Partition.

Hyper-V Networking Configuration Scenarios

In referring to these scenarios, I'll assume that you've read Part 1 of this article series here, so please do so if you have not done so already.

Virtual Network Switch implementation in Hyper-V provides the following functionality:

• Virtual Network Switch operates at Layer 2.
• The Switch maintains a table called MAC Table. This MAC Table contains the MAC Addresses of Virtual Machines connected to it.
• Hyper-V Virtual Network Switch has a learning algorithm in which it learns the MAC address of a Virtual Machine connected to it. This MAC Address, once learned, is stored in the MAC Table of the Virtual Network Switch.
• VLAN IDs can be specified on each Virtual Network Switch except Private Virtual Network Switch.
• You can assign only "one" VLAN ID on property of Virtual Network Switch.
• One VLAN ID can be specified on NIC of Virtual Machine. You can have 12 Virtual NICs created for a Virtual Machine.
• Unlimited Virtual Machines can be connected to a Virtual Network Switch.
• A Hyper-V Virtual Network Switch can be configured in Access Mode and not in Trunk Mode. Please refer to Part 1 of this article series to understand the Access and Trunk Modes.
• There are a few requirements before you can use the VLAN ID or VLAN in Hyper-V:
  • A physical network adapter that supports VLAN configuration.
  • A physical network adapter that accepts packets with VLAN IDs Tagged.

System Administrators/consultants can get confused when it comes to configuring the Hyper-V Networking for any project or customer requirements. For most of the requirements, administrators either do not have idea as to how this is achieved in Hyper-V or end up configuring a complex networking configuration that hits problems which results in poor performance on the Hyper-V Server and in the communications between Virtual Machines.

This topic covers a few scenarios for Hyper-V Networking and explains how you can use them to accomplish your requirement without impacting performance and communications between Virtual Machines. We will explain a couple of scenarios and describe the configuration methods we use to achieve them.

Most of the project requirements end up either with "Allow" or "Do Not Allow" or both. We will learn how you use configuration methods mentioned below to meet "Allow" or "Do Not Allow" specifications.

Each scenario that I'll be describing here can be configured using one of the methods that I've already listed in the 'best practices' section.

Let me give you a simple example. As you know by reading Part 1 of this article series, a Private Virtual Switch in Hyper-V allows you to have communication between Virtual Machines connected to the switch and communication with same Hyper-V Server, but it does not allow communication between Virtual Machines on the Remote Hyper-V Server. The overall objective of the Private Virtual Switch is to block communications for other Virtual Machines or Servers on the LAN.

If this is what you need to accomplish as part of your requirement then you can create the switch. However, is it necessary to create a Private Virtual Switch or could you accomplish the configuration with other configuration methods?

You will have noticed in the 'Hyper-V Networking Best Practices' section that you should not create a Virtual Network Switch for the sake of it, because it increases the overhead for the VMMS.EXE process. This is where I hope that these scenarios come handy because you can adapt the other methods explained in this topic to achieve the results to need.

We will start by looking at a simple scenario first, and then finish the topic with a rather more complex one. Before we start working on the configuration part to accomplish the Hyper-V Networking requirement, here is a checklist:

1. Is connectivity to External networking required?
2. Is it really necessary to create a Virtual Network Switch or can I use existing one?
   1. If yes which one I should use? External, Private, or Internal?
3. Can the requirement be achieved using the VLAN Tagging system?
4. Can I just use a firewall in Virtual Machine or Hyper-V Host to accomplish it?
5. Can I configure different subnets if it is only to meet "Allow" or "Do Not Allow" specs of the requirement?

Scenario 1:

You have two departments in your organization; Finance and HR. You have created two Virtual Machines for each department. These Virtual Machines are hosted on the same Hyper-V Server. You need to make sure HR Virtual Machines talk to each other or have communication between them but no other Virtual Machines, whether they are running on the same Hyper-V server (basically Finance Virtual Machines), Virtual Machines running on remote Hyper-V server or servers located on the Physical LAN.

This is very simple scenario. The requirement clearly indicates that the connectivity to the External Network or Physical LAN is not required for both types of Virtual Machines. That means we should avoid creating an unnecessary External Virtual Network Switch

Let's apply one of the methods that we discussed earlier in order to get the results we want.

Using a Hyper-V Virtual Switch Method

Once configured using a Hyper-V Virtual Network Switch, the solution looks like as shown in Figure 1.1.

In Figure 1.1 you can see that HR Virtual Machines (VM1and VM2) are connected to HR Virtual Network Switch and Finance Virtual Machines (VM3 and VM4) are connected to Finance Virtual Switch.

The switch "HR Virtual Switch" in Figure 1.1 is a "Private Network Switch" type. This is to ensure that the communication is only allowed between HR virtual machines. Please note there is no VLAN ID configured on the Virtual Network Switch at this point of time.

Figure 1.1 - Scenario 1 Configuration: Using a Hyper-V Virtual Switch

So, to achieve the first scenario using a "Hyper-v Virtual Switch" method, we have created two private Network Virtual Switches. Many administrators or consultants end up implementing this configuration into production, which results in extra overhead for Hyper-V VMMS.exe process.

What if you need to reduce the communication overhead by avoiding creating unnecessary Virtual Network Switches? Can we achieve the requirement by just creating one Virtual Network Switch and using VLAN Tag method? Yes, we can.

Using Hyper-V Virtual Switch and VLAN Tagging Method

Figure 1.2 shows the configuration of the same requirement using a VLAN Tagging system. A common Virtual Network Switch has been created. Since the Private Virtual Network Switch does not support VLAN Tagging, we have created an Internal Network Virtual Switch named "Common Virtual Switch".

Figure 1.2 - Scenario 1 Configuration: Using a Hyper-V Virtual Switch and VLAN Tagging Method

The "Common Virtual Switch" is not configured with the VLAN Tag ID. The VLAN ID is left blank on the Virtual Network Switch but is configured on the respective Virtual Machines.

As you can see, both VM1 and VM2, which belong to HR department, have been configured with VLAN ID 2. VM3 and VM4, which belong to Finance department, have been configured with VLAN ID 4.

When configuring VLAN Tag ID, you need to ensure that you configure the VLAN Tag ID on all the connected devices (VM1, VM2, VM3, VM4 and Common Virtual Switch in this example).

The requirements have been achieved both by using a Hyper-V Virtual Network Switch and Hyper-V Virtual Network Switch with VLAN Tagging. Both these methods achieve the same results in that they do not allow HR's Virtual Machines to talk to any other Virtual Machines and Servers connected to the LAN. The latter method avoids the creation of unnecessary Virtual Network Switches.

Since the problem is all about blocking the communication between a set of Virtual Machines, you can always achieve the same results by using a Firewall or different subnets for HR Virtual Machines.

Any network packet sent from any Virtual Machine (VM1 through VM4) will be tagged with its VLAN ID and then forwarded to the Common Virtual Network Switch. The Common Virtual Network Switch follows an algorithm to see if the packet needs to be discarded or forwarded. We will explain this in more detail in the later part of this article series.

Scenario 2:

There are three departments; Accounting, Sales and Finance. You have created three Virtual Machines; VM1 for Accounting, VM2 for Sales and VM3 for Finance. There are three Physical Servers; Server1, Server2 and Server3 located on the LAN. These are running with SQL Server. Accounting Virtual Machine (VM1) needs to access Server1 to store its data, Sales Virtual Machines (VM2) needs to access Server2 to store its sales data, and Finance Virtual Machine (VM3) requires access to Server3 to store its Finance-related data. Management has decided that the Virtual Machines should not be able to talk to each other. They should be able to communicate with the Physical Servers as mentioned below:  

• VM1 Access to Server1 only.
• VM2 Access to Server2 only.
• VM3 Access to Server3 only.

The big difference that we see between Scenario 1 and Scenario 2 is the communication to the External LAN (e.g. VM1 through VM3 talking to Server1 through Server3 on LAN). The moment you see the requirement for External communication you'll think of using an External Virtual Switch.

To achieve the requirements of this second scenario, you can use any of the configuration methods as discussed earlier but the most suitable methods to use are:

• Using another Physical NIC Method (applies when External networking is configured).
• Using Hyper-V Virtual Switch and VLAN Tagging Method.

Using another Physical NIC Method (applies when External networking is configured)

This method is common and most administrators who are not familiar with Hyper-V Networking end up using it. In this configuration method, we need to have:

• Three Physical NICs for each Virtual Machine (VM1, VM2 and VM3).
• Three External Virtual Network Switches.

The following disadvantages are associated with this method:

• Traffic is segregated for each Virtual Machine to its own Physical NIC only.
• Virtual Machines do not use the complete speed/GB of a Physical Network.
• No other Virtual Machine is allowed to use the Physical Network of other Virtual Machines.
• More External Virtual Network Switches need to be created.
• Configuration and communication overhead for VMMS.exe process.
• Cost associated with the physical devices (Network Adaptors).

Let's take a look at the other method available.

Using Hyper-V Virtual Switch and VLAN Tagging Method

This is a better method for such a configuration. Only one External Virtual Network Switch is created and mapped to NIC1 of the Hyper-V Host. Once configured using Hyper-V Virtual Network Manager, the layout looks like Figure 1.3 below:

Figure 1.3 - Scenario 2 Configuration: Using a Hyper-V Virtual Switch and VLAN Tagging Method

As you see in Figure 1.3, the following configuration has been applied to each device/Virtual Machine:

• Each Virtual Machine (VM) is configured with a unique VLAN ID.
• The Servers on the LAN are configured with the matching VLAN ID.
• The Physical Switch (green) is configured in Trunk Mode to allow traffic for VLAN ID 2, 3 and 4.
• VM-Servers Virtual Switch, which is a External Virtual Network Switch is configured with "no" VLAN IDs!

The most interesting part of this configuration is the External Virtual Switch. This Hyper-V Virtual Network Switch is not configured with any VLAN IDs. If you assign any VLAN ID on the Virtual Switch, the traffic will be tagged with that VLAN ID and the communication will be allowed only for that VLAN ID Tagged packet. The VM-Servers Virtual Switch in Figure 1.3 is authoritative for all the traffic from Virtual Machines connected to it (i.e. it is able to receive all traffic and forward them without modifying the VLAN ID in the packet it receives). This process is explained in the next topic.

Hyper-V Networking Tagged and Untagged Traffic

When a network packet is sent from a Virtual Machine to another Virtual Machine on the same Hyper-V Server, a Virtual Machine on Remote Hyper-V Servers, or Servers connected to LAN, then the packet is first received by the Virtual Network Switch with the following Information:

• Source Address
• Destination Address
• VLAN Tag ID

We'll explain the logic behind the Tagged and Untagged VLAN traffic for two virtual machines communication (VM1 and VM2)

Figure 1.4 – VLAN and Virtual Switch Not Assigned any VLAN Tag ID

The Figure 1.4 shows a typical configuration of a Virtual Network Switch created on the Hyper-V Server with five Virtual Machines connected to it. The Virtual Network Switch is either an Internal Type or External Type. It is important to understand the communication between Virtual Machines, Virtual Network Switch and Physical NIC.

As you can see, Virtual Network Switch has not been assigned with any VLAN ID. It is left blank. This is what happens when VM1 sends a packet to the network of Virtual Switch:

1. VM1 sends out a packet with VLAN ID Tagged 2.
2. The packet is received or discarded by the Virtual Network Switch based on the following logic:
   1. Is Virtual Network Switch configured in Access Mode? E.g. Is VLAN ID assigned to the Virtual Network Switch?
      1. If yes, does it match with the one it has received from VM1?
         1. If yes receive the packet and forward it based on the Virtual Switch Type configured.
            1. To all the ports (all Virtual Machines basically) of switch.
            2. To P-NIC1 if it is an external Virtual Switch.
         2. If no, discard the packet as Virtual Network Switch is not configured to accept the packets with VLAN ID other than what has been assigned to it.
3. Once the packet is forwarded by the Virtual Network Switch, it is the destination Virtual Machine which must decide whether it needs to retain the packet or discard it based on the logic mentioned below:
   1. Does VLAN ID tagged in packet match with the one configured on the Virtual Machine?
      1. If yes, receive the packet.
      2. If no, discard the packet.

In short, it depends on the destination device whether to receive the packet or discard it based on the configuration.

The Hyper-V Virtual Network Switch does not, as one might assume, work the same way as a Physical Switch. A Physical Switch can be configured in both modes (Access and Trunk) but a Hyper-V Virtual Network Switch can be configured only in "Access Mode" as of today.

Microsoft Hyper-V Networking and Configuration #1

Most of the article talks about Hyper-V Networking without elaborating on the basics of Networking. Instead, the article focuses more on the Hyper-V Networking, Networking Virtual Switch Types and Guest Operating Systems supported by Hyper-V running on Windows Server 2008/R2 and Windows Server 2012.

This articale will discuss:

• Virtual Networking Overview
• Hyper-V Virtual Network Switch Overview
• Microsoft Hyper-V Virtual Network Switch Types
• Microsoft Hyper-V Virtual Network Maximum configuration
• Supported Guest Operating Systems
• What happens when you create a Virtual Network Switch?

Terms Used Throughout This Article:

Before tackling Hyper-V Networking, there are a few basic terms that I ought to define in case you aren't familiar with them.

---

Parent Partition

A Windows Server 2008 running Hyper-V Role is called the Parent Partition or Root Partition. The Operating System (Windows Server 2008) running on the Root is the "Management Operating System". Parent Partition is responsible to create Child Partition and also controls the communications between all the Virtual Machines.

Child Partition

A Virtual Machine running on Hyper-V Server is called the Child Partition. The Parent Partition creates the Child Partition.

Virtual Switch or
Virtual Network
Switch

A Virtual Switch is a software component of Virtualization Software. Virtual Machines are connected to Virtual Switch in order to allow communications between Virtual Machines. A Virtual Switch, just like Physical Switch, does more than communications.

VLAN

A VLAN is a Virtual LAN. A VLAN is a method of creating independent logical networks. VLAN is a broadcast domain created by the physical or virtual switches.

VLAN ID

A unique number called the VLAN ID identifies the each VLAN. Each VLAN is separated by assigning unique VLAN ID.

VLAN Trunk
and
Access Modes

There are two modes a particular port on a Virtual or Physical Switch can operate in; Access Mode and Trunk Mode. Access Mode is used for end devices that will not require access to multiple VLANs. Trunk Mode is used for passing multiple VLANs to other network devices that need to have communication to multiple VLANs on one occasion.

Integration
Services
Component

A Hyper-V component used to enhance the performance of Virtual Machines running on Hyper-V. The Integration Services component is similar to the VM Additions of Virtual PC but it's more than that in the functionality.

VMBUS

VMBUS is a logical inter-partition communication channel. VMBUS allows Virtual Machines to access hardware resources faster. VMBUS is available only when you install the Integration Service Components on the Virtual Machines running on Hyper-V

---

Virtual Networking Overview

Virtual Networking is designed to meet the requirement to move from a physical to virtual environment which reduces the overall costs of hosting the system.

Both Physical and Virtual Network Switches perform routing. There are two types of routing performed by the switches; IP and MAC Routing. IP Routing is performed by the Layer 3 Switches and MAC Routing at Layer 2 Switches. Microsoft Hyper-V and VMWare both implement Virtual Network Switches which operate at Layer 2.

Microsoft Hyper-V Virtual Networking has been designed as part of its Virtualization Software; Hyper-V. The way that the underlying components of Microsoft Hyper-V Networking behave is completely different from those of VMWare. This series of the article does not compare Virtual Networking in Hyper-V and VMWare. Instead it focuses only on Microsoft Hyper-V Virtual Networking technology.

In the Virtual World, we rely on the vendor of the virtualization software to maintain the quality and performance of Virtual Networking code since it is crucial for improving the overall algorithms of a Virtual component. Microsoft Hyper-V has been designed to improve Virtual Networking by introducing new Networking Technologies such as VMBUS and VSP/VSC design. This is explained in more detail later in this series of articles.

The Hyper-V Virtual Network Switch

The implementation of the Virtual Network Switch in Hyper-V operates at Layer 2. The switch maintains a table called the MAC Table. This MAC Table contains entries consisting of the MAC Address and the name of the Virtual Machine connected. The Hyper-V Virtual Network Switch has a learning algorithm in which it learns the MAC address of a Virtual Machine. This MAC Address, once learned, is stored in the MAC Table of the switch. An unlimited number of Virtual Machines can be connected to a Virtual Network Switch.

In previous versions of Hyper-V, only one parent virtual NIC was supported, however in Windows Server 2012 Hyper-V, multiple NICs are supported. In addition, you can share the physical NIC that is bound to the Hyper-V Switch with the management operating system. The Virtual Networking switch running on Windows Server 2012 can be managed via Windows PowerShell commands.

Microsoft Hyper-V Virtual Network Switch Types

Microsoft Hyper-V implements three types of Virtual Switches or Networking Types as shown in figure 1.1.

There are no changes in Hyper-V Virtual Networking Switch Types in Windows Server 2012. There are a few enhancements done for the Hyper-V Virtual Network Switches but these are beyond the scope of this article.

FIGURE 1.1 – Hyper-V Virtual Network Types

As you can see in Figure 1.1, there are four types of Virtual Switches in Hyper-V based on their network function. You can see that there is one more type called Dedicated. This is neither visible nor available in Hyper-V Virtual Network Manager. You see only three types. We will discuss the Dedicated type later in this article series.

Before I get into more details, I ought to explain that, in a default Hyper-V implementation:

• There are no virtual Network Switches created.
• Virtual Machines created on Hyper-V Networking are not associated with any of the Virtual Network Switch types shown in Figure 1.1.
• There are no Network Adaptors configured in Virtual Machines (depending on the guest Operating Systems).

The default Hyper-V Implementation looks like as shown below in Figure 1.2:

FIGURE 1.2 – Hyper-V Default Implementation and Network Configuration

As you can see in Figure 1.2, there are three VMs created on the Hyper-V Server; VM1, VM2 and VM3. By default, these VMs are not associated with the Virtual Network Switch and cannot have any communication with each other. If any of the VMs running on Hyper-V (VM1, VM2 and VM3) need communicate with Server1 on the physical LAN then they can't do so until Virtual Network Switch is created. It is not created by default.

You create Virtual Switches using the Virtual Network Manager found in the Action Pane on the right-hand side of the Hyper-V Manager.

As shown in figure 1.1, the "External" Virtual Network Switch allows you to communicate with Parent Partition of Hyper-V, Virtual Machines running on same Hyper-V Server, Virtual Machines running on Remote Hyper-V Server, and physical servers on the LAN. The External Network Switch requires that you have at least one Physical NIC (e.g. not associated with any other Virtual Network Switch). You can have one External Virtual Network Switch per Physical NIC.

One thing you'll notice is the remark column for "External" Virtual Network Switch. It says "Conn. Lost Temporarily", which means that the connection is lost temporarily if you create an External Virtual Network Switch. Why so? It is because the External Virtual Network Switch is mapped to a physical NIC on the Hyper-V Server. This is basically a binding of Virtual Network Services to a Physical NIC.

The "Internal" Virtual Network Switch allows you to communicate between the Parent Partition of Hyper-V and the Virtual Machines running on the same Hyper-V Server. You cannot communicate with any other VMs which are associated with a different Virtual Network Switch or physical servers. You can create or use an Internal Virtual Network Switch even if the Physical NIC is not available, because communication happens internally or on the same Hyper-V Server.

The "Private" Virtual Network Switch allows you to have communication only between the Virtual Machines running on the same Hyper-V Server. Communications are only allowed only between the Virtual Machines which are connected to that Internal Virtual Network Switch.

Hyper-V Virtual Networking Maximum Configuration

Support For	MAXIMUM	Remark
Virtual NICs Per Virtual Machine	12 NICs	4 Legacy and 8 VMBus NICs
VLAN	Unlimited
Virtual Machines Per VLAN	Unlimited
External Network Virtual Switch Per Hyper-V Server	1 Per Physical NIC
Internal Network Virtual Switch Per Hyper-V Server	Unlimited
Private Network Virtual Switch Per Hyper-V Server	Unlimited
Virtual Machines Per Virtual Network Switch	Unlimited
Wireless		No support for wireless
VLAN ID Tagging	External, Internal
VLAN ID Tagging On Virtual Machines	One per Virtual MAchine

FIGURE 1.3 – Virtual Network Types and Maximum Configuration

As you can see in figure 1.3, the Hyper-V Virtual Machine can support two types of Networking Cards; Legacy and VMBus NICs. The support for Legacy Network Card is included for Guest Operating Systems which are not supported by Hyper-V. There can be up to four Legacy Network Adaptors. You install a Legacy Network Adapter from the property of Virtual Machine and then selecting "Add New Hardware". Legacy Network Adapters use Device Emulation architecture to communicate with the Parent Partition and to access Network resources. The article linked to in the URL lists all the Guest Operating Systems which are supported on Hyper-V:

List of Guest operating systems that are supported on a Hyper-V virtual machine running on Windows Server 2008 and R2.

Guest Operating Systems supported by Hyper-V running on Windows Server 2012:

Supported Server Operating Systems:

Windows Server 2012	Integration Services included.
Windows Server 2008 R2 with Service Pack 1 (SP 1)	Integration Services installation is required.
Windows Server 2008 R2	Integration Services installation is required.
Windows Server 2008 with Service Pack 2 (SP 2)	Integration Services installation is required.
Windows Server 2008	Integration Services installation is required.
Windows Server 2003 SP2 and R2	Integration Services installation is required.
CentOS 6.0 – 6.2	Linux Integration Services installation is required.
Red Hat Enterprise Linux 6.0 –6.2	Linux Integration Services installation is required.
SUSE Linux Enterprise Server 11 SP2	Integration Services included.

Supported Guest Operating Systems:

Windows 8	Integration Services included.
Windows 7 with Service Pack 1 (SP 1)	Integration Services installation is required.
Windows 7	Integration Services installation is required.
Windows Vista with Service Pack 2 (SP2)	Integration Services installation is required.
Windows XP SP3 and SP2	Integration Services installation is required.

VMBus Network Card Adapters are available only when you install the Integration Services Component. The Integration Services component of Hyper-V leverages the VMBus architecture for the best networking performance. There can be a maximum of 8 VMBus Network Cards.

A Virtual Machine running on Hyper-V can support a maximum of 12 Network Cards (4 Legacy and 8 VMBUS NICs).

VLAN Support is also included in Virtual Machines. A Virtual Machine running on Hyper-V can be configured with a VLAN ID. You can create an unlimited number of VLANs in Hyper-V, and there is no limit either to the number of Virtual Machines per VLAN.

As shown in Figure 1.3, you can have one External Virtual Network Switch per Physical NIC on Hyper-V Server. This type of Network Virtual Network Switch allows Virtual Machines communicate with LAN Servers also. The External Virtual Network Switch is mapped to the Physical NIC in order to allow communication with Physical Devices.

There is no limitation for the Internal or Private Network Virtual Switch. The reason is that Internal and Private operate internally and the communication is restricted to the Virtual Machines running on the Hyper-V. So you can create unlimited number of Private and Internal Virtual Network Switches.

You can have any number of Virtual Machines connected to a Virtual Network Switch. This can be an External, Private or Internal Network Virtual Switch.

In figure 1.3, you also notice the support for VLAN IDs on Virtual Switches. VLAN IDs can be specified on each Virtual Network Virtual Switch except for the Private Network Virtual Switch. These VLAN IDs can be used to create VLANs.

Similarly, VLAN ID support is also available for Virtual Machines. You can have one VLAN ID per Virtual Machine.

Note: There is no support for Direct Wireless for Virtual Machines running on Hyper-V. Instead you need to create a bridge between Wireless NIC and a Virtual Machine NIC.

What happens when you create a Virtual Network Switch?

You can create a Virtual Network Switch by selecting "Virtual Network Manager" that is located on the right pane of the Hyper-V Manager and then select the Network Virtual Switch Type you want to create. You need to select "Virtual Network Manager" to create any Virtual Network Switch Type. However, the creation of an External Virtual Network Switch is different from either Private or Internal Network Switches.

When you create an External Virtual Network Switch, you need to select a Physical NIC to which the Virtual Switch will be mapped. This process requires you to modify the Physical NIC components.

Before creating an External Network Virtual Switch, the network connection folder has only one network connection. The property of the Physical Network Connection looks like as shown below: (I assume you have only one Physical NIC attached to the Hyper-V Server).

FIGURE 1.4 – Property of Physical NIC

When you create the External Network Virtual Switch using Virtual Network Manager, Hyper-V Components or VMMS.EXE, the process makes the following changes:

1. It unbinds the following services, protocols, clients from the Physical NIC:
   1. Client for Microsoft Networks
   2. File and Print Sharing for Microsoft Networks
   3. TCP/IP Protocol IPv4
   4. TCP/IP Protocol IPv6
   5. Any other Service, client or protocol
2. It binds the "Microsoft Virtual Network Switch Protocol"
3. It creates a new network connection in the Network Connections folder with the name you had specified when creating the External Virtual Network Switch. Let's say the name while creating the Virtual Switch you gave is "EXT NET Switch".
4. It binds the following Services, protocols, clients to the External Virtual Network Switch (EXT NET Switch):
   1. Client for Microsoft Networks
   2. File and Print Sharing for Microsoft Networks
   3. TCP/IP Protocol IPv4
   4. TCP/IP Protocol IPv6
5. It unbinds the following protocol from the External Virtual Network Switch; EXT NET Switch:
   1. "Microsoft Virtual Network Switch Protocol"

When you open the Network Connections folder you will see two Network Connections created; one Local Area Connection for physical NIC and other one is "EXT NET Switch" for External Virtual Network Switch as shown in figure 1.5:

FIGURE 1.5 – Network Connections with External Virtual Network Switch

The bindings will also be changed. When you look at the property of the Physical NIC and the virtual Network Switch it will look like Figure 1.6

Property of EXT NET Virtual Switch

Property of Local Area Connection

FIGURE 1.6 – Property of Virtual Network Switch and Physical Connection

In step 3, the Virtual Network Manager unloads and loads the Network Driver for the Physical NIC from the memory. That's the reason that the network connection is lost temporarily when you create an External Virtual Network Switch. Any device that is connected to Hyper-V Server has to retry to reconnect. As an example; if you had connected to a Virtual Machine from a remote computer using VMConnect.exe, the connection is lost and you need to reconnect using VMConnect.exe.

A warning is shown to the user about a temporary loss of network connection when you create the External Virtual Network Switch.

The creation of Private and Internal Network Virtual Switches is same as is shown above. However, you don't have to have the physical NIC to create these switches.

Microsoft Hyper-V 2012 Live Migration and Constrained Delegation

One feature with any good virtualization solution should have the ability to make your VMs mobile. With VMware the feature is called vMotion and with Hyper-V it's Live Migration. When your just using the Hyper-V manager and you need to do a live migration from one system to the next you would have to log into the actual host (hyper-v server) that's running the VM that you wanted to move. This is unless you configured constrained delegation in Active Directory on the hyper-v host objects and configured hyper-v to use the kerberos authentication protocol with live migration. This is somewhat of a pain but it's not necessary when using System Center Virtual Machine Manager which is Microsofts somewhat equivalent to VMware's vCenter. But that's another topic. Here is how you would configure the hyper-v systems so you can do a live migration when using the Hyper-V manager without having to do it from the source host of the VM that needs to be moved.

Configure Hyper-V Live Migration:

1. From Server Manager, click Tools and then click Hyper-V Manager.
2. In the navigation pane, select one of the servers that you want to configure for live migrations.
3. In the Action pane, click Hyper-V Settings.
4. In Hyper-V Settings dialog box, click Live Migrations.
5. In the Live Migrations pane, check Enable incoming and outgoing live migrations.
6. Under Authentication protocol, select Kerberos if you have configured constrained delegation.

microsoft hyper-v 2012 with constrained delegations for live migration

Setting up Constrained Delegation:

1. From Server Manager, select the server if it not already selected. After the server is selected, click Tools, and then click Active Directory Users and Computers. Note: If the AD management tools are not installed you will either have to install them or log into a domain controller.
2. From the navigation pane, select the domain and double-click the Computers folder.

microsoft hyper-v 2012 with constrained delegations for live migration

3. From the Computers folder, right-click the computer account of the source server and then click Properties.

microsoft hyper-v 2012 with constrained delegations for live migration

4. In the Properties dialog box, click the Delegation tab.
5. On the delegation tab, select Trust this computer for delegation to the specified services only. Then select Use Kerberos only.
6. Click Add.

microsoft hyper-v 2012 with constrained delegations for live migration

7. In the Add Services dialog box, click Users or Computers.

microsoft hyper-v 2012 with constrained delegations for live migration

8. In the Select Users or Computers dialog box, type the name of the destination server. Click Check Names to verify that you typed the name correctly, and then click OK.

microsoft hyper-v 2012 with constrained delegations for live migration

microsoft hyper-v 2012 with constrained delegations for live migration

9. To move virtual machine storage, select cifs. This is required if you want to move the storage along with the virtual machine, as well as if you want to move only a virtual machine's storage. If the server is configured to use SMB storage for Hyper-V, this should already be selected.

microsoft hyper-v 2012 with constrained delegations for live migration

10. To move virtual machines, select Microsoft Virtual System Migration Service. 

microsoft hyper-v 2012 with constrained delegations for live migration

11. On the Delegation tab of the Properties dialog box, verify that the services you selected in the previous step are listed as the services to which the destination computer can present delegated credentials. Click OK.
12. From the Computers folder, select the computer account of the destination server and repeat the process. In the Select Users or Computers dialog box, be sure to specify the name of the source server.

Configure SSL on Your Website with IIS

By default, web browsing is being performed by use of the HTTP protocol, i.e. a connection between the client computer (using a web browser) to the web server (using IIS, Apache or any other sort of web server program). HTTP relies on TCP (Transmition Control Protocol) and uses port 80 on the listening server.

The main security issue with HTTP is the fact that all the traffic between the client and the server is done as clear text, meaning that anyone could potentially "listen" to your talk and grab frames and valuable information from the net.

To secure the transmission of information between your web server running IIS 6.0 on Windows Server 2003 and your browser clients, you can encrypt the information being transmitted by using SSL (Secure Sockets Layer).

Note: The procedure for applying SSL on IIS 5.0 (on Windows 2000) and IIS 5.1 (on Windows XP) is quite the same.

In order to successfully use SSL you need to obtain a Server Certificate. In this article I will only focus on obtaining a certificate from a local CA or importing an already existing certificate. However, it is possible (and in many cases preferred) that you obtain the Server Certificate from a trusted 3rd party CA such as Verisign or Thawte.

Configure SSL

To configure SSL for your website on IIS 6.0 (running on Windows Server 2003) complete the following steps:

Note: Although the screenshots are made with IIS 6.0 on Windows Server 2003, the same procedure applies for IIS 5.0 and IIS 5.1.

1. Click Start, point to All Programs, point to Administrative Tools, and then click Internet Information Services (IIS) Manager.
2. In Internet Services Manager, in the console tree, expand SERVERNAME (your local computer), and then expand Web Sites.
3. In the console tree, right-click Default Web Site, and then click Properties.

Note: It's possible that the site you've created was stored under a different virtual server. If your website is not stored within the Default Web Site, right-click your own web site and click Properties.

4. In the Default Web Site Properties dialog box, click Directory Security.

5. On the Directory Security tab, click Server Certificate.
6. In the Welcome to the Web Server Certificate Wizard, on the Welcome page, click Next.
7. On the Server Certificate page, verify that Create a new certificate is selected, and then click Next.

Note: You can also import an already existing certificate. Do do so follow these steps:

1. Click Import a certificate from a .pfx file. Click Next.

2. In the Import Certificate path enter the path to where you've stored your existing certificate. Click Next.

3. Enter the password configured for the .pfx file. Click Next.

4. Go to step #13.

8. On the Delayed or Immediate Request page, click Send the request immediately to an online certification authority, and then click Next.

Note: If you don't have a Certificate Authority (CA) installed on your server or on a different server on the network you can prepare the request but you'll need to manually send it to the CA.

9. On the Name and Security Settings page, in the Name box, type yourservername.domainname.com (or .net, .org, .mil etc. Use your own registered domain name, the one you want people to use when browsing to your site) and then click Next.

Note: You will need a different certificate for each website you'll run on this server, so make sure you provide the exact server URL.

Important note - Internet use: You must make sure that either the Name or the Common Name fields (one of them or both of them) exactly match the external FQDN of the website. For example, if your server's NetBIOS name is SERVER1, and it is located in the MYINTERNALDOM.LOCAL domain, but it will host a website that will require users to enter WWW.KUKU.CO.IL to reach it, you must then use WWW.KUKU.CO.IL as the Name or Common Name in the certificate request wizard, and DO NOT use SERVER1.MYINTERNALDOM.LOCAL.

Important note - Intranet use: For Intranet-only purposes you CAN use the internal FQDN of the server, or even just it's NetBIOS name. For example, if your server's NetBIOS name is SERVER1, and it is located in the MYINTERNALDOM.LOCAL domain, you can use SERVER1.MYINTERNALDOM.LOCAL or just SERVER1 for the Name or the Common Name fields.

You can also change the Bit Length for the encryption key if you want.

10. On the Organization Information page, in the Organization box, type your own company name. In the Organizational Unit box, type a descriptive name and then click Next.

11. On the Your Sites Common Name page, in the Common name box, type yourservername.domainname.com (see important note in step #9) and then click Next.

12. On the Geographical Information page, in the State/province box, type the required info and then click Next.

13. On the SSL Port page, in the SSL port this web site should use box, verify that 443 is specified, and then click Next.

Note: SSL can only listen once on port 443, requiring you to either select a different SSL port for each SSL protected website you're about to host on the server, or, even better, use a different static IP for each site, and share port 443 amongst them.

14. On the Choose a Certification Authority page, in the Certification Authorities box, verify that your online CA is selected, and then click Next.

15. On the Certificate Request Submission page, click Next to submit the request, and then click Finish to complete the wizard.

To use the certificate to secure the web site that is using SSL

1. In the Default Web Site Properties dialog box, on the Directory Security tab, in the Secure communications area, click Edit.

Note: It's possible that the site you've created was stored under a different virtual server. If your website is not stored within the Default Web Site, right-click your own web site and click Properties.

Note: It's also possible that you might not wish to protect the entire website, but merely one or two pages within the large website. In fact, this scenario is highly probable for most site operators that would only like to protect a couple or important pages, such as an online store or registration form. In that case you do NOT need to SSL-protect the entire site, so do NOT right-click the entire site. Right-click only the directory or pages within the site.

2. In the Secure Communications dialog box, click the Require secure channel (SSL) check box, click the Require 128-bit encryption check box, and then click OK.

Note: Using a requirement of 128-bit encryption should pose no problem to current operation systems and web browsers, but keep in mind that older OSs might not be able to connect to your site.

3. On the Directory Security tab, in the Authentication and access control area, click Edit.
4. In the Authentication Methods dialog box, click Basic authentication (password is sent in clear text), and then click Yes to acknowledge the warning.
5. Clear the Integrated Windows Authentication and Enable Anonymous Access check boxes, and then click OK.

Note: You are NOT required to disable anonymous access, this is just a security measure. It might be likely that your site is supposed to allow anonymous access, while still using SSL as the encryption method. This is true for websites that offer online shopping carts where surfers are supposed to enter their credit card numbers. You might not want to restrict these online shops only for people that hold a username and password. In that case keep the Enable Anonymous Access check boxes selected.

6. In the Default Web site Properties dialog box, click OK.
7. In all Inheritance Overrides dialog boxes, click OK.

8. Close Internet Information Services (IIS) Manager.

Verify that SSL is working

To test your new settings connect your open a browser and type your server's FQDN (or NetBIOS name, if on the LAN) in the address bar (for example: http://server200 for your Intranet, or http://www.kuku.co.il for the Internet).

Note: Make sure you've followed the important note in step #9 above.

Since you still used HTTP (plain text http, using TCP port 80) you'll get the following error message:

Now re-type the URL by using HTTPS instead of HTTP. You should be able to view the OWA website.

You'll receive a Security Alert window. Click Ok.

If configured correctly, you should be able to connect to your now SSL-protected website.

To verify that you're using SSL try to find a small yellow lock icon on the browser lower right corner . Double click the lock icon.

A Certificate window will open. Review the information that is entered into the certificate and click Ok.

Note: Make sure you renew your certificate a few weeks before it expires in order to prevent mishaps like this one: Expired SSL Website Certificate.

Hyper-V Benefits

The Hyper-V is software with hypervisor technology on which several virtual machines can run. The hardware of these machines is controlled by the hypervisor and it also allocates resources on every VM operating system. The Hyper-V technology lets the user operate multiple operating systems from one single machine.

Server virtualization is gaining a lot of importance—especially with the launch of Windows Server 2012 and Hyper-V as the virtual platform—as businesses understand that it offers a better security, increased efficiency, and cost-saving solutions. Using Hyper-V, users can get a hands-on experience on the new hardware technology and at the same time use the servers they already have. And, as Hyper-V continues to gain all the importance in the technology world, it has become important for the IT professionals to understand how exactly this technology works and what features and benefits it offers.

Features

Dynamic Memory

This feature helps the users to understand the memory resources of the virtual machine effectively, and at the same time, it also increases the consolidation ratios of the virtual machines. The Hyper-V will use techniques such as Internal Guest Paging and Ballooning, and it offers new functionality for assisting in the startup of virtual machine and setting up minimum RAM requirements with the use of Hyper-V smart paging. A new feature in Windows Server 2012 helps the users to increase the memory configurations with Dynamic Memory when the virtual machine is running.

Live Migration

Sharing becomes simpler in the presence of Hyper-V. In Hyper-V the feature 'shared nothing' lets the users migrate a virtual machine from a server that is running on Hyper-V to a different server without having both the machines in the same storage space or cluster. This ability of the feature means that you can live migrate any virtual machine from different clusters without using complex storage mappings.

Hyper-V Replica

To have interrupted business service and a quick disaster recovery, Windows Server 2012 has introduced Hyper-V Replica that provides replication for the virtual machines. In events such as fire, natural disasters, or power failure, you can lose important data. The virtual machines running on Hyper-V will bring back the machines to a consistent point, and the network can access your machine within no time causing minimum or no damage.

Extensible Switch

This Hyper-V extensible switch is a virtual network switch that helps form a connection between the virtual machines and physical networks. This extensible switch is an open platform and multiple vendors can give extensions, which are written for the standard Windows API framework. The reliability of this framework is strengthened by Windows standard framework.

Benefits

1. Business flexibility: The virtual world is becoming more prevalent, you need to learn how to manage your workload, and you should know quick ways to migrate between your workloads. The Hyper-V allows the users to live migrate from one virtual machine to another, or to migrate from an external clustered environment.
2. Multitenant environments: As businesses have started adopting the virtual datacenters, many service providers have started offering Infrastructure-as-a-service (IaaS). This model provides the users with virtual flexible environments, but they lack security. The Hyper-V offers better security and capabilities for multitenant isolation, which helps keep all the virtual machines isolated, even if they are stored in the same server or network.
3. Larger workloads: To help the users in the virtual environment with larger workloads, Hyper-V provides support of 1 terabyte of memory and 64 virtual processors for the Hyper-V guests. Also, it provides 4,000 virtual machines on a cluster of 64-node.
4. Availability: It is important to have connectivity to your machine for seven days a week and throughout the year. For this, Hyper-V provides the users with excellent back-up support, inbox NIC teaming, and enhanced clustered environments for supporting the virtual fiber channel adapters.

Whether it's about increasing the private IP addresses, hosting multiple websites, custom database applications, VM availability, VM mobility, gaining more flexibility, handling environments with multi-tenants, or gaining bigger scale, Hyper-V provides the users with tools and platforms for increasing your business flexibility. The new Hyper-V gives extended management support, where you can control the overhead administrative costs of your environment and automate different management tasks. And you also get the portability that you require for extending your datacenter or virtualizing on premises to a host provider, it helps you change environment from a simple data center to cloud computing.