HP’s Integrated Lights Out is an out-of-band management feature, provided throughout the Proliant server line, that allows for remote server management via a dedicated module and private network connection. The iLO operating system is firmware based and can be flash upgraded from within the iLO environment itself, from within the server OS, or remotely. Access control can be defined per iLO system using local user accounts (default) or via Active Directory. To integrate with AD the schema must first be extended, iLO objects created, logon policies defined, and policies configured in each iLO management processor (MP).
One of my favorite, albeit extremely hard to find, tools is HP’s Lights-out Migration Utility. Using this tool, one can extend the AD schema to support iLO integration, install management plug-ins into the ADUC MMC, manage the firmware of entire networks of iLO devices at once, and configure the access method for all iLO devices as well.
When first loading the utility package you are presented with three options: Schema Extender, Snap-ins, and Directories Migration Utility. If you’re just looking to mass-manage the firmware of your iLOs you can skip the first two options. If you want to extend your AD schema to integrate your iLOs just go down this list in order as it is fairly self explanatory. The rest of this blog entry will focus on the third option, the Directories Migration Utility.
Clicking the third button will invoke the migration utility installer which will create a start-menu shortcut for easy access. When first launching the utility, the startup screen outlines the steps that the tool provides. Although this tool was intended to be used for LDAP-integration it can serve as a great general purpose bulk iLO management tool.
While it’s scanning, go ahead and prepare the latest firmware images for each iLO version in your environment. The tool will discover iLO and iLO2 and can upgrade both versions simultaneously. The easiest way to do this is to download the “Online ROM Flash Component for Windows-HP Integrated Lights-Out2” (or iLO v1) and EXTRACT the files, don’t install. In the extracted files look for <device name>_<firmware version>.bin, i.e. ilo2_178.bin. Pull this file out and store somewhere convenient. Repeat for iLO v1 firmware.
Once all your iLOs have been discovered, on the next screen you can point to each iLO version image file and upgrade the firmware of each that needs it. *Please note that your iLO MP will reboot as part of the flash process so any network monitoring will report a brief outage.
I don’t know why it’s so hard to find this utility on hp.com but it is. It is definitely a great tool to have in your arsenal if you manage a Proliant shop!

Here is version 2.01: http://goo.gl/TZBc1

To follow up on an earlier posting about how to enable the new recycle bin feature in AD, this post will outline how to perform an object restore. Once the recycle bin has been successfully enabled you can use the ldp.exe tool or PowerShell to view the deleted objects container (hidden in ADUC) as well as recover anything contained within.

Via LDP

Get connected and expose the domain tree: Type ldp into the start search bar, click Connection—>Connect—>enter applicable DC information—>once connected click Connection—>Bind. Next click View—>Tree and enter the AD root as BaseDN you want to work within: dc=domain,dc=com. Drill down into your AD tree and look for CN=Deleted Objects… This is where all your objects go once deleted in AD. Double-click this line and you will see every object currently in a deleted state. Double click on a child object to reveal more details. The CN’s of each should be recognizable as their friendly names and in the details pane the Name value will be visible as well, in my case I deleted a user account named Temp.

To restore, right click the object you want to recover and click Modify. In the “Edit Entry Attribute” box type isDeleted, leave “Values” empty, click the “Delete” radial under Operation, then click the Enter button. You will see the new entry in the Entry List box. Next, go back to the “Edit Entry Attribute” box and type distinguishedName, in the values box type the original DN of the object before it was deleted. The DN of the object in it’s deleted state will not work here. (Look for the “lastKnownParent” line of the deleted object in the details pane and add the object’s CN to it). Click the “Replace” radial under operation then click Enter. You should now have 2 entries in the Entry List box. Tick the “Extended” box at the bottom left and click run. The output window should show that the object was modified with no errors. Go back to ADUC and verify that your object is back from the dead.

Via PowerShell

The PowerShell method is a one line command that pipes a get object operation to a restore object operation. This method is much faster but less gratifying for some reason. The filter criteria can be modified but going by display name should be easy enough. You will get no confirmation of success or failure in the PowerShell display.

Get-ADObject -Filter 'displayName -eq "temp"' -IncludeDeletedObjects | Restore-ADObject

Resource:

Technet

This applies to Server 2008 R2 and Windows 7 as well, of course. While this may be old news to some, MaxPC had a good article in their latest issue about using symbolic links in Vista. To paraphrase, symbolic links are like shortcuts but at the OS level, not the file system level. Starting in Vista/Server 2008, Microsoft changed the naming convention for user profile folders which would break applications configured to point to these locations (i.e. c:\documents and settings —> c:\users).  So to preserve application functionality Windows uses symbolic links to provide a path to get to the new location via the old paths, even though they don’t exist anymore. Look inside any user’s profile and you will see what look like shortcuts to my documents, local settings, etc. These are directory symbolic links.

The command mklink is used to create links and its options include: symbolic links for a file or a directory, hard links in place of symbolic links, or directory junctions.   Directory symbolic links probably get the most use and can be useful to preserve pathing of a folder that has been moved to a new location. The original directory name becomes the symbolic link and cannot exist prior to running mklink.

C:\Windows\system32>mklink /D c:\test c:\newtest
Cannot create a file when that file already exists.

C:\Windows\system32>mklink /D c:\test c:\newtest
symbolic link created for c:\test <<===>> c:\newtest

Now any reads or writes looking for c:\test will be seamlessly pointed to c:\newtest and the application won’t know the difference. Hard links are used to point directly to a file so the OS will treat the link like it’s the actual file, while soft links behave more like shortcuts. Links can be deleted directly in the file system just like any other file or folder.