Well - If I were you, I'd throw a copy of the DB against your test environment and install SP1 - see if the problem still happens.
If it is a bug/defect, we'll only be able to provide a post SP1 fix (Though I've not heard of this sort of issue myself so far, as far as memory serves).
That said, if you're comfortable with SQL, you can hop into the database and forcibly shift the scripts' location around.
If the Console is running into errors, it will log them into the CONSOLE.EXE.LOG - so what you can also do is:
1 - Delete the CONSOLE.EXE.LOG wherever you use it.
2 - Launch the 32-bit Console.
3 - Do your script-moving attempt. Watch it not happen.
4 - Open up the CONSOLE.EXE.LOG - if there's any exceptions or so that we capture, they'll be in there.
... actually, the PXE boot-menu COULD be just a flat file that you need to edit ... looks
Ah yes - here we go. Thought that some ancient memory crept up...
Check this out - In "
YourCore\LDMAIN\landesk\files\" haul "dosmenu.cfg" into NOTEPAD. Yes, it says "DOS", but it's the general config-file for the boot-menu (all OS's - Dos, Linux and WinPE) - the name's historical from when we "only" did DOS.
The structure is pretty simple to figure out ... no SQL involved, you can just try to shuffle things about if needed.
In your case. I would suggest looking at the file on a test system first ... it will probably be easier to look at and reverse engineer, as it were :).
(I remembered this, as I once had to create a massive boot menu, and it ended up being faster writing the CFG-file straight out)
LANDesk EMEA Technical Lead.
Paul, I already tried editing the DOSMENU.CFG file, but the changes don't seem to reflect in the Console. For example, if i have a structure like this:
And I change ITEM2's parent folder ID number to that of PARENT2, close the Console and re-launch it, ITEM2 remains in PARENT1.
I think the DOSMENU file is ONLY for the PXEMENU once booted into your PE environment, which is why one has to click the UPDATE button to generate the new CFG file, while the actual hierarchy is stored in the databse.
As for the drag'n'drop problem, nothing is logged in the Console.log, likely because it's not an error within the 32-bit Console.
Using the same example above, lets say I want to move ITEM1 to PARENT3. When I drag ITEM1 over PARENT2, I get a "PLUS" symbol on my arrow cursor, but when I land on PARENT3, the arrow cursor changes to the circle-slash symbol even though PARENT3 doesn't have 18 items in it. If I delete PARENT3 and create it again, the Console will (usually) let me add items to it.
I have experienced this behavior in various SP levels of 8.7 as well.
Oh I see what you're after.
Hacking the DOSMENU.CFG will change the bootmenu for clients "right away".
If you want to change it "comfortably" from and have those changes reflected in the Console, the table you want to change is the PXEMENU table.
Which again is pretty straight forward if you just look at it on a client with (say) 1-2 PXE scripts, before braving your "full on" PXEMENU-table :).
LANDesk EMEA Technical Lead.