Jose Barreto's Blog

Overview

In a previous blog post, I described 5 different ways to implement Windows Server Failover Clustering with Windows Server 2008 Hyper-V. Those options included: Parent-based Failover Clustering with two physical servers, Child-based Failover Clustering with two physical servers, Mixed Physical/Virtual Failover Clustering, Failover Clustering with two child partitions on one physical server and Standalone demo laptop with Virtual iSCSI SAN. If you missed that one, check http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-hyper-v-failover-clustering-options.aspx.

However, I failed to mention in that post the option to use CIFS/SMB file server share as your option for Failover Clustering storage. This scenario is so unique (with differences in flexibility, cost and performance),  that I would argue it constitutes a sixth method. Here’s how you can do it.

Before and After Diagrams

As I did with the previous blog post, let me describe the scenario using two diagrams. First, here is a diagram describing the scenario before a failure:

Now, here’s a diagram describing the scenario after a failure in SPTNODE1:

As you can see, we use a file server (called SPTSERVER1) for storing the Hyper-V files. The idea is to store the configuration files, the VHD itself and the VHD snapshots in the \\SPTSERVER1\VMSHARE\VM1 folder. As we do when using a SAN for shared storage, the surviving node will take over and start the VM in case of a failure. We can also use the very same scenario for Quick Migration, making the VM move orderly from one node to another by saving the state to the file share and instructing to other node to take over and restore the VM.

Pre-requisites

Before you move forward, you want to make sure you have at least two physical computers running Hyper-V. In our scenario, STPNODE1 and STPNODE2 are running Windows Server 2008 Enterprise (Full or Core installs work fine).

Add the Hyper-V role to STPNODE1 and STPNODE2.

Add the Failover Clustering feature to STPNODE1 and STPNODE2.

You will need to use a general purpose server to act as a file server or a NAS box compatible with CIFS/SMB. You probably want to run Windows Server 2008 for improved performance (new TCP/IP stack and SMBv2 protocol). In our scenario, STPSERVER1 is the file server running Windows Server 2008 Enterprise Edition  (Full or Core installs work fine).

Grant the required permissions for \\SPTSERVER1\VMSHARE\ to the computer accounts for STPNODE1 and STPNODE2, as described at http://blogs.technet.com/josebda/archive/2008/06/24/storing-windows-server-2008-hyper-v-files-on-an-cifs-smb-file-share.aspx.

You might also want to have a management client which could be your desktop (running Windows Vista SP1) or another server (running a Full install of Windows Server 2008). In our scenario, SPTCLIENT1 is the management client.

Install the Windows Server RTM patch described at http://blogs.technet.com/josebda/archive/2008/06/26/windows-server-2008-hyper-v-released-today-includes-a-list-of-main-hyper-v-related-links.aspx in both nodes and also in the management client.

You will need to have a domain infrastructure (Windows Server Failover Clustering requires a domain). The domain controller is not shown in the diagrams.

Steps

You start the process by creating a cluster with the two Hyper-V nodes. To do this, you will use the Failover Cluster Management MMC from either node. In that tool, you will:

1. Validate the configuration
2. Create the cluster
3. Adjust the quorum configuration
4. Create the virtual machine in one of the nodes
5. Make the VM highly available

Running Validation

Here’s the initial screen of the Failover Cluster Management MMC, when first loaded.

Before you create the cluster, you must Validate your Configuration. Be sure to run *all* Validation tests, since solutions are only supported if you do so.

Since we are not using shared storage, the storage tests will generate a warning.  Completing validation with a warning is acceptable.

If you run into any errors during Validation, you must fix those before you proceed.

Creating the Cluster

After you run validation, click the option to “Create a Cluster”. First, you must specify the nodes. In this case we’re using SPTNODE1 and SPTNODE2.

 

Second, you specify the name of the cluster.

 

After confirming the data entered, the cluster is created, as shown below:

Note that we end up with a warning (yellow triangle). If you click the “View Report” button, you find what the issue is:

No appropriate disk could be found for the quorum disk.

This is expected. With only two nodes with no shared storage, you don’t have a valid quorum configuration and a single node failure will cause the cluster to fail.

You can see that in the cluster information below:

Typically, in a shared storage configuration, you would get that third vote from a shared witness disk (also know as a quorum disk).

We will overcome that in the next step.

Configuring the Cluster Quorum Settings

To get our third vote for the cluster without using shared storage, we will use the new option in Windows Server 2008 Failover Clustering to use a file server witness.

First, you need to add permission for the cluster computer account to the file share. The cluster computer account was created when we created the cluster.

As you did when granting permissions to SPTNODE1 and SPTNODE2, add full control permissions for the SPTDEMO\SPTCLUSTER$ account in the share and in the file system at SPTSERVER1.

Next, use the Failover Cluster Management tool to change the Quorum Configuration.

You will find this option by right-clicking the cluster name, then selecting “More Actions”, as shown below:

The wizard will guide you through the process. You will select the option for “Node and File Share Majority”, as shown below:

In the next screen, you will specify the actual shared folder path for the file share witness resource. We will use \\SPTSERVER1\VMSHARE\WITNESS. See below:

After you confirm the operation, you will see the update in the quorum configuration, now showing no warning signs.

 

I would recommend that you also check the status of the storage in the cluster.

You do this by clicking on the “Storage” node under the cluster name in the Failover Cluster Management tool. Here’s what you should see at this point:

As you can see, this is one of the cases where you have a healthy cluster with no shared storage. Exchange Server 2007 CCR clusters also do that.

Creating a regular Virtual Machine on a cluster node

At this point, if you check the Hyper-V Manager tool, you will see no virtual machines:

Now we will use the Hyper-V Manager to create a new VM in SPTNODE1 using only a file share for storage. If you’re doing this from SPTNODE1, you should have no isses. If you’re doing this from any other computer (like the management client SPTCLIENT1), be sure to check this post on how to configure Constrained Delegation to allow remote management of Hyper-V when using file shares: http://blogs.technet.com/josebda/archive/2008/06/27/using-constrained-delegation-to-remotely-manage-a-server-running-hyper-v-that-uses-cifs-smb-file-shares.aspx

Again, this is done through a wizard. This is a regular VM creation, except for the fact that we’re using UNC paths (file share paths) for the storage, instead of regular folders on a local disk. In my specific case, we’re storing this new VM at \\SPTSERVER1\VMSHARE\VM1.

Here you see the virtual machine configuration folder:

Then the location of the new VHD file for the VM:

And even the ISO file we’re mounting will also come from that file server:

Once all is confirmed, we have a new VM, which you should keep in an “off” state for now:

Making the Virtual Machine Highly Available

Now we go back to the Failover Cluster Management tool to make the newly created VM highly available.

Click on the “Services and Applications” node under the cluster name and select the option to “Configure a Service or Application”. Again, it’s a wizard:

After selecting “Virtual Machine” as the type of service, you will select from a list of existing VMs. In our case, there’s only VM1:

After confirming your settings, the VM is made highly available, with a warning:

Again, if you click on the “View Report” button, you find the issues

The path '\\SPTSERVER1\VMSHARE\VM1' where the virtual machine configuration is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine configuration on a clustered file server (configured within a failover cluster).

The path '\\SPTSERVER1\VMSHARE\VM1' where the virtual machine snapshots are stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual machine snapshots on a clustered file server (configured within a failover cluster).

The path '\\SPTSERVER1\VMSHARE\VM1\VM1.vhd' where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

The path '\\SPTSERVER1\VMSHARE\ISO\WindowsServer2008-amd64.iso' where the virtual hard disk is stored is not on a failover cluster and might not be highly available. To achieve the highest availability, store the virtual hard disk on a clustered file server (configured within a failover cluster).

As it usually does, the Failover Cluster Management tool is being very careful, pointing out that the file server share you are using is a potential single point of failure.

In order to have true high availability, you need to make sure that file share is also highly available. To achieve that, you need to place that file share in Failover Cluster as well.

The wizard has no way to detect if the file share is also clustered, so you will always get these warnings.

Now, you can go back and check the properties of the new highly available VM and bring it online.

One interesting thing you will notice is that you will not have any storage associated with that service, as you can see below:

In the summary page, you also confirm that, since you do not have the typical clustered disk listed in the summary for the virtual machine:

Moving the VM to another node

The last step is to prove that you can fail or move the VM to another node.

To do this, I use the option to “Move this service or application to another node”, which you can find when you right-click the virtual machine. See below:

When you do this, you will see that the VM will be taken offline in the source node (the state is saved first), as you can see below:

Then the VM will be brought online on the destination node (by restoring the state). Check below:

This process takes only a moment, and will depend only on how much memory you VM has and how long it takes to save the state to the file server share (from SPTNODE1) and then to restore the state from that same file share (from SPTNODE2).

You can see the final state, after the move to SPTNODE2 is completed, below:

Conclusion

I hope these steps will give you enough to recreate this scenario in your environment and validate that you can create a Failover Cluster for Hyper-V using only a CIFS/SMB file share for storage.

Keep in mind that, if your configuration can pass the Failover Cluster Validation with only a warning due to the missing shared storage, you solution is supported.

Also remember that this solution will only be truly highly available if you file share is also highly available. I’m sure you will find plenty of documentation out there on how to make file servers highly available.

Last, there is the question of performance. As I mentioned in the previous blog post using Hyper-V with file shares, I was impressed with the increased performance of a Windows Server 2008 file server, specially for this type of workload. However, I will leave it to you to test this configuration for yourself and draw your own conclusions about performance. With faster IP networks (including 10Gb Ethernet) and the improvements in the SMB v2 protocol, you might be tempted to trade performance for the added flexibility and reduced cost this could bring to your Hyper-V storage management.

As explained in my previous blog post at http://blogs.technet.com/josebda/archive/2008/06/24/storing-windows-server-2008-hyper-v-files-on-an-cifs-smb-file-share.aspx, you can store your Windows Server 2008 Hyper-V files in a CIFS/SMB file share. This additional storage option can be used for the VM configuration, VHDs, snapshots and ISOs. That post explains the required permissions,  describes in detail how to do it and also offers some performance tips.

In specific cases, however, additional configuration (beyond what is described in that first post) is required. That happens when you need to manage the server running Hyper-V remotely. You see, in that case, your remote management client typically does not have the permission to talk to the file server on behalf of the server running hyper-V. Let me try to use a little diagram to clarify the scenario:

As described in the diagram, I'm running the Hyper-V Manager on SPTCLIENT1 (which can be runnung Windows Vista SP1 or Windows Server 2008) to configure the VMs on SPTNODE1 (running Windows Server 2008 x64) storing the files in a share on the file server STPSERVER1 (running Windows Server 2008 to benefit from the improvements in SMBv2 and in the TCP/IP stack).

If you try to create a new VM stored in the file share in that scenario, you get an error message saying that your access is denied, even though the file share is properly configured with permission to the Hyper-V computer and the user. The exact message is “The operation failed. Failed to create external configuration store at ‘\\SERVER\SHARE\FOLDER’: General access denied error (0x80070005). User ‘DOMAIN\USER’ failed to create external configuration store at ‘\\SERVER\SHARE\FOLDER’: General access denied error (0x80070005).” Here’s a screenshot:

To work around this problem, you have two choices. An easy option is to connect directly to the server running Hyper-V (using a Remote Desktop Connection) and run the Hyper-V Manager directly there. This is usually fine, unless you’re running a core install of Windows Server 2008. Since there is no MMC in a Core install, you can’t run the Hyper-V Manager directly on the server, even though you can RDP to it. As you can probably guess from the diagram, my end goal is to create a two-node cluster and I would like to keep the parent partition as light as possible. Although a Core install is not required by Hyper-V, it is always highly recommended.

Fortunately there is second choice to address the issue: Constrained Delegation. By configuring the computer account of the server running Hyper-V in Active Directory, you can authorize the impersonation required by this scenario. You can start by running the “Active Directory Users and Computers” MMC on your domain controller. Right-click the computer account of the server running Hyper-V and select “Properties”.

Next, go to the “Delegation” tab to confirm that this computer is not trusted for delegation (the default).

You need to configure delegation, but you shouldn’t authorize it to all computers or for all kinds of services. The best practice from a security standpoint is to authorize exactly what you need and nothing else. To do that, select “Trust this computer for delegation to specified services only”, select “Use any authentication protocol” and click on the “Add…” button.

In the dialog to select the account, enter the name of the file servers. After you select the server, you will see the screen below, showing all services available. In this case we’re delegating the CIFS protocol (also known as SMB). You don’t need to select any other services in this case.

Here’s the screen with the final configuration.

We can now remotely connect to SPTNODE1 and reuse the credentials when connecting to SPTSERVER1 to access CIFS/SMB services.  When I retry that operation from SPTCLIENT1, as expected, it works just fine…

In my case, I also had to apply the same configuration to the computer account of the other cluster node: SPTNODE2.

I hope this clarifies all the details on how to configure Constrained Delegation to remotely manage a Hyper-V server that uses CIFS/SMB file shares. Keep in mind that the restriction to impersonate a user stems from a security concern that needs to be properly addressed by granularly granting only the minimum required permissions. Resist the temptation of delegating all services to all computers, without constraints.

Now I’m on to my configuration of a Hyper-V Failover Cluster using only a file server share for storage. But that’s a topic for another blog post…

Hyper-V is here!

As you can confirm on the press release linked below, the final release of Windows Server 2008 Hyper-V was just announced.
You can download the final version (number 18016) immediately from the Microsoft download web site.
This version will also go to Windows Update on July 8th.

Below you will find a collection of links about Hyper-V.

Windows Server 2008 Hyper-V RTM information

Press release on Windows Server 2008 Hyper-V RTM
http://www.microsoft.com/presspass/features/2008/jun08/06-26hyperv.mspx

John Howard's blog post about Hyper-V RTM
http://blogs.technet.com/jhoward/archive/2008/06/26/hyper-v-rtm-announcement-available-today-from-the-microsoft-download-centre.aspx 

Hyper-V RTM Guest Operating System Support Note
http://support.microsoft.com/kb/954958

Windows Server 2008 Hyper-V RTM download – Direct Links

Windows Server 2008 x64 Hyper-V Parent Partition RTM package
http://www.microsoft.com/downloads/details.aspx?FamilyId=F3AB3D4B-63C8-4424-A738-BADED34D24ED

Windows Server 2008 x86 Hyper-V Management RTM package
http://www.microsoft.com/downloads/details.aspx?FamilyId=6F69D661-5B91-4E5E-A6C0-210E629E1C42

Windows Vista SP1 x64 Hyper-V Management RTM package
http://www.microsoft.com/downloads/details.aspx?FamilyId=88208468-0AD6-47DE-8580-085CBA42C0C2

Windows Vista SP1 x86 Hyper-V Management RTM package
http://www.microsoft.com/downloads/details.aspx?FamilyId=BF909242-2125-4D06-A968-C8A3D75FF2AA

Hyper-V and Virtualization main links

Microsoft Virtualization Home Page
http://www.microsoft.com/virtualization

Hyper-V Home Page
http://www.microsoft.com/Hyper-V

System Center Virtual Machine Manager Home Page
http://technet.microsoft.com/en-us/scvmm

Virtualization TechCenter
http://technet.microsoft.com/en-us/virtualization

Hyper-V FAQ
http://www.microsoft.com/windowsserver2008/en/us/hyperv-faq.aspx

Virtualization Case Studies
http://www.microsoft.com/virtualization/case-studies.mspx

Virtualization Solution Accelerators
http://technet.microsoft.com/en-us/solutionaccelerators/cc197910.aspx

Hyper-V Webcasts and Podcasts

Virtualization Capabilities of Windows Server 2008 (Level 100)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032368894&CountryCode=US

Are You Ready for Virtualization? (Level 200)
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?culture=en-US&EventID=1032372420&CountryCode=US

Virtualization Security Best Practices
http://download.microsoft.com/download/5/c/b/5cb1943c-751d-4fd4-a897-38926e90a86f/BrandonBakerHyperVSecurity2Podcast.wma

TechNet Edge Interview: Hyper-V Overview with Mike Neil
http://edge.technet.com/Media/Hyper-V-hits-RTM-interview-with-Mike-Neil/

TechNet Edge Interview: Hyper-V Program managers interview Part 1
http://edge.technet.com/Media/Hyper-V-how-it-works-Interview-with-PMs-Part-1/

TechNet Edge Interview: Hyper-V Program managers interview Part 2
http://edge.technet.com/Media/Hyper-V-how-it-works-Interview-with-PMs-Part-2/

Hyper-V White Papers

Windows Server 2008 Hyper-V Overview
http://www.microsoft.com/downloads/details.aspx?FamilyID=0fe4e411-8c88-48c2-8903-3fd9cbb10d05&DisplayLang=en

Step-by-Step Guide to Getting Started with Hyper-V
http://www.microsoft.com/downloads/details.aspx?FamilyID=bcaa9707-0228-4860-b088-dd261ca0c80d&DisplayLang=en

Windows Server 2008 Hyper-V Performance Tuning Guide
http://www.microsoft.com/whdc/system/sysperf/Perf_tun_srv.mspx

Step-by-Step Guide for Testing Hyper-V and Failover Clustering
http://www.microsoft.com/downloads/details.aspx?FamilyID=cd828712-8d1e-45d1-a290-7edadf1e4e9c&DisplayLang=en

Windows Server 2008 Hyper-V integration with BitLocker
http://www.microsoft.com/downloads/details.aspx?FamilyID=2c3c0615-baf4-4a9c-b613-3fda14e84545&DisplayLang=en

Microsoft.com Operations Virtualizes MSDN and TechNet on Hyper-V
http://download.microsoft.com/download/6/C/5/6C559B56-8556-4097-8C81-2D4E762CD48E/MSCOM_Virtualizes_MSDN_TechNet_on_Hyper-V.docx

Microsoft.com Powered by Hyper-V
http://blogs.technet.com/windowsserver/archive/2008/06/25/microsoft-com-powered-by-hyper-v.aspx

Offline Virtual Machine Servicing Tool
http://technet.microsoft.com/en-us/library/cc501231.aspx 

Windows Essential Business Server Virtualization Guide
http://www.microsoft.com/downloads/details.aspx?FamilyID=840e11e7-6ce7-4b9b-a4ef-c3d5bf97f562&DisplayLang=en

Technet and MSDN blogs related to Hyper-V

http://blogs.technet.com/virtualization
http://blogs.msdn.com/virtual_pc_guy
http://blogs.technet.com/jhoward
http://blogs.technet.com/roblarson
http://blogs.technet.com/virtualworld
http://blogs.technet.com/windowsserver
http://blogs.technet.com/mapblog
http://blogs.technet.com/stbnewsbytes
http://blogs.technet.com/josebda

My main Hyper-V related blog posts

Storage options for Windows Server 2008 Hyper-V
http://blogs.technet.com/josebda/archive/2008/02/14/storage-options-for-windows-server-2008-s-hyper-v.aspx

More on Storage Options for Windows Server 2008 Hyper-V
http://blogs.technet.com/josebda/archive/2008/03/06/more-on-storage-options-for-windows-server-2008-s-hyper-v.aspx

Storing Windows Server 2008 Hyper-V files on an CIFS/SMB file share
http://blogs.technet.com/josebda/archive/2008/06/24/storing-windows-server-2008-hyper-v-files-on-an-cifs-smb-file-share.aspx

Windows Server 2008 Hyper-V Failover Clustering Options
http://blogs.technet.com/josebda/archive/2008/06/17/windows-server-2008-hyper-v-failover-clustering-options.aspx

Windows Server 2008 Core, Hyper-V and Failover Clustering - with screenshots
http://blogs.technet.com/josebda/archive/2008/04/14/snw-demo-windows-server-2008-core-hyper-v-and-failover-clustering-with-screenshots.aspx

Overview

I previously covered the storage options for Hyper-V and described the many choices between directly attached or SAN storage, fibre channel or iSCSI, passthrough or VHD, Virtual SCSI or Virtual IDE, etc.
If you missed that one, check it out at http://blogs.technet.com/josebda/archive/2008/02/14/storage-options-for-windows-server-2008-s-hyper-v.aspx

However, I failed to mention in that post the option to store your VHD files in a CIFS/SMB file server share.
Here's an updated diagram with all the different Storage options for Hyper-V, including the DAS, SAN and file server options:

 

Everyone is quick to remind me that this SMB option would be slower than block storage, if all else is the same.
However, with faster IP networks (including 10Gb Ethernet) and the improvements in the SMB v2 protocol, you might be tempted by the added flexibility in your storage management.

How to do it

Storing your Hyper-V files on a file server is pretty straightforward.
There are, however, a few of things that you need to implement this properly with Hyper-V.

First of all, remember to grant access to the computer account of the computer running Hyper-V.
This is the DOMAIN\COMPUTERNAME$ account, which you can use in the same way you would use a regular user account when granting permissions.

The second thing is that you need to do is use a UNC path when pointing to the file server.
This is a path that looks like \\SERVERNAME\SHARENAME.
Using a mapped drive or mount point does not work with the Hyper-V Manager tool.

Last but not least, you need to do this at the computer running Hyper-V (or connected via Remote Desktop to that computer).
If you try to use the Hyper-V Manager tool remotely, you will get an error message saying "Failed to create external configuration store at '\\SERVERNAME\SHARENAME\FOLDERNAME': General access denied error (0x80070005)".
You can work around this by using constrained delegation to allow a workstation to work on behalf of the computer running Hyper-V.
For details on that option, check http://blogs.technet.com/josebda/archive/2008/06/27/using-constrained-delegation-to-remotely-manage-a-server-running-hyper-v-that-uses-cifs-smb-file-shares.aspx.

Performance tips

Everyone agrees that, all else being the same, it’s faster to use an iSCSI LUN than an SMBv1 file share for your Hyper-V storage.
There are, however, a few things you can do to improve your network performance for Hyper-V.

First, you can use a separate NIC on the server running Hyper-V for the file server traffic. 
This will help isolate the network traffic between the file server and the server running Hyper-V from other network traffic.
To make sure there’s no VM traffic going through this NIC, do not connect it to the Virtual Switch.

You can also use a NIC with a TCP Offload Engine.
These TOE NICs will improve your network performance and handle much of the work without additional burden to the CPU.
This NIC could again be dedicated to the file server traffic.

Last but not least, consider upgrading your Windows file server to Windows Server 2008.
The improved TCP/IP stack and the support for the new SMBv2 will significantly improve your file server performance.

These optimizations will actually work for any kind of TCP/IP traffic (except for the part about SMBv2 protocol enhancements, which are specific to a file server workload).

Step by step instructions

Here are a few instructions on how to do this, based on my test configuration.
I implemented this with two servers, one running Windows Server 2008 Hyper-V (called JOSEBDA-HV2) and another running Windows Server 2008 as a file server (called JOSEBDA-MM1).

The first step was to create a folder on JOSEBDA-MM1 and share it, granting rights to the computer running Hyper-V and to the user running the Hyper-V Manager tool.
Here are the command lines used on JOSEBDA-MM1 to accomplish that:

MD C:\VMSTORE ICACLS C:\VMSTORE /GRANT DOMAIN\ADMINUSER:F /GRANT DOMAIN\JOSEBDA-HV2$:F NET SHARE VMSTORE=C:\VMSTORE /GRANT:DOMAIN\ADMINUSER,FULL /GRANT:DOMAIN\JOSEBDA-HV2$,FULL

The second step was to create the Virtual Machine on the JOSEBDA-HV2 computer, using a UNC path to  configure the location of the files used.

In this case, the path was \\JOSEBDA-MM1\VMSTORE.
Here are a few screenshots of the New Virtual Machine Wizard using the file server path.

First, here is where we specify the location of the virtual machine as a UNC path:

Second, we use the UNC path again when specifying the location of the VHD file. The wizard already suggests the right location:

I also used an ISO file located on a file share path. Here’s that screen:

The review screen shows the entire configuration:
 

And it works… As you can see in the properties of the running VM:

Conclusion

So, I hope you enjoy having yet another storage option for your Hyper-V workload.
I was impressed with the increased performance of SMBv2, but I encourage you to try this out for yourself and draw your own conclusions.
Also keep in mind that you can use this for your VHD files, your ISO files or both.

Heads up for an upcoming webcast on the new file service features in Windows Server 2008 by Drew McDaniel, a Senior Program Manager with the Microsoft Storage Solutions Division (SSD).

Here's a short description: "The Windows Server 2008 operating system contains a lot of changes to core file services components that dramatically increase availability, scalability, and performance. Some of these components are new, others are significantly enhanced. In this webcast, we provide an overview of the changes in Distributed File System (DFS), Volume Shadow Copy Service (VSS), and storage management in Windows Server 2008. We also take a close look at some the most significant and valuable improvements to Windows Server 2008, including Transactional NTFS, Self-Healing NTFS, and the Server Message Block (SMB) 2.0 protocol. So, bring your wet suit and join us for a webcast full of demonstrations and deep technical insight."

This webcast is scheduled for Thursday, July 17, 2008 9:30 AM Pacific Time. Register at
http://msevents.microsoft.com/CUI/WebCastEventDetails.aspx?EventID=1032381104&EventCategory=4&culture=en-US&CountryCode=US

There are many ways to implement Windows Server Failover Clustering with Hyper-V. I could actually find five unique methods to do it. Some of them will actually not give you a fully fault-tolerant solution, but most of them actually make sense in specific scenarios (even if only for demonstrations). In any case, just trying to understand and differentiate them will probably be a good exercise.

1 – Parent-based Failover Clustering with two physical servers

In this first scenario, probably the most common one, you implement Windows Server 2008 Failover Clustering at the Hyper-V Parent (Host) level. You will need some shared storage, like a Fibre-Channel or iSCSI SAN.

Here is a diagram describing the scenario before a failure:

Here is a diagram describing the scenario after a failure:

As you can see, this can survive the failure of one of the physical servers. In fact, if you have a redundant network and storage infrastructure (not shown above), you can have a truly highly available solution.

Additional details about this solution (including screenshots on how to configure it) are available at http://blogs.technet.com/josebda/archive/2008/04/14/snw-demo-windows-server-2008-core-hyper-v-and-failover-clustering-with-screenshots.aspx

2 – Child-based Failover Clustering with two physical servers

In this second scenario, you implement Windows Server 2008 Failover Clustering at the Hyper-V Child (Guest) level. In this case, your shared storage must be an iSCSI SAN.

Here is a diagram describing the scenario before a failure:

Here is a diagram describing the scenario after a failure:

This one can also survive the failure of one of the physical servers. Given redundant network and storage infrastructure (not shown above), you can again have a truly highly available solution.

3 – Mixed Physical/Virtual Failover Clustering

This third scenario is probably is one of the more unusual ones, but I have been asked about it at least a couple of times. Here you have a physical server clustered with a virtual one. If the physical server fails, the virtual sibling will take over the workload. This scenario uses dissimilar hardware with Failover Clustering, but if this is running Windows Server 2008, you can likely make it work. Just make sure you run the Failover Clustering Validation Wizard to confirm this is supported in your specific configuration. In this case, because you need to expose the LUNs directly to the child partition, your shared storage must again be an iSCSI SAN.

Here is a diagram describing the scenario before a failure:

Here is a diagram describing the scenario after a failure:

This can also survive the failure of one of the physical servers. If you configure the network and storage infrastructure to be fault tolerant (not shown above), you can have yet another truly highly available solution.

4 – Failover Clustering with two child partitions on one physical server

This scenario is also common. Here you have a single physical server running Hyper-V and two child partitions where you run Failover Clustering. If the physical server fails, both (virtual) cluster nodes will fail. Obviously, this is not useful for true high availability, but could be interesting for testing, training or demonstrations. In this case, your shared storage must be an iSCSI SAN.

Here is a diagram describing the scenario before a failure:

Here is a diagram describing the scenario after a failure:

This scenario cannot be made truly highly available even if your network and iSCSI SAN are redundant, since you have the physical server running Hyper-V as a single point of failure. The simulated failure can be achieved by turning off one of the child partitions in Hyper-V.

5 – Standalone demo laptop with Virtual iSCSI SAN

This last scenario is something I also get asked a lot. The goal here is to have a single laptop hosting an entire Failover Clustering demo with Hyper-V. In order to accomplish this, you need a virtual iSCSI SAN plus two child partitions to play the role of cluster nodes. To be the virtual iSCSI SAN, you can use an evaluation version of the Microsoft iSCSI Software Target described at http://blogs.technet.com/josebda/archive/2008/01/07/installing-the-evaluation-version-of-wudss-2003-refresh-and-the-microsoft-iscsi-software-target-version-3-1-on-a-vm.aspx. This is certainly not a true highly available solution, but it can be an interesting demo machine with no external network dependencies.

Here is a diagram describing the scenario before a failure:

Here is a diagram describing the scenario after a failure:

As with the previous scenario, this one cannot be made truly highly available, for obvious reasons. In fact, this one only really makes sense for demonstrations or training. The simulated failure can once again be achieved by turning off one of the child partitions in Hyper-V.

Conclusion

I hope this helped you understand the different options for using Failover Clustering with Hyper-V. Note also that you can combine some of these solutions, like the first and the second (some VMs using parent-based and some using child-based failover clustering).

For production use, it’s probably wise to restrict yourself to the first two scenarios. However, if you have a Hyper-V capable laptop and some free time, I would encourage you to try out the last one. Although not a supported production solution, it will certainly teach you a lot about all the technologies involved…

Links 

Additional information about Windows Server 2008 Failover Clustering support
http://support.microsoft.com?id=943984

Failover Clustering support in previous versions of Windows Server
http://support.microsoft.com/?id=309395.

Step-by-Step Guide to Getting Started with Hyper-V
http://www.microsoft.com/downloads/details.aspx?FamilyID=bcaa9707-0228-4860-b088-dd261ca0c80d&DisplayLang=en

Step-by-Step Guide for Testing Hyper-V and Failover Clustering
http://www.microsoft.com/downloads/details.aspx?FamilyId=CD828712-8D1E-45D1-A290-7EDADF1E4E9C&displaylang=en

Failover Cluster Step-by-Step Guide: Configuring a Two-Node File Server Failover Cluster 
http://technet2.microsoft.com/windowsserver2008/en/library/adbf1eb3-a225-4344-9086-115a9389a2691033.mspx

Additional details on Storage Options for Hyper-V
http://blogs.technet.com/josebda/archive/2008/02/14/storage-options-for-windows-server-2008-s-hyper-v.aspx 
http://blogs.technet.com/josebda/archive/2008/03/06/more-on-storage-options-for-windows-server-2008-s-hyper-v.aspx.

Scott Johnson added another post to the Storage Server blog, this time focusing on the History of the Windows Storage Server, all the way up to the Windows Unified Data Storage Server 2003 Refresh, released in August of 2007. Did you know, for instance, that the WUDSS 2003 Refresh introduced support for iSCSI dual-active clustering, 16 Terabyte iSCSI LUNs, OOBE customization and Software RAID support?

He also did a great job of describing all the different editions of Windows Server 2003 and Windows Unified Data Storage Server 2003, highlighting the different features available in each edition. Can you name the four editions of WSS 2003 and the two editions of WUDSS 2003 available today? Can you tell which of the six editions include support for Clustering? Which include the Microsoft iSCSI Software Target?

Find all the answers at
http://blogs.technet.com/storageserver/archive/2008/06/09/a-brief-history-of-windows-storage-server-releases.aspx

I am spending this week in Orlando, Florida, working at the TechEd 2008 - IT Professionals conference. I am at the System Center Data Protection Manager 2007 booth in the TLC (Technical Learning Center). I will be showing DPM's ability to protect Windows Server, SQL Server, Exchange Server, SharePoint Server and Virtualization workloads. If you are attending the conference, feel free to drop by and chat about DPM or any other topic of interest to you. Below is a map of the TLC area and where you can find me...

If you're not attending the event, be sure to check it virtually via webcasts and information being released about new products and technologies, like Virtual Machine Manager 2008, Desktop Virtualization and Identity Lifecycle Manager "v2" (just to name a few). Here are a few links (including a playback of Bob Muglia's keynote earlier today):

http://www.microsoft.com/techedonline

http://www.microsoft.com/presspass/events/teched/default.mspx

Scott Johnson (Program Manager for the Windows Storage Server product line) has just added the the first post on a brand new blog on Windows Storage Server.

This first post is a comprehensive list of all the key features of Windows Storage Server and Windows Unified Data Storage Server.

Check it out at http://blogs.technet.com/storageserver/archive/2008/06/04/welcome-to-the-new-windows-storage-server-blog.aspx

Overview

In this article, we’ll describe the process to install the VSS Hardware Provider (and, incidentally, the VDS Hardware Provider) for the Microsoft iSCSI Software Target, which is part of Windows Unified Data Storage Server 2003 (WUDSS 2003).

This package, referred to as “Microsoft iSCSI Software Target Client” supports both Windows Server 2003 and Windows Server 2008. We’ll show the Windows Server 2008 screenshots.

We’ll use two servers in this scenario. SERVER0 is the iSCSI Software Target, running WUDSS 2003. SERVER1 is the application server (a SQL Server, for instance) running Windows Server 2008 and the built-in iSCSI initiator. We’ll install the VSS hardware provider in SERVER1.

Before the installation

Below you see the output of the VSSADMIN command-line tool running on SERVER1 before the installation:

C:\Users\Administrator>vssadmin list providers vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool (C) Copyright 2001-2005 Microsoft Corp. Provider name: 'Microsoft Software Shadow Copy provider 1.0'    Provider type: System    Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}    Version: 1.0.0.7

You can confirm that there is no VSS provider installed except the in-box system provider.

Since we’re running Windows Server 2008 on SERVER1, we can also use the DISKSHADOW command line tool to check which VSS providers are loaded, which you can see below:

C:\Users\Administrator>diskshadow Microsoft DiskShadow version 1.0 Copyright (C) 2007 Microsoft Corporation On computer:  SERVER1,  5/23/2008 11:08:15 AM DISKSHADOW> list providers         * ProviderID: {b5946137-7b9f-4925-af80-51abd60b20d5}                 Type: [1] VSS_PROV_SYSTEM                 Name: Microsoft Software Shadow Copy provider 1.0                 Version: 1.0.0.7                 CLSID: {65ee1dba-8ff4-4a58-ac1c-3470ee2f376a} Number of providers registered: 1 DISKSHADOW> exit

Installing the client

To install the VSS hardware provider, we’ll run the “Microsoft iSCSI Software Target Client” setup on Server1.

Keep in mind that this software was updated this year to include support for Windows Server 2008, so you need to get an updated version from your WUDSS vendor.

Please note that Microsoft provides this client software to the OEMs that sell WUDSS, not directly to end users.

This is generally referred to by the Partner Knowledge Base article number that documents it.

If your OEM support person has any trouble finding it, ask them to look up Partner KB 949499. This is not a public KB, but all WUDSS OEM partners have access to it.

There are two versions of the Client, one for 32 bits and one for 64 bits. Choose the right file and run it.

The setup is delivered as an MSI file that leverages the Microsoft Installer technology. Here’s the welcome screen:

After you click next and accept the license agreement, you are taken to the screen that offers a choice of “Typical” or “Custom” install. See that below:

The “Typical” option will install both hardware providers (VDS and VSS). The “Custom” option will ask if you want to install VDS, VSS or both. See the screen below:

You then need to specify the user credentials to be used by the providers. Those will be used to authenticate with the iSCSI Software Target.

The account must have administrator privileges in both servers involved. Here’s that screen:

In the last screen you confirm the operation and start the actual installation. It’s a very quick install and it does not require a reboot.

Checking with VSSADMIN

After that, you should be all set. You can verify this by running VSSADMIN again.

Check the output below, which shows the “list providers” parameter being used to verify everything is in place:

C:\Users\Administrator>vssadmin list providers vssadmin 1.1 - Volume Shadow Copy Service administrative command-line tool (C) Copyright 2001-2005 Microsoft Corp. Provider name: 'Microsoft iSCSI Target VSS Hardware Provider'    Provider type: Hardware    Provider Id: {2f900f90-00e9-440e-873a-96ca5eb079e5}    Version: 3.1.3465 Provider name: 'Microsoft Software Shadow Copy provider 1.0'    Provider type: System    Provider Id: {b5946137-7b9f-4925-af80-51abd60b20d5}    Version: 1.0.0.7

Checking with DISKSHADOW

If you’re running Windows Server 2008, you can also use DISKSHADOW to verify that the VSS hardware provider is loaded.

Check the output below, which shows the “list providers” command being used to verify everything is in place:

C:\Users\Administrator>diskshadow Microsoft DiskShadow version 1.0 Copyright (C) 2007 Microsoft Corporation On computer:  SERVER1,  5/23/2008 11:08:15 AM DISKSHADOW> list providers         * ProviderID: {2f900f90-00e9-440e-873a-96ca5eb079e5}                 Type: [3] VSS_PROV_HARDWARE                 Name: Microsoft iSCSI Target VSS Hardware Provider                 Version: 3.1.3465                 CLSID: {363948d2-035d-4d1d-9bfc-473fece07dab}         * ProviderID: {b5946137-7b9f-4925-af80-51abd60b20d5}                 Type: [1] VSS_PROV_SYSTEM                 Name: Microsoft Software Shadow Copy provider 1.0                 Version: 1.0.0.7                 CLSID: {65ee1dba-8ff4-4a58-ac1c-3470ee2f376a} Number of providers registered: 2 DISKSHADOW> exit

Since DISKSHADOW is a VSS Requester, you can now use it on SERVER1 to create and expose a snapshot. For instance, check this output:

C:\Users\Administrator>diskshadow Microsoft DiskShadow version 1.0 Copyright (C) 2007 Microsoft Corporation On computer:  SERVER1,  5/23/2008 11:17:56 AM DISKSHADOW> list shadows all Querying all shadow copies on the computer ... No shadow copies found in system. DISKSHADOW> set context persistent DISKSHADOW> add volume E: DISKSHADOW> create Alias VSS_SHADOW_1 for shadow ID {6425d88d-9ed4-403a-a095-1ede1f85d7d7} set as environment variable. Alias VSS_SHADOW_SET for shadow set ID {dc00511e-4698-4d53-88f1-a47a7f275e58} set as environment variable. Querying all shadow copies with the shadow copy set ID {dc00511e-4698-4d53-88f1-a47a7f275e58}         * Shadow copy ID = {6425d88d-9ed4-403a-a095-1ede1f85d7d7} %VSS_SHADOW_1%                 - Shadow copy set: {dc00511e-4698-4d53-88f1-a47a7f275e58} %VSS_SHADOW_SET%                 - Original count of shadow copies = 1                 - Original volume name: \\?\Volume{a2ae039a-28ed-11dd-a3e2-00155d344309}\ [E:\]                 - Creation time: 5/23/2008 11:18:41 AM                 - Shadow copy device name: \\?\Volume{a2ae03a0-28ed-11dd-a3e2-00155d344309}                 - Originating machine: SERVER1.demo.local                 - Service machine: SERVER1.demo.local                 - Not exposed                 - Provider ID: {2f900f90-00e9-440e-873a-96ca5eb079e5}                 - Attributes:  No_Auto_Release Persistent Hardware Number of shadow copies listed: 1 DISKSHADOW> expose {6425d88d-9ed4-403a-a095-1ede1f85d7d7} S: The shadow copy was successfully exposed as S:\. DISKSHADOW> exit

That shadow copy can also be seen from the Microsoft iSCSI Software Target MMC running at SERVER0:

Conclusion

I hope these steps helped you install your VSS hardware provider for the Microsoft iSCSI Software Target.

At this point, you can start creating and exposing snapshots of your iSCSI VHDs on SERVER0 from SERVER1 using any other VSS Requester (like your favorite backup application).

Notes

For more details on VSS, check http://blogs.technet.com/josebda/archive/2007/10/10/the-basics-of-the-volume-shadow-copy-service-vss.aspx

For more information about WUDSS 2003, check http://www.microsoft.com/windowsserversystem/storage/wudss.mspx. Please note that WUDSS is only sold via OEMs like HP and Dell. It is not available via any other Microsoft sales channels like software retailers or volume licensing. WUDSS is also not available from MSDN or TechNet subscriber downloads.

Overview

In this article, we’ll describe the process to install the VDS Hardware Provider (and, incidentally, the VSS Hardware Provider) for the Microsoft iSCSI Software Target, which is part of Windows Unified Data Storage Server 2003 (WUDSS 2003).

This package, referred to as “Microsoft iSCSI Software Target Client” supports both Windows Server 2003 and Windows Server 2008. We’ll show the Windows Server 2008 screenshots.

We’ll use two servers in this scenario. Server0 is the iSCSI Software Target, running WUDSS 2003. Server1 is the application server (a SQL Server, for instance) running Windows Server 2008 and the built-in iSCSI initiator. We’ll install the VDS hardware provider in Server1.

Before the installation

Below you see a screenshot of the DISKRAID command-line tool running on Server0 before the installation.

Because there is no VDS hardware provider installed, DISKRAID cannot do anything and just shows a message and quits.

Installing the client

To install the VDS hardware provider, we’ll run the “Microsoft iSCSI Software Target Client” setup on Server1.

Keep in mind that this software was updated this year to include support for Windows Server 2008, so you need to get an updated version from your WUDSS vendor.

Please note that Microsoft provides this client software to the OEMs that sell WUDSS, not directly to end users.

This is generally referred to by the Partner Knowledge Base article number that documents it.

If your OEM support person has any trouble finding it, ask them to look up Partner KB 949499. This is not a public KB, but all WUDSS OEM partners have access to it.

There are two versions of the Client, one for 32 bits and one for 64 bits. Choose the right file and run it.

The setup is delivered as an MSI file that leverages the Microsoft Installer technology. Here’s the welcome screen:

After you click next and accept the license agreement, you are taken to the screen that offers a choice of “Typical” or “Custom” install. See that below:

The “Typical” option will install both hardware providers (VDS and VSS). The “Custom” option will ask if you want to install VDS, VSS or both. See the screen below:

You then need to specify the user credentials to be used by the providers. Those will be used to authenticate with the iSCSI Software Target.

The account must have administrator privileges in both servers involved. Here’s that screen:

In the last screen you confirm the operation and start the actual installation. It’s a very quick install and it does not require a reboot.

Specifying iSCSI Targets

WARNING: This section include information about modifying the registry. As you probably know, this may damage your system. Proceed with care, validate any changes in a test environment first and always perform a back up before making changes to the registry.

If both the storage and application servers are in the same domain, share the same subnet and have the ability to talk via UDP, the provider will discover the target automatically via mailslots.

However, there is a chance that the Microsoft iSCSI Software Target VDS Hardware Provider service may not detect all iSCSI Software Target servers on the network if one or more of the conditions above are not met.

To work around the issue, you need to manually add the iSCSI Software Target to be managed by the Microsoft iSCSI Software Target VDS Hardware Provider by following these steps:

1. Open Registry Editor.
2. Navigate to HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\WTVDSProv\WTServers
3. Create a REG_SZ value where the value name is the iSCSI Software Target server name and the value is blank (one for each iSCSI Software Target)

See the screen below, showing the registry in Server1 after adding the entry for Server0:

Restart the VDS service

If VDS is running, you need to restart VDS service so it can use the newly installed hardware provider (you do not need reboot the server, just stop and start the VDS service).

You can do this using the Services MMC or using the SC command line, as shown below:

Checking with DISKRAID

After that, you should be all set. You can verify this by running DISKRAID again.

This time, since the hardware provider is loaded, it should load and give you a command prompt.

Check the screenshot below, which shows the “list subsystems” and “list providers” commands being used to verify everything is in place:

Checking with Storage Manager for SANs

You can also use Storage Manager for SANs (SMfS) to verify that the VDS hardware provider is working.

Check the screen below to see Server0 details in the SMfS subsystems list:

Conclusion

I hope these steps helped you install your VDS hardware provider for the Microsoft iSCSI Software Target.

At this point, you can start provisioning iSCSI LUNs from Server1 using either DISKRAID and SMfS.

I will follow up with a couple of post on exactly how to do that…

Notes

For more details on VDS, check http://blogs.technet.com/josebda/archive/2007/10/25/the-basics-of-the-virtual-disk-services-vds.aspx

For more information about WUDSS 2003, check http://www.microsoft.com/windowsserversystem/storage/wudss.mspx. Please note that WUDSS is only sold via OEMs like HP and Dell. It is not available via any other Microsoft sales channels like software retailers or volume licensing. WUDSS is also not available from MSDN or TechNet subscriber downloads.

I hear a lot of comments about the fact that Hyper-V can expose SCSI disks (either directly attached SCSI disks or LUNs on SAN) to child partitions (also known as guests) as IDE disks.

Before you go telling little Virginia that, “Yes, there is a SAN”, you might want to consider how abstracting that fact is actually a perfectly fine way to configure your virtual machines.

First of all, virtualization is a lot about shielding the child partition from having to understand certains details of the real hardware. This is what makes virtual machines so easy to move between hosts.

Second, even on real hardware, the native BIOS does not really know how to interact with every SCSI disk or SAN. For instance, the way a server typically boots from those disks is through Int 13h extensions put in place by in the BIOS in the HBA, SCSI controller or RAID controller. Those BIOS extensions, which fire before the OS loads, will hook that interrupt and let the OS known enough about the disk to continue going until there’s a good chance to load a driver that understands more about the system. My point here is that, even on a non-virtualized system, there’s a lot of abstraction already going on anyway.

Also keep in mind that, if the guest operating system has the Hyper-V integration components installed, the performance of that Virtual IDE disk will be just as good as that of Virtual SCSI disks. At some point during the OS loading process, we switch from treating the disk as a legacy IDE disk to using the new VSC/VSP model which delivers the improved performance. And this happens automatically, just like holiday magic :-)

While you can argue in favor of exposing more of the real hardware details to child partitions, consider that life as a virtual machine is much simpler if you just believe that those IDE disks just magically appear under the Device Manager tree.

For details about the many ways to expose storage to Hyper-V, check http://blogs.technet.com/josebda/archive/2008/02/14/storage-options-for-windows-server-2008-s-hyper-v.aspx
For the background on that Virginia reference, check http://www.newseum.org/yesvirginia/

Microsoft has just published the preliminary syllabus for an upcoming instructor-led training on Windows Server 2008 Clustering.

This will be Course 6423: Implementing and Managing Windows Server 2008 Clustering.

Here’s a list of the modules included:

• Module 1: Introduction to Clusters
• Module 2: Introduction to Microsoft Windows Server 2008 Failover Clusters
• Module 3: Preparing to Install a Failover Cluster
• Module 4: Overview of Failover Cluster Storage Requirements
• Module 5: Configuring a Failover Cluster
• Module 6: Configuring Cluster Resources and Server Roles
• Module 7: Maintaining Microsoft Failover Clusters
• Module 8: Implementing Geographically Dispersed Clusters
• Module 9: Implementing Network Load Balanced Clusters

This one is not available quite yet, but it’s never too early to call your favorite Microsoft Certified Learning Solutions Partners and confirm their plans to put it on the schedule.

Get all the details at http://www.microsoft.com/learning/en/us/syllabi/6423aprelim.mspx

1 – What is Storage Explorer

Storage Explorer is a new tool in Windows Server 2008 to help you understand how your server SAN storage is configured.

It provides information about the storage fabrics (Fibre Channel and iSCSI) and also about the configuration of each server.

This new tool can greatly help you understand your server configuration as it relates to SAN storage. It is also a useful troubleshooting tool.

1.1 – Storage Explorer with an FC SAN

When working in a Fibre Channel (FC) SAN, Storage Explorer will show all the FC switches in your storage fabric, with details about what is connected to each port of each switch.

It will also show information about other servers connected to the storage fabric, including information about HBAs and LUNs. To do that, Storage Explorer will benefit from the FC registration service, which allows other hosts to register with the FC switch. Once Storage Explorer discovers other Windows machines, it will connect to them via WMI to gather additional information.

Storage Explorer does not need to run on a machine with an FC HBA but can connect remotely to another machine with an FC HBA. Once connected to that machine, it can gain access to the FC SAN and perform the discovery steps described.

Here’s a couple of sample screenshots of Storage Explorer in an FC SAN:

1.2 – Storage Explorer with an iSCSI SAN

When working in an iSCSI SAN, Storage Explorer will show information about Discovery Domains, iSCSI Target Portals and nodes registered with your iSNS server.

It will also show each server connected to the iSCSI storage fabric, including information about initiators, targets and LUNs.

Storage Explorer will perform discovery of iSCSI fabrics by connecting to the iSNS server and subsequently using WMI to gather more information from each discovered Windows machine.

Here’s a sample screenshot of Storage Explorer in an iSCSI SAN:

2 – Known Issues

Storage Explorer uses a number of different methods to discover information about your storage fabric and your servers.

However, it’s possible that it might not show all the expected information.

I tried to compile here a list of common issues related to Storage Explorer.

2.1 – iSCSI without iSNS

In an iSCSI environment, you will need a properly configured iSCSI Initiator, including a reference to your iSNS Server. This is required for the iSCSI discovery in Storage Explorer to work.

If you don’t have an iSNS server in your network or if the computer running Storage Explorer is not able to connect to the iSNS Server, you won’t see the iSCSI fabric information in Storage Explorer.

Please note that similar issues will occur if your computer is configured to connect to the iSNS server but somehow cannot resolve the iSNS server name (DNS configuration) or cannot connect to it (network issues, firewall configuration).

Also note that each node (iSCSI Targets and iSCSI Initiators) needs to be properly configured to connect and register with the iSNS server for everything to work correctly.

If you don’t already have an iSNS server in your network, you can install the Microsoft iSNS Server on a computer running Windows Server 2003 or Windows Server 2008.

For Windows Server 2003, download the x86 or IA64 version from http://www.microsoft.com/downloads/details.aspx?familyid=0DBC4AF5-9410-4080-A545-F90B45650E20&displaylang=en. If you are running an x64 edition of Windows Server 2003, you should download and install the x86 version of the iSNS server.

For Windows Server 2008, an iSNS Server is already included in the product. Just use Windows Server 2008 Server Manager to add the “Internet Storage Name Server” feature, available in the x86, x64 and IA64 editions.

2.2 – FC Switch blocking CT commands

Storage Explorer uses CT commands (FC-GS-4 spec) to query FC switches for fabric information. Only Fabric switches are supported.

Certain switches are pre-configured not to respond to CT commands and this will prevent Storage Explorer from showing any information about the FC fabric.

You can find additional information about these CT command and a link to the latest FC-GS-4 specification at http://www.t11.org/t11/stat.nsf/upnum/1505-d

Some switches do not support any CT Passthrough commands by default, thus preventing Storage Explorer from showing any fabric or server information.

Please note that this might not affect all hardware revisions and/or models of an FC switch.

If you find that appropriate, you can reconfigured your switch by changing from the closed mode (default) to open mode (not default).

Please check with your switch vendor before making any modifications to your default configuration and validate this in a test environment first.

2.3 – HBA blocking CT commands

Some HBAs are configured by default for FC-AL (only), and this will cause them not to send the CT commands required for discovery.

Please note that this might not affect all hardware revisions and/or models of an HBA.

You will likely be able to fix this by updating the HBA software and/or reconfiguring it to properly send out the CT commands.

Please check with your HBA vendor before making any modifications to your configuration and validate this in a test environment first.

Please note also that Microsoft does not support the use of FC-AL for most applications or for booting. You can check details at http://support.microsoft.com/kb/317162 and http://support.microsoft.com/kb/305547.

2.4 – Cannot connect to servers via WMI

When obtaining additional information about the servers, Storage Explorer uses WMI to connect and query the servers.

If your server cannot resolve the names of the other servers (DNS configuration) or cannot connect to the other servers via WMI (network issues, firewall configuration), you will see no details for those servers.

Storage Explorer will need to resolve the server names as returned by the FC switch (if Fibre Channel is used) or the iSNS server (if iSCSI is used).

You can also run into similar issues due to restricted permissions not allowing access to the required WMI classes.

The WMI classes used by Storage Explorer are not new in Windows Server 2008 (they were introduced with Windows Server 2003 SP1). These classes are supported by the WDK and the inbox drivers.

Additional information about the WMI information queried by Storage Explorer can be found at: http://msdn2.microsoft.com/en-us/library/ms807117.aspx

2.5 – Directly-attached SCSI devices (includes SAS, Parallel SCSI, Virtual SCSI)

Storage Explorer will not list any information about directly-attached SCSI drives or arrays, since there is no switch capable of providing fabric information via CT commands (technically, there is no fabric).

This applies to directly attached SAS disks, Parallel SCSI disks, directly-attached FC or SAS arrays, Virtual SCSI disks in a Hyper-V environment or any other SCSI disk connected without iSCSI or a fibre channel switch.

Those directly attached disks will show in Disk Management. The directly attached arrays can be managed through Storage Manager for SANs (with their VDS Hardware Provider installed). However, they will not show in Storage Explorer.

2.6 – Incompatibilities between FC switches or between switches and HBAs

Certain incompatibilities between HBAs and fibre channel switches can also result in incomple