When you try to install Symantec Backup Exec Agent to a remote computer you receive the following error:
"Error connecting to the remote server. Ensure that the server is available, has WMI enabled, and is not blocked by a firewall.24"
To fix this problem try the following on the remote computer:
Run Group Policy Editor or the local group policy editor (gpedit.msc) and from the Local Computer Policy/Computer Configuration/Windows Settings/Security Settings/Local Policies/User Rights Assignments allow Administrators, Local Service, and Network Service accounts to "Adjust Memory Quotas for Process Properties" and Local Service, and Network Service to "Replace a process level token". Remote user must also be a member of Local Administrators group and Remote Registry service must be running.
Reboot the remote server to apply changes.
Try to install Backup Exec agent again after rebooting the remote server.
Sunday, March 18, 2012
Monday, March 12, 2012
How to determine the ESXi installation type
ESXi installed on a host can be one of these types:
Embedded
Installable
PXE
To determine the type of ESXi installation:
Connect to the host via SSH.
Run this command:
# esxcfg-info -e
You see an output similar to:
boot type: visor-thin
You can determine the ESXi type based on the output of this command.
For example:
visor-thin indicates an installable deployment
visor-usb indicates an embedded deployment
visor-pxe indicates a PXE deployment
For more information read the following article from VMware
Embedded
Installable
PXE
To determine the type of ESXi installation:
Connect to the host via SSH.
Run this command:
# esxcfg-info -e
You see an output similar to:
boot type: visor-thin
You can determine the ESXi type based on the output of this command.
For example:
visor-thin indicates an installable deployment
visor-usb indicates an embedded deployment
visor-pxe indicates a PXE deployment
For more information read the following article from VMware
Thursday, March 8, 2012
How to clear the Hardware Status warnings/errors in vCenter Server
To clear the warnings/errors from the Hardware Status tab:.
Restart the sfcdb service.
To restart the service in ESXi, run this command:
services.sh restart
To restart the service in ESX, run this command:
service sfcbd restart
Click Update. The error should now be cleared.
For more information read the following article from VMware.
- Go to Hardware Status tab and select the System event log view.
- Click Reset event log.
- Click Update. The error should now be cleared.
- Select the Alerts and warnings view.
- Click Reset sensors.
- Click Update. The memory should now be cleared.
Restart the sfcdb service.
To restart the service in ESXi, run this command:
services.sh restart
To restart the service in ESX, run this command:
service sfcbd restart
Click Update. The error should now be cleared.
For more information read the following article from VMware.
Wednesday, March 7, 2012
ESX/ESXi hosts fail with a purple diagnostic screen and report the error: #PF Exception(14)
When new worlds are created, an integer is incremented. When this integer overflows, the kernel panics and fails with a purple diagnostic screen. In ESXi, new worlds are created for all processes because there is no service console operating system. Therefore, this number increments much faster in ESXi than ESX. In ESXi, this issue occurs when the system has been running for a very long time (over a year) without a reboot and has been actively creating processes. In ESX classic, it is almost impossible to hit this threshold.
To workaround this issue, reboot the host. Rebooting the host restarts the counter and eliminates the risk of any failure.
To workaround this issue, reboot the host. Rebooting the host restarts the counter and eliminates the risk of any failure.
To avoid a reboot, you can check to determine if your system is at risk.
To determine if your system is at risk, run this script in the ESXi command line:
highWID=$(vsish -e ls world | sed 's!/$!!' | sort -n | tail -n 1)
let microFull=highWID/7400
echo ${microFull}
highWID=$(vsish -e ls world | sed 's!/$!!' | sort -n | tail -n 1)
let microFull=highWID/7400
echo ${microFull}
If this script returns a value close to 100,000, it is recommended to schedule a reboot.
Thursday, March 1, 2012
How to change the boot order of a virtual machine using vmx options
In ESXi/ESX, choose the boot device using the advanced virtual machine options bios.bootOrder and bios.hddOrder.
Note: These settings override the boot order that you might have set in the virtual machine's BIOS previously.
The virtual machine's boot order can be set to any virtual NIC via ethernetX, where X is the number of the device. For example, ethernet0 or ethernet5. It can also be set to hdd, cdrom, or floppy. If set to cdrom or floppy there are multiple devices, the virtual machine tries them sequentially until it finds one to boot from. If bios.bootOrder is set to hdd, you also have to define bios.hddOrder and set a device (for example, scsi0:3 or ide1:0) to boot from.
You can also configure a list of devices. Ensure to put the list into quotation marks and seperate the devices with commas. For example:
bios.bootOrder = "ethernet5,ethernet2,hdd,cdrom,floppy"
bios.hddOrder = "scsi2:2,scsi0:1,ide1:0"
In this example, the virtual machine tries to boot with ethernet5. If there is nothing to boot from, try ethernet2. If that fails, try from the disks (hdd) defined in hddOrder, then all cdroms, and finally from all floppys.
Unlike BIOS, you can choose from all available NICs and disks, but there is a maximum of 5 NICs and 8 disks that can be used in a boot order list. If you move a bootOrder/hddOrder configured virtual machine to a host that is not running on ESXi/ESX, it might not use the boot order you expect it to upon the next restart.
To configure bootOrder for a virtual machine using the vSphere Client:
Note: These settings override the boot order that you might have set in the virtual machine's BIOS previously.
The virtual machine's boot order can be set to any virtual NIC via ethernetX, where X is the number of the device. For example, ethernet0 or ethernet5. It can also be set to hdd, cdrom, or floppy. If set to cdrom or floppy there are multiple devices, the virtual machine tries them sequentially until it finds one to boot from. If bios.bootOrder is set to hdd, you also have to define bios.hddOrder and set a device (for example, scsi0:3 or ide1:0) to boot from.
You can also configure a list of devices. Ensure to put the list into quotation marks and seperate the devices with commas. For example:
bios.bootOrder = "ethernet5,ethernet2,hdd,cdrom,floppy"
bios.hddOrder = "scsi2:2,scsi0:1,ide1:0"
In this example, the virtual machine tries to boot with ethernet5. If there is nothing to boot from, try ethernet2. If that fails, try from the disks (hdd) defined in hddOrder, then all cdroms, and finally from all floppys.
Unlike BIOS, you can choose from all available NICs and disks, but there is a maximum of 5 NICs and 8 disks that can be used in a boot order list. If you move a bootOrder/hddOrder configured virtual machine to a host that is not running on ESXi/ESX, it might not use the boot order you expect it to upon the next restart.
To configure bootOrder for a virtual machine using the vSphere Client:
- Shut down the virtual machine.
- Click the virtual machine in the Inventory.
- Click the Summary tab for that virtual machine, then click Edit Settings.
- In the Virtual Machine Properties dialog, click the Options tab.
- Under Advanced, click General.
- Click Configuration Parameters.
- Click Add Row.
- Create two new rows.
- Enter bios.bootOrder to the Name column and enter the devices in the Value column.
- Enter bios.hddOrder to the Name column and enter the devices in the Value column.
- Click OK to save the changes.
Subscribe to:
Posts (Atom)