RME 4.3 - Auto Allocation doesn't work

Sven Hruza · ‎07-25-2009

Hi,

I created some user defined groups in CS.

After discovery all new devices will be put in the first group with their IP-address as "Display Name".

After configuration of the hostname and display name the devices will be put in their right group (group 2 - 5 sorted by location and IP-address).

All but this first group should be auto managed by RME. But that is not working! RME doesn't detect devices which are new in the groups 2 - 5.

If I apply the auto allocation settings once again without changing sopmething the new devices will be managed by RME.

Is there something to configure else or is auto allocation not designed for such a task?

Thanks!

Sven

Joe Clarke · ‎07-25-2009

I cannot reproduce. I created a group in Common Services called Import Group with a ruleset of:

Device.DisplayName startswith "nms-"

I set this group to be the RME Auto-allocation group.

I then added a new device to DCR with an IP address for a display name. RME did not manage the device as the device was not put into Import Group. I then changed the display name to nms-6506a, waited a few seconds, and the device was put into Import Group, and RME properly managed it.

It sounds like you have things configured correctly, so you may be experiencing a problem with EssentialsDM. It could also be that you need to wait for RME to recognize that the group membership has changed.

Sven Hruza · ‎07-27-2009

I checked the EssentialsDM. The process is up and running.

Then I changed the display name of two devices and checked the EssentialsDM_Server.log.

There I found one line for the right timestamp.

[ Mon Jul 27 11:31:57 CEST 2009 ],INFO ,[Thread-1064],com.cisco.nm.rmeng.inventory.dm.server.DCRMessageProcessor,OnDeviceUpdate,344,The Admin Setting for the CDA on Credential Edit is not selected

But that means, that there is no credential verification configured, right?

Is there anything else I can check?

Joe Clarke · ‎07-27-2009

It looks like things should be working, but debugging would need to be enabled so more analysis could be done.

Sven Hruza · ‎07-27-2009

I enabled debugging under

RME -> Set Application Logging Levels -> DeviceManagement.

Is that enough?

Now I wanted to test once again, but I got the failure "Internal error in communication channel".

Is it possible, that there is a connection between the two failures?

I only found this communication error with LMS 3.1 and not for 3.2?!?

I attached the logfiles, perhaps it will be helpful!

Thanks!

Joe Clarke · ‎07-27-2009

The error in dcr.log looks similar to CSCsu84143, but that was fixed in LMS 3.2. So you may have found a new bug. I recommend you open a TAC service request so more analysis can be done.