Month: September 2009

Running trixbox on Hyper-V 2008 R2

Previously, I’ve never had much success running trixbox within a virtual environment, but I decided to revisit the possibility with the recent release of Windows Server 2008 R2 and the latest version of trixbox (currently 2.8) and this time had much greater success.

The only thing I had to do was install the Microsoft Hyper-V Integration Components for Linux on the machine and set the kernel parameters appropriately (as described below).

You can download the .iso from Microsoft at http://www.microsoft.com/downloads/details.aspx?displaylang=en&FamilyID=ab7f4983-93c5-4a70-8c79-0642f0d59ec2.

Currently, CentOS/RedHat doesn’t appear to be supported by Microsoft, but following the steps below will allow you to install the appropriate drivers (and confirm a successful intallation): –

  • Mount the downloaded .iso on your trixbox machine
  • Install the kernel-devel and gcc (GNU Compiler Collection) packages by running the commands below

yum install kernel-devel

yum install gcc

  •  Now you’ll need to mount the CD ROM using these commands

mkdir -p /mnt/cdrom

mount /dev/cdrom /mnt/cdrom

  • Copy the contents of the CD to the local machine

cp -rp /mnt/cdrom /opt/linux_ic

  • Unmount the CD ROM

umount /mnt/cdrom

  • Run the driver setup

cd /opt/linux_ic

./setup.pl drivers

  • Set the kernel boot parameters as per this article
  • You’ll need to restart to initialise the drivers

shutdown -r now

  • When the machine is back up and running, make sure the drivers are loaded by running the command below

lsmod | grep vsc

  • This should give you a result similar to the following

netvsc

storvsc

blkvsc

vmbus

scsi_mod

Now you have the integration components installed, configure the rest of the options on your trixbox and test it out. I allocated mine 512MB RAM, and it doesn’t skip a beat while I performed audio streaming tests.

Getting “The version does not match a supported version” when trying to configure SQL 2005 Reporting Services

Recently I had to uninstall and re-install SQL 2005 Reporting Services for SCOM 2007 R2.

While configuring it using the Reporting Services Configuration Manager, under the Database Setup tab I was prompted to upgrade the database version. When I clicked OK, I got the following messages: –

The database version (C.0.8.40) does not match your Reporting Services installation. You must upgrade your Reporting Services database.

And then: –

Couldn’t generate the upgrade script. There is no upgrade script available for this database version.

Which had further details: –

ReportServicesConfigUI.WMIProvider.WMIProviderException: The version does not match a supported version.

Additionally, trying to access the reporting page via my browser gave me this error: –

The version of the report server database is either in a format that is not valid, or it cannot be read. The found version is ‘Unknown’. The expected version is ‘C.0.8.40’. To continue, update the version of the report server database and verify access rights. (rsInvalidReportServerDatabase)

The upgrade was failing because of a version mismatch, and this was caused by the Reporting Services component being installed individually from the SQL core services. The solution was to apply the latest service pack (SP3) to the SQL installation, which re-aligned the versions and allowed the ReportServer database to be upgraded via the Reporting Services Configuration Manager.

Linux (specifically CentOS running trixbox) gains excessive time on system clock

I found this issue specifically on CentOS running the trixbox telephony software, where over a 12 hour period my system clock had gained over 3 hours of extra time.

This is not a good thing for VoIP, as it relies heavily on time for RTP packet switching.

I also had a compounding issue of my system locking up whenever I tried to perform an NTP update from one of my domain controllers, with an error similar to the following: –

BUG: soft lockup – CPU#0 stuck for 10s! [bash:2513]
EIP: 0060:[<c06100b8>]

dahdi_dummy_timer

It turns out that this service is particularly time sensitive, and the very large time step incurred by an NTP update causes it to lock up until the time is back in phase, but in my case that will never happen because of the rate that the system is gaining time.

My solution was to disable ACPI and APIC at boot time, prevent the dahdi service from starting at runtime and then perform an NTP update and update the hardware clock with the system time by performing the following steps: –

  1. Modified the kernel boot options by modifying the boot loader config file (trixbox uses grub, so I had to edit “/boot/grub/grub.conf” to add “divider=10 clocksource=acpi_pm” after the appropriate kernel line
  2. Ran “chkconfig dahdi off” to prevent the dahdi service from automatically starting
  3. Restart
  4. Ran “ntpdate -u <NTP server IP>” to update the time
  5. Ran “hwclock –systohc” to update the hardware clock from the system clock
  6. Ran “chkconfig dahdi on” to allow the dahdi service to start automatically again

Now the time is accurate and my VoIP calls are working properly.

“Failed to register service principal name” on Hyper-V host

I recently replaced one of my Hyper-V hosts with Windows Server 2008 R2, and noticed that I was getting the following event logged every two minutes: –

Log Name:      Microsoft-Windows-Hyper-V-VMMS-Admin
Source:        Microsoft-Windows-Hyper-V-VMMS
Date:          20/09/2009 5:52:42 PM
Event ID:      14050
Task Category: None
Level:         Error
Keywords:    �
User:          SYSTEM
Computer:      HyperV01.mydomain.internal
Description:
Failed to register service principal name.

 I was nearly certain that this was due to the fact that I hadn’t removed the computer from the domain before rebuilding it, and therefore it had acquired the old computer account when it was re-joined. This error indicates that there was an error updating the “servicePrincipalName” attribute of the computer account for my Hyper-V server.

I jumped in to my Active Directory to check out the permissions of the computer account first, and the first thing I noticed was that there was an unresolvable SID in my ACL. This wasn’t causing the issue, but it was a good indication that the permissions were probably in need of attention.

To understand how to resolve this issue, it’s important to understand what’s failing. In this case, we can see from the event 14050, that the SYSTEM account on my Hyper-V host tried to update the servicePrincipalAttribute of it’s own computer account within Active Directory, but failed. We believe it’s a permissions issue, so we should check the “SELF” entry in the ACL to see if it has the correct permissions: –

 

…And bingo! The “SELF” entry is missing the “Validated write to service principal name” permissions, so therefore it can’t write the attribute. “SELF” in this case, corresponds to the SYSTEM account of the host that owns the computer account.

So I went ahead and granted this permission to the computer account, and confirmed that the servicePrincipalName attribute updated on next attempt and that the events were no longer being logged.

Windows Server 2008 domain controller blue screens on startup with STOP: c00002e2

Earlier in the year, I had a hardware issue which brought down one of my Hyper-V servers (and my virtual web server hosting this website along with it). When I finally resolved the issue (I had a faulty hard disk), I had to re-install Windows Server 2008 on the Hyper-V server and then bring all of my virtual machines back online. I wrote down my resolution steps, and now have finally had some time to share this.

I used Virtual Machine Manager 2008 to add the rebuilt server back in as a library server, and then copied my virtual machine files in to the Virtual Library share so that it would pick up the machines.

Each of my virtual hosts have two disks – One for the operating system, and one for the data. This meant that after I had finished creating the “new” VM using the .vhd containing the OS for each machine, I had to go back and attach the data .vhd as well.

It seems that when you do this (for whatever reason) the disk is not brought back online automatically. As I have my Active Directory database stored on my data drive, when the domain controller attempts to access the database, it can’t so it blue screens and then restarts. I don’t believe that this is the behaviour on Windows Server 2003 machines, so I am assuming it’s either the behaviour for Windows Server 2008 or maybe it’s just the Server Core install of Windows Server 2008.

In a nutshell, playing around with the virtual disks for a Windows Server 2008 domain controller can cause a lot of grief. If you ever get a BSoD with this message – “STOP: c00002e2 Directory Services could not start because of the following error: A device attached to the system is not functioning. Error Status: 0xc0000001. Please shutdown this system and reboot into Directory Services Restore Mode, check the event log for more detailed information.” – this just might be the reason.

EDIT (04/04/10): I have revisited this article as I ran in to another situation when moving a virtual machine recently. As F.H.R. stated in the comments below, Windows puts the secondary disk offline. If you bring the disk back online using diskpart or Disk Management, you might still have the same issues.

If you do still have a blue screen after bringing the disk back online, ensure that the disk is initialised. If you are using diskpart, select the disk and then use the command “attrib disk clear readonly” which should bring your domain controller back to life.

If you still have issues, follow the rest of this article.

In order to resolve this issue, I presented a new VHD to the domain controller and booted in to Directory Services Restore Mode. Once I was in there, I was able to move my Active Directory database across to this new disk, swap the drive letters around, and then restart.

I’m not sure why this is necessary, but I can tell you that 7 months later I have used this process a few times when playing around with my domain controllers, and with 100% success.