The Virtual Machine Manager Self-Service Portal 2.0 (VMMSSP) is a fully supported, partner-extensible solution that can be used by customers to pool, allocate, and manage their compute, network and storage resources to deliver the foundation for a private cloud platform in their datacenter. VMMSSP (also referred to as the self-service portal) is a fully supported, partner-extensible solution built on top of Windows Server 2008 R2, Hyper-V, and System Center VMM. You can use it to pool, allocate, and manage resources to offer infrastructure as a service and to deliver the foundation for a private cloud platform inside your datacenter. VMMSSP includes a pre-built web-based user interface that has sections for both the datacenter managers and the business unit IT consumers, with role-based access control. VMMSSP also includes a dynamic provisioning engine. VMMSSP reduces the time needed to provision infrastructures and their components by offering business unit “on-boarding,” infrastructure request and change management. The VMMSSP package also includes detailed guidance on how to implement VMMSSP inside your environment.

Please Note: This early release of Windows 7 and Windows Server 2008 R2 SP1 Beta is not available for home users. The SP1 Beta does not provide new end-user features, and installation is not supported by Microsoft.

Windows 7 and Windows Server 2008 R2 SP1 Beta helps keep your PCs and servers on the latest support level, provides ongoing improvements to the Windows Operating System (OS), by including previous updates delivered over Windows Update as well as continuing incremental updates to the Windows 7 and Windows Server 2008 R2 platforms based on customer and partner feedback, and is easy for organizations to deploy a single set of updates.

Windows 7 and Windows Server 2008 R2 SP1 Beta will help you:

• Keep your PCs supported and up-to-date
• Get ongoing updates to the Windows 7 platform
• Easily deploy cumulative updates at a single time
• Meet your users' demands for greater business mobility
• Provide a comprehensive set of virtualization innovations
• Provide an easier Service Pack deployment model for better IT efficiency

Hi,

We are going to talk about a new feature in Windows Server 2008 R2 for Failover Clustering, ETW tracing.  With this added functionality, we have provided a mechanism of tracing why NLB has decided to drop or accept a given network packet.

This blog provides the following information on the new ETW tracing for NLB delivered in Windows Server 2008 R2.

·         Overview of ETW Tracing

·         How to Setup ETW Tracing

·         How to Enable, Disable and View the Traces

·         How to Uninstall ETW Tracing Manifest

·         Examples of Tracing Output

Details on how to interpret the results and use them for advanced debugging purposes will be covered in the future blog posts.

Overview of ETW Tracing

ETW is best described by the following MSDN article:

Event Tracing for Windows (ETW) is a general-purpose, high-speed tracing facility provided by the operating system. Using a buffering and logging mechanism implemented in the kernel, ETW provides a tracing mechanism for events raised by both user-mode applications and kernel-mode device drivers. Additionally, ETW gives you the ability to enable and disable logging dynamically, making it easy to perform detailed tracing in production environments without requiring reboots or application restarts.

NLB leverages this infrastructure to provide the end users with more detailed information regarding why packets are accepted or rejected by NLB.  While ETW is designed and implemented with performance in mind, you want to be aware that these logs consume storage space.  For example, a server handling 100 connections per second, could fill up many MB of data in less than a minute due to the detailed level of analysis it is doing, so it is important to be aware of this if you plan to run ETW tracing for extended periods of time.  Below, in the installation section, you can see the command line for finding out where the ETW log file is located and how to delete it when done with debugging.

How to Setup ETW Tracing

You can find a manifest file here: http://blogs.msdn.com/clustering/pages/9944942.aspx.  The text on that page should be saved as networkloadbalancing-core-diagnostic.events.man and copied to your NLB cluster nodes.  

Important: this is an unsupported script, please use this script at your own risk.  Microsoft’s Customer Support Services (CSS/PSS) will not support issues associated with this script.

Then run the following command from the directory where you copied the manifest file:

> wevtutil im networkloadbalancing-core-diagnostic.events.man

Note that this needs to be done from an elevated console window.  The above command will only register the NLB manifest.  The tracing is not yet being collected, but the following sections describe how to do this.

How to Enable, Disable and View the Traces

On the NLB cluster node you can to collect traces through the UI or Command Line.

UI (Event Viewer – eventvwr.msc)

·         Enable Analytics and Debugging Logs (one time)

·         Make sure you’ve installed the manifest

·         Click “View” menu and select “Show Analytic and Debug Log”

·         To start tracing.

·         Navigate to the channel: Events Viewer\Applications and Services Logs\Microsoft\Windows\NLB\Diagnostics.  Right click on the channel and select “Enable Log”.

·         Run your scenario

·         To stop and view collected events

o   Navigate to the channel. Right click on the channel and select Disable Log. You will now see events show up in the list.

·         At this point you should see the NLB ETW tracing in the Diagnostics pain on the middle of the screen.

Command Line (Event Viewer - wevtutil.exe)

·         To see provider information:

           >  wevtutil gl Microsoft-Windows-NLB/Diagnostic

This tells us that the ETW tracing file that is being generated is stored at:

%SystemRoot%\System32\Winevt\Logs\Microsoft-Windows-NLB%4Diagnostic.etl

·         To see statistics:

> wevtutil gli Microsoft-Windows-NLB/Diagnostic

·         To start use:

> wevtutil sl Microsoft-Windows-NLB/Diagnostic /e:true /q

·         To stop use:

> wevtutil sl Microsoft-Windows-NLB/Diagnostic /e:false /q

·         To view events as a text file first stop the provider and then use:

> wevtutil qe Microsoft-Windows-NLB/Diagnostic /f:text > events.txt

How to Uninstall the NLB Tracing Manifest

From an elevated console window, run:

> wevtutil um networkloadbalancing-core-diagnostic.events.man

Example of Tracing Output

Node1: Node 1 accepted the connection

1.  Log Name:      Microsoft-Windows-NLB/Diagnostic

2.  Source:        Microsoft-Windows-NLB-Diagnostic

3.  Date:          10/30/2009 2:36:50 PM

4.  Event ID:      1

5.  Task Category: Filtering Receive Accept

6.  Level:         Information

7.  Keywords:      Accept,Receive,Filtering,NLB

8.  User:          N/A

9.  Computer:      G10C3N8X64N2.ctdev.nttest.microsoft.com

10.         Description:

NLB cluster on interface {10000000-0000-0006-7b00-310030003000} received traffic from 10.30.4.198:63691 destined to 10.30.4.157:5001 [protocol: TCP (0x0), flags: 0x2]. This cluster node will accept this traffic (reason: Unconditional Ownership). Source port 63691, destination port 5001, and protocol TCP have been used for the accept/drop decision.

In the above tracing from Node1, we see that the connection we defined in our user scenario is being accepted (line 5). The event ID “1” (line 4) indicates that this event pertains to an “Accepted Connection”.  The highlighted green segment depicts that the reason this connection was accepted was that this packet was “unconditionally owned” by the current node.  We will see more reasons in future blog posts regarding debugging NLB with ETW tracing.

Node2: Node 2 rejected the connection

1.  Log Name:      Microsoft-Windows-NLB/Diagnostic

2.  Source:        Microsoft-Windows-NLB-Diagnostic

3.  Date:          10/30/2009 2:36:50 PM

4.  Event ID:      2

5.  Task Category: Filtering Receive Drop

6.  Level:         Information

7.  Keywords:      Drop,Receive,Filtering,NLB

8.  User:          N/A

9.  Computer:      G10C3N8X64N1.ctdev.nttest.microsoft.com

10.         Description:

NLB cluster on interface {10000000-0000-0006-7b00-300036004200} received traffic from 10.30.4.198:63691 destined to 10.30.4.157:5001 [protocol: TCP (0x0), flags: 0x2]. This cluster node will drop this traffic (reason: Owned Elsewhere). Source port 63691, destination port 5001, and protocol TCP have been used for the accept/drop decision.

Similarly, Node2 has rejected this packet, and the reason in green highlighting shows that this packet was “Owned Elsewhere” (Node1 as per above).  The even ID “2” (line 4) can be used in event viewer to filter for only dropped packets.

Thanks,

Rohan Mutagi & Ahmed Bisht

Clustering and High-Availability Team

Microsoft

Happy Holidays Cluster Fans!

The System Center Data Protection Manager (DPM) 2010 Beta is now available for download and testing. 

This supports backing up your Cluster Shared Volume (CSV) disks, in addition to the following Clustering and Hyper-V features:

·         Supports Windows Server from 2003 through 2008 R2 including Hyper-V Server 2008 and 2008 R2

·         Protection of Live Migration-enabled servers running on CSV in Hyper-V R2

·         Flexibility to protect virtual machines from Windows guests or from the hypervisor host

·         Host-based backups will now enable single-item restores from within the VHD

·         Ability to restore virtual machines to an alternative host

·         Enhanced disaster recovery options for long-distance data protection and business continuity initiatives

Try the Beta now at: http://www.microsoft.com/systemcenter/dataprotectionmanager/en/us/2010beta-overview.aspx.

Documentation of how to use DPM 2010 with CSV is included with the download package.

[2/23/10] Update: The DPM 2010 Release Candidate (RC) is now available!  Download it here: http://connect.microsoft.com/site840/Downloads/DownloadDetails.aspx?DownloadID=26452

More information at the DPM team blog: http://blogs.technet.com/systemcenter/archive/2010/02/15/data-protection-manager-2010-release-candidate-now-available.aspx

 

 

We still strongly recommend using a hardware snapshot provider for protecting CSV workloads.  The rationale for this recommendation is described here: http://blogs.technet.com/asim_mitra/archive/2009/12/11/snapshot-provider-considerations-while-backing-up-a-csv-cluster.aspx

 

If you have any issues, comments or feedback, you can report them to Microsoft’s Customer Service and Support (CSS), your Technical Account Manager (TAM) or discuss it in the DPM Newsgroup.

 

Thanks,

Symon Perriman
Program Manager II
Clustering & High-Availability
Microsoft

 

read full article at source

Are Dynamic Disks supported on Failover Clusters? 

Yes, they are, however support is not provided natively in-box in Windows for Failover Clusters.  It requires an add-on product from Symantec called Storage Foundation for Windows to enable support of Dynamic Disks on Windows Server Failover Clusters.  This is also true for the recently released Windows Server 2008 R2.  You can learn more about the Storage Foundation for Windows product here:

http://www.symantec.com/business/storage-foundation-for-windows

This KB article also discusses support for Dynamic Disks on Windows Server Failover Clusters: http://support.microsoft.com/kb/237853  

Now let me ask you…why do you want to use Dynamic Disks? 

Dynamic Disks do provide a number of different features, so we like to understand why you use them.

I commonly hear two answers when I ask this question:

•         “I need to have large partitions”

•         “I need to be able to dynamically grow partitions”

 Well, did you know that you actually don’t need Dynamic Disks to accomplish those?

Large Partitions

While Basic disks that use MBR partition table only support 2 TB partitions, GUID partition table (GPT) disks enable partitions that are greater than 2 TB and are fully supported on Failover Clusters, using Windows Server 2008 and 2008 R2.  If you happen to still be using Windows Server 2003, you can add support for GPT based disks with a post Service Pack 2 hotfix, available at:  http://support.microsoft.com/kb/919117

If you want to learn more about the advantages of GPT disks, here is a good FAQ:  http://www.microsoft.com/whdc/device/storage/GPT_FAQ.mspx 

So, you can create large volumes with Basic disks, and there is no need for Dynamic Disks. 

Dynamically Growing Partitions

With Windows Server 2003, 2008 and 2008 R2 you can dynamically increase the size of a partition on a Failover Cluster.  In Windows Server 2003 this needed to be done via the command line with DiskPart, as described in this KB article: http://support.microsoft.com/kb/304736

In Windows Server 2008 and 2008 R2, there is a simple right-click option in the Disk Management (DiskMgmt.msc) snap-in to “Extend Volume”.  Another new option in Windows Server 2008 R2 is that you can now not only extend a volume, but you can also “Shrink Volume”. 

So, you can dynamically grow or shrink volumes with Basic disks, no need for Dynamic Disks.

So, is there really a need for Dynamic Disks?

There are fewer reasons why you might need Dynamic Disks these days, since much of this functionality is now possible with Basic disks.  What are the reasons why you might actually need them?  That is fair to discuss as well and I commonly hear two answers:

•         “I want to use Software RAID”

•          “I need to be able to span a single volume over multiple LUNs”

Software RAID & Spanning Volumes

With Failover Clustering it requires external storage (Fibre Channel, iSCSI or SAS), so most customers choose to go with the Hardware RAID they already have in the storage array instead of using Software RAID.  With spanning volumes, that really is a matter of how you do your SAN management when increasing capacity.  Most storage arrays these days support dynamically expanding the size of a LUN.  As I said earlier, with Basic disks you can dynamically increase the size of that volume to match the new larger LUNs.  However some people prefer to concatenate LUNs and span a single volume over multiple LUNs, then they just create a new LUN and span the volume over that new LUN when they want to add capacity.  For IT departments that are segmented, I sometimes hear this is ‘easier’ for SAN admins to just create a new LUN, opposed to tracking down the right LUN and expanding it.  I have no right or wrong answer for you here, it’s a matter of how you manage your SAN’s.

I hope this helps in understanding that Dynamic Disks are supported with Windows Server Failover Clustering with the add-on product from Symantec Storage Foundations for Windows.  Microsoft has continually strived to build functionality into Windows that provides ease of use and convenience for server administrators.  This is the case with the ability to dynamically expand and shrink volumes and create large volumes using GPT formatted disks.  As mentioned, using Dynamic Disks do provide a great add-on product that extends the functionality of Failover Clustering.

Hi Cluster Fans,

We have recieved many questions around the difference in behavior between Windows Server 2003 MSCS and Windows Server 2008 (and R2) Failover Clustering as it relates to the file shares and the new scoping behavior.  Chuck Timon’s article will help you understand the differences and the change in behavior: http://blogs.technet.com/askcore/archive/2009/01/09/file-share-scoping-in-windows-server-2008-failover-clusters.aspx.

With that cleared up, I’ve seen a few requests to get the old behavior and to share folders on multiple scopes.  You can do that by adding multiple client access points (CAP) to your highly available File Server.  This blog post illustrates how this can be achieved.

I’m starting with a HA File Server ahmedbc4FSy1 as you see here in this snapshot from Failover Cluster Manager.  Note that I’ve already populated those with some file shares.

To add a new scope, I can easily add a CAP to the same group from the Actions pane:

The name I’ll use is ahmedbc4FSnew.  Once done, I see multiple CAPs in the cluster group.

When I browse to \\ahmedbc4FSnew, I do not see the same shares I see when I browse to \\ahmedbc4FSy1.  Why?  Check out the file share scoping information that is described in the linked article.

If you do want to share the same shares in that new scope, you can easily do that in the GUI by selecting the appropriate scope name when you “Add a shared folder”:

Once you run through the “Provision a Shared Folder Wizard (ahmedbc4FSnew)” wizard, you’ll have the share you in that new scope:

If you have a handful of shares to share in the new scope, you can easily do that through the GUI.  But, if you have many shares and you’d like to script this action, here is how it can be done.

What you’ll need before you run the script?

-          Run this in PowerShell v2.  You’ll need v2 because I use the new and (may I add) very powerful PowerShell CMDlet Add-Type.  If you have Windows Server 2008 R2, you have this in-box already.

-          Make sure you have the FailoverClusters PowerShell module installed.  If you are running this on a Windows Server 2008 R2 Failover Cluster node, you already have this in-box.

-          Run this in an elevated window.  If you start the PowerShell window using the “Windows PowerShell Modules” shortcut, that takes care of this.

The script is available here: http://blogs.msdn.com/cfs-filesystemfile.ashx/__key/CommunityServer-Blogs-Components-WeblogFiles/00-00-00-73-13/3750.share.txt

Copy the contents of the script into file and rename it to share.ps1, change the $cluster, $from, and $to variables on the top of the script, and run the script to create the shares in the new scope.

Enjoy!

Ahmed Bisht
Senior Program Manager
Clustering & High-Availability
Microsoft