The transaction log for database ‘VIM_VCDB’ is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

Recently I have gotten this error on a couple of vCenter servers I manage, due to them using SQL Express installs for the VCDB and then having a large number of deletes occur on events & tasks. The reason for the message is that by default the SQL express DB log file is limited to 500MB and the deletes fill the log up. Now all the “fixes” I’ve found by searching for the error in the title simply say “change the limit” so it doesn’t fill up. Which I don’t really like as a fix as it’s a workaround, especially as the log file on one of the servers had to grow to around 15GB, which is insane for a 2GB DB.

Instead I started looking for a way to get this back under control and in the end I had to search for the database being full, which lead me to http://bohemiangrove.co.uk/vmware-vcenter-server-5-5-database-is-full/

Now most of the article was irrelevant to me as I had already performed the tasks purging the DB of old events. However, there is a command at the end of the article:

dbcc shrinkdatabase ( VIM VCDB , 5 )

Now I’m not a SQL admin so I don’t know what sort of affects this might have on the DB (negative or otherwise) but after backing up the DB I ran the command and the DB & Log file both shrank and haven’t grown massively since.

Upgrading ESXi 5.0 host to 5.5

Over the past week I have been trying to upgrade an ESXi 5.0 host to ESXi 5.5 Update 3d. Trying to upgrade it via VUM I would get “Cannot execute upgrade script on host”. Trying to patch the host to the latest 5.0 patches via VUM would generate the “The host returns esxupdate error code:15. The package manager transaction is not successful. Check the Update Manager log files and esxupdate log files for more details.” message.

Checking esxupdate.log, the only error I could find was:

ERROR: An esxupdate error exception was caught:
ERROR: Traceback (most recent call last):
ERROR: File “/usr/sbin/esxupdate”, line 216, in main
ERROR: cmd.Run()
ERROR: File “/build/mts/release/bora-768111/bora/build/esx/release/python-2.6-lib-zip-stage/768111/visor/pylib/python2.6/site-packages/vmware/esx5update/Cmdline.py”, line 144, in Run
ERROR: File “/build/mts/release/bora-768111/bora/build/esx/release/python-2.6-lib-zip-stage/768111/visor/pylib/python2.6/site-packages/vmware/esximage/Transaction.py”, line 243, in InstallVibsFromSources
ERROR: File “/build/mts/release/bora-768111/bora/build/esx/release/python-2.6-lib-zip-stage/768111/visor/pylib/python2.6/site-packages/vmware/esximage/Transaction.py”, line 345, in _installVibs
ERROR: File “/build/mts/release/bora-768111/bora/build/esx/release/python-2.6-lib-zip-stage/768111/visor/pylib/python2.6/site-packages/vmware/esximage/Transaction.py”, line 388, in _validateAndInstallProfile
ERROR: File “/build/mts/release/bora-768111/bora/build/esx/release/python-2.6-lib-zip-stage/768111/visor/pylib/python2.6/site-packages/vmware/esximage/HostImage.py”, line 630, in Stage
ERROR: File “/build/mts/release/bora-768111/bora/build/esx/release/python-2.6-lib-zip-stage/768111/visor/pylib/python2.6/site-packages/vmware/esximage/HostImage.py”, line 463, in _download_and_stage
ERROR: InstallationError: (‘VMware_locker_tools-light_5.0.0-3.90.3982828’, ‘[Errno 32] Broken pipe’)

In VUA.log, the only errors were related to PACKAGE_COMPLIANCE indicating that the 5.5.0 packages weren’t available (as it’s a 5.0.0 host).

So searching around a bit, I found this article:
https://kb.vmware.com/kb/2030665

I tried all the solutions offered in the article, but none worked. Checking the disk space with the vdf -h command showed that there was ample free space on all partitions, as did running df -h. What I had noticed was that the /locker/packages/5.0.0/ folder was missing so I recreated it and attempted to re-run the patching, which would fail. I ended up creating a VMware Workstation image of an ESXi 5.0 host so that I could grab the 5.0.0 folder from it to copy onto the existing host. However it was at this stage, when trying to copy 5.0.0 tools back onto the host using WinSCP, I’d get an error 4. This lead me to again look into the free space on the drive, which I did by logging onto the host via SSH and running:

df -h

This showed that the volume Hypervisor3 was 100% full!

Filesystem   Size    Used Available Use% Mounted on
vfat       285.9M  285.9M     16.0k  100% /vmfs/volumes/Hypervisor3

Investigating the Hypervisor3 store, there were a number of very old zdump.xxx files, amounting to around 100MB in the /vmfs/volumes/Hypervisor3/var/core/ folder. I copied these to my local machine, deleted from the host and re-copied the tools which then completed successfully.

After clearing the space I was still unable to upgrade the host to 5.5, but I was able to remidate with the latest 5.0 patches. Once the host was up to date on the patch level, re-running the upgrade to 5.5 was successful.

Lesson learned from this experience:
Check that there are no old dump files before upgrading a host!

Updated inactive computer accounts script

Original found on Spiceworks forum. Now exports to CSV and replaces computer description with date that script is run.

# This PowerShell Command will query Active Directory and return the computer accounts which have not logged for the past
# 60 days.  You can easily change the number of days from 60 to any number of your choosing.  lastLogonDate is a Human
# Readable conversion of the lastLogonTimeStamp (as far as I am able to discern.  More details about the timestamp can
# be found at technet – http://bit.ly/YpGWXJ  –MWT, 03/12/13

# Activates the required module in PS for this script to work.
import-module activedirectory

# 30 is the number of days from today since the last logon.
$then = (Get-Date).AddDays(-30)

# Generate the CSV for those comuters affected
Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | where-object {$_.DistinguishedName -notlike “*OU To Exclude*”} | Select-Object -property Name,lastLogonDate | sort Name,lastLogonDate | Export-Csv C:\SCRIPTS\Logs\Disabled_Computer_Records-$((Get-Date).ToString(‘yyyy-MM-dd’)).csv -Delimiter “;” -notype

# If you would like to Disable these computer accounts, uncomment the following line:
Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | where-object {$_.DistinguishedName -notlike “*OU To Exclude*”} | Set-ADComputer -Enabled $false -Description “$($_.Description) Disabled by script on $(get-date -format yyyy-MM-dd)”

# If you would like to Remove these computer accounts, uncomment the following line:
# Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Remove-ADComputer

Finding old AD user accounts with powershell

The following is a modified script that I have used to pulling old/inactive user accounts out of AD.

# Activate the required module in PS for this script to work.
import-module activedirectory

# 90 is the number of days from today since the last logon.
$then = (Get-Date).AddDays(-90)

# -Searchbase is OU where user accounts are kept. *Excluded Sub OU* is required if a sub OU Needs to be excluded from the search.
Get-ADUser -Property Name,lastLogonDate -Filter {Enabled -eq $true -and lastLogonDate -lt  $then} -SearchBase “OU=AD Users,DC=Domain,DC=com” | ? {($_.DistinguishedName -notlike “*Excluded Sub OU*”)} | Select-Object -property Name,lastLogonDate | sort Name,lastLogonDate | Export-Csv C:\SCRIPTS\Logs\User_Records.csv -Delimiter “;” -notype

TeamViewer on Converted VM

I installed an SSD into my home ESXi host and wanted to migrate my Windows Home Server onto the SSD. As the SSD was quite small, I had to use VMware Converter to “Convert” the VM to another VM with a reduced disk size.

Afterwards, TeamViewer would not connect if I wasn’t logged into the machine (either via the console or RDP). Every time I tried to connect I got a “WaitforConnectFailed” error. Uninstalling and reinstalling TeamViewer was of no help.

As part of the VM conversion process, VMware Converter strips out the network card and installs a new one. This meant that TeamViewer was somehow binding to the old “hidden” network card which would obviously not connect. Using the instructions in the following article (the instructions work with all versions of Windows from XP upwards), I removed the non-present NIC and voilá, it now works as it should. A fairly unique situation, but one I thought was worth documenting.

DayZ Epoch – Dedicated server reboot

So I’ve recently set up a private dedicated server for DayZ Epoch for myself and a few friends. Because we only have a fairly limited time of day that we can play at (what with working and all), I’m only really concerned with rebooting the server once a week.

The server OS does an auto reboot every week, at 3:45 AM, then to allow any patches to finish installing/configuring, I wait 15 minutes before triggering an ArmA II start at 4:00 AM. The batch file I use is:

@echo off
cd /d E:\DayZ_Epoch_Server
start “” “DayZ_Epoch_instance_11_Chernarus.bat”
taskkill /f /im cmd.exe
@exit

This is called by the Task Scheduler at 4:00 AM which then runs the default bat file, which if you call directly fails.

American IPA

This is the latest homebrew, a Young’s American IPA:

Young's American IPA

Young’s American IPA

It’s highly hopped and at the moment quite bitter and it’s at 6.9% ABV. It’s only just finished it’s secondary fermentation and will get better over the next 4 weeks, so I’ve picked up a few “Commercial” IPA’s to back to back with it and see what it’s like. It’s quite difficult to find IPA’s so strong these days but I’ve managed to get some in the 5.5 – 6.5% range.

Fermentation vessel modifcation

So, over the past 18 months or so I’ve started to get into home brewing. So far I’ve only been dealing with kits, but will be looking to start doing it “properly” (i.e. all-grain brewing) in the not too distant future.

Anyway, my last couple of brews have had very vigorous initial fermentation’s, so much so that they’ve “foamed over”. In order to counter this, I’ve made some modifications to my fermentation vessel lid. It’s only a basic “Young’s” FV so it doesn’t have even an airlock so I’ve added a bung for an airlock and I have also fitted a tap:

FV Lid

The tap will have a length of 1/2″ tube running from it into my bottling bucket, which will have a sterile liquid covering the end of the tube. Then, should I suffer any more foam over, it’ll flow up the tap, down the tube and into the second bucket. This is completely untested, but with the airlock also helping to release a build up of CO2 I reckon it should work. I will update when I’ve done my next brew, but that won’t be for a while as I’m waiting for the last lot to be ready to drink before I start on the next, which should be the end of May.

Powershell Script for disabling computer accounts

I found this script online (can’t remember where exactly), but have modified it to exclude an OU and output to a log file:

<CODE>

# This PowerShell Command will query Active Directory and return the computer accounts which have not logged for the past
# 60 days. You can easily change the number of days from 60 to any number of your choosing. lastLogonDate is a Human
# Readable conversion of the lastLogonTimeStamp (as far as I am able to discern. More details about the timestamp can
# be found at technet – http://bit.ly/YpGWXJ –MWT, 03/12/13

import-module activedirectory # Activates the required module in PS for this script to work.

$then = (Get-Date).AddDays(-30) # The 30 is the number of days from today since the last logon.

Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | where-object {$_.DistinguishedName -notlike “*OU TO EXCLUDE*”} | FT Name,lastLogonDate > C:\SCRIPTS\Stale_Records.log

# If you would like to Disable these computer accounts, uncomment the following line:
# Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Set-ADComputer -Enabled $false

# If you would like to Remove these computer accounts, uncomment the following line:
# Get-ADComputer -Property Name,lastLogonDate -Filter {lastLogonDate -lt $then} | Remove-ADComputer

</CODE>

Mapping drives with SSD’s

So I’ve recently upgraded to SSD’s on most of my machines, along with an upgrade to Windows 8.1 on my main machine. I’ve started to run into an issue where my mapped drive to my NAS don’t reconnect at logon. I’ve been searching the web for a while now seeing if I could work out why this is, but haven’t been successful. Today however, I’ve hit upon the answer; I first mapped the drive via IP rather than name which was successful, so then put the name of the NAS into the HOSTS File. This was also successful, so it definitely appears to be DNS that is affecting it.

I can leave it there, but I’m curious now; what if I stand up a VM on my ESXi host to act as a DNS server for my local network, a job that is currently being handled by the router? I suspect it will be better, but we won’t know until we try!

*Edit: So, before I went through the setup a a DNS server, I decided to try one more thing; all the clients that use my router for DHCP get a connection suffix of “home”, so I changed the drive mapping to connect to \\nas.home\share and that appears to be working. I’ll try it on a few more machines but it looks like that’s the answer here: add the DNS Connection Suffix to your drive map and it should be good to go.