Website Migrated and Theme issues

Whilst trying to make the home page and blog page look the same I managed to break the wp-admin section of my blog. Thanks to the guys at Loho.co.uk they have migrated my whole site to a new platform where I can administer the site more efficiently and I have been able to remove the faulty theme. Hopefully I can fix what I broke but for now its going to be the standard WP theme.

Making Windows Mobile work with Self-Signed certificates

If you try to synchronise a Windows Mobile PDA with Exchange Direct Push using SSL and the certificate is not issued by a Certification Authority (CA) that is in the PDA’s trusted certificate list then the device will not activate. Most commonly I have come across this with SBS servers that use the default self-signed certificate.

The solution should always be to purchase and install a certificate that is issued by a trusted CA to overcome the issue and the PDA will start to work automatically in these cases. If however you don’t want to purchase the certificate then you can bypass the security checks that Windows Mobile imposes on Active Sync. To do this requires you to install the certificate on the PDA and modify the registry to accept the installed certificate as a trusted one.

As each time I have done this I haven’t had the relevant PDA in front of me I have found a useful tool, that saves you trying to talk the end user through making the changes themselves, called My Mobiler (http://mymobiler.com/) which lets you interact with the PDA from your desktop.

  1. Install the certificate on the PDA
    1. Browse to your Outlook Web Access URL in Internet Explorer and save the certificate locally to your desktop by clicking on the padlock icon
    2. Connect the PDA via USB to the PC and allow Active Sync to connect.
    3. Click Explore Device in Active Sync and copy the certificate to the folder that is open
    4. Open File Explorer on the PDA and click on the certificate (it should be in My Documents)
    5. You will likely receive errors that the certificate is not trusted. Click More and then Install
    6. You should receive confirmation the certificate has been installed successfully.
  2. Install PHM RegEdit on your PDA
    1. There are a number of places to download the .cab file on the Internet (link) save this to your desktop
    2. With the PDA connected Explore the device again and copy the .cab file to the device
    3. Open File Explorer and click on the .cab to install it (again it should be in My Documents)
    4. When prompted that the installer cannot be verified click Install
  3. Apply the registry fix
    1. Click Start and select Programs. Scroll down and click on PHM Registry Editor
    2. Expand the following path: HKEY_CURRENT_USERSOFTWAREMicrosoftActiveSyncPartners
    3. You will see a list of GUID keys. Search through these for the one that contains the name “Microsoft Exchange” this is the key you need to modify
    4. Click Edit and select new DWORD
    5. Name the DWORD “Secure” and leave the value as 0
    6. Exit the Registry Editor

If everything has worked correctly your PDA should now synchronise with Exchange

AdminSDHolder groups and Send As

Looked at an issue a colleague had today where the SendAs permissions for a user were being removed automatically from a their account causing issues with their PA not being able to send email as they had configured it. The problem here was that the user in question was in one of the protected AdminSDHolder groups and Active Directory will reset the Send As permissions for members of these groups on an hourly basis.

As well as the ability for another user to Send-As the user in question this can also have implications if you run Blackberry Enterprise Server as the BES Service Account needs Send-As permissions to forward email from a handset to another recipient.

Microsoft have released a KB article on this (907434) which details the situation further but basically the solution should be to remove the user from the groups and if they need to perform the actions granted by the AdminSDHolder groups then they should be given a second “admin” account to perform these tasks.

The list of groups that are affected by the AdminSDHolder changes are:

  • Administrators
  • Account Operators
  • Server Operators
  • Print Operators
  • Backup Operators
  • Domain Admins
  • Schema Admins
  • Enterprise Admins
  • Cert Publishers

ESXi enabling SNMP

Last night I wrote an article about how to monitor the health of an ESXi server (link here) and I wanted to explain a bit more about my findings with SNMP on an ESXi host.

My goal with the monitoring was to use the check_dell and check_hp commands I have found for Nagios/Opsview to monitor the hardware that ESX is running on. The ESXi installs I am working with are using the Dell and HP management agents installed so I thought that everything would work out of the box and enabling SNMP would let me query the different aspects of the hardware.

The official line from VMWare was that SNMP is not enabled on ESXi and with no console cant be enabled. I knew however, having read a recent post on the TechHead blog (link here) that you could see the snmp.xml file and this shows that it is not enabled which made me think it must be possible to enable it. I was right.

A quick google came up with this article and I had a look and this was a fairly simple process to run:

First you need to enter the “unsupported” console on your ESXi server. To do this press Ctrl+Alt+F1 at your ESX console, now type the word unsupported (N.B. you will not see the text on your screen) and press Enter. If all goes well you should see a password prompt, enter your root password here and you should get a warning you are entering a mode that should only be enabled with VMWare support and be presented with a console.

type the following command to enter the VI text editor and start to modify the snmp.xml file:

You should see a single line of text at the top of the screen which is the contents of the xml file. Press i to enter Insert mode and change

to

Then scroll across and add the community name you want the SNMP agent to respond on and place this between the following tags

so it should look like

I wasnt interested in setting up SNMP traps so left this blank and quit the VI editor by press Esc to exit insert mode and then :wq to write the file and quit the editor.

Finally we need to restart the services on the esx host which can be done with the following command

Great, SNMP is now enabled so I should be able to get the information from the HP/Dell management agents that I want. Wrong. My snmpwalk of the host provided little to no useful information about what I was trying to unlock.

My thoughts now are simple. SNMP is not enabled in ESXi for the reason that there is not much there to query and you can use the CIM queries that I mentioned in the previous post to look at this instead.

Monitoring ESXi Server health using Nagios/Opsview

As part of a project I am currently working on I have a requirement to check that my clients’ infrastructure is working to the best of its ability. Whilst we perform regular checks to ensure the sites are running as expected we don’t currently have an easy way to check the health of the ESX hosts that the virtual servers run on. Until now.

I had spent a lot of time trying to “hack” SNMP to be enabled on the ESXi boxes which involved editing the snmp.xml file in the “unsupported” console on the host but after enabling this found that it didnt give me the data I was looking for to run my checks against. Looking a bit further I found a python script which queries the CIM service on the ESX host to find out whether the hardware is working as expected. The script uses the CIM service to check the ESX Health Status and report back to your monitoring platform what the current status of the host is.

Installation is fairly straightforward. The following details are for an Opsview install running on Ubuntu 8.04LTS server but should be easily adaptable to any installation if needs be.

First login to your server as normal and download the latest version of the pywbem module (http://archive.ubuntu.com/ubuntu/pool/universe/p/pywbem/pywbem_0.7.0.orig.tar.gz)

Once you have downloaded the module extract and run the python installer as root

Next you need to download the check_esx_wbem.py script (http://communities.vmware.com/docs/DOC-7170) and place it in your libexec folder

You can test this from the command line using the following command

In the case above I received the following output but if everything is working as expected the script should return “OK”

Now we have confirmed the script is running we need to add it to Opsview. The first step here is to reload Opsview to pickup the new plugin. Once complete goto Configuration -> Service Checks and Create New Service Check. Setup your check in a similar way to the image below (remember to substitute “root” and “Password” with a valid username and password to login to your ESX host

Save this service check and then apply this to your ESX hosts. If you have multiple ESX hosts that have different username and passwords then you don’t need to create multiple Service Checks as the later versions of Opsview let you specify exceptions when you configure the check for a host

Once you have configured this reload Opsview and wait for Opsview to start checking the ESX server(s). Below is the screenshot from my server with its disconnected PSU

This should now allow you  to keep an eye on your ESX hosts alongside the rest of your network monitoring system.