After performing a physical to virtual conversion one of the tasks you have to do is to set the IP address of the new virtual NIC. When you do this you then get a warning message saying the IP is already assigned to the physical NIC, Windows 2008 is better than 2003 as it at leasts removes it from the old NIC for you.

All the same this seems a bit illogical, that physical NIC is no longer connected to the server so why should it keep the details? Also it can cause confusion for some services as the details are still stored in the registry even though the NIC isn't active. Should you have a dig around there's no trace of it in the Device Manager though, and hacking bits out of the registry isn't a great idea.

The process for removing the old NICs is actually quite simple and I found a good explanation of how to do it here:

http://www.tacktech.com/display.cfm?ttid=419

A few months ago we took over the IT support for an insurance firm in the City, but with the contract we inherited a problem the previous IT company couldn't resolve. Part of the firm's business still ran on a ten year SCO Unix server which was barely clinging to life and hadn't been backed up for three years. They still had a support contract with the original suppliers of the SCO system but they had quoted over £10k to migrate their data to the current platform. The system was running on borrowed time and every reboot could have been its last so we had to come up with a solution.

I finally felt I had time to get round to installing the Windows 7 Beta and see what all the fuss was about for myself. Now I could setup my shiney new Samsung NC10 to dual boot it but I thought it would be best to play it safe and start off with a virtual machine. Apart from the helpful snapshot function in ESX it would also be more team friendly as the rest of the technicians could access it. So I created a new VM on one of our ESX dev servers, assigned it a 12GB virtual disk and attached the 32bit ISO of Windows 7 Beta, then started it. All went according to plan to start with, the standard Windows install questions, a reboot or two and eventually I ended up with a Windows 7 desktop in the console.

 The plan worked for about two minutes until I noticed there was no network connection, and checking the Device Manager showed it knew there was an Ethernet Controller but it couldn't find a suitable driver. The driver update utility looked very similar to the Vista one but of course wanted to look on the Internet so was a non-starter. I thought this was pretty peculiar as you can't get much more standard than VMware virtual devices, and Microsoft must expect users to test a beta in a virtual environment. Suspicious that this might be a cunning ploy to encourage the use of Hyper-V I had a quick Google, expecting a rapid answer.

So we've got a nice fat ESX server running in our training lab with 20 XP VMs installed on it - and a bunch of barely IT literate users each with a desktop PC that is fully locked down so there is no chance of them screwing anything up. We want to give them access to the XP VMs so they can screw those up instead, e.g. see how much malware they can acquire in 10 minutes of unprotected Internet browsing. That means we can't allow any sort of network connection between our nice safe desktops and these VMs, otherwise we're going to get all that malware coming back into our network, which rules out the obvious candidates like RDP or VNC. What we can do though is connect to the VM consoles as our ESX server is all properly vLANned so the VMs are on one network with an Internet connection but our ESX server and desktops are on a completely separate network.

So how do we get those users connected to those consoles?

I've been helping one of the nice people upstairs prepare for some lectures he is going to present for his local community. Its an IT education class but concentrating particularly on domestic users and the dangers of the Internet - malware, phishing and the rest. Now his local council helpfully have a large IT facility with about 50 PCs in it which would be ideal for training except of course they have gone to an awful lot of effort to prevent anyone installing any sort of malware. This makes it impossible to demonstrate to your average home user how easy it is to pickup Internet nastyness on your usual sort of home PC.

 The title rather gives it away, but of course I suggested VMware ESX as the ideal solution, especially since they give it away free now.

We have been using Asterisk for the last four years; it facilitates our distributed model of operation, effectively bridging the gap between traditional PSTN and VoIP. Asterisk enables us to bring important customer calls into our head office via trustworthy ISDN technology whilst at the same time linking branch offices and remote users via VoIP. If we cannot make an outbound call with our SIP and IAX2 trunks, we simply fall back to ISDN.

Many organisations use Asterisk in conjunction with the Trixbox CE distribution to give an excellent administration front-end with FreePBX and good presence management with Hudlite. FreePBX has a poorly documented feature which allows you to separate devices from users. Therefore as users move through our distributed network, they associate themselves with a device by logging in. Calls can transparently be connected with the user rather than using traditional extensions which do not move. Unfortunately Hudlite does not currently support users and devices, forcing us to stay with device only calls if we wish to retain its features.

 We really did not want to make this choice, we wanted rich presence management, integration with messaging, mobility of users and full logging via a searchable database. We therefore decided to look at Microsoft Office Communications Server (OCS). OCS has come on a long way in the last four years and with OCS 2007 R2 just round the corner and the excellent desktop and PDA client, Communicator 2007, it has a promising future.

We recently had an enquiry from a client who has around 150 Linux servers in about 20 data centres scattered around the UK. They have a perfectly effective backup solution but were interested in improving their Disaster Recovery, in particular how to speed up recovery of a server in the event of hardware failure. In particular they wanted a solution that would allow them to take complete system images that when required could be quickly restored to a replacement server. Not only that but it had to be doable remotely and by a non-Linux technician following a simple sheet of instructions.