Common problems include:

• A-Records and PTR’s registered for the Parent Partition under multiple IP addresses
• NetBIOS conflicts
• Unwanted traffic going through network cards that you want to dedicate to, for example, VM’s or iSCSI.

These problems have nothing to do with Hyper-V actually.  They’re just issues you can face with any server containing more than one network card.

Step #1: Ensure that you have a good naming convention for you network cards

As you can see I have explicitly named by network cards.  One for the parent partition, one for the VM’s.  If you have one or more network cards for VM’s or iSSCI, name them accordingly.

Step #2 : Ensure that the parent partition uses the right network card

In the image below you can see that the Parent Partition network card is first in the order.  This means that network services will attempt to use this interface before the VM NIC #1.

Step #3 : Ensure that the VM or iSCSI NIC does not register itself in DNS

Make sure that the network cards you dedicate for VM external networks do not register themselves in DNS.  Just configure the basic IP address and mask.  You do not need to include DNS servers etc.  Remember, you are more or less turning this network card into a virtual switch.

Note that the “Register this connections addresses in DNS” is left un-ticked.  If you built you base OS for the parent partition with all the network cards patched, chances are that you will find more than one address registered for the server in DNS.  Ensure that you remove unwanted A-records and PTRs.

Step #4: Ensure that you disable NetBIOS over TCP/IP on the VM network cards

Example:

[xml]$computerlist = Get-Content computers.xml
foreach( $computer in $computerlist.computers.target) 
{ 
    Write-Host $computer.name
} 

What would the XML file look like?

<computers> 
  <target> 
    <Name>server1</Name> 
  </target> 
  <target> 
    <Name>server2</Name> 
  </target> 
</computers>

Nice and simple really.

This above is taken from http://technet.microsoft.com/en-us/library/cc773347(WS.10).aspx 

The TechNet article then shows you how to manually, through the GUI, modify the access control entries (ACE’s).  You can find details here.  

So, how do you go about this task if you have quite a few OU’s?  You need the following from the Windows Server 2003 Support tools:

• dsquery
• dsacls

dsquery will, by default, only return the first 100 results.  You’ll need the ‘–limit 0’ to process more than 100 objects, in this case OUs.

To protect all OU’s in a domain run the following:

for /F "tokens=*" %%i in ('dsquery OU -limit 0') do dsacls %%i /D "EVERYONE:SDDCDT"

To protect a specific OU and all leaf OU’s:

for /F "tokens=*" %%i in ('dsquery OU “ou=target,dc=domain,dc=net” -limit 0') do dsacls %%i /D "EVERYONE:SDDCDT"

For /F “tokens=*" %%i in ('dsquery OU –limit 0') do dsacls %%i /S

With the economic down turn and the green agenda Virtualisation has become a hot topic with my customer. These days its all about getting the best value for money as possible with your IT budget, so when my customer had a number of servers out of warranty and due for replacement the Hyper-V platform was the first port of call.

The first thing we did was run the Microsoft MAP tool against these servers to ensure that they were real candidates for Virtualisation. This tool can be found at

http://www.microsoft.com/downloads/details.aspx?familyid=67240B76-3148-4E49-943D-4D9EA7F77730&displaylang=en

Information on using the tool can be found at

http://technet.microsoft.com/en-us/library/bb977556.aspx

Currently my customer has a number of Hyper-V GEO Cluster's based on HP boot from SAN Blades. All  of the Virtual Hosts are managed centrally by Microsoft System Centre Virtual Machine Manager (SCVMM). Using the map tool we were able to determine that based on the existing hardware we could achieve an 8 - 1 virtual machine ratio. Considering that the new hardware runs cooler / cheaper and is only a couple of U per blade compared to the 6 - 8 U servers they were replacing everyone was happy.

All of the machines to be Virtualised were Windows 2000 & ran bespoke applications. If we were to rebuild these servers on new kit it would have taken a lot of time and effort to ensure that the applications were tested etc.. not to mention the downtime involved.

Pre-Requisites

You will need the following patches on the Hyper-V target systems.

KB950050, KB951308, KB956589, KB956697, KB956710, KB956774

You will need the following patch on the SCVMM Server

KB959596

You will also need the following version of WAIK for all offline conversions. The version included with the OS will not do the job. Install this on the SCVMM Server.

http://www.microsoft.com/downloads/details.aspx?familyid=C7D4BC6D-15F3-4284-9123-679830D629F2&displaylang=en

Using the P2V Wizard

In this example I am performing a physical to virtual conversion on a Windows 2000 server.

A Windows 2000 server P2V has the following pre-requsites.

• Service Pack 4
• 512MB RAM minimum

As the source service is Windows 2000 the only option is an offline conversion. As part of the process an agent will be installed on the source server and the server will be re-booted into WinPE so that the contents of the source servers hard drive can be copied via BITS.

1. With the Virtual machines menu option high lighted click on Convert Physical Server.

2. Enter the Computer name or IP address of the Physical Server and account details of a user that has local administrator rights on the source Physical Server.

3. Enter a Name for the New Virtual Server. Set the owner of the Virtual Machine (defaults to the logged in user) and add a description for the Virtual Server.

4. Click Scan System to install the SCVMM agent & gather information on the Physical Server.

5. After the scan the System Information panel will be populated. Click Next to continue.

6.  Here we select the volumes to be copied to the new VM as part of the P2V process. You can also change the VHD type from Dynamic to Fixed.

7. Typically on this screen I choose to obtain an IP address automatically from DHCP. You can specify an IP address & Network card (using MAC address) if required.

8.  On this screen you can specify the number of process and amount of RAM the VM will use. I usually set the VM to use 2 processors during the P2V process. This helps with the integration components setup, it can be changed back to a single processor later. Please note that these settings will be used to determine the placing of the VM on a host server as we will see later.

 

9. Here you choose the server that will host the VM. You can see the suitability of each host based on the Star Rating. This is much improved when SCOM is used in conjunction with SCVMM. In the screen shot below SCOM was not configured.

10. As the host I selected was a Windows 2008 Hyper-V cluster I got this message box popping up. Click Yes to continue. SCVMM will set up the new virtual server as a clustered VM.

11. Select the volume that the VM will reside on. If your target volume does not appear on this list refresh the cluster information within SCVMM.

12. Select the Virtual Network that the Virtual Machine will use.

13. As this VM will reside on a cluster do not change these settings. This allows the cluster service to manage the Virtual Machine.

14. If all is ok you should see this screen. You can run into an issue that can occur  with legacy hardware (i.e. RAID controllers) not included with the WINPE Image, which is used to boot into the P2V environment . If you can obtain the Vista driver for the problem hardware copy it to SCVMM\Drivers\Import folder to solve the issue.

 

 

15. This last screen gives us a summery of the P2V job & the option to View and copy the PowerShell script generated by the wizard. You can copy out this script and modify it for automating this process if required.

 

16. After clicking Create the jobs screen will pop up. This screen provides real time information regarding the P2V process including the time required to copy the contents of the targets volumes to the new virtual machine.

 

17. Here we can see the BITS copy in progress and the amount of time remaining to copy the volumes.

18. The script we created with the Wizard also installs the required virtual machine components. In some cases this process will seem to hang. This can be resolved by using the Hyper-V console on the target machine to re-start the VM.

 

20. Once the jobs screen completes we will have a running Windows 2000 VM. Check that the VM is running on the External Virtual Network and that the source machine is turned off and removed from the Network.

The process was quick with minimal downtime for the users. We did run into some issues with legacy RAID controllers but got around them using the fix mentioned in step 14. The new VM’s are a lot more stable than the previous hardware and are now on a high availability platform giving my customer more peace of mind.

One of the most common conversations I have about virtualisation is the "how do I make my virtual machines highly available?" one.  Topics like Hyper-V Quick Migration are then discussed and off the techie goes to start testing.  When I revisit the discussion I have noticed the false sense of security people get just because their virtual machines are highly available.  HA options for VM's do not mean stop worrying about host clustering, network load balancing or traditional backups  ...  no matter how clever the technology.  Highly available virtual machines no longer have the single point of failure at the (host) hardware level .. and that's about as far as it goes.  You still have to mitigate against the same risks at the OS level (and above) regardless of whether or not its physical or virtual.  Okay, some of you are saying duh!  Bear with me though.  It's not uncommon for people to think just because they have a Hyper-V cluster or VMWare HA that the majority of potential outages are accounted for.

Consider the following:

1. Most HA options will require that the host(s) is/are functioning correctly.  If you have problems with the host, expect problems with your HA solution.
2. Replication of virtual hard disks will not protect you from data loss or corruption inside VM.  The loss will be replicated.
3. Replication of virtual hard disks will not protect against corruption of virtual hard disks or settings.  The corruption will be replicated.
4. Live migration options really only work for planned downtime.  Unplanned downtime will result in your VM's being restarted with a (varying) loss of service.

With the above in mind, have  a read of the following:

• Hyper-V Hardware considerations
• Backing Up Hyper-V Virtual Machines
• Hyper-V Clustering Options
• Design for a Failover Cluster in Which All Nodes Run Hyper-V 
• Requirements and Recommendations for Failover Clusters in Which All Nodes Run Hyper-V   
• Checklist: Failover Cluster in Which the Servers Run Hyper-V   

Long story short, virtualisation has not changed anything when it comes to mitigation against system failure/outage.  The same rules still apply.  Virtualisation high availability solutions represent only the first layer of protection .. just don't forget the other options like:

• Traditional Backup and Recovery
• Host Clustering
• Network Load Balancing

We are running an event this December for Microsoft Premier customers.  I'm pretty excited about it actually.  Premier Field Engineering and Microsoft Consulting Services are teaming up to present real world details on Hyper-V, System Centre Virtual Machine Manager 2008 and Application Virtualisation.  We plan on running as many demonstrations as possible during the event so death by PowerPoint should not be an issue.

This event is only open to Microsoft Premier Customers.  Contact your Technical Account Manager to reserve your place.  If you are not a Premier Customer we plan on running the event again early in 2009.  Drop me an email if you are interested in attending.

Here is the agenda for the event :

Title:  Technology Day – Microsoft Virtualisation (Level: 300)

Location

Microsoft Sandyford
Building 3, (Atrium B)
Carmenhall Road,
Sandyford Industrial Estate, Dublin 18

Training Room 5.41

Date & Time
Fri 5^th December @ 9:15

Breaks

15 mins @ 11:15 am
1 hour @ 1pm – 2pm (Lunch)
15 mins @ 3:30pm

Morning

09:30

Workshop Introduction

09:45

Microsoft Virtualisation @ Nissan Ireland
Rory Donnelly (CIO Nissan Ireland)

10:00

Virtual Data Centre :

Microsoft Server Virtualisation and System Centre Virtual Machine Manager
Gavin McShera, Victor Arzate Rodriguez and David McCormick

This session is aimed at providing skills to deploy and administer a Virtualised Data Centre, using Microsoft Server Virtualisation products and System Centre Virtual Machine Manager 2008.

Content:             

Hyper-V Architecture

• Understand the architecture behind Windows Server 2008 Hyper-V and Hyper-V Server.
• Learn how to increase uptime, by understanding what is happening under the covers of Hyper-V.

Getting to grips with Server Core Hyper-V and Hyper-V Server

• Understand the process of enabling Hyper-V on Server Core including enabling remote management.
• Understand the best practices for management and delegation.
• Learn from our experience of deploying Hyper-V Server Core.

Performance Best Practice & High Availability

• Understand Hyper-V Performance Best Practices – The big 4: Disk, Memory, Network & Processor.
• Understand Failover Clustering Best Practices, Server Core hosts & Management.

Managing Hyper-V

• Learn how to effectively manage Hyper-V hosts in an enterprise deployment using SCVMM 2008.
• Understand SCVMM design considerations and best practices.

Deploying and Migrating to Hyper-V

• Understand various methods of virtual machine deployment, including with SCVMM 2008.
• Learn about some common migration routines.

Afternoon

02:15

Application Virtualisation with Microsoft App- V (formerly Softgrid)
Alan Stone and Paul Devlin

This session introduces Microsoft Application Virtualisation and provides notes from the field with real world scenarios

Content:    

• An overview of the App-V technology
• How App-V can mature the IT Environment

Notes from the Field

• How App-V helped a customer overcome application delivery challenges
• Benefits to mobile workers
• Application Compatibility
• Sequencing Recipes best practices

Application Virtualisation 4.5 What does the future hold?

• Integration with the System Centre family of products
• New Deployment methods for Virtualised applications
• Asset intelligence & App-V 4.5

03:45

Open Discussion – Q & A

Single Sign On for Windows XP Clients

Single Sign On (SSO) to Windows Server 2008 (W2K8) Terminal Services uses the Credential Security Service Provider (CredSSP).  CredSSP delegates credentials to defined target servers and is native to Windows Vista.  Windows XP SP3 includes CredSSP but it is not enabled by default.  Windows XP SP2 clients can still connect to W2K8 Terminal Services but users will be prompted for credentials upon establishing the first session.  Having to enter your username and password ruins the RemoteAPP experience.  So what do you need to get your Windows XP client seamlessly connecting to a W2K8 Terminal Server?

• Windows XP SP3
• Remote Desktop Connection (RDC) 6.1 (Part of SP3)

KB951608 explains the CredSSP for Windows XP SP3 in detail.

Once you have SP3 installed you need to make the following changes:

Client side:

• Enable CredSSP
• Configure Single Sign On for credential delegation
• Define target servers

Server side:

• Modify RDP protocol settings

Enable CredSSP

The CredSSP settings have to be APPENDED to the existing parameters.  See KB951608.  Appending to existing keys could prove time consuming if you have a lot of clients.  Here is a script written in VBS that may make automating the task a little easier.

Disclaimer: Do not blindly run these scripts without testing first.  Make sure you take a backup of the registry!

Const HKEY_LOCAL_MACHINE = &H80000002

strComputer = "."

Set oReg=GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\default:StdRegProv")

‘strKeyPath = "SYSTEM\CurrentControlSet\Control\Lsa"

strValueName = "Security Packages"

oReg.GetMultiStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,arrSecurityPackages

For Each strValue In arrSecurityPackages

if lcase(strValue) = "tspkg" then intTSPKG = 1 ‘ Set a flag to say that value already exists

Next

if intTSPKG <> 1 then ‘Value doesn’t exist so lets create it

intNewArraySize = Ubound(arrSecurityPackages) + 1

reDim Preserve arrSecurityPackages(intNewArraySize) ‘Resize the array for new value and keep existing values

arrSecurityPackages(intNewArraySize) = "tspkg" ‘ Add the new value

oReg.SetMultiStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,arrSecurityPackages

End if

strKeyPath = "SYSTEM\CurrentControlSet\Control\SecurityProviders"

strValueName = "SecurityProviders"

oReg.GetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

intResult = InStr(strValue, "credssp.dll") ‘Will return position found in string

if intResult = 0 then ‘Position of 0 means string not found

strValue=strValue & ",credssp.dll"

oReg.SetStringValue HKEY_LOCAL_MACHINE,strKeyPath,strValueName,strValue

End if

Configure Single Sign On and define target servers

The following registry changes enable CredSSP for the default credentials.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation]

"AllowDefaultCredentials"=dword:00000001

"ConcatenateDefaults_AllowDefault"=dword:00000001

The following registry changes define the target servers.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\CredentialsDelegation\AllowDefaultCredentials]
"1"="TERMSRV/*"

You can explicitly name your terminal servers e.g. :

• TERMSRV/myserver.mydomain.com : A specific server
• TERMSRV/*.mydomain.com : All servers in mydomain.com
• TERMSRV/* : All servers

RDP Protocol changes

You have to make some changes to the default RDP protocol settings on your server in order to allow Windows XP SP3 clients connect.

Open Terminal Server Configuration snap-in and modify the RDP connection properties as follows:

Note that the tick has been removed from the "Allow connections only from computers running Remote Desktop with Network Level Authentication".  I have the Encryption level set of Client Compatible but there is no reason why you cannot use High.

Make sure that the Use client-provided log on information radial button is selected.

You should now be in a position to make use of the SSO functionality from your Windows XP clients.  However, there is a KB titled When you enable SSO for a terminal server from a Windows XP SP3-based client computer, you are still prompted for user credentials when you log on to the terminal server which comes with a patch.  During my testing I did not come across this problem ... but I figured it was worth noting.

The participating vendors (at time of writing are):

• Cisco Systems, Inc.
• Citrix Systems, Inc.
• Novell, Inc.
• Sun Microsystems
• Unisys Corp.
• Virtual Iron Software
• VMware, Inc.

The SVVP does not mean that Microsoft support the products from the vendors listed above.  The SVVP means the validated third party product provides a suitable environment upon which the Microsoft operating system can run.  If you think about it, the SVVP is very similar to the hardware certification for Microsoft operating systems.

Now that you know the supportability of your Microsoft operating systems turn your eyes to the support statements for Microsoft server software. Microsoft server software and supported virtualization environments. 

You'll find statements for :

• Microsoft Application Virtualization (App-V)
• Microsoft BizTalk Server
• Microsoft Commerce Server
• Microsoft Dynamics AX
• Microsoft Dynamics CRM
• Microsoft Dynamics NAV
• Microsoft Exchange Server
• Microsoft Forefront Client Security
• Microsoft Intelligent Application Gateway (IAG)
• Microsoft Forefront Security for Exchange (FSE)
• Microsoft Forefront Security for SharePoint (FSP)
• Microsoft Host Integration Server
• Microsoft Internet Security and Acceleration (ISA) Server
• Microsoft Office Groove Server
• Microsoft Office PerformancePoint Server
• Microsoft Office Project Server
• Microsoft Office SharePoint Server and Windows SharePoint Services
• Microsoft Operations Manager (MOM) 2005
• Microsoft Search Server
• Microsoft SQL Server 2008
• Microsoft System Center Configuration Manager
• Microsoft System Center Data Protection Manager
• Microsoft System Center Essentials
• Microsoft System Center Operations Manager
• Microsoft System Center Virtual Machine Manager
• Microsoft Systems Management Server (SMS)
• Microsoft Visual Studio Team System
• Microsoft Windows HPC Server 2008
• Windows Server 2003 Web Edition
• Microsoft Windows Server Update Services (WSUS)
• Windows Web Server 2008

Licensing changes:

I ran into problems once I downloaded and installed the Windows PowerShell 2.0 Community Technology Preview (CTP).  Powershells execution policy wouldnt let the scripts run anymore.

You can change the executionPolicy a number of ways:

Registry:  

HKLM\SOFTWARE\Microsoft\PowerShell\1\ShellIds\Microsoft.PowerShell

Change the key: REG_SZ ExecutionPolicy to Unrestricted

PowerShell:

set-executionpolicy unrestricted

Note: By changing the execution policy you are technically opening your system up to remote execution of PowerShell scripts from unsigned/untrusted sources.  I want to be able to mount vhds easily coz Im a lazy kinda guy.   Im running Hyper-V on my laptop so Im not too concerned about security in this instance.  You should think carefully about making this change in a production environment.

The second thing I noticed was that the registry settings provided by James no longer worked.  So I came up with a slight modification as follows:

 Windows Registry Editor Version 5.00

[HKEY_CLASSES_ROOT\Virtual.Machine.HD]

[HKEY_CLASSES_ROOT\Virtual.Machine.HD\DefaultIcon]
@="%SystemRoot%\\system32\\imageres.dll,26"

[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell]
@="Mount"

[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Mount]

[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Mount\command]
@="cmd /k \"powershell -NoProfile -Command \"& 'c:\\Program Files\\Hyper-V\\Mount-VHD.ps1' '%1'\"\""

[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Unmount]

[HKEY_CLASSES_ROOT\Virtual.Machine.HD\shell\Unmount\command]
@="cmd /k \"powershell -NoProfile -Command \"& 'c:\\Program Files\\Hyper-V\\Unmount-VHD.ps1' '%1'\"\""

[HKEY_CLASSES_ROOT\.vhd]
@="Virtual.Machine.HD"

I've used cmd/k instead of cmd/c so I can see what the PowerShell script reports when its finished along with a couple of changes to get PowerShell to accept the string after the -Command.

Now all is great in the land of Hyper-V on my laptop.

Where is the cluster log in Windows 2008 ?

This short answer is its no longer there. On our Windows 2008 cluster node if we navigate to %systemroot%\system32\LogFiles\Cluster your wont find the cluster.log file anymore.

Why ? Its been replaced by a much more sophisticated event based tracing system.

The Vista\Windows Server 2008 Event Model is the next generation of Windows Event Logging and replaces the current version of the Event Log shipped in Microsoft® Windows® 2003 Server, Microsoft® Windows® XP, Windows 2000, and previous versions of Microsoft® Windows NT®.

The new model is a major update to the NT Event Log service. It maintains 100% backwards compatibility with the existing APIs and functionality and fully leverages the existing NT Event Log instrumentation in the applications and services. At the same time, it eliminates some of the limitations of the NT Event Log and provides additional features to better support monitoring and diagnostics of Windows applications, services, components, and drivers.

In a future post I will go through the new Logging and tracing features for clusters in Windows 2008 but for now lets look at how to get access to the old familiar cluster.log file.

Here's how to go about it.

1.   Go to a command prompt

2.  Type "Cluster /Cluster:yourclustername log /gen /copy "C:\temp". You should get output as follows

3. Navigate to the c:\temp directory and there you will find the .log files for each node of your cluster.

The cluster log can now be opened in Notepad.

Please note that you need to run this command after each change as its not dynamically updated like the old .log file.