So I recently showed you how easy it was to install VMware under Redhat. Now lets look at how easy it is to install Windows XP as a guest OS.
First you will need to get a hold of your Windows XP CD ready for the installation, put it into the CD-Rom.
Open up the VMware console and select File > New > Virtual Machine. This will open us the Wizard that will walk us through the installation. Click Next and then select Typical and again click Next. Select Windows XP from the list of operating systems available, you can normally leave the location as its default but remember that you need at least 8Gb (the default) per guest OS that you are installing. I normally choose a bridged network setup, with most network layouts now there is a DHCP server and its easy to add another IP to your network. You can however set it to share its IP with the host system. As you go through the next steps, selecting the defaults is normally good enough. You can tweak if you wish but I am happy to settle for the defaults.
Once all that is complete it will make 8Gb of space available for your install. At this point you can start the guest system and it will then boot from the Windows CD. Continue as normal through the Windows install and you should wind up with a Windows XP installation.
Once it is all up and running I do highly suggest that you install VMware Tools, available by doing VM > VMware Tools. The installer should then pop up and start. You should see the VMware icon in the lower corner by the clock.
Poke around and have fun. All the other OS installs are carried out in much the same manner.
That’s it, a working XP guest installation!
Exchange is a massive enterprise tool and as such you’d expect it to provide a simple method for restoring mail folders. No such luck! Instead a restore on exchange is quite a long process.
First up you need to discover the storage group that your mailbox is in. This requires a quick search on an active directory server. Once you have that you can go on to create a ‘recovery storage group’ linking it to the correct storage group.
Then you start up your TSM restore and recover the storage group (we use TSM as our backup). On our setup that means that you are restoring approximately 20Gb of data. Once thats done (it can take a while), we can then mount the recovery group. At this point we are left with one of two options: copy all the mail and folders into your existing mail account effectively doubling your mail, or you can merge the contents back into your mail so only copying what is missing.
My issue is that neither of these options are really what a use wants. If we copy the mail back, then we effectively double the amount of mail that a user has. If we merge the data back, it can merge e-mails back into folders that maybe the user will not look at, thus leaving behind stray meant-to-be-deleted e-mails. Nine times out of ten all the user has lost is a single folder or a single mail.
The solution to this is to add another step into the process, extract the mailbox from the recovery group into a PST file, then merge the folder out of the PST file back into the mailbox in the main storage group. But even here there is a problem, if you don’t know the exact folder name you can’t find out what it is and therefore cannot restore it.
In reality what is needed here is a solution that allows the administrators the ability to extract individual folders within a mailbox. It is obvious that the exchange restores are built with the intent of only being used in a situation of disaster, total loss of a storage group or something similar. However almost all the restores undertaken will be for single users.
Looking back to the old method we used with exim makes this look even more silly. As there we could simply find the file representing the mail folder and restore it. Done!
Comments