OS: Solaris 10 ( Sparc, 64 bit )
In Common Services, in the device distribution section, is lists over 1000 devices in the RME row.
In RME->Device Management , it lists 1344 "Normal" devices
If you click on "Normal Devices" and select "All Devices" , it will show "0 devices selected"
in RME->Reports->Report Generator , any device selection will result in "0 devices selected" .
If you try to add devices from DCR, it will say "no new devices exist in DCR"
To say the least, I'm stumped.
I've restarted the daemon mgt server several times
done the ./dbserv10 -f /path/to/rmeng.db procedure a few times
Switched between local and remote authentication mode ( ACS and non-ACS )
Pls check this...
rme > admin > device mgmgt > device mgmgt settings
-->enable auto mode
check auto mode apply it and restart the services...
rate if was helpful.
Pls check the services window for ciscoworks....in windows its services.msc.
CW Process order:
>> The only services that should be automatic are :
* Ciscoworks Daemon Manager
* CWCS rsh/rcp
* CWCS syslog
* CWCS tftp
put the rest back to manual.
Then restart the Daemon Manager
--> do a service restart and untouch the server untill all the services come up.
Secondly if it does not solve it, and If you have a good backup of the Lms, you can do two things...
1 --- Keep a backup of the cs, then remove all devices from Ciscoworks common services, restart the Lms.
Import the device credential list in Cs and check the status
2 --- Do a database restoration from a good db backup.
Two options you can try below, start with option 2 and if that does not work, use option 1.
1. Stop LMS Daemon manager from "/etc/init.d/dmgtd stop".
2. Execute "/opt/CSCOpx/bin/perl /opt/CSCOpx/bin/dbRestoreOrig.pl dsn=rmeng dmprefix=RME".
3. Start LMS daemon from "/etc/init.d/dmgtd start".
4. If you auto managed enabled in RME, then wait about 20 minutes after services startup for the devices to populate in Normal mode.
Post the daemons.log, dcmaclient.log, dcmaservice.log, "CSCOpx/bin/pdshow -brief" and ensure the "EssentialsDM" and all other RME services are running. If not,
1. Stop LMS daemon manager /etc/init.d/dmgtd stop.
2. Remove two files from the following location "CSCOpx\MDC\tomcat\webapps\rme\WEB-INF\lib" called ctmregistry and ctmregistry.backup.
3. Start LMS daemon manager /etc/init.d/dmgtd start.
Let us know the results.
I posted modified (cleaned up ) logs. Those processes were running, but there are errors in the log files. I performed Option 1 as well. The database cleared up but it did not automatically re-add devices from the DCR. Doesn't the automatic setting only trigger device additions if and only if the DCR adds a new device? What I am getting at is if the DCR service inventory is unchanged, and I re-initialize the RME database, then RME inventory will be empty until the DCR server adds a new device to its inventory.
Right now, there is no reason a new device will by added by the DCR service, as its inventory is correct. If all of this true, won't I need to manually tell the RME service to add devices from the DCR inventory?
I ended up restoring the database to default, starting the daemon manager, allowing RME to re-add devices from the DCR, and finally rebooting the server before I could select devices for reports/jobs .
The Campus Manager database is apparently having trouble as well, so I have just finished backing up the user defined groups and wiping the ANI database. Hopefully all devices will be available to select/manage when CiscoWorks finally comes up.
After restoring both the ANI and RME databases to original states and letting them rebuild, the device selector for RME was still broken. There was a URN error message - URN : ogs_server_urn ErrMsg : URN already in use - in the RMEOGSServer.log file which led me to research the Web application settings.
There I discovered the ctm_config.txt file was empty. So I copied settings from a working installation of CiscoWorks, and restarted the daemon manager. I probably could have just restarted the RMEOGSServer process, but regardless the device selector worked after that, and no more error messages appeared in the log file.
My guess is that the empty config file caused RME to grab a random port, but it was always selecting on that was already in use. Anyway, its all fixed now.