This is usually because there's still some artifact of the user somewhere in the DB. Here's two "quickies" to help you.
Option 1:
=========
The only script in this regard that is known is to be found here:
http://www.droppedpackets.org/scripts/ldms_delete_users/
Option 2:
==========
If Option 1 should fail, you'll need to take a more manual approach. Here's what needs to be done.
Delete all the related data with this user in the database. Steps:
1. Open up your SQL Enterprise manager (I assume you are using SQL Server), and find your LANDesk Database.
2. Find the 'ConsoleUser' table
3. Right click on the user that you wish to delete, and click on delete.
4. It will ask you if you wish to permantly delete that user. Click on Yes.
5. It will then give you an error saying something about the Delete statement conflicted with a column reference constraint. Then it will give you the database name, table, and column. You will then have to go to that table, and delete the column that it referenced.
Example:
a. I have a database called 'April', and my user is named 'splintercell'
b. I open up the 'ConsoleUser' table and find the user 'splintercell'. I notice that the 'ConsoleUser_IDN' = 5
c. I right click on the user 'splintercell' and then click on 'delete'
d. It asks me if I want to permantly delete this user, and I click on 'Yes'
e. SQL gives me an error about the Delete statement conflicted with a column reference constraint. Then it says, "The conflict occurred in
database 'April', table 'ConsoleUserScope', column 'ConsoleUser_IDN'
f. I then open up table 'ConsoleUserScope' and find 'ConsoleUser_IDN' of 5(Since 5 was the ConsoleUser_IDN of my user 'splintercell'
g. I then right click on 5 and click on delete.
This will keep bringing up errors until you have gotten to the child object that you can delete. You just have to keep going to each table that it tells you to go to. It is a long process.
NOTE -- this assumes your competent and comfortable using SQL. If you're not, you can open up a case with LANDesk support, and we can help you out here (assuming we can get a DB backup from you).
Do *NOT* attempt Option 2 if you're not sure what you're doing - at best you're not going to do anything, at worst (with a bit of "wrong" SQL) you could break the DB. So always have a full backup beforehand (that's verified).
Paul Hoffmann
LANDesk EMEA Technical Lead
