Generating 100% CPU with calc or PowerShell

Occasionally when testing something I want to generate 100% CPU load on a Windows computer. There are several utilities out there to do this, but that implies you have the utility on hand and are comfortable running it on the server. A colleague of mine (thanks Mark S.) showed me this nifty trick of using calc.exe to generate 100% CPU. The best thing about this is that every standard Windows OS installation has calc.exe.

This post provides two methods of generating 100% CPU load, the original calc.exe method, and a simple one line PowerShell command to do the same thing from the command-line (locally or on a remote server with PS v1 and psexec). Note that there may be a better method with PowerShell, I simply scripted the same operation calc was performing.

On dual-CPU/core computers this uses 100% of one CPU/core. To use more than that, calc or the PowerShell command can be run more than once, and Windows by default will run the new process on another less-busy CPU/core.

One practical application of this is to load-test a VMware VI3 cluster, generating 100% CPU on one or more VMs to see how ESX and DRS/VC handles the load. I have also used this in the past when testing multi-threaded applications and processor affinity to see how Windows allocates a processor.

calc.exe

Use calc to calculate the factorial of a number - the product of all integers from 1 up to and including the number specified, eg 5! = 1x2x3x4x5

1. Run calc.exe and switch to scientific mode
2. Type a large number (eg. 12345678901234567890), press the 'n!' button.
3. Calc will ask to confirm after warning this will take a very long time
4. 100% CPU utilisation will now occur (essentially forever)
   

PowerShell
 

Using the largest int32 positive integer, calculate the factorial to generate 100% CPU utilisation
$result = 1; foreach ($number in 1..2147483647) {$result = $result * $number};

Depending on how fast the CPU is, this could finish, so a loop to run the command above 2 billion times:
foreach ($loopnumber in 1..2147483647) {$result=1;foreach ($number in 1..2147483647) {$result = $result * $number};$result}

If you want to see how long the command takes to run:
Measure-Command {$result = 1; foreach ($number in 1..2147483647) {$result = $result * $number}}

Using the command-line then provides the ability to run the command remotely. To use psexec to remotely execute powershell v1 factorial to generate 100% CPU:
psexec \\%computername% /s cmd /c "echo. | powershell $result = 1; foreach ($number in 1..2147483647) {$result = $result * $number}"

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin. 

Read more!

Converting VHD to VMDK SCSI for ESX

I had problems converting a 2003 server VHD to a vmdk that I could import into a VM running on ESX. I used WinImage to convert eh VHD->VMDK, but it seems WinImage creates the VMDK as an IDE device, which is unsupported by ESX. I'm sure there are better ways to do this, such as satisfying whatever the pre-requisites are to getting VMware converter to automatically inject the drivers, but it was interesting doing it manually.

Below is information on the process that I thought would have worked automatically, followed by the manual steps I took to make it work.

To convert the vmdk, the following process was first tried to get VMware converter to convert the IDE disk to something ESX would recognise:

1. 1. Use WinImage to create the vmdk from the vhd
2. 2. Use a VMware workstation VMX, including the disk as an IDE device. (a modified vmx is fine you don’t actually need VMware workstation)
3. 3. Use VMware converter to import the workstation VMX into VC

I thought this would have been enough, but the VMware Converter process failed at 95% saying that it couldn’t find symmpi.sys. Symmpi.sys is the LSI Logic SCSI driver for the virtual SCSI adapter. I’m guessing that running VMware converter should automatically inject the drivers into the vmdk but couldn’t in this scenario (maybe because my local PC didn’t have the driver, or maybe because the driver cache cab files containing symmpi.sys weren’t on the target vmdk).

Powering on the machine resulted in a stop 0x7b inaccessible disk error. To manually fix the problem, I then:

1. Added the disk to another VM. When starting the VM it warned that the new disk was created for LSI not buslogic. I said yes to convert to buslogic (which this VM was using as opposed to LSI).

The drive was then accessible through the VM, and I added the drivers (file and registry):

1. Copied the driver file to the drivers directory: copy "\\%workingVM%\c$\WINDOWS\system32\drivers\symmpi.sys" "%mountedDrive%:\WINDOWS\system32\drivers"
2. Copied the driver cache files to the machine from a working 2003: copy "\\%workingVM%\c$\WINDOWS\Driver Cache\i386\*.*" "%mountedDrive%:\WINDOWS\Driver Cache\i386"
3. Exported the HKLM\SYSTEM\CurrentControlSet\Services\symmpiregistry and HKLM\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_1000&dev_0030 entries from a working server as regedit4 files (not Unicode).
4. Loaded the %mountedDrive%:\windows\system32\config\system registry hive on the disk to HKLM\VM: reg load HKLM\VM %mountedDrive%:\windows\system32\config\system
5. Modified the reg files to match the path the hive was loaded to (eg HKLM\VM\controlset001 instead of HKLM\system\currentcontrolset). The modified reg files are included below.
6. Imported the registry files which modified the loaded system hive on the disk
7. Disconnected the hive, shutdown the VM and disconnected the disk from the VM and reattached to the server created during the VMware Converter process
8. Turned on the server and was prompted to convert the disk type back to LSI (which I did).
9. The server started normally

Note that the conversion between buslogic and LSI logic in both directions were only required because the virtual machine that I mounted the disk on had a different adapter type.

---

REGEDIT4
[HKEY_LOCAL_MACHINE\VM\ControlSet001\Services\symmpi]
"ErrorControl"=dword:00000001
"Group"="SCSI miniport"
"Start"=dword:00000000
"Type"=dword:00000001
"ImagePath"=hex(2):73,79,73,74,65,6d,33,32,5c,44,52,49,56,45,52,53,5c,73,79,6d,\
6d,70,69,2e,73,79,73,00
"Tag"=dword:00000021

[HKEY_LOCAL_MACHINE\VM\ControlSet001\Services\symmpi\Parameters]
"BusType"=dword:00000001

[HKEY_LOCAL_MACHINE\VM\ControlSet001\Services\symmpi\Parameters\PnpInterface]
"5"=dword:00000001

[HKEY_LOCAL_MACHINE\VM\ControlSet001\Services\symmpi\Enum]
"0"="PCI\\VEN_1000&DEV_0030&SUBSYS_00000000&REV_01\\3&61aaa01&0&80"
"Count"=dword:00000001
"NextInstance"=dword:00000001

REGEDIT4
[HKEY_LOCAL_MACHINE\VM\ControlSet001\Control\CriticalDeviceDatabase\pci#ven_1000&dev_0030]
"Service"="symmpi"
"ClassGUID"="{4D36E97B-E325-11CE-BFC1-08002BE10318}"

References:
Injecting SCSI controller device drivers into Windows
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=1005208

Troubleshooting a virtual machine that fails to boot with STOP 0x7B error
http://kb.vmware.com/selfservice/viewContent.do?externalId=1006295&sliceId=1

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

VMware VI3 iSCSI with multiple non-HBA NICs

While researching iSCSI on VI3, I came across some interesting information when using the ESX iSCSI software initiator that would be applicable to many installations, highlighting a potential bottleneck.

The short version is that if you’re using the iSCSI software initiator connecting to a single iSCSI target, multiple uplinks in an ESX network team for the VMKernel iSCSI port would not be used for load balancing.

This can be easily proven by connecting to the service console and running esxtop (n) to view the traffic for individual network adapters. Assuming your storage is in use, one or more physical uplinks for the vSwitch handling iSCSI should be showing traffic. You can also use resxtop through the RCLI on ESXi.

Why this happens

My understanding is that current ESX software initiated iSCSI connections have a 1:1 relationship between NIC and iSCSI targets. An iSCSI target in this sense is a connection to the IP-based SAN storage, not LUN targets. This limitation applies when the SAN presents a single IP address for connectivity.

VI3 software initiated iSCSI doesn’t support multipathing, which within ESX leaves only load balancing the physical uplinks in a team. Unfortunately, that leaves load balancing up to the vSwitch load balancing policy exceptions. I don’t believe any of the three choices fit most scenarios when connectivity to the iSCSI is through a single MAC/IP:

• Route based on the originating virtual switch port ID, based on virtual port ID, of which there is only one VMKernel iSCSI port
• Route based on source MAC hash, based on source MAC, of which there is only one
• Route based on IP hash, based on layer 3 source-destination IP pair, of which there is only one (VMKernel -> iSCSI virtual address). I don’t think this is a generally recommended load balancing approach anyway

Link aggregation

The VI3 SAN Deploy guide does state that one connection is established to each target. This seems to indicate one connection per LUN target, but the paragraph starts with software iSCSI and switches half way through to discuss iSCSI HBA’s.

I’m still unsure of whether software iSCSI has multiple TCP sessions, one per target (I don’t believe this is the case). The blog referenced below also talks about 802.3 link aggregation which states the ESX 3.x software initiator does not support multiple TCP sessions.

However, if multiple TCP sessions were being established for the iSCSI software initiator to a single target IP address, this opens the possibility of link aggregation at the physical switch. When using 802.3ad LACP in this IP-IP scenario, the switches would have to distribute connections based on the hash of TCP source/destination ports, rather than just IP/MAC.

The following excerpt from the SAN deploy guide:

Software iSCSI initiators establish only one connection to each target.

Therefore, storage systems with a single target that contains multiple LUNs have all LUN traffic routed through that one connection. In a system that has two targets, with one LUN each, two connections are established between the ESX host and the two available volumes. For example, when aggregating storage traffic from multiple connections on an ESX host equipped with multiple iSCSI HBAs, traffic for one target can be set to a specific HBA, while traffic for another target uses a different HBA. For more information, see the “Multipathing” section of the iSCSI SAN Configuration Guide. Currently, VMware ESX provides active/passive multipath capability. NIC teaming paths do not appear as multiple paths to storage in ESX host configuration displays, however. NIC teaming is handled entirely by the network layer and must be configured and monitored separately from ESX SCSI storage multipath configuration.

VI4/vSphere

Excerpts from the following blog, indicate that changes in vSphere for software iSCSI to support multiple iSCSI sessions, allowing multipathing or link aggregation, which would allow separate iSCSI TCP sessions to be spread across more than one NICs (depending on how many iSCSI sessions).

http://virtualgeek.typepad.com/virtual_geek/2009/01/a-multivendor-post-to-help-our-mutual-iscsi-customers-using-vmware.html

The current experience discussed above (all traffic across one NIC per ESX host):

VMware can’t be accused of being unclear about this. Directly in the iSCSI SAN Configuration Guide: ESX Server‐based iSCSI initiators establish only one connection to each target. This means storage systems with a single target containing multiple LUNs have all LUN traffic on that one connection, but in general, in my experience, this is relatively unknown.

This usually means that customers find that for a single iSCSI target (and however many LUNs that may be behind that target – 1 or more), they can’t drive more than 120-160MBps. This shouldn’t make anyone conclude that iSCSI is not a good choice or that 160MBps is a show-stopper. For perspective I was with a VERY big customer recently (more than 4000 VMs on Thursday and Friday two weeks ago) and their comment was that for their case (admittedly light I/O use from each VM) this was working well. Requirements differ for every customer.

The changes in vSphere:

Now, this behavior will be changing in the next major VMware release. Among other improvements, the iSCSI initiator will be able to use multiple iSCSI sessions (hence multiple TCP connections). Looking at our diagram, this corresponds with “multiple purple pipes”for a single target. It won’t support MC/S or “multiple orange pipes per each purple pipe” – but in general this is not a big deal (large scale use of MC/S has shown a marginal higher efficiency than MPIO at very high end 10GbE configurations) .

Multiple iSCSI sessions will mean multiple “on-ramps” for MPIO (and multiple “conversations” for Link Aggregation). The next version also brings core multipathing improvements in the vStorage initiative (improving all block storage): NMP round robin, ALUA support, and EMC PowerPath for VMware which integrates into the MPIO framework and further improves multipathing. In the spirit of this post, EMC is working to make PowerPath for VMware as heterogeneous as we can.

Together – multiple iSCSI sessions per iSCSI target and improved multipathing means aggregate throughput for a single iSCSI target above that 160MBps mark in the next VMware release, as people are playing with now. Obviously we’ll do a follow up post.

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

Vista Sidebar Gadget for SiteMeter

This post provides a Vista Sidebar gadget to report on sitemeter information for a web site being monitored. In a previous post I’ve provided a command-line PowerShell method to retrieve the same information, but I thought I’d try this GUI thing people keep talking about.

This is a very simple Vista sidebar gadget, it doesn’t have settings, or fly-outs, or links, or any other bits of cleverness, it was really just my first look into how Vista gadgets work. All I did was take the Microsoft hello-world example gadget and add a bit of javascript to (badly) scrape the sitemeter web page.

The gadget:

1. Has a transparent PNG background image and writes the text in white on two lines, with a gadget size of 128x64
2. Uses the MSXML DOM to issue a HTTP GET and for the sitemeter URL, using an asynchronous callback
3. Parses the HTTP response, looking for the first index of the word ‘Today’ and extracts the number
4. Updates the second field in the gadget with the current date/time to tell when the last successful get occurred
5. Uses the SetTimeout method to sleep for an hour before calling the getData() function again

What the gadget doesn’t do that could make this better:

1. Have the URL and timeouts stored in a settings file to save having to modify the JS when scraping a different URL or changing the timeout.
2. Have a flyout or something which shows the other summary information on the sitemeter page
3. Use a separate CSS and init() function rather than the in-line code from the example

To create this:

1. Download the gadget samples from http://www.microsoft.com/downloads/details.aspx?FamilyID=b1e14e4f-3108-4c57-8b78-1157ca40dcc2
2. Copy SDK_HelloWorld.gadget to *.zip
3. Unzip the contents of the gadget zip file to a working directory and remove the read-only attribute from the files
4. Create a transparent PNG background 64x64 in size (or use the one provided in this post), and overwrite Background.png
5. Update images\aerologo.PNG with the png from this post
6. Update HelloWorld.html with the contents below:
7. Update the height and width to 128x64
   - Add the script tag:
   - Update the in-place init() funciton to call getData()
   - Create SiteMeter.js with the contents below
8. Create a new directory and copy all of the gadget files to "%Systemdrive%\users\%username%\appdata\local\microsoft\Windows Sidebar\gadgets\SiteMeterCounter.gadget"
9. Update the URL in SiteMeter.js with the page to scrape
10. Add the gadget

HelloWorld.html

<!--
 *************************************************************************
 *
 * Name: SiteMeter.html
 *
 * Description: 
 * Simple SiteMeter counter
 * Displays the current count of today's visitors from the provided SiteMeter URL
 * 
 *
 * Modified from the 'Hello World' Microsoft example 
 ************************************************************************
-->
<html xmlns="http://www.w3.org/1999/xhtml">
    <head>
     <title>SiteMeter Count</title>
     <style type="text/css">
      body
      {
          width: 128px;
          height: 64px;
                        font-family: calibri;
                        color: white; 
      }
      #gadgetContent
      {
          width: 128px;
                        top: 3px;
          text-align: center;
                        overflow: hidden;
                        font-weight: bold;
                        font-size: 14px;
      }
      #lastUpdate
      {
          width: 128px;
                        top: 20px;
          text-align: center;
                        overflow: hidden;

                        font-size: 9px;
      }
     </style>
     <script type="text/javascript" src="SiteMeter.js"></script>
     <script type="text/jscript" language="jscript">


        // --------------------------------------------------------------------
        // Initialize the gadget.
        // --------------------------------------------------------------------
     function init()
     {
         var oBackground = document.getElementById("imgBackground");
         oBackground.src = "url(images/background.png)";
                getData();
        }
     </script>
    </head>
 
<body onload="init()">
    <g:background id="imgBackground">
 <span id="gadgetContent">-</span>
 <span id="lastUpdate">-</span>
 </g:background>
</body>
</html>

SiteMeter.js

var globalURL = "http://www.sitemeter.com/default.asp?a=stats&s=s451qaz2wsx";              // URL for lookup
var globalTimeoutId;
var globalError;
var XMLHttp;

function getData()
{
    try 
        { XMLHttp = new ActiveXObject("Msxml2.XMLHTTP"); 
    } 
    catch (e) 
        { XMLHttp = new ActiveXObject("Microsoft.XMLHTTP"); 
    }

    // Timeout, if call not come back in 30 seconds, abort with the default error message.
    globalTimeoutId = setTimeout(function() {
                                         XMLHttp.abort();
                                         document.getElementById("gadgetContent").innerHTML = "Timeout";
                                         }, 30000); 
        
    // Asynchronous get
    XMLHttp.open("GET", globalURL, true);

    XMLHttp.setRequestHeader("Content-Type","application/x-www-form-urlencoded");
    XMLHttp.setRequestHeader("Connection", "close");

    // Callback for when the page has loaded
    XMLHttp.onreadystatechange = parseData

    // Send the request
    XMLHttp.send(null);

}

function parseData()
{
    var Results;
    var td;

    gadgetContent.innerHTML = XMLHttp.status;

    if (XMLHttp.readyState == 4 && XMLHttp.status == 200)
    {

        var date = new Date();
        lastUpdate.innerHTML = date.getDate() + "/" + (date.getMonth() +1)  + "/" + date.getYear() + " " + date.getHours() + ":" + date.getMinutes() + ":" + date.getSeconds();

        globalError = 0;

        Results = XMLHttp.responsetext;
        if (Results.indexOf("Today") >= 0)
        {

            td = Results.substring(Results.indexOf("Today")+20, Results.indexOf("Today")+80);
            td = td.substring(td.indexOf("<font"), td.length);
            td = td.substring(0, td.indexOf("</font>")+7);

            gadgetContent.innerHTML = td;
        }
        else
        {   
            globalError = 1;
            document.getElementById("gadgetContent").innerHTML = "Error";
        }

        // Set a callback for the getData function in one hour
        clearTimeout(globalTimeoutId);
        globalTimeoutId = setTimeout(getData, 3600000);
    }

} 

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

Security with 2003 R2 FSRM quotas

This post provides information on several aspects of security with Windows Server 2003 R2 FSRM quotas, which you may come across if you use the previous two posts to implement FSRM quotas on a standalone server or MSCS clustered node.

LocalService Command Notification Task

If your quota has a notification task that runs a command, you may need to set the security of the executable or areas accessed by the command. By default, FSRM runs commands as the LocalService account - an account with restricted local permissions.

In this example, the command executed is the logentry.bat batch file from the previous post, which simply writes a log entry to a file. To allow the batch file to run as the localservice account – which is a member of the 'Authenticated Users' group, I set the following permissions:

• Add authenticated users:R to the root (not OICI - object inherit, container inherit) using SDDL with cacls
• Add authenticated users:R to c:\scripts to execute the logentry.bat file
• Add authenticated users:C to c:\logs to allow writing the log entry
• Ensure that cmd.exe can be executed (default permissions should suffice)

This was done with the following commands:

• cacls c:\ /S:"D:PAI(A;OICI;FA;;;BA)(A;;0x1200a9;;;AU)(A;OICI;FA;;;SY)"
• cacls c:\scripts /e /g "authenticated users":R
• cacls c:\logs /e /g "authenticated users":C

Note that while testing this, I was using localsystem (unrestricted local permissions) to verify that security was the issue, but in an MSCS cluster when failing over the virtual server from one cluster node to the other, the quota template reset itself to localservice instead of localsystem.

Before setting permissions to allow LocalService to run the script, this left the notification task not executing successfully. Depending upon what your command does you may require elevated local or remote privilege, for which you may want to use localsystem or networkservice.

Target Permissions preventing execution

When specifying a command to run as a notification task, 2003 R2 FSRM will not allow running a command which standard users have change/full control to, directly or through inheritance.

To me this seems like an unusual approach for an out of the box Microsoft product and isn't very intuitive, as in my lab inherited permissions from a parent directory allowing Users:F were causing the task to fail.


References

Implementing 2003 FSRM quotas Command-line
http://waynes-world-it.blogspot.com/2009/02/implementing-2003-fsrm-quotas.html

2003 FSRM and NTFS Quotas compared
http://waynes-world-it.blogspot.com/2009/02/2003-fsrm-and-ntfs-quotas-compared.html

LocalService Account
http://msdn.microsoft.com/en-us/library/ms684188(VS.85).aspx

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

Implementing 2003 FSRM quotas

This post provides information on implementing Windows Server 2003 FSRM quotas using the command-line dirquota.exe utility, creating a template and then applying that template to the filesystem using an autoquota. Example control files are provided to create the template, and a simple batch file to create a daily log file with quota notifications.

The first command below creates the soft 100MB quota template with three thresholds (85/99/150), and four notifications for those thresholds, two for email and one each for and command execution and event log entry. The second command creates an autoquota using the template on the specified remote server against the specified path. Note that in this example, the commands were run on a 64-bit physical server running MSCS, and the target server was a virtual cluster server (v01).

• dirquota template add /Remote:v01 /Template:Test_Quota /Limit:100mb /type:Soft /label:"Test Default Quota" /add-threshold:85 /add-notification:85,M,c:\admin\control\Test_Quota_Email.txt /add-threshold:99 /add-notification:99,M,c:\admin\control\Test_Quota_Email.txt /add-notification:99,C,c:\admin\control\Test_Quota_Command.txt /add-notification:99,E,c:\admin\control\Test_Quota_Event.txt /add-threshold:150 /add-notification:150,M,c:\admin\control\Test_Quota_Email.txt
• dirquota autoquota add /Remote:v01 /path:q:\folder1 /sourcetemplate:"Test_Quota"

Notes:

1. The use of 99% instead of 100% was intentional, as 100% is not a notification; it’s a limit, so the pre-defined variables are different. This is obvious in the subject of the email, where the ‘[Quota Threshold]’ variable isn’t resolved when it’s a 100% 'notification'.
2. The quota information is logged to \\p01\c$\logs\QuotaUsage_YYYYMMDD.log for 99% of quota usage, as well as sending an email to DiskUsageMonitor and logging an event on the cluster, and all quota information is available through the FSRM MMC snap-in.
3. Within a single email notification, an email can be sent to one or more administrators, and/or the person who took the limit over the threshold – the owner of the file. In the template below, emails will be sent to both users for all three thresholds, and administrators for the 150% notification. E-mail notifications will be limited to one per day for the same notification.
4. Any command can be run; in the example here a simple batch file is run that appends a log entry to a daily log file, providing an easy method to see quota alerts for each day.
5. The notifications aren’t triggered until first create, so if you apply quotas to existing data, the notifications won’t start appearing until new data is written.
6. A quirk with the 64-bit OS - creating the quota template only works with the 32-bit version of the dirquota.exe utility. If the physical server (p01 in the example above) were a 64-bit server, you would have to run the 32-bit dirquota.exe utility to create the template and autoquota (2003 enterprise R2 x64 SP1).

Configuration Files

Templates, quotas and autoquotas can all be created via command-line utilities. When creating templates with notifications, the information is supplied via control files. Example control files for running a command, logging an event, and sending an email are shown below.

Note the following global properties can be specified in each notification:

• Notification – m | e | c | r
• m - an e-mail notification
• e - an event log notification
• c - a command or script execution
• r - a report generation
• RunLimitInterval – The number of minutes to wait between sending notifications to save repeated unnecessary notifications. A setting of 0 indicates a notification will be sent on each trigger.

Test_Quota_Command.txt

Notification=c
Command=c:\windows\system32\cmd.exe
Arguments=/c c:\admin\scripts\logentry.bat "%Date%,%Time%,[Source Io Owner],[Quota Path],[Server],[Quota Limit MB] MB,[Quota Used MB] MB,[Quota Used Percent]"
MonitorCommand=Disable
Account=LocalService
LogResult=Enable
RunLimitInterval=0

Test_Quota_Event.txt

Notification=e
RunLimitInterval=1440
EventType=Warning
Message=Excessive usage by [Source Io Owner] on [Quota Path], shared on [Server]. Limit of [Quota Limit MB] MB, [Quota Used MB] MB in use ([Quota Used Percent]% of limit).

Test_Quota_Email.txt

Notification=m
RunLimitInterval=1440
To=[Source Io Owner Email]
From=FSRM@server.domain.com
ReplyTo=FSRM-DoNotReply@server.domain.com
Cc=DiskUsageMonitor@domain.com
Subject=[Quota Threshold]% quota threshold exceeded
Message=A file written by [Source Io Owner] has exceeded the [Quota Threshold]% quota threshold for the quota on [Quota Path] on server [Server]. \
\
The quota limit is [Quota Limit MB] MB, and [Quota Used MB] MB currently is in use ([Quota Used Percent]% of limit).\
\
\
\

Logging to File

I'm not sure why a method to append to a log file wasn't included in the GUI, but this batch file appends a one-line entry to a rolling log file:

:: LogEntry.bat

:: Write a log for quota alerts

::%Date%,%Time%,[Source Io Owner],[Quota Path],[Server],[Quota Limit MB] MB,[Quota Used MB] MB,[Quota Used Percent]%

Set AdminLog=C:\Logs

for /f "tokens=1-8 delims=/:. " %%i in ('echo %date%') do Set DateFlat=%%l%%k%%j
Set LogFile=%AdminLog%\QuotaUsage_%DateFlat%.log

Echo %~1 >> %LogFile%

References

2003 FSRM and NTFS Quotas compared
http://waynes-world-it.blogspot.com/2009/02/2003-fsrm-and-ntfs-quotas-compared.html

FSRM and NTFS Quotas in 2003 R2
http://waynes-world-it.blogspot.com/2008/06/fsrm-and-ntfs-quotas-in-2003-r2.html

Configuration files for notifications in File Server Resource Manager
http://technet2.microsoft.com/windowsserver2008/en/library/a4426339-5345-44d5-81b7-a35a703daaac1033.mspx?mfr=true

How to use File Server Resource Manager (FSRM) to configure the notification feature for File Screening Management in Windows Server 2003 R2
http://support.microsoft.com/kb/926092

File Server Resource Manager Protocol Specification
http://download.microsoft.com/download/9/5/E/95EF66AF-9026-4BB0-A41D-A4F81802D92C/%5BMS-FSRM%5D.pdf

Dirquota admin options
http://technet2.microsoft.com/windowsserver2008/en/library/14c2a340-54cf-46fa-8b0d-beed6c220c671033.mspx?mfr=true

LocalService Account
http://msdn.microsoft.com/en-us/library/ms684188(VS.85).aspx

Configuration files for notifications in File Server Resource Manager
http://technet2.microsoft.com/windowsserver2008/en/library/a4426339-5345-44d5-81b7-a35a703daaac1033.mspx?mfr=true

Create an auto quota
http://technet2.microsoft.com/WindowsServer/en/library/0de5535e-ef25-4ffa-a724-155573044ddc1033.mspx

Dirquota autoquota
http://technet2.microsoft.com/WindowsServer2008/en/library/2809c575-8d93-47cb-8bfc-a427da83cc2a1033.mspx

File Services

http://technet2.microsoft.com/windowsserver2008/en/library/6e5bb377-db25-4603-b1ff-ecc4f6c29b691033.mspx?mfr=true

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

2003 FSRM and NTFS Quotas compared

This post provides a quick comparison of 2003 FSRM and NTFS quotas, which I find useful when explaining how quotas in 2003 R2 work, as opposed to (or combined with) NTFS quotas. Also included is information on where the quota data is stored, and some methods to view that data.

Quota metafile information has been part of the NT filesystem since Windows NT 3.5, but has not been supported by the Operating System since the implementation of NTFS 5.0 – available in Windows 2000 and later.

When enabled, NTFS quotas track information as part of each write operation to the filesystem, providing a per-volume mapping between user SID and logical disk usage based on file ownership. While all the necessary information is stored in the NT filesystem, managing NTFS quotas is time-consuming and challenging for administrators.

Windows Server 2003 R2 File System Resource Manager (FSRM) provides a filesystem minifilter to control quotas, and a much improved interface to manage and report on quotas from a per-folder perspective.

The main differences between the two distinct quota methods available in 2003 R2 are that:

1. FSRM provides per-folder quotas, as opposed to per-user/volume NTFS quotas. Regardless of file ownership, files in a folder will count towards the FSRM-set limits.
2. SMB calls to return the free disk space are based on hard quotas at the root of the share or volume, not the quota applied to a folder - regardless of the share access point. NTFS hard quotas are volume-wide, and disk space is presented based on used-hard quota total, regardless of the share root or access method (remote SMB or local).
3. FSRM quotas count only the size on disk of files, as opposed to NTFS quotas which count the logical uncompressed size. This is primarily considered for NTFS compressed files, but is presumably the same for offline files.
4. FSRM quotas are controlled by a file system mini-filter storing quota data in \System Volume Information\SRM\quota.md and quota.xml, as opposed to NTFS quotas which are stored as part of the filesystem in \$Extend\$Quota file in $INDEX_ROOT NTFS attributes
5. FSRM allows autoquota's, a concept of setting a quota at a top-level directory and each direct child subdirectory automatically inherits a copy of that quota. This provides an easy method of exception-based quotas. Managing NTFS quotas is GUI-based unless the WMI automation interface is used and an NTFS quota entry is automatically created for each new user SID.
6. FSRM provides much improved reporting and alerting for quotas, whereas NTFS quotas only provide rudimentary reporting and eventlog entry alerting.
7. FSRM has no supported automation interface to manage quotas, whereas NTFS quotas can be managed by WMI. However, the .Net assembly srmlib.dll provides an undocumented framework for managing FSRM quotas, which could be scripted through PowerShell if required.
8. FSRM provides very strong support for command-line administration with dirquota.exe, with NTFS quotas having limited support available through fsutil
9. In a MSCS cluster scenario, FSRM stores settings in the registry, located in HKLM\Cluster\SRM\Settings\SrmGlobalSettings\Data. NTFS quotas have all information stored on the filesystem, making both methods functional in a MSCS server cluster with shared storage.
10. FSRM quotas provide improved notification - including in-built email, event logging, running a command or triggering a report.
11. FSRM quotas allow for templates to be created, separating the creation of a standard set of quotas from the application of those quotas. This allows scalability and much improved process control.

How FSRM quota information is stored

FSRM quotas are stored in the "?:\System Volume Information\SRM\quota.xml" and "?:\System Volume Information\SRM\quota.sd" files, with the XML containing the configuration, and the SD file containing the actual quota information.

To see the configuration of FSRM quotas for a particular volume:

• psexec /s /i /d cmd.exe
• xcopy /h "?:\System Volume Information\SRM\quota.xml" %temp%
• attrib -r -s -h "%temp%\quota.xml"

The SD file is secured so only system can access, is marked as system/hidden and is locked by the mini-filter. One method to view the SD:

• psexec /s /i /d cmd.exe
• nfi "h:\System Volume Information\SRM\quota.md"
• diskedit Read Sectors (as returned by nfi)

How NTFS quota information is stored

NTFS stores quota information in a metafile on each volume called \$Extend\$Quota, with the information contained in the INDEX_ROOT $O and $Q NTFS attributes. Nfi.exe and diskedit.exe can be used to identify the file, and view the data contained in the logical sectors.

nfi q:

File 24
\$Extend\$Quota
$STANDARD_INFORMATION (resident)
$FILE_NAME (resident)
$INDEX_ROOT $O (resident)
$INDEX_ROOT $Q (resident)
$INDEX_ALLOCATION $Q (nonresident)
logical sectors 1036140-1036147 (0xfcf6c-0xfcf73)
$BITMAP $Q (resident)

Quota Minifilter driver

FSRM quotas use a minifilter driver to function – quota.sys – mounted by default in the I/O stack with an altitude of 125000 as part of the ‘FSFilter Physical Quota Management’ group. While this altitude can be changed by modifying a registry value, this is not recommended.

Both the R2 file screen filter (260800) and the cluster file system (200000-209999) are loaded higher in the stack then the quota minifilter.


fltmc filters & fltmc instances

Filter Name Num Instances Frame
------------------------------ ------------- -----
DfsDriver
Datascrn 0 0
Quota 1 0

Filter Volume Name Altitude Instance Name
----------------------------- -----------------------------
Quota Q: 125000 Quota


To detach the filter from a volume, the following command can be run:
• fltmc detach [volume:]

Note that doing so leaves the SRM directory in the ‘System Volume Information’ on the volume, and during testing when fltmc was used to reattach the quota filter to the volume, the previous quotas were seen as invalid and returned errors.


References

FSRM and NTFS Quotas in 2003 R2
http://waynes-world-it.blogspot.com/2008/06/fsrm-and-ntfs-quotas-in-2003-r2.html

Inside Win2K NTFS, Part 1
http://msdn.microsoft.com/en-us/library/ms995846.aspx

You cannot create quotas on File Server Resource Manager (FSRM) in Windows Server 2003 R2
http://support.microsoft.com/kb/555941

FSRM quota information does not appear in the NTFS file system Quota Entries window, and NTFS file system disk quota information does not appear in FSRM in Windows Server 2003 R2
http://support.microsoft.com/kb/915042

Limited Group Policy management for NTFS quotas.
http://technet2.microsoft.com/windowsserver/en/library/2d82decb-6726-4c5c-b872-1658b0fc3e3e1033.mspx?mfr=true

Disk Quotas Tools and Settings
http://technet2.microsoft.com/windowsserver/en/library/3b5b242b-7bb2-48e4-8e5f-224a08b36b271033.mspx

HOW TO: Configure Disk Quotas for a Shared Disk in a Cluster
http://support.microsoft.com/kb/278365

Disk Quotas Tools and Settings
http://technet2.microsoft.com/windowsserver/en/library/3b5b242b-7bb2-48e4-8e5f-224a08b36b271033.mspx

Managing Disk Quotas in Windows Server 2003 and Windows XP
http://www.microsoft.com/technet/scriptcenter/topics/win2003/quotas.mspx

Designing a Disk Quota Strategy
http://technet2.microsoft.com/windowsserver/en/library/1EE8754E-48D6-4472-9B53-29E8D1DE09F81033.mspx

Quotas in a cluster:
http://support.microsoft.com/kb/278365

How Disk Quotas Work
http://technet2.microsoft.com/windowsserver/en/library/5becbcd6-8da3-4c3b-bc0e-258acd3ec1811033.mspx?mfr=true

Disk Quotas and Free Space
http://www.microsoft.com/technet/prodtechnol/windows2000serv/reskit/core/fncd_str_ctkj.mspx?mfr=true

Quota Minifilter Driver
http://technet2.microsoft.com/windowsserver2008/en/library/7c5a0b98-d963-4a1d-a499-316322746a8e1033.mspx?mfr=true

MUP Changes in Microsoft Windows Vista
http://msdn.microsoft.com/en-us/library/aa488427.aspx

File System Minifilter Load Order Groups and Altitude Ranges
http://www.microsoft.com/whdc/driver/filterdrv/alt-range.mspx

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

printQueue AD objects for 2003 Cluster

Print queue objects in AD provide a useful facility when users are trying to find printers, but with a 2003 MSCS clustered virtual print spooler, occasionally the information in AD does not reflect the current state of printers. This post describes some problems I've come across with duplicate/incorrect information and some ideas of how to automatically combat the problem.

Print Queue Objects in AD

Print queue objects in 2003 clustering are named with the virtual print server name, but they are children off a physical computer account. Which computer account the printers are children of is determined by the physical node that owned the cluster spooler resource when the printer was originally published in AD. As a virtual print server fails between nodes, the printer objects in the directory are not re-published (I assume unless the object is not found in the directory).

It's intuitive that print queue objects would be republished on failover to the node that currently owns the spooler, but that could potentially be hundreds or thousands of printer objects being created/deleted with each failover so it's practical not to. It appears the printer object is confirmed using the virtual print server name, and no change is made if the object is found - regardless of which physical node the print queue object is a child of.

In the scenario of a stand-alone printer server, when a printer is deleted, the spoolsv service also removes the directory object. In a clustered virtual print server this also occurs, however, it appears that in a 2003 cluster the object is not automatically removed from the directory if the node that owns the object when deleted is different than the publishing node.

None of this really matters if everything is working perfectly, but in a 2003 MSCS I have seen the following situations:

1. Print queues that no longer exist still being visible through a search in AD
2. Duplicate print queue objects, published against each physical none in the cluster that has hosted the virtual print spooler.

The first was a bigger problem, and I believe the following scenario will result in stale print queue objects persisting:

1. You have a two node cluster, CL01 and CL02. CL01 owns a virtual print spooler and other cluster groups, under which you create all the print queues.
2. At a later time you decide that the load could be better split, and move the virtual print spooler to CL02
3. You then clean up your print queues from the virtual server, also expecting that they will be automatically removed from AD.

In the scenario above, the print queue objects would not be removed from AD, as the physical node that owns the spooler (CL02) does not own the original print queue objects - as they were created when CL01 owned the resources. In this state, the invalid print queue objects will not be purged. Note that this is assuming you aren't using AD printer pruning - by disabling the spooler service on your DCs or using Group Policy to control pruning.

I'm unsure of the exact scenario that caused the duplicate print queue objects, presumably there was some problem finding the existing record, so at some point it was created off the other node as well - resulting in duplicate results in a search (both of which would work, but still).

Some low maintenance ideas to correct this problem:

1. Use AD printer pruning, which will ensure print queue objects in AD are managed. Note that this sounds like the obvious solution, but does have caveats and may not suit all environments.
2. Periodically remove published records from all but the designated primary node, toggle the published attribute on those printers no longer having a record in AD, causing the printers to be republished against the primary node. This could easily be scripted and scheduled
3. Modify printer creation change control processes to ensure that new printers are only created and deleted when the preferred owner is hosting the virtual print server

In an ideal world, three above followed by one make the most sense, but if you needed option two you could do something like this:

1. dsrm CN=%virtual_server%-%QueueName%,CN=%physical_server%,DC=domainRoot
2. cscript prncfg.vbs -s -b \\%virtual_server%\%QueueName% -published
3. cscript prncfg.vbs -s -b \\%virtual_server%\%QueueName% +published
4. dsquery * -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName distinguishedname find /i "%QueueName%"

This removes the AD object against the 'incorrect' node, toggles the published flag (using prncfg from the Resource Kit Tools - see 'Network Printing Tools and Settings' reference below), and then queries AD to verify the printQueue object has been created.

Printer Pruning in AD

Pruning of printer objects in Active Directory is controlled either by the server that deletes the printer from its local spooler, or Domain Controllers through periodic printer pruning. Printer pruning is a domain/site-wide activity which processes all printQueue objects.

In a clustered solution, I believe when a Domain Controller looks up the printqueue objects, it will connect to the virtual print spooler node to verify the printers still exist. So regardless of which physical is publishing the printer, as long as the printer is contactable through the virtual server it shouldn’t be pruned.

As long as the spooler service is enabled on at least one Domain Controller, it will prune printers (at the default of 3x8 hour checks). There are risks of doing this, primarily that if the print server is down for longer than 24 hours (or if the DC can’t contact the server), all printers will be pruned from the directory. This logs an Event 50 for each pruned printer in the system event log of the DC that pruned the object - at least it’s easy to trace.

Printer Commands

Query and compare the printers published from each server to determine duplicates:

• dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported > CL1.txt
• dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported > CL2.txt
• for /f "skip=1" %i in (CL1.txt) do @find /i "%i" CL2.txt

The following two commands help identify mismatches in printers published in AD versus those shared through the virtual print server.

Count the number of printers published in AD:

• find /i /c "%virtual_server%" CL?.txt

The number of printers shared against a node:

• rmtshare \\%physical_server% find /i "\\%virtual_Server%" /c

Query printers published against a physical server:

• dsquery * "CN=%physical_server%,DC=domainRoot" -limit 0 -filter "(&(objectClass=printQueue)(objectCategory=printQueue))" -attr cn printerName driverName printCollate printColor printLanguage printSpooling driverVersion printStaplingSupported printMemory printRate printRateUnit printMediaReady printDuplexSupported

References:

Network Printing Tools and Settings
http://technet.microsoft.com/en-us/library/cc778201.aspx

Printer Pruner May Prune All the Print Queue Objects on Its Site
http://support.microsoft.com/kb/246906

Printer Pruner May Not Remove Printer Queue Objects from Active Directory
http://support.microsoft.com/kb/246174/

A server does not prune printers on a Microsoft Windows Server 2003-based server cluster
http://support.microsoft.com/kb/908128

Useful Windows Printer command-line operations:
http://waynes-world-it.blogspot.com/2008/09/useful-windows-printer-command-line.html

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!

VirtualCenter Physical to Virtual

This post describes a process I executed to replace a physical VMware VirtualCenter box with a virtual equivalent running in its own cluster. There were no VM outages of machines running on the cluster – each ESX kept merrily running the virtuals until everything was sorted out with the VC layer.

Note that this was done in a lab instance of ESX 3.5 and VirtualCenter 2.5, had this been production I probably would have taken a little more care.

I don’t think there is any compelling reason why you wouldn’t run a virtual VC box, it would be hypocritical of VMware to suggest virtualizing your application servers, except VirtualCenter which should be physical. Having said that, this process could also be used in reverse, taking a VM VirtualCenter instance physical should the need arise. This would also be useful for a VirtualCenter disaster recovery scenario.

The configuration before completing these steps

1. Physical VirtualCenter 2.5 running on Windows Server 2003, called vc01, static IP
2. Virtual Windows Server 2003 computer running in the cluster, called vc02, dynamic IP \
3. SQL 2005 database for VC, running on a separate SQL server.
4. ESX 3.5 VC 2.5, single network, iSCSI shared storage

Prerequisites

1. The IP address of the VirtualCenter server
2. The ESX host of the VM becoming the new VC server
3. The path to your VMware FlexLM license file (assuming you’re using a license server)
4. The logon details for the SQL connection between vpxd and the database

Steps Taken

On the physical VirtualCenter box that is going to be decommissioned:

1. Take note of the physical ESX host running the VM becoming the new VC server
2. Stop the vpxd service and change the startup to manual (sc stop %service%, sc config %service% start= demand)
3. Stop the vmountVpx, vmware-ufad-vci, vmware-converter and webAccess services change the startup to manual
4. Stop the flexlm instance and set the startup to manual
5. Take a backup of your .lic license file
6. Change the IP address to dynamic (assuming it is static)
7. Power off the physical machine
8. Delete the computer account for vc01 from the domain
9. On the SQL server hosting the VirtualCenter database, backup the VC database and log file with the following command executed through management studio:
   
   

   BACKUP DATABASE [VMVC]
   TO DISK = N'c:\temp\VC_PreMoveToVM.bak'
   WITH
   DESCRIPTION = N'VirtualCenter Pre-move to VM backup'
   , INIT
   , NAME =
   N'VC Pre move to VM'
   GO
   
   RESTORE VERIFYONLY
   FROM DISK =
   N'c:\temp\VC_PreMoveToVM.bak '
   WITH FILE = 1
   GO
   

10. In the service console of one of the ESX hosts, backup the current certificates (just in case):
1. mkdir /tmp/cert_backup
2. cp /etc/vmware/ssl/* /tmp/cert_backup
11. On the VM becoming the new VirtualCenter server running on a host in the cluster: Rename the server from vc02 to vc01, with the same static IP as the previous vc01
12. Restart the virtual machine
13. Install the SQL Native Client - required for VC 2.5 SQL connectivity on a non-SQL server
14. Install VirtualCenter including FlexLM, connecting to the existing database and using the license file copied off the physical server
15. In VirtualCenter, disconnect the first ESX host in the cluster - maintenance mode is not possible at this stage – login errors occur because of the incorrect certificate
16. Copy the new VC certificates - I use pscp here, but whatever you normally use to copy files to ESX would be fine:
    
    1. cd "C:\Documents and Settings\All Users\Application Data\VMware\VMware VirtualCenter\ssl"
    2. pscp rui.crt vcadmin@esx01:/etc/vmware/ssl/
    3. pscp rui.key vcadmin@esx01:/etc/vmware/ssl/"
17. In the service console of the ESX node you’ve just updated the certificates on, restart the management interface, the ESX host did not seem to pick up the new certificate dynamically (maybe it would on a schedule without a restart):
    1. service mgmt-vmware restart
18. Connect the ESX host to VC through the VI Client interface
19. Repeat steps 15-18 for each other ESX host in the cluster
20. In VirtualCenter, run 'Reconfigure for HA' on each ESX node
    
    Testing
    
    
21. Ensure the vpxd.log file reports no problems with host connectivity or certificates (also check the VC/ESX logs)
22. Ensure each ESX host is receiving licenses from the 'new' license server, either through the VI client or the FlexLM admin tool.
23. Ensure you can perform simple tasks such as powering on a virtual machine
24. Ensure VMotion/HA/DRS is working

The (untested) rollback plan if something goes wrong:

1. Shutdown the new VirtualCenter VM
2. Restore the database from the backup taken
3. Power on the physical VC box, change the IP to the static IP
4. Restart the vpxd and VMware License Server services
5. For each ESX host in the cluster, disconnect the host, restore the old certificates, restart the management service and connect the ESX host to the old VirtualCenter instance

Additional notes:

• Even though user login errors were returned when the vpxd service tried to form the cluster - which points to the vpxuser account used by VC to manage ESX hosts - this was misleading as this username and password is stored in the VC database – which had not been modified (in the vpx_host table). The next logical step was certificates, which lead to certificate update process used above.
• Manually copying the certificates may not be strictly required, as when I went part-way to reconnecting a host without updating the certificates, I was prompted that another VC instance was managing these servers, would I like to continue. Presumably it would have automatically updated the certificates as required.

Read more!

Virtual 2003 MSCS Cluster in ESX VI3

This post shares a method I've used to create test-lab instances of standard 2003 file and print Microsoft Cluster Services (MSCS) clusters in a VMware ESX VI3 virtual environment. The resultant solution is not supported and definitely not production-ready, but if you want a real multi-node MSCS cluster in an ESX lab environment, this process might be helpful with a minimum set of requirements.

With my usual theme of repeatable command-line execution, most of these operations can be completed via the command-line, either in the ESX service console or a command-prompt from the virtual MSCS nodes.

I followed bits and pieces of the VMware supported method - which is very specific and quite restrictive. Note that I’m a little dubious that this cluster would be particularly stable – the SCSI reservations MSCS uses to lock disks are in no way supported when using a shared VMDK through a shared SCSI adapter (I think RDM is the only supported method), but it does work and at least provided me with a test environment.

The shared nothing model of 2003 MSCS clustering dictates that only one node accesses the partition at any one time, but the disk still needs to be visible to both nodes. A limitation of this solution is that both MSCS nodes need to be hosted on one ESX server – a requirement you could satisfy with a DRS rule to keep the two nodes together. However, if DRS decided to migrate both VMs, the cluster would almost certainly break during the failover (and possibly after).

If you follow the steps below, you should end up with two virtual x64 2003 enterprise servers, both members of a single MSCS cluster. In the cluster there will three shared disks (VMDKs), one for the quorum and one each for file and print – with a virtual server and relevant cluster resources. A test file share is created, along with drivers and a test printer. You'll need to modify the commands that reference the public adapter and IP addresses

Steps involved:

1. Create an area for storage of the shared disk on your datastore:
   1. mkdir /vmfs/volumes/%datastore%/cluster01
2. Create a 5GB quorum disk:
   
   1. vmkfstools -d thick -a lsilogic -c 5G /vmfs/volumes/%datastore%/cluster01/MSCS-Quorum.vmdk
3. Create a 5GB disk for shared data:
1. vmkfstools -d thick -a lsilogic -c 5G /vmfs/volumes/%datastore%/cluster01/MSCS-disk01.vmdk
4. Create two 2003 x64 enterprise virtual machines, either through cloning, deployment with templates or whatever your standard build process may be
5. If cloning was used, run sysprep on both nodes to give a unique SID and join your lab domain
6. Shutdown the first node and add the shared disk
1. Add the quorum disk, mounted under scsi 1:0 (which adds a new SCSI adapter)
2. Set the newly created SCSI Adapter to SCSI bus sharing virtual
3. Add disk01, attached as scsi 1:1
7. In the first VM, use disk administrator (or diskpart) to initialise the quorum and disk01 disks, partitioned with basic. Record the signature of the disk and the drive letter used (although this is the disk volume when the disk is owned by the OS, not the cluster).
8. Add a service account for the cluster service:
1. dsadd user "CN=clustersvc,CN=Users,DC=test,DC=local" -pwdneverexpires yes -pwd password -disabled no -desc "MSCS VM cluster service account"
2. Ensure the service account is an administrator of each virtual 2003 node
9. Use Cluster Administrator to install the cluster on the first node, with your chosen cluster name, using the created quorum disk and service account
10. Verify correct operation of the single-node cluster, and then add the second VM node to the cluster.
11. Create a new port group to allow a second private adapter on each ESX server:
1. esxcfg-vswitch -A MSCS-Private Private
2. Add a second interface to each VM cluster node, allocated separate address space
3. Verify connectivity (ping) and configuration following cluster best practices (no gateway, no DNS etc)
4. Mark as a private heartbeat connection for the cluster, prioritised above the LAN connection.
12. Create a virtual resource group, creating IP, network name and disk resources in the group, the following commands will create a group called v01, in the lab01 cluster. For these steps, you’ll need the drive letter to use (M: below), the disk signature, the public network name, IP Address and subnet mask of the virtual server being created:
1. cluster /cluster:lab01 group "v01" /create
2. cluster /cluster:lab01 res "v01 Disk01" /create /group:"v01" /type:"physical disk"
3. cluster /cluster:lab01 res "v01 Disk01" /priv Drive="M:"
4. cluster /cluster:lab01 res "v01 Disk01" /priv signature=0x%disksignature%
5. cluster /cluster:lab01 res "v01 Disk01" /prop Description="M: disk01"
6. cluster /cluster:lab01 res "v01 Disk01" /On
7. cluster /cluster:lab01 res "v01 IP" /create /group:"v01" /type:"IP Address"
8. cluster /cluster:lab01 res "v01 IP" /priv Network="%publicNetwork%"
9. cluster /cluster:lab01 res "v01 IP" /priv Address=192.168.10.10
10. cluster /cluster:lab01 res "v01 IP" /priv SubnetMask=255.255.255.0
11. cluster /cluster:lab01 res "v01 IP" /priv EnableNetBIOS=1
12. cluster /cluster:lab01 res "v01 IP" /priv OverrideAddressMatch=0
13. cluster /cluster:lab01 res "v01 IP" /AddDep:"v01 Disk01"
14. cluster /cluster:lab01 res "v01 IP" /On
15. cluster /cluster:lab01 res "v01" /create /group:"v01" /type:"Network Name"
16. cluster /cluster:lab01 res "v01" /priv RequireKerberos=1
17. cluster /cluster:lab01 res "v01" /AddDep:"v01 IP"
18. cluster /cluster:lab01 res "v01" /priv Name="v01"
19. cluster /cluster:lab01 res "v01" /On
13. Install ABEUIamd64.msi on each node if Access Based Enumeration is required
14. To create a test directory, share and ABE resource on the new virtual server on the cluster (v01):
1. md \\v01\m$\Dir01
2. cluster /cluster:lab01 res "v01 Dir01 Share" /create /group:"v01" /type:"File Share"
3. cluster /cluster:lab01 res "v01 Dir01 Share" /priv path="M:\Dir01"
4. cluster /cluster:lab01 res "v01 Dir01 Share" /priv Sharename=Dir01
5. cluster /cluster:lab01 res "v01 Dir01 Share" /priv Remark="Dir01 File Share"
6. cluster /cluster:lab01 res "v01 Dir01 Share" /prop Description="Dir01 File Share"
7. cluster /cluster:lab01 res "v01 Dir01 Share" /priv security=Everyone,grant,F:security
8. cluster /cluster:lab01 res "v01 Dir01 Share" /AddDep:"v01"
9. cluster /cluster:lab01 res "v01 Dir01 Share" /AddDep:"v01 Disk01"
10. cluster /cluster:lab01 res "v01 Dir01 Share" /On
11. cluster /cluster:lab01 res "v01 Dir01 ABE" /create /group:"v01" /type:"Generic Application"
12. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv CommandLine="cmd.exe /k abecmd.exe /enable Dir01"
13. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv CurrentDirectory="%SystemRoot%"
14. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv InteractWithDesktop=0
15. cluster /cluster:lab01 res "v01 Dir01 ABE" /priv UseNetworkName=0
16. cluster /cluster:lab01 res "v01 Dir01 ABE" /prop SeparateMonitor=1
17. cluster /cluster:lab01 res "v01 Dir01 ABE" /prop Description="Access Based Enumeration for Dir01 File Share"
18. cluster /cluster:lab01 res "v01 Dir01 ABE" /AddDep:"v01"
19. cluster /cluster:lab01 res "v01 Dir01 ABE" /AddDep:"v01 Disk01"
20. cluster /cluster:lab01 res "v01 Dir01 ABE" /AddDep:"v01 Dir01 Share"
21. cluster /cluster:lab01 res "v01 Dir01 ABE" /On
15. Additional shared cluster disks can be created as required, eg:
1. vmkfstools -d thick -a lsilogic -c 5G /vmfs/volumes/%datastore%/cluster01/MSCS-disk02.vmdk
2. Add the disks to one node, (scsi 1:2 in this example). Initialise and allocate in the cluster (as in step 7 above)
16. To create a virtual print server (assuming you’ve mounted disk02 from step 15 for use in the cluster):
1. cluster /cluster:lab01 group "v02" /create
2. cluster /cluster:lab01 res "v02 Disk02" /create /group:"v02" /type:"physical disk"
3. cluster /cluster:lab01 res "v02 Disk02" /priv Drive="P:"
4. cluster /cluster:lab01 res "v02 Disk02" /priv signature=0x%disksignature%
5. cluster /cluster:lab01 res "v02 Disk02" /prop Description="P: print01"
6. cluster /cluster:lab01 res "v02 Disk02" /On
7. cluster /cluster:lab01 res "v02 IP" /create /group:"v02" /type:"IP Address"
8. cluster /cluster:lab01 res "v01 IP" /priv Network="%publicNetwork%"
9. cluster /cluster:lab01 res "v01 IP" /priv Address=192.168.10.11
10. cluster /cluster:lab01 res "v01 IP" /priv SubnetMask=255.255.255.0
11. cluster /cluster:lab01 res "v02 IP" /priv EnableNetBIOS=1
12. cluster /cluster:lab01 res "v02 IP" /priv OverrideAddressMatch=0
13. cluster /cluster:lab01 res "v02 IP" /AddDep:"v02 Disk02"
14. cluster /cluster:lab01 res "v02 IP" /On
15. cluster /cluster:lab01 res "v02" /create /group:"v02" /type:"Network Name"
16. cluster /cluster:lab01 res "v02" /priv RequireKerberos=1
17. cluster /cluster:lab01 res "v02" /AddDep:"v02 IP"
18. cluster /cluster:lab01 res "v02" /priv Name="v02"
19. cluster /cluster:lab01 res "v02" /On
17. Create v02 print spooler:
1. cluster /cluster:lab01 res "v02 Spooler" /create /group:"v02" /type:"print spooler"
2. cluster /cluster:lab01 res "v02 Spooler" /priv DefaultSpoolDirectory="P:\Spool"
3. cluster /cluster:lab01 res "v02 Spooler" /prop Description="v02 Print Spooler"
4. cluster /cluster:lab01 res "v02 Spooler" /AddDep:"v02 Disk02"
5. cluster /cluster:lab01 res "v02 Spooler" /AddDep:"v02"
6. cluster /cluster:lab01 res "v02 Spooler" /On
18. On v02, add a standard Laserjet 4000 retail driver for x64 and x86, run from a cluster node:
1. rundll32 printui.dll,PrintUIEntry /ia /c \\v02 /m "HP LaserJet 4000 Series PCL6" /h "x64" /v "Windows XP and Windows Server 2003"
2. rundll32 printui.dll,PrintUIEntry /ia /c \\v02 /m "HP LaserJet 4000 Series PCL6" /h "x86" /v "Windows 2000, Windows XP and Windows Server 2003"
19. Create a test printer on v02 called printer01 using the LJ 4000 driver, with a record in DNS, published in AD, set to duplex by default, with customised permissions using the standard winprint processor:
1. dnscmd %DNSserver% /recordadd %zone% printer01 A 192.168.10.100
2. cscript //nologo portmgr.vbs -a -c \\v02 -p printer01 -h 192.168.10.100 -t LPR -q printer01
3. cscript //nologo prnmgr.vbs -a -c \\v02 -b printer01 -m "HP LaserJet 4000 Series PCL6" -r printer01
4. cscript //nologo prncfg.vbs -s -b \\v02\printer01 -h printer01 -l "%Location%" +published
5. setprinter.exe \\v02\printer01 8 "pDevMode=dmDuplex=2,dmCollate=1,dmFields=duplex collate"
6. subinacl /printer \\v02\printer01 /grant=%domain%\%group%=F
7. setprinter \\v02\printer01 2 pPrintProcessor="WinPrint"

References

VMware Support method of running MSCS clusters:
http://www.vmware.com/pdf/vi3_35/esx_3/r35u2/vi3_35_25_u2_mscs.pdf

Implementing an MSCS 2003 server cluster Cluster
http://waynes-world-it.blogspot.com/2008/03/implementing-mscs-2003-server-cluster.html

subinacl 5.2.3790.1180:
http://www.microsoft.com/downloads/details.aspx?FamilyID=E8BA3E56-D8FE-4A91-93CF-ED6985E3927B

Windows Server 2003 Resource Kit Tools:
http://www.microsoft.com/downloads/details.aspx?FamilyID=9d467a69-57ff-4ae7-96ee-b18c4790cffd&DisplayLang=en

Wayne's World of IT (WWoIT), Copyright 2009 Wayne Martin.

Read more!