hp Lights-Out Directories Migration Utility error

[Steve Owensby]

We have approx 1500 Lights Out devices in our environment that we are migrating to our Active Directory. I am getting the following error using the hp Lights-Out Directories Migration Utility, on the "Configure Directory" screen after clicking the "Update Directory" button: "Collection was modified; enumeration operation may not execute." The 1st Lights-Out device in the list has the "Distinguished Name" field populated, but all of the other :Distinguished Name" fields are blank. When I check the AD, the device with the distinguished name column populated, appears in the proper OU and has the correct Role assigned. So I can get one migrated, but none of the others in the list.
Here is some more info: I am using the hp Lights-Out Directories Migration Utility v1.14 to migrate these devices. The Schema was updated last month with the "Schema Extender Utility". I have installed the MMC Snap-In on my local workstation (XP SP1 - .Net Framework 1.1 SP1 - also where I am running the Migration Utility). I have a list of IP addresses that I am importing from. I have upgraded all of the devices to the latest firmware (iLO = 1.62, RILOE II = 1.13 and RILOE = 2.53). I am using the DNS names for the object names.
If I enter the devices one at a time, I get the same error, but I can then proceed to configure the Lights-Out device with no issues. I can then log into the Lights-Out with my Active Directory account.

[Jeff Allen_5]

Interesting. What happens if you choose just 2-10 of them at a time? I have had problems beyond 50 or so at a time similar to yours. I KNOW it cannot do 1500 at one time. I read in a doc somewhere that HP only supports 100 at a time.

Also, is this a 2k3 domain or 2k? Assuming 2k3, I "think" all the DC's have a writeable copy of the schema so you should not have to target any one DC, but you could try targeting other servers to see.

[Steve Owensby]

It did not matter how many I placed in the list. I did find the resolution though. Even though the Migration UItility asks you for an Active Directory Administrative account, it only uses that account info for the first migration. When I ran the utility using runas with the administrative credentials, it ran all of them fine.
I only had a portion of my 1500, but well over the 100 limit you mentioned. I had it do almost 200 with no issues.

[Elena Atance]

I suffered exactly the same problem and after some tests I could find that:

1. When you delete any HP device, this is marked as tombstoned.
2. You cannot see them in the using dsa.msc in the â HP Devicesâ tab of the associated HP Role properties.
3. If you try to add additional Devices to the Role, the error "Collection was modified; enumeration operation may not execute" appears.
4. If you examine the REAL values of the HP Role Attributes using Adsiedit.mscâ ¦surprise! The deleted devices are still there, in the hpqTargetMembership attribute, marked as tombstoned, but if we take into account the default tombstone time in AD (60 days) the erase procedure is not operational at all.
Using adsiedit you will see in the hpqTargetMembership value something similar to:
CN=ILO_name\0ADEL:328a5d37-9f48-49f8-90e7-281b05f8191e,CN=Deleted Objects,DC=domain,DC=com

Workarounds:

WORKAROUND 1: The Device should be deleted from the associated HP Role properties (the â HP Devicesâ tab) before actually deleting the HP Device itself in dsa.msi. Deleting the Device before removing its membership in the Role will cause the problem.


WORKAROUND 2: If the Device has been deleted prior to the removal of its membership in the role then the only way to solve it is by editing the attribute in adsiedit and deleting the wrong value (similar to CN=ILO_name\0ADEL:328a5d37-9f48-49f8-90e7-281b05f8191e,CN=Deleted Objects,DC=domain,DC=com). I am not sure if waiting the 60 days would solve the problem (my tests didnâ t last so much).


Now, the problem could be easily solved if HP provided a tool to delete objects as it has to create them.

[Elena Atance]

The problem seems to be solved in V2.01 of the LDAP Migration tool =:-)