Replace noisy power supply fan in HP Proliant Gen7 Microserver

My 3.5 year old HP Proliant Gen7 MicroServer’s power supply fan starting getting noisy, so I set out to find a replacement. I had a similar issue with the GPU fan on my Sapphire Radeon HD 5770 about a year ago, and I remember from that project, finding a specialty replacement fan isn’t easy.

I scoured forums for hours trying to find a drop-in replacement, but wasn’t very successful. Most people seem to prefer swapping out the stock PSU for a PicoPSU. That moves the transformer outside of the case (like a laptop power supply) but leaves an ugly hole in the back of the system with wires sticking out. I prefer keeping to stock designs when I can, so I wanted to narrow down at least a replacement fan that would fit the stock PSU.

The HP ProLiant MicroServer owners’ thread on was one of the best resources. Specifically, post 896 from bluefull gave several possible drop-in replacements for the stock T&T 4020HH12S-ND1 fan. Additionally, there was some great information in the HP ProLiant MicroServer N40L Owner’s Thread *Part 5* on Shawry, beginning in post #558, describes the main issue with these fans – even though they are rated for 12V, the PSU is actually only putting out 5V. One fan in particular caught my eye, the Noiseblock BlackSilent Pro series. According to the specifications on the site, the fan had a starting voltage of 5V and an operating voltage of 5-13.2V which I had hoped would work as a drop-in replacement. I was able to find the NB BlackSilent Pro PM-2 40mm in the US at and ordered one.

The fan uses a standard 3-pin Molex connector with a signaling cable, but the stock fan uses a smaller 2-pin 4mm mini-Molex connector. Unfortunately, I forgot to order a 2-pin to 3-pin adapter, so I had to resort to cutting the old connector from the stock fan and splicing it onto the new fan’s power cable. I wasn’t overly concerned with doing this as the NB BlackSilent Pro is ingeniously designed with a break-away power connector for using different length power cables and the fan comes with both a 20cm and 50cm cable. At any rate, the fan fits perfectly into the psu, but I wasn’t able to get it to spin up by connecting it to the fan header inside the PSU. Not to worry, the design of the fan and the PSU lends itself to allowing you to connect the fan to a standard 4-pin Molex power connector while still ensuring proper fit into the case.

I installed the fan so the power connector would route outside of the power supply like so:

The HP Proliant MicroServer psu with the replacement NoiseBlocker BlackSilent Pro PM-2 fan

The Proliant MicroServer PSU with the replacement NoiseBlocker BlackSilent Pro fan

I was able to easily slide the power supply back into place, and the connector was then accessible between the PSU and case fan:

The CPU power cable next to the MicroServer case fan

The CPU power cable next to the MicroServer case fan

I then used a standard 4-pin to 3-pin adapter to piggy back off the optical drive power connector:

The PSU power cable connected to a 3-pin to 4-pin Molex adapter.

The PSU power cable connected to a 3-pin to 4-pin Molex adapter

Everything fits nicely in the space behind the optical drive:

HP Proliant Microserver


Fan spun up without issue once the server was powered on.

A side note, I had originally thought the noise was coming from the case fan and went through the effort of ordering a Cougar Vortex CF-V12HPB PWM fan as a replacement, only to find out the HP MicroServer fan header uses a custom pinout. The server will not boot if it does not properly detect the case fan, so if replacing the case fan, you’ll need to swap the conductor pins to the proper slots.

Running Windows 8 Server from a USB Flash Drive with Phison Controller

Since I deployed my HP Proliant Microserver, I had been running ESX from a USB flash drive. Now that Windows 8 Beta is available, I wanted to test out some of the new Hyper-V features in my home lab. All the talk about Windows To Go had me thinking it would be a good test to run Windows 8 Hyper-V server from a USB flash drive. After all, deploying Microsoft Hyper-V Server 2008 R2 on a USB Flash Drive was already supported.

I found a good tutorial about running Windows 8 Developer Preview from a UFD which outlines the process. If you’ve used WAIK before, then you’re familiar with the process which basically involves creating the partitions on disk, and then applying a WIM file to the partition. This process works great for Consumer edition on many UFD’s, however, Windows To Go is not supported with server edition. That doesn’t mean Windows 8 Server cannot be installed to a UFD though – it just means that the same rules apply as 2008 R2.

Specifically, the UFD needs to have it’s Removable Media Bit set to 0. This is a setting in the UFD’s controller that tells Windows how to treat the device. Typically, when you attach a UFD, Windows classifies the device as a Removable Disk:

There’s a couple of limitations that come with Removable Disks in Windows though. Specifically, you can’t create multiple partitions on them (even if you do via other partitioning methods, Windows will only show you the first partition), and you can’t run Windows directly from them. So, in order to deploy Windows 8 server to a UFD, the RMB needs to be set to 0.

Some UFD manufacturers provide utilities to set this. Lexar has the BootIt utility for instance. This utility may work for UFD’s manufactured by others provided it’s using the same controller. After some searching, I came across and excellent thread that described how to flip the Removable Media Bit for non-Lexar UFD’s. The ChipGenius and USBDeview utilities will give you detailed information about the Controller in the UFD:

This tool provides a few critical pieces of information: The Chip Vendor, Part Number, VID and PID. Using the VID and PID, you can find out if there is a tool available that will allow you to program the UFD controller. Head over to the Russian site (I recommend using Chrome and you can auto-translate the page) and enter your VID and PID. This will list all known UFD’s matching those ID’s and let you know what utility you can use to program the controller, as well as helpful hints from other users. In my case, the Patriot XT Rage 16GB UFD showed up in the list:

In my case, I needed to use Phison’s MPALL tool (version 3.20) to program the Phison PS2251-38 controller on the Patriot XT Rage 16GB UFD. has a catalog of all utilities for Phison controllers and I was able to easily download the necessary version. Inside the MPALL archive, you’ll find a few utilities. The first is GetInfo which displays current configuration of the controller:

The second tab has partition information:

Notice the Fixed Disk setting of “No” – this is the RMB on Phison controllers. All that’s necessary is for us to update that using the other utilities in the archive. It took some testing/tweaking to figure out how things work with the Phison USB Mass Production Tool, and admittedly I’m a bit fuzzy on the specifics. However, it looks as though there are two controller configuration sections that need updating: F1 and F2 (I haven’t been able to find what these mean, but they seem to be common to all UFD’s). There are two Parameter Editor utilities that generate INI files that can then be used by the flash utility, one for the F1 configuration (writes to a MP.INI file) and one for the F2 configuration (writes to the QC.INI file). In here, we can set the UFD to be a Fixed Disk:

You will find all of the necessary information from the GetInfo screen for the Controller, FC1-FC2 settings, the VID and PID’s, etc. Once you have your settings in place, hit save to write them to the MP.ini file. From there, you can use the MPALL F1 utility to write the configuration to the UFD. When performing this procedure, ensure that ONLY the UFD you want to program is connected. Insert the USB flash drive, click the Update button which will populate the various boxes with ANY UFD found that has a Phison controller. Once it’s detected, click Start to program.

Once F1 is done, you’ll need to do the same for F2. I was unable to get it to successfully update the F2 settings using any of the versions, however, even though the MPALL F2 utility reported an error, GetInfo did show that both F1 + F2 where set on the controller after the update. A few notes that may save you some time:

  •  I’m not sure where the “MAPPING” setting comes from, but when I created my MP.INI and QC.INI files using the ParamEditor utilities, the MPALL utilities would not find my UFD. I had to add MAPPING=0 to the Configuration section of both files.
  • The Inquiry Version of my UFD was PMAP to start and though I had it set in MP.INI, the MPALL F1 utility changed to to DL07. Because of this, my QC.ini had to have Inquiry Version set to DL07 in to avoid a Incorrect Inquiry Version error message.

Once this is done properly, the partition will show as a fixed disk:

Now that we have a UFD with the RMB set to 0, we can proceed with deploying Windows 8 to it. Obviously, the FAT32 partition the pre-format created won’t work for Windows 8, so we’ll need to clean out that information. We’ll use diskpart for this – run the following commands from a command prompt:

select disk X
create partition primary
format FS=NTFS quick

This will delete the existing partition table, create a new primary partition and mark it as active and then format it as NTFS. Now, we can use the imagex utility (available as part of the WAIK) to apply the install.wim file to the UFD. Either mount the ISO or insert the DVD and apply the image to the UFD:

imagex /apply F:\sources\install.wim 4 G:\

The number 4 is the index of the image in the WIM file to be applied. The Windows 8 beta media has multiple available (Standard Core, Standard w/ GUI, Datacenter Core, and Datacenter w/ GUI) so I’m applying Datacenter w/ GUI by selecting index 4. You can read the available options by using the imagex /info F:\sources\install.wim command. Once the image has been applied, we need to write a boot record using bcdboot:

bcdboot G:\windows /s G:\

If you’ve done everything correctly, you should now have a bootable UFD with a base install of Windows 8 Server that is recognized as a non-removable hard disk:

HP Proliant MicroServer

I have been wanting to upgrade my home server for quite some time and have been eyeballing WHS machines as I was looking for something with a small footprint. While I would normally build my own system, cases for mini-ITX boards that have space for at least 4 HDD’s are quite expensive. In fact, the only one I could find that really fit the bill was the Chenbro case. I also had my eye on the ACER H340 series (now H341 and H342), but when I found the HP Proliant MicroServer, it was exactly what I was looking for.

A quick peek at the specs:

  • AMD Athlon II Neo N36L Dual-Core processor @ 1.3GHz w/ 2M L2 cache
  • 2 DIMM slots supporting up to 8GB DDR3 PC3-10600E unbuffered ECC RAM @ 800MHz (while ECC is supported, it is not required)
  • AMD RS785E/SB820M Chipset
  • Integrated SATA controller with RAID0,1 (this is done in the driver)
  • 4-port SATA backplane supports up to 4x2TB LFF SATA drives (ships with single 160GB HDD)
  • Single ODD SATA port (forced IDE mode)
  • Embedded Broadcom NC107i PCI Express Gigabit Ethernet Server Adapter supports PXE & WOL
  • Onboard VGA with 128MB shared video RAM
  • 1x PCI-e Gen2 16x half-height full length slot (max 25W)
  • 1x PCI-e Gen2 1x half-height full length slot
  • 7 USB ports (4 on the front, 2 in the back, 1 internal)
  • 1 rear eSATA port
  • 200W 1U Flex ATX Power Supply
  • Trusted Platform Module support
  • IPMI 2.0 compliant
  • Optional ILO management card

I made a few small modifications to the base configuration by adding 2x4GB PC3-10666 DDR3 RAM modules (this was non-ECC consumer grade RAM), a CD/DVD-ROM drive, 2x1TB Western Digital Caviar Green HDD’s, and a 16GB Patriot memory stick (to run ESXi). The integrated CPU supports AMD-V and XD bit required for virtualization, so running ESXi (and I suspect Hyper-V) works fine. The system itself is light-weight and the perfect size (10.5″ x 8.3″ x 10.2″). With the exception of the HDD caddies, the case is very sturdy – metal all around.

Great compact design in my opinion. Cables are routed well and the motherboard is mounted to a tray secured by two thumb screws. You need to disconnect cables and remove the motherboard in order to install PCI-e cards and RAM.

You’ll notice what looks like a PCI-e x4 slot on the motherboard. That’s actually for the optional remote management card and adding it will cover the PCI-e x1 slot. The motherboard sits underneath the HDD housing, so RAM with certain size heat-spreaders may not fit. The internal USB connection is in the lower left-hand corner of the motherboard. You’ll notice there is plenty of room for a large USB flash drive if you so choose.

The HDD drive caddies are plastic and the backplane has necessary SATA connections. Screws are located on the bottom inside the front door. There’s also a handy torx driver for working on the system.

Plenty of clearance for the USB flash drive that will hold the ESXi installation.

As far as the ESXi installation goes, couldn’t be simpler. I attempted to use SYSLINUX to install ESXi from a USB flash drive, but couldn’t get the installation going so I hit Best Buy for a cheap SATA CD/DVD-ROM drive. Note that the system has just a standard Molex power connector for the ODD, so you’ll need to purchase a  Molex to SATA power cable. Total installation time was only about 10 minutes. I am using the supplied 160GB for VMDK storage and will use RDM for the 1TB HDD’s to create a software R1 array since the embedded RAID controller is not supported by ESXi.

While 8GB of RAM won’t be enough to virtualize a datacenter, there should be plenty of RAM to run a few Virtual Machines. I was able to P2V my domain controller (was an Optiplex GX1 PII 400MHz box with 256MB – I know … well past it’s prime) in about an hour (only had 100Mbps nic) and am currently downloading Windows Home Server codename Vail to test out WHS in a virtual machine. All-in-all, if you’re looking for a home server or virtual test lab, this box is a great fit!

Partition Alignment

Squeezing every ounce of performance out of your disk array is critical in IO intensive applications. Most times, this is simply an after-thought. However, doing a little leg-work during the implementation phase can go a long way to increasing the performance of your application. Aligning partitions is a great idea for SQL and virtualized environments – these are the places you will see the most benefit.

The concept of aligning partitions is actually quite simple and applies to SAN’s and really any disk array alike. If you are using RAID in any capacity, then aligning disk partitions will help increase performance. It is best illustrated by the following graphics, borrowed from (This is a great read, but specific to VMWare environments, however, the same concepts apply).

Using unaligned partitions in a virtual environment, you can see that a read could ultimately result in 3 disks accesses to the underlying disk subsystem:

By aligning partitions properly, that same read results in just 1 disk access:

While these graphics are Virtual Machine and VMWare specific, the same is true for Hyper-V and SQL (except remove the middle layer for SQL). In order for partition alignment to work properly, you need to ensure that the lowest level of the disk sub-system has the highest segment size (also referred to as stripe size). Depending upon your RAID controller or SAN, this could default to as low as 4K or as high as 1024K. I won’t cover what differences in segment sizes mean for performance, that’s an entirely difference discussion, but generally speaking defaults are usually 64K or 128K. The basic idea behind a proper stripe size is that you want to size it so that most of your reads/writes can happen in 1 operation.

From there, you need to ensure that your block or file allocation unit size is set properly – ideally smaller or the same size as the segment size and that it is a multiple of the segment size. Lastly, you should then set the offset to the same as the segment size. By default, Windows 2003 will offset by 31.5K, Windows 2008 by 1024K, and VMWare VMFS default’s to 128.

Setting the segment size may or may not be an online operation – that depends entirely on your RAID controller or SAN as to whether this can be done to an already configured array or if it has to be done during the initial configuration. Changing the offset and/or block size of a partition however is NOT an online operation. This means that all data will have to be removed from the partition, the offset configured, and the partition recreated. Prior to Windows 2008, this cannot be done to system partitions so for Windows 2003, you would have to attach the virtual hard disk to another system, set the offset and format the partition, and then perform the windows installation.

The following links provide detailed information about aligning partitions in both VMWare and Windows. Consult your SAN or RAID controller documentation for setting or finding out the segment size.

Recommendations for Aligning VMFS Partitions

Disk Partition Alignment Best Practices for SQL Server