My good friend Mark Morowczynski, Microsoft PFE for Active Directory, wrote a three-part series on the Ask Premier Field Engineering (PFE) Platforms
blog about IPv6 that is well worth reading.
You can follow Mark on Twitter @markmorow
Hyper-V 3.0 on Windows Server 2012 offers a new feature called an extensible virtual switch. This feature allows you to replace the Windows integrated virtual switch in Hyper-V with a third-party switch, such as the Cisco 1000V. You can get a quick overview of Hyper-V extensible virtual switches here
The Cisco 1000V virtual switch provides many advanced capabilities to Hyper-V VMs such as advanced switching (private VLANs, ACLs, PortSecurity, and Cisco vPath), security, monitoring, and manageability. Best of all it’s free to download here
The following information comes from Cisco’s Cisco Nexus 1000V Switch for Microsoft Hyper-V
Features and Capabilities
The Cisco Nexus 1000V Switch for Microsoft Hyper-V:
- Offers consistent operational experience across physical, virtual, and mixed hypervisor environments
- Reduces operational complexity through dynamic policy provisioning and mobility-aware network policies
- Improves security through integrated virtual services and advanced Cisco NX-OS features
The following table summarizes the capabilities and benefits of the Cisco Nexus 1000V Switch for Microsoft Hyper-V.
|Advanced Switching||Private VLANs, Quality of Service (QoS), access control lists (ACLs), portsecurity, and Cisco vPath||Get granular control of virtual machine-to-virtual machine interaction.|
|Security||Dynamic Host Configuration Protocol (DHCP) Snooping, Dynamic Address Resolution Protocol Inspection, and IP Source Guard||Reduce common security threats in data center environments.|
|Monitoring||NetFlow, packet statistics, Switched Port Analyzer (SPAN), and Encapsulated Remote SPAN||Gain visibility into virtual machine-to-virtual machine traffic to reduce troubleshooting time.|
|Manageability||Simple Network Management Protocol, NetConf, syslog, and other troubleshooting command-line interfaces||Use existing network management tools to manage physical and virtual environments|
If you have multiple IP addresses on and Exchange 2010 Hub Transport server for the same network, Exchange will always use the preferred IP address for all outbound traffic and consequently, the send connector.
There may be times when you want Exchange to use another IP. Maybe because you already have that IP address configured in your firewalls. Unfortunately, you can’t specify the IP address to use in Exchange for a send connector on Hub Transport servers, only Edge Transport servers.
You can, however, install a hotfix on Windows Server 2008 or Windows Server 2008 R2 servers which allows you to use netsh
to disallow certain IPs to be used for outbound traffic. The hotfix is required for all versions of Windows Server 2008 SP2 and Windows Server 2008 R2 RTM. It is included in Windows Server 2008 R2 SP1.
Hotfix for Windows Server 2008 SP2: http://support.microsoft.com/kb/975808
Hotfix for Windows Server 2008 R2 RTM: http://support.microsoft.com/kb/2386184/
Once the hotfix is installed, run the following command from an elevated CMD prompt:
Netsh int ipv4 add address <Interface Name> <IP address> skipassource=true
This will cause Windows to disallow the IP address on the specified NIC from being used for outbound network traffic.
There are many reasons why you may need to use a port scanner to check if a TCP or UDP port is open. Microsoft has a little known utility called PortQry
that allows you to perform basic port scanning from the command line.
You can download PortQry from http://www.microsoft.com/downloads/en/details.aspx?familyid=89811747-c74b-4638-a2d5-ac828bdc6983&displaylang=en
Download the PortQryV2.exe package and run it to extract the PortQry.exe program, EULA and readme file. I typically copy PortQry.exe to my %SystemRoot% folder so I can run it from any directory.
Here are some examples of how to use PortQry from the command line:
- portqry -n servername -e 80 – Queries remote computer servername to check if it’s listening on TCP port 80 (HTTP).
- portqry -n servername -p UDP -o 37,88,135 – Queries the remote computer to check if it’s listening on UDP ports 37, 88 and 135.
- portqry -n 10.0.0.21 -r 1-1024 – Queries the IP address to determine if it’s listening on any of the well-known TCP ports. The output will display each port and whether it’s listening or not listening.
- portqry -n 10.0.0.21 -r 1:1024 | find “: LISTENING” – Same as above, but only lists open ports.
PortQry can also be run in silent mode using the -q
switch. The program exit with a returncode of 0
if listening, 1
if not listening, or 2
if listening or filtered. This is useful for batch file processing.
I’ve had a number of problems with Windows Server 2008 Hyper-V guests that hold onto their original IPv4 address after running SysPrep.
SysPrep is supposed to remove this kind of server-specific information, but for some reason this isn’t happening with Server 2008 images. Removal of machine-specific information is called “generalization” and is supposed to happen when you click the Generalize checkbox in SysPrep.
I’ve seen this cause the following symptoms:
“The IP address you have entered for this network adapter is already assigned to another adapter (microsoft Virtual machine Bus Network Adapter) which is no longer present in this computer”
For this error, do the following:
Open a command prompt and enter set devmgr_show_nonpresent_devices=1
Enter start devmgmt.msc to start Device Manager
In the Device Manager window, click View and Show hidden devices
Under Network Adapters you will see the dimmed conflicting device, probably the Microsoft Virtual Machine Bus Network Adapter. Delete it and you can continue to configure the existing adapter.
The other issue I’ve seen is when the network adapter hangs onto the imaged machine’s IP address and you cannot delete it. In this case, you view the properties of the adapter and see the old IP address as an additional IP address. It looks like you can successfully remove the old IP address, but it still shows up when you view the NIC’s properties again.
In this case, you do the following from the Hyper-V host server:
- Connect to the VM guest session from the host. You will lose RDP connectivity otherwise.
- Open Device Manager
- Expand Network Adapters, right-click the misbehaving NIC and select Uninstall
- Right-click Network Adapters and select Scan for hardware changes
- Reconfigure the new adapter