Managing the System Registry Hive on Windows Server 2003 and Windows Server 2008 Integrity Systems
an average of approximately three to four paths are presented to each disk. The reality is that
some disks may have 32 paths and some may have only 2, giving an average that is not very
indicative.
What should be very clear here is that for 156 drives to have 787 volumes, something is definitely
wrong. Either a number of disks have been deleted and represented, or another program is
creating volumes. Reviewing the next section should give more insight into the number of
volumes if Veritas Volume Manager (SFW) is installed on the system.
With this knowledge (the number of actual system drives, paths, and volumes), the next step is
to perform a careful review of the registry entries to determine which entries are stale. For each
ControlSet in the System hive, these stale drives, paths, and volumes should be deleted in order
to reclaim a significant amount of System hive space.
Special Consideration for Symantec Veritas Volume Manager (SFW)
If the system uses Symantec Veritas Volume Manager, it would be a good idea to check how
many volumes are being managed by it. This is done with the following command from a
PowerShell prompt:
($VXVMCount = dir
hklm:\System\ControlSet001\Enum\STORAGE\Volumes\VXVM*).count
This gives the number of Veritas-managed volumes. If this number is larger than the volumes
known to exist, Veritas provide a utility called VxScrub that can delete stale Windows and Veritas
volumes. Please consult the Veritas Volume Manager documentation for use of VxScrub. While
it is a very effective tool, VxScrub does require a mandatory reboot immediately after it deletes
the stale entries.
Working with the SAN Administrator for MPIO Optimizations and SAN Maintenance
Most organizations split their System Administrator and SAN teams. This sometimes leads to
miscommunication. If System hive space is near maximum, then any changes to disks or SAN
devices can lead to additions to the registry without the Administrator's knowledge. A good
example of this is the SCSI key, which in the previous example showed 524 paths. If all of these
paths belonged to one SAN device, and the firmware was upgraded, giving a new identity string
(such as a new firmware level appended to it), then all 524 paths would be replicated. Given this
knowledge, you can see why it is so important for Administrators to know about any changes
to the SAN infrastructure.
The number of paths to a disk may also surprise an Administrator. The MPIO Framework
automatically enables every path to a maximum of 32, even though this might not be desired.
Once the amount of paths is greater than 2, the additional paths are added to increase throughput
to the device. In such cases it is worthwhile to analyze how many paths are needed for both
redundancy and throughput. Given that current storage devices can easily have 4 or 8 ports, as
well as the server having just two dual-port Fibre Channel host bus adapters, it is now possible
for MPIO configurations to reach 32 paths easily. The question Administrators must ask is whether
32 paths are really necessary, since a reduction in paths will reduce the number of entries in the
System hive, and therefore alleviate pressure on the limit.
Introducing the HP Registry Monitor Service
One of the problems with monitoring the System hive without automation is that its true size
can differ from its indicated size. As discussed earlier, whenever elements are deleted, like an
entire ControlSet, that space is marked as free inside the hive, but the size on disk remains the
same. This means the indicated size of the file on disk could be just shy of 32 MB, which may
worry an Administrator, but its true size could be closer to 12 or 13 MB. Since the true size of
the consumed space cannot be gleaned with normal Windows tools, Hewlett-Packard has created
a Management Service that monitors the true size of the System hive, sends an SNMP or WBEM
Proactive Avoidance 21