VMware Flings are a curious concept. Not quite production code, yet not quite hobby code either. However, it’s a veritable goldmine of useful tools and applications to complement, manage and augment your VMware estate. For example, Auto Deploy is a very useful feature of vSphere, but I don’t see a lot of it in the wild as most folks think it’s a little too “command line” to be worth the effort. Having to do most of the work in PowerShell puts a lot of people off (and I have to say, I don’t blame them. I winced when it came up on my VCAP-DCA exam). So what has someone done? Written a GUI tool for it. A solution that fixed a problem, not a solution looking for a problem.

I’m not here to discuss that one, however. I’m primarily an EUC boy and there are several useful (did I say free?) tools on VMware Flings that can bail out your average Horizon View Joe. One of which is ViewDbChk. Yes, I know it doesn’t have a fancy name, but it’s a true bacon saver in the sense that I found myself saying “Wow, ViewDbChk really saved my bacon there”. As View folks will know, data is splattered across various different repositories, including a database for View Events, a database for View Composer, a database for vCenter and the ADAM/LDS database, replicated between the Connection Servers.

This is where ViewDBChk comes into play. On occasion, what is seen in vCenter and what is shown in View Administrator can get a little out of whack, and this can slow you down or cause you unforeseen issues. For example, if you’re plain impatient like me, you may find that a pool deletion has apparently hung, so you help it along by manually torching some VMs and replica VMs from vCenter (in the lab, obviously. Never in the real world!). At this point the delete task can get stalled because there are now no objects for View to refer to, or things could be the other way around where View has left orphaned VMs behind in vCenter and you just need to perform a little housekeeping. ViewDbChk is really useful in performing this clean sweep and keeping your vCenter and View installations in perfect sync.

To use the tool, first download it from the Flings website, unzip and copy the files over to any Connection Server in your View installation you want to tidy up. Then you need to start a command prompt as ViewDBChk is a command line tool, ensuring you right click and use the “Run As Administrator” option, otherwise you’ll get some fairly cryptic errors and this caught me out at first. From your Administrator command prompt, run ViewDbChk –scanMachines. This will run through and check your View estate for issues, as shown below (desktop/pool names redacted!) :-

From this point on it’s really just a case of following the bouncing ball. One word to note is that for me, just typing “y” or “n” for the questions did not seem to work properly, so I just typed in “yes” and “no”. Obviously for the tool to work it’s magic, you kind of have to let it do it’s thing 😉

Once some duff VMs have been found, you are asked to disable the pool affected. Then as shown below, the affected VMs are listed with the reason for the ongoing issue, in this case the master VM or snapshot couldn’t be found in vCenter (ooops!). At this point the tool will ask you if you want it to tidy that up. Say yes and the tool will do the rest. Once all affected VMs have been cleaned up, you are then prompted to re-enable the pool, as per the screen shot below.

This is all well and good for a couple of VMs, but what if your View environment is in a stinky old state? Well you can add switches to the tool to force through a tidy up without having to constantly say “yes”. Also worth bearing in mind is the in built limit of 5 VMs before you have to run the tool again. To circumvent this, use the command ViewDBChk –scanMachines –force –limit 100 to set an upper limit of 100 VMs (or whatever you deem appropriate).

Props to Griff James for this cool tool, and happy flinging!!