Monthly Archives: September 2010

Broadcom HBAs do not work with HP P4000 SANs

BLUF – If you use LeftHand/HP P4000 SANs, DO NOT purchase the iSOE option on Broadcom NICs, it doesn’t work.  At least not yet.

On our last purchase cycle, we decided to try out Broadcom’s iSCSI Offload Engine (iSOE) option on their NetExtreme II 5709C NICs.  Well, it turns out that their version of iSOE doesn’t play nice with the HP P4000 SANs.  The only HBAs supported are ones made by QLogic.  I asked HP for details on if and when HP plans to support them.  It appears that they are working on supporting the feature, but no timeline on release just yet.

We have successfuly used the TCP Offload Engine in our production environment for quite some time now, so that’s still a good option.

Here is the link to HP’s Compatibility Matrix (I guess I should have looked at that first):  http://h20195.www2.hp.com/v2/GetPDF.aspx/4AA2-5654ENW.pdf

Configuring Jumbo Frames on a Hyper-V/Server Core Virtual NIC

I was recently reading two excellent articles on NIC configuration for server core and virtual NICs.  The reason I happened upon these postings was because I was searching for a way to enable Jumbo Frames.  Unfortunately, I didn’t find anything that specifically addressed doing this work on vitrualized NICs in Hyper-V Server, which is slightly different than physical NICs. 

Using Michael Platt’s article, I discovered that it did not take into account multiple NICs with the same device name.  What I really needed was a way to reference the “Friendly Name” (the one you set in the Hyper-V Virtual Network Manager).  After doing a search of the registry, I found that the friendly names of the virtual NICs are stored in 

HKLM\SYSTEM\CurrentControlSet\Enum\Root\VMS_MP\

From there, one can search for the correct NIC as described in the article, using the “Driver” value.

As an aside, you can lookup the GUID for physical drivers by running a search of the friendly name in

HKLM\SYSTEM\CurrentControlSet\Control\Network\

The containing key will match the NetCfgInstanceId of the NIC you want to modify. 

Using these methods, you can be sure you’re configuring the correct NIC within the registry.

HP P4000 VSA/FOM for Hyper-V now available!

After nine months, HP announced on 6 September that a Hyper-V version of their P4000 VSA (and Failover Manager) are now available!

http://bizsupport1.austin.hp.com/bc/docs/support/SupportManual/c02514463/c02514463.pdf

Thank GOD!  I can now tear down those VMware servers I was using for Failover Manager….

SQL Server 2008 installs in a DISA-compliant environment

If you’re running a SQL Server 2008 install on a server that is compliant with the DISA STIG, you should be aware the certain default administrator permissions are removed.  These permissions are expected by the installer and installation will fail with a cryptic ‘ACCESS DENIED’ error.  You must ensure the administrator account you are using to run the installer has the following permissions:

Local Policy Object Display Name User Right
Backup files and directories SeBackupPrivilege
Debug Programs SeDebugPrivilege
Manage auditing and security log SeSecurityPrivilege

More than likely, these are managed by Group Policy, so you’ll have to get your domain management guys involved to fix the issue.

Reference: http://support.microsoft.com/?kbid=2000257

Using FQDN certificates with HP ILO2

Being a Dell shop, it has been an experience for me to work with a couple of brand new HP servers we just got in.  One of our first configuration actions is to install SSL on the remote control (aka ILO or DRAC).

We discovered that our CA was issuing certificates to ILO with the host name run into the domain name.  When ILO tries to install the cert, it finds that it is invalid and reverts to the self-signed cert instead.  After scratching my head for a bit, I find out that this is a known bug with firmware 2.0:

http://forums11.itrc.hp.com/service/forums/questionanswer.do?threadId=1437869

Apparently, HP is new at using FQDNs for certificates (which I find odd).  Fortunately, they relased 2.1 on 9 September, which fixes the missing dot issue.  It can be downloaded at:

ftp://ftp.hp.com/pub/softlib2/software1/sc-windows-fw-ilo/p1443420321/v63248

Java Runtime installation failure (Error 1330)

For security reasons, our network is completely disconnected from the Internet.  And I mean completely… we are not allowed to connect, ever.  In this situation, you quickly realize almost every vendor assumes you have Internet access (really? people still assume) and management of your network becomes harder by an order of magnitude.

As an example, earlier this week, I was trying to create an install package for the latest JRE, version 6 update 21.  I ended up getting an error 1330, invalid digital signature in data1.cab during the installation process.  After some research, I came across the following forum posts:

http://forums.sun.com/thread.jspa?threadID=5403715 and
http://forums.sun.com/thread.jspa?threadID=5380073
EDIT: Sorry, I know these links are broken, but Oracle changed the forum structure when Sun got gobbled by them and I haven’t had the time, or patience, to find where they went.  Personally, I consider this an HFE failure (the fact that the links broke when the site was migrated).  Shame on you Oracle.

Based on our connectivity (or lack of it), I realized this was due to the fact that JRE has a CAB file that uses a VeriSign code signing certificate that is NOT part of the Microsoft Root CA list.  To make matters worse, the CAB wants to run a CRL check that goes back to VeriSign.  After fiddling around trying different security options to bypass the CRL check, I finally gave up and went another way.

It turns out, that this issue only affects the JRE installer that is available for general consumer download.  The JDK, on the other hand, has a copy of the JRE as part of the package that doesn’t have this issue.  The bad part, is that the JDK makes you install, well, JDK stuff in addition to the JRE (which is an option).  Of course, I took this on as a challenge to split out the JRE as a standalone installer.

Most installers work the same way.  You download a single file and the file extracts all of the actual installation files into a temporary directory.  Since we only want the JRE from the JDK package, we will begin the install process.  Do not continue with the installer, or exit it.  Doing either action will cause the temporary files to be deleted.

At this point, the files are extracted to a temp directory located at:

C:\Users\<username>\AppData\LocalLow\Sun\Java\jdk1.6.0_21

(EDIT: This post was originally done with version 6 update 21.  Use the appropriate directory if your version is different.  This process has been most recently tested on version 6 update 25).  If you look inside this directory, you will see a msi file for the JDK along with a number of CAB files.

The one we’re interested in is the sj160210.cab file.  (EDIT: This filename is specific to the 32-bit version.  The 64-bit version may differ.  What you’re looking for is the cab that begins with ‘SJ’).  Double-clicking on this will show you the files within the CAB:

The jre.msi is the standalone JRE installer! You can use this by simply double-clicking on it, or rolling it as an SCCM package or script with msiexec support.  The adjacent MST files are language transforms (and are not needed for English).  Now, you can install JRE without the pesky CRL check!

Windows Server 2008 RDP sessions suddenly disconnect

I have a particular bad-boy server that always seems to kick me off at random intervals.  Never gave it much thought since I would just log back in.  Slightly annoying.  Well, today I went looking for an answer and here it is:

http://support.microsoft.com/kb/2083411