I built an NCM Job that does this and only this. I run it every day to ensure no one has a config that isn't saved, which will be lost during a power outage.
Of course, before you do ANYTHING, submit your planned change as a Change Request to the appropriate Change Administration Board so your work is logged and expected, and so the right folks learn about it. Never operate as if you're in a vacuum--you're not. Others appreciate knowing you're on the ball, making changes for the better, and that you and your team mates always dot the i's and cross the t's. It's how you earn trust from others. That trust goes a long way in the future.
If some devices require a different syntax or script, build a "first" Job for one set of devices and get it running.
- Then copy the job and use it to build a new one for other devices that need different scripts.
- Edit the second job and include or exclude the right devices selected.
- Edit the script in the copied job to use the right syntax for its devices.
- Rename the second job intuitively so you know this is a Juniper instead of a Cisco Job
- Run this second job on a second schedule
Here's how to do this in your environment with NCM:
1. Go to NCM's Jobs List and create a new Job. I'll paste in screen shot of mine to help you out:
- Name the job intuitively
- Select the frequency
- Select the start time
- Select the start and ending dates for the job
- Fill in Comments about the purpose of the job and include your name just in case someone has questions about the job.
- Select the Nodes you want to participate in this Job. List them individually, select them through logic--whatever is easiest and comprehensive.
- View the Selected Nodes and verify the ones you expect are present actually ARE present. Modify the selection method until you get only the nodes you want, and ALL the nodes you need.
Safety tip: Do the first build of this job with only one node present. Make it a test node that can't hurt anything if your job happens to include mistakes. Once you complete building the job and have run it successfully against that one test node, go back into the job and edit it to include all the nodes you want.
- Fill in the Notification Details. Be complete. What good is a job that doesn't tell you if it failed?
- Put in the Job Specific Details to Execute the script. Enter the commands just as you would if you were at the CLI prompt. Don't forget carriage returns or line feeds, or they may not work as you expect.
- Use the right syntax. Write memory is deprecating some day, so use "copy running-config startup-config" or the equivalent for your devices.
- Review the Job.
- Look through it with a fine-toothed comb.
- Find those typos and correct them.
- Fix any missed nodes or commands or schedules.
- Look at the output here and ensure it's what you expect.
- Click Finish and run the job manually or via schedule.
It's never a foolish idea to test a new job on just one node--preferably a node in the test lab. If you inadvertently pasted in script from some other buffer, you might have unexpected commands in your script that may damage your environment. Don't be that person who makes a foolish error and then lets NCM be the "stupid machine" that blindly does exactly what you instructed.
After testing successfully, feel free to add in more nodes as needed.
Feel free to reach out to me with questions. This is a simple solution that can be customized to any environment that uses CLI commands to accomplish ANY task.
Perfect, just had it fire off and worked like a charm. Thanks!
I'm happy to hear it's working for you. Please feel free to make my answer "Correct" so others can find it.