As a matter of fact, it is integrated with ACS.

Then you have two options. One is to temporarily break the ACS integration, then see if you can resolve the phantom aliases. The alternative is to go through every device and make sure every IP address is configured as a client in ACS. Obviously, breaking ACS integration would be much easier.

If, after breaking the integration, the aliases are still empty, the database cleanup procedure can be attempted with TAC's help.

Breaking ACS integration is not an option. Also, if an IP address is not in ACS, it show up in CS on the Not in ACS list. That list is empty. I think it's time for a TAC case.

Thanks for the feedback!

Its also present in 3.0 and 3.01 so its not fixed either :)

Assuming you had a clean database going into 3.0.1, this problem shouldn't happen again. Are you saying it has? With zero aliases showing in RME in LMS 3.0.1, can you get RME to show a non-zero alias count but have no devices showing as aliases?

Its even better than that. I did a clean install of 3.0, followed by an immediate upgrade to 3.01. I imported a hand checked CSV inventory consisting of just the ip addresses (for host_name and display_name), sysObjectID, and credentials. It was ok for a few discoveries, but then Aliased with no aliases cropped up.

I know what's happening here. This is a bug in discovery. See CSCsm66330. I see the same thing, but my alias list doesn't have phantoms. Are you integrated with ACS?

This one has reared it's ugly head again but this time on a 2nd server. I didn't follow up on your question.

Yes, we are integrated with ACS.

Check the Common Services > Device and Credentials > Reports > Devices not in ACS report to make sure you're not seeing any entries there that could be these phantom aliases.

All servers report "0" devices on the "Not in ACS" report; on both the CS homepage and the "Devices that are not configured in ACS Report" on the page you refer to above.

I could see how going back and forth between ACS mode and non-ACS mode might create a fictitious alias but just this week a 2nd server now/also shows "2" on the alias list and yet, nothing shows up on the alias remediation page. This 2nd server has been integrated with ACS for over a year. The LMS processes have been stopped/started on Solaris many times but ACS integration has been 100%. Once we flipped the switch, we never went back.

I suppose what might have happened is the alias was resolved by a different application (e.g. DFM). As I said in my first post, there is a procedure you can get from TAC to manually clean these bogus aliases from the database.

Why did Cisco eng's ever integrate LMS with ACS, I will never figure out.. It's been causing numerous faults and yet not one TAC eng. can tell me why it is beneficial.

Had similar case - but some of my devices were not in the ACS. I had to make a dummy grp of addresses in ACS to fix this:-((

here is what i was told by TAC..

""""The problem seems to be an issue with ACS integration. If an alias device is

in CiscoWorks, but not listed in a Network Device Group in ACS, then it will

not be seen when you click on the number of alias devices.

You can tell if this is the issue by going to Common Services>Device and

Credentials>Reports and running a Devices that are not configured in ACS

report."""""""