A couple of questions:
This shows up on the RME home page, under Recently Completed Jobs:
I have a Archive poll job configured along with an Archive update job.
The archive poll runs before the update job.
The Archive update completes successfully on 27 items, but the update job fails with one item being only partially successful.
The reason on the item is:
Error polling for change on Primary Startup Config, not fetching the config.
It is using telnet as the protocol.
Whay would RME not be able to get the startup config if it can get everything else?
This shows up under Collection Status:
Inventory 27 Items
0 partially successful
4 out of sync
On the out of sync items, if you check them you can select "Sync on Device"
Is this recommended to do?
Also, where do I check the config archive to make sure they are actually getting archived?
In addition, if I have a router fail, is there a procedure to restore the existing config to the new router with CiscoWorks?
There could be a few reasons for not being able to poll for changes on the startup config. The best bet is to enable ArchiveMgmt debugging under RME > Admin > System Preferences > Loglevel Settings, then reproduce the problem, and check the dcmaservice.log for errors. A sniffer trace filtering on the problem device may also be helpful.
Syncing the configs is always a good thing to do to make sure you have the latest archived config from every device.
The best way to check if the config s being archived is to search your archive by device, and verify the date of the config matches the date of the config on the device (i.e. seen when you do a show run).
If you need to replace a router, you can either use Config Editor in Merge mode to push the entire archived config back to the new device (once it is managed in RME), or manually push the latest config from the shadow directory. The shadow directory will always store the latest config on the device that RME has archived, and is intended for use outside of RME. As such, all of the files under the shadow directory are indexed by device display name. The shadow directory can be found under NMSROOT\files\rme\dcma\shadow on Windows and /var/adm/CSCOpx/files/rme/dcma/shadow on Solaris.
When looking at the actual devices that show out of sync in RME, the device shows the startup and run being the same.
It is in RME that the startup config is different than the run config.
Is there an old startup config cached somewhere?
Right, you need to sync whichever is different on the device to RME. If one of the configs is failing to sync, then you need to troubleshoot that using the dcmaservice.log.
So, yes, RME has an old startup config archived for the device.
So the "Sync to Device" is not actually syncing the configs on the device, just the configs in the Archive Manager?
You also need to be aware that if you are running port security in "sticky" mode, the mac address learned on the switch port will be added to the running configuration, which is now different to the start-up configuration, so RME does a poll and see's the configs are out of sync, now these sort of dynamic running config changes can be excluded, another example is the ntp clock period changes periodically which is also a difference between the running and start-up configs.....RME can exclude these sort of dynamic changes.
I have notice that in DFM, there are a total of 27 devices,
24 are questionable and 3 are known.
Does this have to do with the fact that they were manually put in rather than allowing them to be Discovered?
And how do I correct it?
Questioned means that DFM could not communicate with the devices via either ICMP or SNMP. Check that the SNMP credentials are correct for the devices in DCR, and make sure the address by which DFM knows the device is ICMP reachable from the DFM server.
All of that is correct, I am getting successful config archives and software report jobs, I can see everything in campus manager and Cisco view.
Everything is showing up everywhere.
How often does the DFM check for communication?
It depends on how you've configured DFM. If the device goes into a question state, never again. You will have to rediscover the device in DFM. Else, it depends on the various polling parameters in DFM.
If you are going to go deep into DFM, you should start a new thread for that.