Quickly cooking the quickbooks books

Several of our customers run the intuit software quickbooks as their accounting package.

In some instances (seems to be when saving  a new customer or supplier) the software crashes and leaves the database in an un-usable state. To fix the problem you have to run the quickbooks file doctor.

So, with the normal "it worked for me, YMMV, At your own risk..." this is how I fix it;

On the server (or the workstation hosting the files)
logon as an admin user (just to make sure)
run services.msc as administrator
stop
1/ qbcfMonitorService
2/ quickbooksDB23
copy quick books company file file to desktop from it's normal home;

run file doctor as administrator
pick the correct file
enter the QB Admin password

whilst it's analysing the file
select all files from the data file sub directory and cut them
(not the shortcut to backups or any of the folders)
goto your quickbooks backup folder
create a directory called "file recovery <todays date>"
Ener that directory and paste the files cut earlier
Go back to the analysis window, which will probably still be going...

When prompted tell it you are on the server
close the browser window that it opens for you
close the file doctor
cut the (now repaired) company file from the desktop and paste it back to it's correct location
check the two services stopped previously are started again (the file doctor normally does this)

browse to the company file VIA THE NETWORK (not locally)
double click the data file to open quickbooks.
logon as the qb admin user
switch to single user mode (file, switch to single user mode)
(you may need to get people to log out if anyone is on)

go to the banking menu then write cheques
click "pay to the order of" then press CTRL + L
close the name list and the cheque writing window

Click File, Utilities, Verify (this takes a few mins)
When it finishes open qbwin.log
Open in notepad and find all occurrences of "duplicate" names and id numbers

File, utilities, Rebuild
Pick the same folder you created erlier to backup the data files too

switch too multi user mode

email someone at the customers the duplicate names

Virtual Machine Host, hard drive config

This is going to be post one of probably 6 or so (If I do them all) relating to how I have gone about setting up Virtual Machines Hosts at various sites. It is mostly to act as an aid memoir for myself but if it helps anyone else then that's a good thing.

Moving virtual machines between hosts works a lot better if the 2 hosts are configured the same way. I want to try and standardize the way I setup VM Hosts to make life easier down the line. The first thing I am looking at is how I have the VM disk images stored on the host.

All the advise seems to point to using LVM to manage your disk images. This makes sense as it means it's easy to resize the virtual disk and easy to change the underlying physical disk architecture without disturbing the virtual disks.

The standard layout we will be using will have a disk (or array) for the Host Operating System and then one or more disks (or arrays) for the virtual machines to live on. By putting the host os on a separate drive I hope to keep the VM Disk IO load away from the physical host so it does not degrade performance. On hosts where there are lots of drive bays I will probably create multiple arrays to serve different functions. One example may be to have 2 x 1TB SAS disks in a mirror for the OS' and 4 x 2TB SATA disks in raid 5 for the data.

My plan is to have, as standard, two volume groups called "VM OS Disks01" and "VM Data Disks01". It should not matter which physical disk they are located on as long as the VG names are consistent across servers. In situations where there are multiple disks we may have Disks02, Disks03, Disks04 etc in addition to the 2 standard ones.

There also seems to be some discussion (*) as to the best way to create a Physical Volume if you are using the entire disk. One option is to use the raw device the other is to create a partition table and one primary partition. The raw disk approach requires less setup but could cause issues if someone looks at the disk with, say fdisk as it would appear to be empty...The SAFE method would appear to be to create a partition table and one partition that uses the whole disk and then create the PV on that partition however the most flexible (if your admins are not idiots) is to use the block device.

For this example I want to put two VGs on one disk. Each VG takes up an entire PV and each PV takes an entire device so I'm going create a partition table with 2 partitions so that I can create 2 PV's one for each VG. The "disk" I am using is actually a 6TB raid 5 array on 4 x 2TB disks being managed by a HP raid card.

So, to the setup;

Create a partition table
parted /dev/sdb mklabel gpt

Create 2 partitions
parted /dev/sdb mkpart primary 0GB 2000GB
parted /dev/sdb mkpart primary 2000GB 6000GB

Create 2 physical volumes, one on each partition
pvcreate <your device name>
pvcreate /dev/sdb1
pvcreate /dev/sdb2

Create 2 volume group. They could contain several PVs for fault tolerance but we only have the one as the hardware is worrying about sorting the disk out for us.
vgcreate <VG name> <pv device(s)>
vgcreate vm_os_disks01 /dev/sdb1
vgcreate vm_data_disks01 /dev/sdb2

Create some logical volumes (more a practice than a requirement at this stage)
lvcreate -L <size> -n <volume name> <vg it should be housed in>
lvcreate -L 128G -n Ubuntu-test-OS-01 VM_OS_Disks01
lvcreate -L 500G -n Ubuntu-test-Datastore-01 VM_data_Disks01
lvcreate -L 500G -n Ubuntu-test-Datastore-02 VM_data_Disks01
lvcreate -L 500G -n Ubuntu-test-Datastore-02 VM_data_Disks01
lvcreate -L 160G -n Windows_7-OS-01 VM_OS_Disks01


* http://serverfault.com/questions/439022/does-lvm-need-a-partition-table