Permission Analyzer, Get insight in the network permissions
http://www.permissionanalyzer.com/eng/home.html
With Permission Analyzer, you can quickly determine whether your system access permissions are appropriately set, need to be changed or have been altered. As a network administrator or a division manager it is hard to gain an overview of the access rights within a computer network. In general, it is not possible to check the number of access rights per user or user group. If a freelancer is accidentally placed in a user group that has access to, for example, quotes, then it can be harmful to the company.
Permission Analyzer gives you a clear overview of the access rights of each user or user group. You are then able to continually supervise the access rights of the computer network within the organization.
Apart from the overview of access rights, Permission Analyzer can also give you an overview of the software installed on each workstation. The program gives an answer to questions such as:
When was the last time a user logged on?
Which users are blocked from accessing?
Which users have an infinite password?
With clear answers to these questions, you can keep your network clean and well-organized, which will benefit the supervision procedure.
onsdag 3. mars 2010
tirsdag 2. mars 2010
VMware: Virtual machine does not power on because of missing or locked files
http://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=10051
Details
• Virtual machine cannot power on
• Error messages during power up include:
o Unable to open Swap File
o Unable to access a file since it is locked
o Unable to access Virtual machine configuration
• The following messages appear in /var/log/vmkernel:
o WARNING: World: VM xxxx: xxx: Failed to open swap file: Lock was not free
o WARNING: World: VM xxxx: xxx: Failed to initialize swap file
• When opening a console within Lab Manager, you may receive the error:
o Error connecting to.vmx because the VMX is not started
• Powering on a virtual machine results in the power on task remaining at 95% indefinitely
• Cannot power on a virtual machine after deploying it from a templateA virtual machine reports conflicting power states between vCenter and the ESX host console
Solution
To prevent duplicate access to active virtual machine files, ESX hosts establish a lock on these files. In certain circumstances, these locks may not be released when the virtual machine is powered off. The files cannot be accessed if they are locked, and the virtual machine cannot power on.
These virtual machine files are commonly affected by lock issues:
•.vswp
• vmware.log
•-flat.vmdk
•.vmx
Identifying the locked file
To identify the locked file, try to power on the virtual machine. During power on, an error may display or be written to the virtual machine's log. The error and the log entry identify the virtual machine.
1. Connect VMware Infrastructure (VI) Client to either the ESX host or to the VirtualCenter Server.
2. Locate the affected virtual machine, and try to power it on.
3. Open a remote console window for the virtual machine.
4. If the virtual machine is unable to power on, an error on the remote console screen may display with the name of the affected file. If an error does not display, proceed to the next step to look in the vmware.log file for the virtual machine.
5. Log in as root to the ESX host using an SSH client.
6. To confirm that the virtual machine is registered on the server and to obtain the full path to the virtual machine, run the command:
[root@esxhostname]# vmware-cmd -l
The output returns a list of the virtual machines registered to the ESX host. Each line contains the full path of a virtual machine's .vmx file. For example:
/vmfs/volumes///.vmx
Record this information as it will be required in the remainder of this process. This is thereferenced in the remainder of the article.
Verify that the affected virtual machine appears in this list. If it is not listed, the virtual machine is not registered on this ESX host. The host on which the virtual machine is registered typically holds the lock. Ensure that you are connected to the proper host before proceeding.
7. To move to the virtual machine's directory, run the command:
[root@esxhostname]# cd /vmfs/volumes//
8. Use a text viewer to read the contents of the vmware.log file. At the end of the file, look for error messages that identify the affected file.
Identifying the ESX host that is locking the file
Because a virtual machine can move between hosts, the host where the virtual machine is registered may not be the host with the file lock. The lock must be released by the ESX host that owns the lock. This host is identified by the MAC address of the primary service console.
To identify the host by the MAC address:
1. To report the MAC address of the lock holder, run the command:
[root@esxhostname]# vmkfstools -D /vmfs/volumes///
2. This command writes the MAC address of any host that is locking the .vmdk file to the vmkernel log file. To locate this information, run the command:
[root@esxhostname]# tail /var/log/vmkernel
Look for lines similar to the following:
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Lock [type 10c00001 offset 13058048 v 20, hb offset 3499520
Apr 5 09:45:26 Hostname vmkernel: gen 532, mode 1, owner 45feb537-9c52009b-e812-00137266e200 mtime 1174669462]
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Addr <4, 136, 2>, gen 19, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)len 297795584, nb 142 tbz 0, zla 1, bs 2097152
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)FS3: 132:
(END)
The second line displays the MAC address a fter the word owner. In this example, the MAC address is 00137266e200.
3. To determine if the MAC address corresponds to the host that you are logged into, see Identifying the ESX Service Console MAC address (1001167). If it does not correspond, you must establish an SSH connection to each host that can run this virtual machine. Once identified, use the host in the following procedures.
Note: If this process does not reveal the MAC address, it is possible that it is an NFS lock (for more information, see the section Removing the .lock file (NFS Only)), or that you have to migrate the virtual machine to each host to identify the lock holder.
4. If, due to power failure or other reasons, you are unable to obtain the MAC address in this method, you must then manually migrate the virtual machine to each host in the cluster. At each host, attempt to power on the virtual machine. When you reach the host that holds the lock, it should successfully be able to power on.
Removing the .lck file (NFS Only)
The virtual machine's files may be locked by the NFS storage. You can identify this by the .lck.#### (where #### refers to the World ID that has the file lock) at the end of the filename. This is an NFS filelock. These can be removed safely, as long as the virtual machine is not running on any other ESX host.
Determining if the file is being used by a running virtual machine
If the file is being accessed by a running virtual machine, the lock cannot be removed. It is possible that the lockholder host is running the virtual machine and has become unresponsive.
To determine if the virtual machine processes are running:
1. To determine if the virtual machine is registered on the server, run the command:
[root@esxhostname]# vmware-cmd -l
Note: If the virtual machine is registered on more than one ESX host, see Virtual machines appear to be running or registered on multiple ESX servers (1005051).
2. To assess the virtual machines current state, run the command:
[root@esxhostname]# vmware-cmdgetstate
If the output from this command is getstate() = on, the virtual machine has become unresponsive. To address this issue, see Troubleshooting a virtual machine that has stopped responding (1007819).
If the output from this command is getstate() = off, the ESX host may be unaware of the file lock.
3. To stop the virtual machine process, see Powering off a virtual machine hosted on ESX host from the command line (1004340).
Determining if the .vmdk file is in use by other virtual machines
A lock on the .vmdk file can prevent a virtual machine from starting. However, since virtual machine disk files can be configured for use with any virtual machine, the file may be locked by another virtual machine.
To determine if the virtual machine's disk file is configured for use on more than one virtual machine, run the command:
[root@esxhostname]# egrep -i.vmdk /vmfs/volumes/*/*/*.vmx
The output refers to the virtual machine you are currently working on. If any additional virtual machines are configured to use the disk, determine if they are currently running. Powering off the other virtual machine using the disk file releases the lock. You must determine which virtual machine should have ownership of the file, then reconfigure your virtual machines to prevent this error from occurring again.
If the .vmdk file is not used by other virtual machines, proceed to the next section to remove the lock.
Removing the lock
Note: Follow these sections in order. If removing the .vswp file does not unlock the file, try clearing the lock with the touch command. If that does not resolve the issue, try rebooting the ESX host. Do not skip a section.
Removing the .vswp file
The .vswp file is used by running virtual machines as memory swap space. It is typically deleted when the virtual machine is powered off. If this file and its reference in the .vmx file still exist when powering back on, it can prevent the virtual machine from starting. If the virtual machine is not running, this file can safely be deleted.
To remove the .vswp file:
1. To move to the virtual machine's directory, run the command:
[root@esxhostname]# cd /vmfs/volumes//
2. To delete the .vswp file, run the command:
[root@esxhostname]# rm /vmfs/volumes///.vswp
Note: Depending on the lock held on this file, it may or may not be successfully removed.
3. To backup the virtual machine's .vmx file, run the command:
[root@esxhostname]# cp.vmx .vmx.bak
4. Use a text editor to open the .vmx file for the virtual machine. Locate and delete the line:
sched.swap.derivedName
5. Save and exit the file.
6. Try to power on the virtual machine. If the issue persists, proceed to the next section to remove the lock.
Clearing the file lock with the touch command
The file lock can often be resolved from the lockholder without impact to the operation of the host or the virtual machines running on the host.
To clear the file lock with the touch command:
1. Run the command:
[root@esxhostname]# touch
Note: Performing a touch * command will perform the operation on all files in your current directory.
2. Try to power on the virtual machine. If the issue persists, proceed to the next section to clear the lock.
Clearing the file lock by rebooting the ESX host
As a final troubleshooting step, try restarting the ESX host that holds the lock.
To restart the ESX host:
1. Migrate all virtual machines from the host to new hosts.
2. When the virtual machine are moved, place the host in maintenance mode and reboot.
Note: If you have only one ESX host or do not have the ability to migrate virtual machines, you must schedule a downtime for all affected virtual machines prior to rebooting. When the host has rebooted, start the affected virtual machine.
Details
• Virtual machine cannot power on
• Error messages during power up include:
o Unable to open Swap File
o Unable to access a file since it is locked
o Unable to access Virtual machine configuration
• The following messages appear in /var/log/vmkernel:
o WARNING: World: VM xxxx: xxx: Failed to open swap file
o WARNING: World: VM xxxx: xxx: Failed to initialize swap file
• When opening a console within Lab Manager, you may receive the error:
o Error connecting to
• Powering on a virtual machine results in the power on task remaining at 95% indefinitely
• Cannot power on a virtual machine after deploying it from a templateA virtual machine reports conflicting power states between vCenter and the ESX host console
Solution
To prevent duplicate access to active virtual machine files, ESX hosts establish a lock on these files. In certain circumstances, these locks may not be released when the virtual machine is powered off. The files cannot be accessed if they are locked, and the virtual machine cannot power on.
These virtual machine files are commonly affected by lock issues:
•
• vmware.log
•
•
Identifying the locked file
To identify the locked file, try to power on the virtual machine. During power on, an error may display or be written to the virtual machine's log. The error and the log entry identify the virtual machine.
1. Connect VMware Infrastructure (VI) Client to either the ESX host or to the VirtualCenter Server.
2. Locate the affected virtual machine, and try to power it on.
3. Open a remote console window for the virtual machine.
4. If the virtual machine is unable to power on, an error on the remote console screen may display with the name of the affected file. If an error does not display, proceed to the next step to look in the vmware.log file for the virtual machine.
5. Log in as root to the ESX host using an SSH client.
6. To confirm that the virtual machine is registered on the server and to obtain the full path to the virtual machine, run the command:
[root@esxhostname]# vmware-cmd -l
The output returns a list of the virtual machines registered to the ESX host. Each line contains the full path of a virtual machine's .vmx file. For example:
/vmfs/volumes/
Record this information as it will be required in the remainder of this process. This is the
Verify that the affected virtual machine appears in this list. If it is not listed, the virtual machine is not registered on this ESX host. The host on which the virtual machine is registered typically holds the lock. Ensure that you are connected to the proper host before proceeding.
7. To move to the virtual machine's directory, run the command:
[root@esxhostname]# cd /vmfs/volumes/
8. Use a text viewer to read the contents of the vmware.log file. At the end of the file, look for error messages that identify the affected file.
Identifying the ESX host that is locking the file
Because a virtual machine can move between hosts, the host where the virtual machine is registered may not be the host with the file lock. The lock must be released by the ESX host that owns the lock. This host is identified by the MAC address of the primary service console.
To identify the host by the MAC address:
1. To report the MAC address of the lock holder, run the command:
[root@esxhostname]# vmkfstools -D /vmfs/volumes/
2. This command writes the MAC address of any host that is locking the .vmdk file to the vmkernel log file. To locate this information, run the command:
[root@esxhostname]# tail /var/log/vmkernel
Look for lines similar to the following:
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Lock [type 10c00001 offset 13058048 v 20, hb offset 3499520
Apr 5 09:45:26 Hostname vmkernel: gen 532, mode 1, owner 45feb537-9c52009b-e812-00137266e200 mtime 1174669462]
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)Addr <4, 136, 2>, gen 19, links 1, type reg, flags 0x0, uid 0, gid 0, mode 600
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)len 297795584, nb 142 tbz 0, zla 1, bs 2097152
Apr 5 09:45:26 Hostname vmkernel: 17:00:38:46.977 cpu1:1033)FS3: 132:
(END)
The second line displays the MAC address a fter the word owner. In this example, the MAC address is 00137266e200.
3. To determine if the MAC address corresponds to the host that you are logged into, see Identifying the ESX Service Console MAC address (1001167). If it does not correspond, you must establish an SSH connection to each host that can run this virtual machine. Once identified, use the host in the following procedures.
Note: If this process does not reveal the MAC address, it is possible that it is an NFS lock (for more information, see the section Removing the .lock file (NFS Only)), or that you have to migrate the virtual machine to each host to identify the lock holder.
4. If, due to power failure or other reasons, you are unable to obtain the MAC address in this method, you must then manually migrate the virtual machine to each host in the cluster. At each host, attempt to power on the virtual machine. When you reach the host that holds the lock, it should successfully be able to power on.
Removing the .lck file (NFS Only)
The virtual machine's files may be locked by the NFS storage. You can identify this by the .lck.#### (where #### refers to the World ID that has the file lock) at the end of the filename. This is an NFS filelock. These can be removed safely, as long as the virtual machine is not running on any other ESX host.
Determining if the file is being used by a running virtual machine
If the file is being accessed by a running virtual machine, the lock cannot be removed. It is possible that the lockholder host is running the virtual machine and has become unresponsive.
To determine if the virtual machine processes are running:
1. To determine if the virtual machine is registered on the server, run the command:
[root@esxhostname]# vmware-cmd -l
Note: If the virtual machine is registered on more than one ESX host, see Virtual machines appear to be running or registered on multiple ESX servers (1005051).
2. To assess the virtual machines current state, run the command:
[root@esxhostname]# vmware-cmd
If the output from this command is getstate() = on, the virtual machine has become unresponsive. To address this issue, see Troubleshooting a virtual machine that has stopped responding (1007819).
If the output from this command is getstate() = off, the ESX host may be unaware of the file lock.
3. To stop the virtual machine process, see Powering off a virtual machine hosted on ESX host from the command line (1004340).
Determining if the .vmdk file is in use by other virtual machines
A lock on the .vmdk file can prevent a virtual machine from starting. However, since virtual machine disk files can be configured for use with any virtual machine, the file may be locked by another virtual machine.
To determine if the virtual machine's disk file is configured for use on more than one virtual machine, run the command:
[root@esxhostname]# egrep -i
The output refers to the virtual machine you are currently working on. If any additional virtual machines are configured to use the disk, determine if they are currently running. Powering off the other virtual machine using the disk file releases the lock. You must determine which virtual machine should have ownership of the file, then reconfigure your virtual machines to prevent this error from occurring again.
If the .vmdk file is not used by other virtual machines, proceed to the next section to remove the lock.
Removing the lock
Note: Follow these sections in order. If removing the .vswp file does not unlock the file, try clearing the lock with the touch command. If that does not resolve the issue, try rebooting the ESX host. Do not skip a section.
Removing the .vswp file
The .vswp file is used by running virtual machines as memory swap space. It is typically deleted when the virtual machine is powered off. If this file and its reference in the .vmx file still exist when powering back on, it can prevent the virtual machine from starting. If the virtual machine is not running, this file can safely be deleted.
To remove the .vswp file:
1. To move to the virtual machine's directory, run the command:
[root@esxhostname]# cd /vmfs/volumes/
2. To delete the .vswp file, run the command:
[root@esxhostname]# rm /vmfs/volumes/
Note: Depending on the lock held on this file, it may or may not be successfully removed.
3. To backup the virtual machine's .vmx file, run the command:
[root@esxhostname]# cp
4. Use a text editor to open the .vmx file for the virtual machine. Locate and delete the line:
sched.swap.derivedName
5. Save and exit the file.
6. Try to power on the virtual machine. If the issue persists, proceed to the next section to remove the lock.
Clearing the file lock with the touch command
The file lock can often be resolved from the lockholder without impact to the operation of the host or the virtual machines running on the host.
To clear the file lock with the touch command:
1. Run the command:
[root@esxhostname]# touch
Note: Performing a touch * command will perform the operation on all files in your current directory.
2. Try to power on the virtual machine. If the issue persists, proceed to the next section to clear the lock.
Clearing the file lock by rebooting the ESX host
As a final troubleshooting step, try restarting the ESX host that holds the lock.
To restart the ESX host:
1. Migrate all virtual machines from the host to new hosts.
2. When the virtual machine are moved, place the host in maintenance mode and reboot.
Note: If you have only one ESX host or do not have the ability to migrate virtual machines, you must schedule a downtime for all affected virtual machines prior to rebooting. When the host has rebooted, start the affected virtual machine.
søndag 28. februar 2010
Question concerning HDMP files
Hello all,
I wonder if anyone can explain the ReportQueue files that I have located in a Windows Temp folder for Vista (Ultimate 64bit). I have an HP 9500 Pavillion laptop and have had a great deal of trouble today with Ad Aware 2007 by Lavasoft totally freezing during scans and then crashing my computer. I eventually uninstalled it and ran a cleanup and defrag only to find that I have a new 2GB file (evidently created today) in C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report1ecfd905\WERD945.tmp.hdmp
I am denied access to the file, so I have no idea what it is, how I got it, or whether it caused the problems with the Ad Aware scans. I'd love to know if it can be deleted and... if all of the other so called report files in the Windows temp folder that contains them can go, too. In addition, if I am denied access exactly how can they be removed??
To resolve this problem simply click:
Start --> ControlPanel -->> Problem Reports and Solutions
and then click: Clear solution and problem history
cleans up all the content of ReportQueue folder.
I wonder if anyone can explain the ReportQueue files that I have located in a Windows Temp folder for Vista (Ultimate 64bit). I have an HP 9500 Pavillion laptop and have had a great deal of trouble today with Ad Aware 2007 by Lavasoft totally freezing during scans and then crashing my computer. I eventually uninstalled it and ran a cleanup and defrag only to find that I have a new 2GB file (evidently created today) in C:\ProgramData\Microsoft\Windows\WER\ReportQueue\Report1ecfd905\WERD945.tmp.hdmp
I am denied access to the file, so I have no idea what it is, how I got it, or whether it caused the problems with the Ad Aware scans. I'd love to know if it can be deleted and... if all of the other so called report files in the Windows temp folder that contains them can go, too. In addition, if I am denied access exactly how can they be removed??
To resolve this problem simply click:
Start --> ControlPanel -->> Problem Reports and Solutions
and then click: Clear solution and problem history
cleans up all the content of ReportQueue folder.
Delete of C:\$Extend\$UsnJrnl:$J:$DATA
Delete C:\$Extend\$UsnJrnl:$J:$DATA safely 1 command!!!
Have you ever noticed when you run O&O Defrag and there's always those pesky files named: C:\$Extend\$UsnJrnl:$J:$DATA that just will not defrag no matter what you try?
Well now you can just remove it!!! Right click command prompt, run as administrator:
fsutil usn deletejournal /n c:
Below is a FAQ item from the website:
How do I defragment "C:\$Extend\$UsnJrnl:$J:$DATA"?
This huge file is used by Windows to track changes in other files and cannot be defragmented. You can delete it by entering the following on the Run commandline (Windows 2003/XP/Vista, not Windows 2000), it can take several minutes to finish.
How do I defragment "C:\$Extend\$RmMetadata\$TxfLog\$Tops:$T:$DATA"?
How do I defragment "C:\$Extend\$RmMetadata\$TxfLog\$Tops:$T:$DATA"?
This is a special NTFS system file used by the Windows Transactional Resource Manager. MyDefrag cannot move or defragment this file. It can be cleaned with the fsutil command, see below. Do not try to delete this file by hand.
Use the following commandline to see information about the TOPS files: fsutil resource info c:\
The following commandline will instruct Windows to clean (not delete) the TOPS file at the next reboot: fsutil resource setautoreset true c:\
This is a special NTFS system file used by the Windows Transactional Resource Manager. MyDefrag cannot move or defragment this file. It can be cleaned with the fsutil command, see below. Do not try to delete this file by hand.
Use the following commandline to see information about the TOPS files: fsutil resource info c:\
The following commandline will instruct Windows to clean (not delete) the TOPS file at the next reboot: fsutil resource setautoreset true c:\
fredag 26. februar 2010
Device Manager Does Not Display Devices Not Currently Present in Windows
http://support.microsoft.com/kb/241257
SYMPTOMSDevice Manager displays only non-Plug and Play devices, drivers, and printers wh...Device Manager displays only non-Plug and Play devices, drivers, and printers when you click the Show hidden devices command on the View menu to enable it. Devices that are installed but are not currently connected to the computer (such as a Universal Serial Bus (USB) device or "ghosted" devices) are not displayed in Device Manager, even when you use the Show hidden devices command.
Back to the top
WORKAROUNDTo work around this behavior and display phantom devices when you use the Show h...To work around this behavior and display phantom devices when you use the Show hidden devices command:
Click Start, point to Programs, point to Accessories, and then click Command Prompt.
At the command prompt, type the following lines, pressing ENTER after each line
set devmgr_show_nonpresent_devices=1
cd\%SystemRoot%\System32
start devmgmt.msc
where %SystemRoot% is the folder in which Windows 2000 is installed.
Troubleshoot the devices and drivers in Device Manager, as required.
NOTE: You must first select show hidden devices on the Device Manager View menu before you can see devices that are no longer present in the system.
When you are done troubleshooting, quit Device Manager, and then close the Command Prompt window. Closing the window clears the variable you set in step 2 and prevents ghosted devices from being displayed when you use the Show hidden devices command.
NOTE: When you quit Device Manager and close the Command Prompt window, the set devmgr_show_nonpresent_devices=1 variable is turned off so you cannot see the phantom devices.
An alternative approach, for developers or power users who need this feature enabled constantly, is to set this environment variable globally. To do so, perform the following steps:
Right-click My Computer.
Click Properties.
Click the Advanced tab.
Click the Environment Variables tab.
Set the variables in the System Variables box.
NOTE: You should use this method only for troubleshooting or development purposes, to prevent users from accidentally uninstalling a required device that is not currently present (such as a USB device or docking station that is not currently connected to a laptop computer).
Back to the top
SYMPTOMSDevice Manager displays only non-Plug and Play devices, drivers, and printers wh...Device Manager displays only non-Plug and Play devices, drivers, and printers when you click the Show hidden devices command on the View menu to enable it. Devices that are installed but are not currently connected to the computer (such as a Universal Serial Bus (USB) device or "ghosted" devices) are not displayed in Device Manager, even when you use the Show hidden devices command.
Back to the top
WORKAROUNDTo work around this behavior and display phantom devices when you use the Show h...To work around this behavior and display phantom devices when you use the Show hidden devices command:
Click Start, point to Programs, point to Accessories, and then click Command Prompt.
At the command prompt, type the following lines, pressing ENTER after each line
set devmgr_show_nonpresent_devices=1
cd\%SystemRoot%\System32
start devmgmt.msc
where %SystemRoot% is the folder in which Windows 2000 is installed.
Troubleshoot the devices and drivers in Device Manager, as required.
NOTE: You must first select show hidden devices on the Device Manager View menu before you can see devices that are no longer present in the system.
When you are done troubleshooting, quit Device Manager, and then close the Command Prompt window. Closing the window clears the variable you set in step 2 and prevents ghosted devices from being displayed when you use the Show hidden devices command.
NOTE: When you quit Device Manager and close the Command Prompt window, the set devmgr_show_nonpresent_devices=1 variable is turned off so you cannot see the phantom devices.
An alternative approach, for developers or power users who need this feature enabled constantly, is to set this environment variable globally. To do so, perform the following steps:
Right-click My Computer.
Click Properties.
Click the Advanced tab.
Click the Environment Variables tab.
Set the variables in the System Variables box.
NOTE: You should use this method only for troubleshooting or development purposes, to prevent users from accidentally uninstalling a required device that is not currently present (such as a USB device or docking station that is not currently connected to a laptop computer).
Back to the top
onsdag 27. januar 2010
Reset Administrator Password on iLO
http://blog.netnerds.net/2006/04/ribcl-reset-administrator-password-on-ilo/
Here's a zip of just hponcfg.exe, add_user.xml, and Administrator_reset_pwd.xml. Since it's an exe with no apparent supporting files, y ou may be able to just use that.
Latest version of hponcfg.exe is packed in the latest version of HP Support Pack and can be downloaded here: http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=3716247&prodTypeId=18964&prodSeriesId=3716246&swLang=13&taskId=135&swEnvOID=1005
Here's a zip of just hponcfg.exe, add_user.xml, and Administrator_reset_pwd.xml. Since it's an exe with no apparent supporting files, y ou may be able to just use that.
Latest version of hponcfg.exe is packed in the latest version of HP Support Pack and can be downloaded here: http://h20000.www2.hp.com/bizsupport/TechSupport/SoftwareIndex.jsp?lang=en&cc=us&prodNameId=3716247&prodTypeId=18964&prodSeriesId=3716246&swLang=13&taskId=135&swEnvOID=1005
Abonner på:
Innlegg (Atom)