I've been migrating a client to vSphere 4 this weekend and have encountered this problem with all their servers, and its not the first time either so I thought I should share the solution.

This is most common with Dell servers and their so called "OEM" licensing, and its another one of their sly cost-saving measures that you dont notice until they really cause you a hassle. To elaborate a bit more, you  may or may not be aware that OEM stands for Original Equipment Manufacturer, and such a license is supposed to only be used once on the hardware it is supplied with. HP are more honest about their licensing and offer two types of OEM license, Standard and "BIOS Locked", which sometimes appears as "Restricted OEM" if you run a system information tool such as Belarc. The difference is quite major, standard OEM will require re-activation after a significant hardware change whilst BIOS Locked will not re-activate after a change. You can guess which version is cheaper, hence why Dell use it, but its hard to tell beforehand as they do not tag it any differently.


Its always a good idea to use a tool such as Belarc to get a full system report before you start a conversion, here's part of my one:


Dastardly Dell fail to mention that this is actually an OEM-Restricted license....


Since converting a server to a virtual machine represents a significant change of hardware it will initiate the re-activation process, with standard OEM you will just get the popup reminder after you have logged in. BIOS locked OEM however will not let you get past the logon prompt, even in Safe Mode, you have to complete the re-activation process or shut the system down. Seems simple enough until you go through the process, probably having to use the "Telephone" option as you can't configure the network properties beforehand, and after typing all the numbers you will end up with a Microsoft operator telling you to contact Dell (or the original hardware supplier).

You've probably already spent all the time on the phone to Microsoft and Dell getting nowhere, but if you haven't yet then don't bother. The only way you will get it to activate at this stage is to obtain a new OEM product key and I haven't found a way to convince them yet. There is a not too painful solution though, but it might cost you a new license:

You need to obtain a license key for the version of Windows that you are running that you know will activate and the media to go with it. It doesnt matter if your VM is Windows 2003 R1 and you can only get an R2 license and media, this process will still work and you'll get an R2 update as a bonus. Try and make sure that the media is the same service pack level as the VM though otherwise you may get a lot of errors until you can reapply the service packs later.

Boot your VM off the Windows CD you have obtained, if you are using ESX then you will probably have to go into the virtual BIOS and change the boot order first, and the install process will start. Select the option to install Windows and it will run a scan for existing installations on the hard disks, if at this point it says it can't find any hard disks then you need to check what the virtual SCSI controller is. This is only likely to occur with ESX as HyperV and Xen both use IDE, if the controller is "BusLogic" then try changing it to "LSI Logic Parallel" and you should find the installer recognises it next time. 

The Windows Setup routine should find your existing installation so select the option to repair it, then let it run through the re-install process. About halfway through it will prompt you for a product key, enter the new one you have obtained and it should accept it, if not then you haven't got the right media to match the key type - OEM keys need OEM media, Volume License needs VL media and retail needs full retail media. 

There is another issue which sometimes pops up if your server has .Net 2 installed, you may be prompted for the CD2 media as it wants an "install.exe" file, but this isn't anywhere on the Windows Server media. To get round it you have to download the dotnet2 redistributable and use a program such as 7zip to unpack it (you'll see the install.exe in there!) and then another program such as ISOrecorder to turn it into an ISO. Mount your new ISO on the VM and the installer will happily continue, I've also heard the same thing can occur with IE 7 or 8.

Once the installer has completed the server will reboot and this time you should be able to login without any problems. Before you do  anything else though I advise running Windows Update as the repair process will have effectively uninstalled every update released after the media date.

We've just acquired a pair of HP DL380 G6s for our vSphere 4 test lab, they have the new Intel Nehalem Xeon CPUs and chipset with all the latest virtualisation features. Plenty more to come on all that but first of all here's something you won't find in the documentation. Having just installed the ESXi 4.0 hypervisor on the servers the classic question came up from one of the junior technicians - "what's the difference between ESX and ESXi?". Someone else then answered that ESXi doesn't have local console access like ESX does, so all management has to be done from the vSphere client. Although this answer would probably score you points in the VMware exam its not exactly true, as I was able to prove.... This is the same procedure which worked in ESXi 3.5, it still works in 4.0 too. Although VMware do provide a remote CLI appliance that gives you much of the scripting support you'd get with ESX sometimes its much easier to use the console, so once you've got your ESXi4 server up and running at the yellow and black screen do this:
1) Press Alt-F1 2) Type "unsupported" - note you wont see this echoed on the screen, but after you press return you will be prompted for the root password. 3) Enter the password 4) Marvel at "tech support mode"

Whilst you're in there why not give yourself remote SSH access too:
1) type "vi /etc/inetd.conf" 2) remove the # before the SSH line, save and close 3) enter "services.sh restart"
The VI text editor is a good example of how ESXi has been stripped down, its the old school *nix text editor and you will probably have to Google the instructions for it if you haven't used it for a while, but forget about something fancier like Nano. Like its says on the warning page though, this is "unsupported mode", so if you break it don't expect to get any support, you'll just have to re-install. ESX Server was has always been in effect a glorified Linux server, with all the admin and configuration options you would expect from a Linux server. The problem VMware had was that it was getting rather bloated, a standard ESX 3.0 install would use near enough 2GB of disk space and took a good few minutes to boot. In response to this VMware developed ESXi, a lean, mean hypervisor with minimal disk and memory footprint which could then be "embedded" on a server. This fitted in with VMware's vision of the future of virtualisation, where server boxes just become plug and play vSphere resources. It also happened to reduce the functionality enough to not annoy all those people who had paid for ESX when they started to give ESXi away for free :) Reading the VMware documentation you get the impression they rebuilt the ESXi hypervisor from scratch as a dedicated virtualisation OS. In fact it looks more like they went through their last Linux build and simply removed all the stuff which wasn't essential. As a result there is still a Linux based OS under there, and a console you can access, but a lot of the packages you might expect as standard won't be available.

Although proper SSL certificates from providers such as Digicert and Verisign have become much cheaper nowadays there are still many occasions when you might prefer to just use a self signed certificate. One of the most common occurences of this is with SBS server, to provide SSL secured web services such as OWA and RPC over HTTP. However the certificate warning you get everytime you open the web site is annoying and maybe confusing for less experienced users. In older versions of IE you could just install the certificate after viewing it but with the improved security in IE7 and IE8 this no longer works. Whilst putting the URL in your "Trusted Sites" list will let you view and import the certificate you will find it is still not properly trusted. The solution is to provide your users with the correct certificate file to install, but its not obvious where you get this from....

One complaint our helpdesk hears quite often from clients is that "our Internet access seems really slow today", which is a particularly vague and subjective problem. Once the technician has established that this condition is affecting all users and isnt just a temporary period of high demand what can he do to establish the cause of the problem?

 Since it's launch into the mainstream in the 1990's ADSL has become a very cost effective ways for small businesses to perform large amounts of Internet activity without having to pay for expensive corporate level T1 connections.  However as with most things in life "you get what you pay for".  The fundamental problem with low cost ADSL connections is the service level agreement.  We get many calls to our support desk with reports of ADSL downtime, most of which are for brief periods however we have had cases of ADSL connections that have been ‘down' for up to three days.  Because of the organic growth of ADSL the technology  the telephone exchanges are under constant pressure to cope with the sheer demand and resolution of common problems can become a lengthy process.  Some ISPs (Internet Service Providers) are starting to offer response or fix times with meagre compensation but that's of no reassurance to a small business that has been left without email or Internet connectivity for a number of days. 

One low cost workaround is to install a secondary and lower specification ADSL connection (perhaps through an alternative provider to the primary connection) that remains dormant until it is required for failover purposes through an inexpensive router.  If you have your own mail server the mail records could be pointed to both connections so the process is seamless, surprisingly failover has had a very slow uptake.  I'm sure the investment of around £500 a year must be worth a more than business losses through potential email and Internet failure but as they say "you get what you pay for".

Being one for detail I'm amazed every time I receive emails from different users from the same organisation but with differing signatures.  Most of these emails come from small to medium businesses with some really slick marketing in general, in fact one could relate it to somebody wearing a very sharp evening suit with a pair of white sport socks! 

Microsoft seem to have omitted this essential feature which has prompted a host of third party applications available in the market place.  My preference is a product from Exclaimer called Mail utilities for Exchange that simply requires installation on your exchange server.  Not only can it standardise the signatures across your organisation but individual groups can be created to alert the recipients of important company information from differing departments as it integrates with the active directory.  A console can also be created for non technical administrative staff in order to manage the signatures, so there's absolutely no need to get dressed in the dark again!

LES circuits have become increasingly common in recent years for providing high speed WAN links between two sites, usually either between two company offices or between a client site and an ISP PoP (Point of Presence), where it is used to provide Internet connectivity. The limiting factor is usually distance to the nearest PoP as the LES circuit cannot cover more than about 15km so they tend to be limited to city environments. It is based on fibre optic technology but the end connections are presented as standard RJ45 network ports, standard speeds are 10 or 100Mbps, so for practical purposes it is the same as a long CAT5 cable.

There are however a couple of things to look out for when setting up a LES circuit, and there is little documentation generally available:

 

Now you can configure SBS email notification without enabling the SBS health monitoring feature in few simple steps.

Before starting this procedure you need to know why you are doing this:

If you configure default notifications in the Health Monitor of your SBS management console, every time you open or reboot the server, the successful alert will be sent too. So to avoid this situation you need to follow these few steps

I'm not a fan of catchall mailboxes, they are a legacy of POP mail systems and getting Exchange to do it has always been a bodge. However the need arose recently with a client we migrated to SBS2008 so I decided to see what the options are for doing it in Exchange 2007.

We recently installed two LES10 Internet connections at two sites in the South East for a logistics company. Our customer hosts websites and  therefore it was important that downtime was kept to zero.

We installed two Cisco ASA units at each site as an active/standby failover pairs. These firewalls would listen on a different default gateway to the old Internet connections which were still operational. After intial testing all we had to do was to change the default gateways on the approximately 30 servers and modify the DHCP configuration which the desktop PCS would pick up after their current leased expired. One or two desktop PCs had their NICs set with a static IP address but is was easy enough to change to DHCP as users reported problems. Everything appeared to be running nicely with no disruption. We then turned off the old Internet connection making the old default gateway unobtainable.

Soon after we got a support call from the payroll department, they could not access timekeeping data from a device which few people new anything about. We did not have any login information so we called the manufacturer: all we got was a voice mail.  We left a message but no one called us back. In the meantime no one was going to get paid because there was no up to date time keeping information. The payroll department were using PCs on a different subnet to the time keeping device and therefore it could not respond because it was trying to reply through a non existent default gateway.