@martius

A very simple way to see what command line options client Windows Update Agent (wuauclt.exe) has is to drop the executable in notepad. In the beginning of  the notepad (Word wrap enabled) you will find them!

In Windows 7 these options are available:

/DetectNow
/ReportNow
/RunHandlerComServer
/RunStoreAsComServer
/ShowSettingsDialog
/ResetAuthorization
/ResetEulas
/ShowWU
/ShowWindowsUpdate
/CloseWindowsUpdate
/SelfUpdateManaged
/SelfUpdateUnmanaged
/UpdateNow
/ShowWUAutoScan
/ShowFeaturedUpdates
/ShowOptions
/ShowFeaturedOptInDialog
/DemoUI 

Many of them are undocumented. What some of them mean can be found on the interwebs, others I have no clue!

So, what does this picture mean?

By default, volumes are spread across three members in one pool. So if you have six arrays in a pool, a different combination of three members will be used to handle different volumes.

There is a maximum of 16 nodes in a Hyper-V cluster which means every node in the cluster will get 6 persistent rervervations on a volume (96/16 = 6).

These 6 persistent reservations per node are then spread over a maximum of 3 members in a pool. We will then get 2 connections per member. If we apply redundancy this will result in 1 connection per NIC per Hyper-V cluster node.

If the above is correct then my previous post (http://www.delltechcenter.com/thread/4007957/Microsoft+Windows+2008+R2+CSV+and+Equallogic+SAN/ or http://www.martius.nl/?p=1896) on how to calculate the persistent reservations in wrong. This is because of the spread over max 3 members which actually means no mather how many Equallogics you are using(max. 16 in a pool) only 3 will be used to locate the volume.

The new calculation would then be:

Number of Equallogics   = 3 (max spread)
Number of NICs    = N
Number of MPIO    = M (default HIT = 2)
Number of Servers   = S

3 * N * M * S = 96

The numbers will then be:

3 * 2 * 1 * 16 = 96

Obvious question then is why should you use the DSM of Equallogic above the use of the standard Microsoft Multipath capabilities? The Equallogic DSM has a default MPIO per NIC of 2 while only one is available.

Another question is if this is the way Equallogic supports a 16 node Hyper-V cluster?

What are your thoughts? Please share them in getting this Equallogic – Persistent Reservation mystery clarified.

Since Windows 2008 R2 it is possible to build an Hyper-V cluster with Cluster Shared Volumes (CSV). One way to build suge a cluster is to use Equallogic PS series.

With atleast firmware 4.3.5 there is an issues when you create an Failover Cluster for use with Hyper-V with the following configuration:

- More then one PS series Equallogic
- More then 2 NIC’s per node
- More than 4 nodes
- More then the default MPIO HIT kit which is 2.

All has too do with how Equallogic handles Peristent Reservations (PR). Per CSV there are only  max. 32 PRs available. But how do they get this number? My assumption is the following formula:

Number of Equallogics   = E
Number of NICs    = N
Number of MPIO    = M (default HIT = 2)
Number of Servers   = S

E * N * M * S =32

So for instance if you have 2 Equallogics, 2 NIC’s per node which is the minimum, the default  HIT kit settings of 2 and 4 nodes you will end up with the following:

2 * 2  * 2 * 4 = 32

Why did I use this example. This because with 5 nodes the failover cluster will fall over when ever you want to do a storage migration or an reboot of one of the nodes. This is because you will have 40 PR’s! This all is with firmware version 4.3.5.

Now, is Equallogic doing nothing to fix this because a Hyper-V cluster can contain a maximum of 16 nodes. With the formula from above you will get with the use of only 1 Equallogic atleast 64 PR’s (1 * 2 * 2 * 16). But why build a 16 nodes Hyper-V cluster with only 1 Equallogic PS series? You will probably use atleast 2 maybe 3 arrays.

Equallogic has released a firmware version 4.3.5 Patch L1 which you can get here. If this will fix the issue with the limited number of PR’s I don’t know. What I also don’t know is if this Patch L1 includes the Patch H1 which I received from Equallogic support which fixed my problems with my 7 nodes, 2 Equallogic, 2 NIc’s per nodes and default HIT kit settings Hyper-V failover cluster. What do I know? Firmware 4.3.5 patch H1 fixed my problem, but rumours are that this only allows 96 PR’s.

This 96 PR’s will get you this:

E * 2 * 2 * S = 96

This leaves you with 24 to be made up out of (the 2 NIC’sS and 2 MPIO’s are a minimum) :

2 Equallogics and 12 nodes
3 Equallogics and 8 nodes
8 Equallogics and 3 nodes
12 Equallogics and 2 nodes

Hopefully Equallogic will enlarge the number of PR’s per CSV to atleats support the maximum number of arrays in a group which is I believe is 15 and with the maximum of 16 nodes in a Hyper-V Cluster . With these numbers and the default of 2 NIC’s and 2 MPIO’s the PR number must be 960 per CSV!

 This artcile is based on my personal experience with Equallogics and is in no way supported by Equallogic or Microsoft. I’m still waiting on an answer how the PR number per CSV is calculated.

***  UPDATE ***

My initial calculation might be wrong! Please read this >>> http://www.martius.nl/?p=1957

 Hij is tenminste te downloaden via Technet

ISO FILE: en_windows_server_2008_r2_standard_enterprise_datacenter_and_web_x64_dvd_x15-59754.iso

SHA1: AD855EA913AAEC3F1D0E1833C1AEF7A0DE326B0A

ISO/CRC: F111FF61

Sometime ago I had an issue with a target on one of my customers servers (Windows Server 2008 Core) and an Equallogic PS5000XV. The issues was the error message below.

Event 7.4.3
ERROR
 1-7-09  13:57:28
000-SAN002
iSCSI login to target ’192.168.199.13:3260, iqn.2001-05.com.equallogic:0-8a0906-bbb8ad503-b53d4d74e944a34d-000-srv666-hd00′ from initiator ’192.168.199.103:49913, iqn.1995-05.com.broadcom.iscsiboot’ failed for the following reason: 
CHAP user ‘mpio-000-SRV123-0-8a0906-bbb8ad503-b53d4d74e944a34d-91d1a2′ authentication failed.

Obviously somewhere a something went wrong or a bit fell over. Anyhow…this error sucks because little info can be found on the Internet regarding this issue.

What to do?

First of all: Before you start make sure no active applications, services or Virtual Machines are using the iSCSI target on the specific server.

Remove the persistent tartget from the server with is giving the error. In my case ’192.168.199.103′.

1. Retrieve the session list with: iSCSIcli sessionlist > C:\Temp\sessionlist.txt. Below my SessionID example:
2. Look for the following info: Initiator Name, TargetName and Target Portal for the target that is reporting the issues;
3. Fill in the found info in the following iSCSICLI command: iSCSIcli RemovePersistentTarget <Initiator Name> <TargetName> * TargetPortal 3260. In my case this would be:  iscsicli RemovePersistentTarget Root\ISCSIPRT\0000_0 iqn.2001-05.com.equallogic:0-8a0906-bbb8ad503-b53d4d74e944a34d-000-srv666-hd00 * 192.168.199.240 3260;
4. Log-out all existing sessions that the target is using with: iSCSIcli LogoutTarget <SessionId>. In my case this would be: iSCSIcli LougoutTarget fffffa8029687018-400001370000041d. Logout ALL found SessionID’s for the specific TargetName.
5. Open regedit.exe and make a back-up of HKEY_LOCAL_MACHINE\SOFTWARE\EqualLogic\EHCM\MpioChap
6. Search in regedit.exe on the troubled server for “‘mpio-000-SRV123-0-8a0906-bbb8ad503-b53d4d74e944a34d-91d1a2″ and delete it! Mine looked like this in an export.
7. After delting the registry key rebuild the persistent target on the troubled server to the specific target. Do this with iSCSIcli PersistentLoginTarget TargetName T * * * * * * * * * * * * * * * 0. Mine looked like this iSCSIcli PersistentLoginTarget iqn.2001-05.com.equallogic:0-8a0906-bbb8ad503-b53d4d74e944a34d-000-srv666-hd00 T * * * * * * * * * * * * * * * 0. 

As you can check in your Equallogic Group Manager you will find that now for each NIC in your server which is connected to the iSCSI VLAN a Session is made.

The 192.168.199.103 and 192.168.199.104 have been reconnected. Previouslu only the 192.168.199.104 session would show up!

It is out there! Search and you will find!!!

7600.16384.090710-1945_x64fre_client_en-us_Retail_Ultimate-GRMCULXFRER_EN_DVD.iso

To start off! Out of the box Apple does not support the configuration of a wired-wireless connection to the Apple Express (AE). So this was challenge one!

The second challenge was to create a virtual machine of Windows 7 Build 7201 with the firewall enabled.

The last challenge was to create all this in a stable way so it would work “quick” and should be “easy” to set-up.

My used hardware/software is:

• Normal x64 PC with Microsoft Windows Server 2008 R2 RC
• Microsoft Hyper-V virtual machine with Windows 7 build 7201, fixed IP address, firewall enabled
• Apple Express 802.11n with firmware 7.4.2. The AE is joined to my existing network (from the Davolink) with an WPA-TKIP configuration. No MAC address filtering is used. Fixed IP address.
• Apple iTunes 8.2.0.23
• Apple Airport Utility 5.4.2
• Davolink DV-2020 WiFi AP, firmware unknown

There is a wire from the PC to the Davolink WiFi AP. The link between the Davolink link and the Apple Express is wireless (DUHHH).

After setting up all the bits and hardware I ran into some nasty errors like:

“An unknown error (-15006) occurred while connecting to the remote speaker“, “The remote speaker cannot be found on your network. Please verify your network settings and AirTunes configuration or select another speaker from the menu at the bottom of the iTunes window.” and the most nasty one (because there was no direct real error message) the loosing of sound and connection to the AE.

Than the troubleshooting started! Firewall on, firewall off, different versions of iTunes, upgrade firmware on AE, multiple reboots of all the hardware and software in many orders etc etc.

Then the EUREKA moment arrived eventually after 18 hours! What is it, what is it, what is it!!!

I found the magic sequence in how to get the sound blasting out of my speakers.

1. Setup the AE to join an existing wireless network
2. Boot all the hardware and software in a not-specific order.
3. Fire-up the Apple Airport Utility and manually connect to the AE.
4. Reboot or update the AE without making any changes!
5. Start iTunes and check if you can select the remote speakers at the right bottom
6. Stop the Bonjour service! (The holly grail!!!) but leave the start-up type at Automatic.

So….surprised?

In the end I was because the Bonjour service should keep the remote speakers discovered for eternity because that’s the whole point of the service, not to “disconnect� them after an hour��.

This worked for me…will it work for you? Please let me know!

UPDATE:

After reading many, many, many postings on Apple forums I applied the folowing tip. This seems to make it even more stable.

Open iTunes > Edit > Preferences > Advanced Tab > Streaming Buffer Size > Set this to LARGE!

The larger the “chunks”, the lesser the posibility that set-recieve errors can occure…..sounds fine to me!