A nice little bug I've found in the Dell VSM appliance is that if you reinstall it (blowing away the original VM and deploying it from the OVF again) it won't register correctly in vCenter.
Even removing the old vCenter plugin entries through the vCenter web gui won't fix it
The simple workaround is to assign a new IP to the new VM and it'll register fine.
Friday 15 November 2013
Wednesday 9 October 2013
Microsoft product activation fails with error 0x80000048
If you need to activate windows over the phone (e.g. for a server isolated from the internet in say, a DMZ) but get error 0x80000048, you'll need to enable (and start) the Telephony service which seems to be needed to pull up the phone numbers you need to call.
Tuesday 1 October 2013
The updates you are trying to apply are not Dell-authorized updates
If you get the error "The updates you are trying to apply are not Dell-authorized updates" on a Dell Poweredge server when trying to update firmware with the Lifecycle Controller (F10) option, you need to update the DRAC and LC firmware through the DRAC gui (or with RACADM).
You need:
iDRAC – at least version 1.85 or newer
Lifecycle Controller – at least version 1.5.2 or newer
Thursday 26 September 2013
VMware vCenter Support Assistant can't resolve vCenter server name
The vCenter Support Assistant is a free Linux (SUSE) based virtual appliance to aid support requests in a vmware environment.
It's quite easy to setup but it has an odd quirk with DNS resolution.
By default, it will try to connect to the vCenter name you use in your vCenter vi-client, and it will ignore the name you use in the setup wizard to register with vCenter.
e.g. if you register with a FQDN for vCenter, but then use the short name in your Windows vi-client, it will report connectivity from virtual appliance to vCenter FAILS during it's diagnostics checks run at first login.
The solution is to manaually go into the linux console and etc the /etc/resolve.conf file and add a search suffic
1. Open Console
2. Login as root
3. edit the resolve.conf file
vi /etc/resolve.conf
4. append the search suffix to the end of the file
search yourdomain.com
5. save the file
esc
!wq!
6. rerun diagnostics
The last two checks should now pass.
Version of VCSA used was 5.1.1. YMMV with other versions.
It's quite easy to setup but it has an odd quirk with DNS resolution.
By default, it will try to connect to the vCenter name you use in your vCenter vi-client, and it will ignore the name you use in the setup wizard to register with vCenter.
e.g. if you register with a FQDN for vCenter, but then use the short name in your Windows vi-client, it will report connectivity from virtual appliance to vCenter FAILS during it's diagnostics checks run at first login.
The solution is to manaually go into the linux console and etc the /etc/resolve.conf file and add a search suffic
1. Open Console
2. Login as root
3. edit the resolve.conf file
vi /etc/resolve.conf
4. append the search suffix to the end of the file
search yourdomain.com
5. save the file
esc
!wq!
6. rerun diagnostics
The last two checks should now pass.
Thursday 19 September 2013
Validation of Dell OMSA Online Repository in VMware Update Manager Download Sources fails
Dell kindly provide an repository containing all the VMware OpenManage versions that you can point Vmware Update Manager to in order to get the right .VIB for your ESXi server
The Update Manager service needs to be able to access the repository url which is https://vmwaredepot.dell.com/index.xml.
If Vmware Update manager lives behind a firewall then the changes are you'll be pointing it a web proxy (In my case this was ISA 2006). Even though it was allowed unauthenticated access, the validation step kept failing.
A bit of investigation of the firewall logs revealed an odd error:
995 The I/O operation has been aborted because of either a thread exit or an application request
A bit more digging revealed this article, pointing to Java as the culprit. As Update Manager seems to have some Java components, I updated Java to the latest version (JRE7 Update 40), both x32 and x64 but this didn't resolve the issue.
Another read of the original answer from Jim Harrison led me to wonder if a non-SSL connection would work, so I modified the URL to http://vmwaredepot.dell.com/index.xml and hey presto! the validation succeeded.
The full Dell White Paper is located here:
The Update Manager service needs to be able to access the repository url which is https://vmwaredepot.dell.com/index.xml.
If Vmware Update manager lives behind a firewall then the changes are you'll be pointing it a web proxy (In my case this was ISA 2006). Even though it was allowed unauthenticated access, the validation step kept failing.
A bit of investigation of the firewall logs revealed an odd error:
995 The I/O operation has been aborted because of either a thread exit or an application request
A bit more digging revealed this article, pointing to Java as the culprit. As Update Manager seems to have some Java components, I updated Java to the latest version (JRE7 Update 40), both x32 and x64 but this didn't resolve the issue.
Another read of the original answer from Jim Harrison led me to wonder if a non-SSL connection would work, so I modified the URL to http://vmwaredepot.dell.com/index.xml and hey presto! the validation succeeded.
The full Dell White Paper is located here:
Friday 13 September 2013
Can't login after running sysprep?
When running sysprep, the password usually doesn't change unless you get clever with unattended installation scripts.
However if you're using a non-standard (e.g. renamed) local admin account, you may be unable to log on to it after running sysprep. This is because sysprep actually renames the local admin account back to "Administrator" but leaves the password unchanged.
Just login with Administrator and your password and you should be able to log in ok (tested with Windows 2008 R2 but I'm sure all versions of Windows are the same).
However if you're using a non-standard (e.g. renamed) local admin account, you may be unable to log on to it after running sysprep. This is because sysprep actually renames the local admin account back to "Administrator" but leaves the password unchanged.
Just login with Administrator and your password and you should be able to log in ok (tested with Windows 2008 R2 but I'm sure all versions of Windows are the same).
Friday 23 August 2013
Error building from Windows 2003 media "virtual media session already exists"
Recently I've had to rebuild a 9th Gen III server (PERC6 controller) from scratch over DRAC connection. There are a few ways to achieve this. The recommended way is to use the Dell installation helper CDs which have over the years gone by a few different names:
Dell Server Assistant
Installation and Server Management
System Build & Update Utility
They work by slipstreaming drivers into a Windows 2003 installation off a Windows CD or an ISO presented over a DRAC connection virtual media session.
Unfortunately I needed to install Windows 2003 (in order to get SP1 installed). This meant using the ISM version 5.2 and the only version that supported this was for 9th Gen I servers (with a PERC5 controller). Booting resulted in no hard disks detected.
So the other way to get the OS installed is to boot off Windows media (or DRAC Virtual Media) and press F6 for an OEM driver disk.
The drivers are easily downloadable from the Dell drivers page - you just need the hard disk unzip package which contains the .cat, .sys, .inf and oemsetup.inf files. These then need to be turned into a floppy image and mounted via the drac.
This is where the "virtual media session already exists" error pops up. I'm not sure the root cause but a workaround is to use the virtual flash.
In order to do this you need to upload the floppy image to the virtual flash and enable it under the virtual media configuration tab with the tickbox.
Once this is done, you need to change the boot order to the virtual flash is higher than the physical floppy or virtual floppy.
Once you've done all this, the windows setup wizard should find the perc6 driver mapped as A: on the virtual flash when you press F6.
For this guide, I used the latest DRAC version (1.65) and the Java Virtual Media plugin.
Dell Server Assistant
Installation and Server Management
System Build & Update Utility
They work by slipstreaming drivers into a Windows 2003 installation off a Windows CD or an ISO presented over a DRAC connection virtual media session.
Unfortunately I needed to install Windows 2003 (in order to get SP1 installed). This meant using the ISM version 5.2 and the only version that supported this was for 9th Gen I servers (with a PERC5 controller). Booting resulted in no hard disks detected.
So the other way to get the OS installed is to boot off Windows media (or DRAC Virtual Media) and press F6 for an OEM driver disk.
The drivers are easily downloadable from the Dell drivers page - you just need the hard disk unzip package which contains the .cat, .sys, .inf and oemsetup.inf files. These then need to be turned into a floppy image and mounted via the drac.
This is where the "virtual media session already exists" error pops up. I'm not sure the root cause but a workaround is to use the virtual flash.
In order to do this you need to upload the floppy image to the virtual flash and enable it under the virtual media configuration tab with the tickbox.
Once this is done, you need to change the boot order to the virtual flash is higher than the physical floppy or virtual floppy.
Once you've done all this, the windows setup wizard should find the perc6 driver mapped as A: on the virtual flash when you press F6.
For this guide, I used the latest DRAC version (1.65) and the Java Virtual Media plugin.
Wednesday 7 August 2013
Dell Openmanage Essentials shows cluster name instead of hostname
When you use Openmanage to discover servers that are part of a Microsoft HA cluster, by default it will use the cluster name for the active node instead of the hostname.
To get around this, add an exclusion against the Cluster VIP and Openmanage Essentials should ignore the cluster info and just connect to the host.
To get around this, add an exclusion against the Cluster VIP and Openmanage Essentials should ignore the cluster info and just connect to the host.
Wednesday 1 May 2013
Vmware Update Manager Error code 15 when updating Dell OpenManage
The vmware update manager logfile (C:\ProgramData\VMware\VMware Update Manager\Logs) may show the error “Could not find a trusted signer”
This can be resolved by removing the Dell VIBs for OpenManage and the Equallogic Multipath Module and reinstalling manually
esxcli software vib remove -n OpenManage -n dell-configuration-vib -n dell-eql-host-connection-mgr -n dell-eql-hostprofile -n dell-eql-routed-psp
Manually re-install the OpenManage VIB
esxcli software vib install -d /tmp/OM-SrvAdmin-Dell-Web-7.2.0-6945.VIB-ESX51i.zip
Reboot the host to remove the loaded VIBs from memory and load the new version of OpenManage
The equallogic module can be reinstalled with Update Manager with no reboot required
This can be resolved by removing the Dell VIBs for OpenManage and the Equallogic Multipath Module and reinstalling manually
esxcli software vib remove -n OpenManage -n dell-configuration-vib -n dell-eql-host-connection-mgr -n dell-eql-hostprofile -n dell-eql-routed-psp
Manually re-install the OpenManage VIB
esxcli software vib install -d /tmp/OM-SrvAdmin-Dell-Web-7.2.0-6945.VIB-ESX51i.zip
Reboot the host to remove the loaded VIBs from memory and load the new version of OpenManage
The equallogic module can be reinstalled with Update Manager with no reboot required
Friday 1 February 2013
Access denied exporting event logs
The main reason for an access denied message exporting event logs even when you're logged on with an administration user is if you're trying to save them to a UNC path.
Just save the file locally and manually copy to the UNC path.
Subscribe to:
Posts (Atom)