This discussion has been locked. The information referenced herein may be inaccurate due to age, software updates, or external references.
You can no longer post new replies to this discussion. If you have a similar question you can start a new discussion in this forum.

appending node name to CLI command

I am looking at solarwinds pushing a Kron scheduler to all cisco switches within my origanization. This is an automated backup to a ftp server and initiates a write mem. I am having issues passing the device name into the cli. Here is the code below, please provide suggestions. I am a little inexperienced using NCM in this fashion to push this configuration


.CHANGE_TEMPLATE_DESCRIPTION
This template configures physical interfaces based on interface description. It was verified on a Cisco 3850 Catalyst Switch running IOS software version 16.3.7.
.CHANGE_TEMPLATE_TAGS
Cisco, interface, VLAN, description, properties
.PARAMETER_LABEL @ContextNode
NCM Node
.PARAMETER_DESCRIPTION @ContextNode
The node the template will operate on. All templates require this by default. The target node is selected during the first part of the wizard so it will not be available for selection when defining values of variables.
*/
script configure_SZ_Kron_Backups (
NCM.Nodes @ContextNode)
{
CLI
{
configure terminal
kron occurrence SaveConfigSchedule at 20:00 recurring
policy-list SaveConfig
!
kron occurrence WeeklyBackupConfigSchedule at 20:00 Fri recurring
policy-list WeeklyBackupConfig
!
kron occurrence MonthlyBackupConfigSchedule at 0:00 1 recurring
policy-list MonthlyBackupConfig
!
kron policy-list SaveConfig
cli write mem
!
kron policy-list WeeklyBackupConfig
cli show start | redirect xxx.xxx.xxx.xxx/.../[SysName]
!
kron policy-list MonthlyBackupConfig
cli show start | redirect xxx.xxx.xxx.xxx/.../[SysName]
}
}

  • I may be barking up the wrong tree, but it seems you may be doing a lot more work than necessary.

    Forgive me if I'm way off base, but I recommend you use NCM's New Job functionality to accomplish what you want.  I've used it to create many new Jobs that accomplish all sorts of things, from backing up running configs separately from startup-configs, doing scheduled reboots of devices, performing file transfers, doing archiving of configuration files, and so much more.

    NCM's built in Scheduling feature eliminates the need for your chron jobs.  Set the Schedule on any job to run once, run ten times, run every day, run every hour--you're in complete control.

    And the pre-created Job tasks NCM provides have virtually all of the bases covered; you may not need to create any new Job at all.  Just open an existing one, edit it to do what you want, select the nodes to be included, set the schedule, and let it run on its own.

    NCM will even notify you and your team if a job finishes successfully or if it fails.  And it'll show you what went wrong if something did fail.

    Best of all (in my opinion), NCM backs up to whatever directory you specify.  You could have it write to the default directory on each APE, but that's not the best practice.  Instead create a share that your NCM service account can use to archive the config files to.  That gets you the files where you want or need them, without you having to do anything special.  

    Something else I like about that best practice is your organization's server backup solution will automatically make tape or spinning disk or solid state backups of your servers, meaning you've automatically got copies of your archived config files in case anything should go wrong.  Having NCM automatically notify you of failed backup or archive jobs is nothing more than you'd expect from the full features it offers.

    And you can use simple logic to automatically add any (or every) new device on your network to the backup Job.  I just tell the Job to include all Cisco and Juniper devices.  As soon as they're added into NPM, NCM will include them in all Jobs that use that logic.  There's no longer any need to manually add individual nodes to multiple Jobs--simple Groups and machine logic ensure every newly added node participates in the appropriate Jobs.

    If you need help, I'll be happy to guide you through setting up a new Job, or modifying an existing one.

    Swift Packets!

    Rick Schroeder