Friday, 27 January 2012

ESXi 5.0 Dell PERC 6i Health Status Monitoring

Dell UPS shut down software for ESXi installations

Looks like Dell have finally sorted out the UPS shut down software for ESXi and vCenter.

Quick guide:
Download the software from the link below. Install the MUMC on the vCenter server if it's physical. Open the web console. Default username admin password admin
Under system and 'edit module settings' enable Virtualization.

After the new virtaulization submenu appears you can add the vCenter instance.

You should now see a new tab in vSphere client when you click on vCenter instance at the top of the tree.

Software download:

User guide:

YouTube guide:

Old software :(

Tuesday, 24 January 2012

OpenManage Support for VMware ESXi 5.0

This page outlines OPENMANAGE SUPPORT FOR VMWARE ESXi 5.0 / vSphere v5.0

(Updated 12/12/2011)
Dell OpenManage Server Administrator agent officially supports vSphere v5.0 / ESXi 5 as of December 2011, starting with OMSA 6.5 A02.
Dell uses VMware's VIB mechanism to load the Dell OpenManage Server Administrator (OMSA) monitoring agent into ESXi. To complete the install, you will need to download the OpenManage 6.5 A02 OMSA vCenter Install Bundle (VIB). 
For instructions on how to install OpenManage Server Administrator 6.5 A02 on VMware ESXi, refer to theOpenManage 6.5 Server Administrator A02 ESXi 5.0 Tech Sheet.
For full documentation and support information about OpenManage and ESXi 5, visit the OpenManage 6.5 Server Administrator A02 Documentation page.

Monitoring Consoles
The OpenManage Essentials console allows you to monitor your ESXi5.0 systems in a one to many fashion. For more information about OME, visit
If you are interested in using the VMware vSphere console for managing your physical and virtual servers, consult the Dell TechCenter page outlining the Dell Management Plug-in for VMware vCenter.

Legacy Info:
Prior to December 2011, OMSA 6.5 A01 only partially supported ESX5i with caveats. Historical information is avalable in this document that outlined limited Dell OpenManage 6.5 A01 support of ESXi 5 . The content is provided “as is” and without express or implied warranties of any kind.

Tuesday, 17 January 2012

.NET bases applications are slow to load or certain in-app tasks are slow

This behaviour will occur with any .NET 1.1 and 2.0 assembly that is authenticode-signed, not only Measurement Studio assemblies. Digital signing is also referred to as code signing. Code signing a .NET library is strongly recommended by Microsoft, and Measurement Studio signs all of our ActiveX and .NET components.

Code signing of assemblies makes components tamper-proof and ensures that you know the identity of the component publisher.

The reason why this problem is occurring is because of the mechanism used by the .NET Common Language Runtime (CLR) to verify code-signed .NET assemblies. Part of the verification process requires an online look-up to check whether the certificate with which the assembly is signed has been revoked and is no longer valid. Windows does this by downloading a CRL (Certificate Revocation List). The first time a code-signed assembly is loaded by the .NET CLR, the CRL is downloaded from the certificate provider's server and cached on the system.

When the .NET CLR loads a code-signed assembly and is unable to reach the CRL distribution point, it records the failure as an inability to provide the assembly evidence that it was code-signed. So the assembly is allowed to load, but is not marked as being digitally signed. There is a 15 second delay for CRL retrievals. This is how long the CLR will keep on re-trying to download the CRL before it finally times out. So the delay in loading the .NET assembly occurs because Windows is unable to download the CRL and keeps trying to download it for 15 seconds before timing out.

This behavior is by design.

The .NET CLR will not indicate any error or throw any security exception when verifying a signed assembly if the CRL distribution point cannot be reached. An error here from 
WinVerifyTrust(), the API used by the .NET CLR to verify a code signed assembly, prevents the assembly from being marked as code signed. Note that this does not apply to assemblies loaded thru the Internet Explorer hosting interface.

You could manually download the CRL and install it on your system. But the CRL is valid only for 10-15 days, so unless your system is able to update the file after this time, you will run into the same problem again.

Microsoft recommends disabling CRL checking as a workaround by disabling this option in Internet Explorer. Use the following steps to disable the CRL checking in Internet Explorer:
  1. Select Start»Control Panel
  2. Double-click Internet Options
  3. Select the Advanced tab. 
  4. In the Security section, uncheck the Check for publisher's certificate revocation option.
By disabling the CRL checking using the Internet Options, you are not exposing yourself to a security threat because this check is not working. The reason why this problem is showing up is because your network settings are not allowing Windows to access the CRL.

In addition, it is possible to programmatically set the CRL verification. When the 
Check for publisher's certificate revocation is unchecked, a setting in the registry is changed. To turn off CRL verification, set HKCU\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing\State  from 0x00023c00 to 0x00023e00. To turn CRL Checking on again, reset the State key to 0x00023c00

Disabling IPv6 in Windows 2008

Unticking IPv6 in the NIC settings only disables IPV6 for that NIC. This does not apply to sudo NIC like Intra-Site Automatic Tunnel Addressing Protocol (ISATAP), 6to4 and Teredo. To disable this to the system open and CMD prompt with elevated privileges and execute this command:

reg add hklm\system\currentcontrolset\services\tcpip6\parameters /v DisabledComponents /t REG_DWORD /d 4294967295

Further reading:

Friday, 6 January 2012

Disabling network offloading in Windows

There is some useful info on offloading on this website
But in my opinion it is still best to disable offloading. One example is the Microsoft Small Business Server best practices analyser recommends it, now why would Microsoft do this if it was not for the best.

To Determine the current state of offloading on the system issue these commands:

netsh int ip show global
netsh int tcp show global

To disable offloading issue these commands:

netsh int tcp set global rss=disabled
netsh int ip set global taskoffload=disabled
netsh int tcp set global autotuning=disabled
netsh int tcp set global congestion=none
netsh int tcp set global chimney=disabled

Remember this only disables offloading within the OS kernal, NOT the NICs! You can use the BACS control suite or the Intel driver options to disable this on the adapter.