Configuration and Discovery

The following sections describe how to configure and discover Cisco Meraki devices for monitoring by SL1 using the Cisco: Meraki [API] PowerPack and the Meraki API:

Generating a Cisco Meraki API Key

To configure Cisco Meraki for monitoring using the Meraki API, you must first generate an API key for a read-only Meraki user. You will then enter this user's API key in the Basic/Snippet credential or SOAP/XML credential you create in SL1 to monitor Meraki.

While an API key for a read-only Meraki user is acceptable for most credential purposes in this PowerPack, an API key for a user with write permissions is required for the automation that changes configurations and reboots devices.

If the read-only user has access to multiple organizations, then SL1 can discover all of those organizations with a single discovery session. In this scenario, each organization is created as a separate "root level" device with the networks and devices for that organization modeled in the DCM Tree as children of the organization. Organizations and their child components can be moved between collectors after discovery for load balancing purposes.

However, if you want each Meraki organization to have its own corresponding ScienceLogic organization in SL1, ScienceLogic recommends creating a unique read-only user account and API key for each organization in Meraki. You can then create separate credentials in SL1 for each Meraki organization using those unique API keys, and then use those credentials to run separate discovery sessions for each organization.

To create a read-only user:

Go to Organization > Administrators, and then click the Add admin button.

On the Create administrator page, complete the following fields:

Name. Type the user's name.

Email. Type the user's email address.
Organization access. Select Read-only.

Click Create admin. Cisco Meraki sends an email to the email address provided, describing how the user can complete the registration process. The user must complete those steps before generating the API key.

To generate a Cisco Meraki API key for that read-only user:

Go to Organization > Settings:

In the Dashboard API access section, select the Enable access to the Cisco Meraki Dashboard API checkbox.
Click the Save Changes button.
Click the profile link in the Dashboard API access section.

In your user profile, navigate to the API access section and click the Generate new API key button.

In the API access section, the API key appears. Copy and save the key value.

API keys are visible only to the user that created them.

Creating a Basic/Snippet Credential

To configure SL1 to monitor Cisco Meraki systems using the Meraki API, you must create a Basic/Snippet credential. This credential allows the Dynamic Applications in the Cisco: Meraki [API] PowerPack to connect with the Cisco Meraki API. An example Basic/Snippet credential that you can edit for your own use is included in the PowerPack.

NOTE: If you are using an SL1 system prior to version 11.1.0, the new user interface does not include the Duplicate option for sample credential(s). ScienceLogic recommends that you use the classic user interface and the Save As button to create new credentials from sample credentials. This will prevent you from overwriting the sample credential(s).

To create a Basic/Snippet credential:

Go to the Credentials page (Manage > Credentials).
Locate the Cisco: Meraki - API sample credential, click its Actions icon () and select Duplicate. A copy of the credential, called Cisco: Meraki - API copy appears.
Click the Actions icon () for the Cisco: Meraki - API copy credential and select Edit. The Edit Credential page appears:

Supply values in the following fields:

Name. Type a new name for the Meraki credential.

All Organizations. Toggle on (blue) to align the credential to all organizations, or toggle off (gray) and then select one or more specific organizations from the What organization manages this service? drop-down field to align the credential with those specific organizations.
Timeout (ms). Keep the default value.

Hostname/IP. Keep the default value.

You must use the default value of "https://api.meraki.com" in the Hostname/IP field.

Port. Keep the default value.

Username. Keep the default value.

Password. Type the Meraki API key.

Click Save & Close.

If you would like to test your credential using the Credential Tester panel, click Save & Test. For detailed instructions on using the Credential Tester panel, see the Testing the Cisco Meraki API Credential section.

Creating a Basic/Snippet Credential in the SL1 Classic User Interface

To create a Basic/Snippet credential:

Go to the Credential Management page (System > Manage > Credentials).

Locate the Cisco: Meraki - API credential, and then click its wrench icon (). The Edit Basic/Snippet Credential modal page appears:

Complete the following fields:

Credential Name. Type a new name for the credential.

Hostname/IP. Keep the default value.

You must use the default value of "https://api.meraki.com" in the Hostname/IP field.

Port. Keep the default value.
Timeout(ms). Keep the default value.
Username. Keep the default value.
Password. Type the Meraki API key.

Click the Save As button.
When the confirmation message appears, click OK.

Creating a SOAP/XML Credential

If you access Meraki systems through a third-party proxy server, you can create a SOAP/XML credential to enable the Dynamic Applications in the Cisco: Meraki [API] PowerPack to connect with the Cisco Meraki API via the proxy server.

Similarly, if you want to discover only some selected devices, you can create a SOAP/XML credential that specifies tag values that the Dynamic Applications in the Cisco: Meraki [API] PowerPack can use to determine which devices should be discovered.

NOTE: If you are on an SL1 system prior to version 11.1.0, you will not be able to duplicate the sample credential. It is recommended that you create your new credentials using the SL1 classic user interface so you do not overwrite the sample credential(s).

Two example SOAP/XML credentials that you can edit for your own use are included in the PowerPack:

Cisco: Meraki - API - Proxy, for users who connect to Meraki through a third-party proxy server

Cisco: Meraki - API (Selective), for users who want to discover only some selected devices based on tag values

To define a SOAP/XML credential:

Go to the Credentials page (Manage > Credentials).
Locate the sample credential you want to use, then click its Actions icon () and select Duplicate. A copy of the credential, called Cisco: Meraki - API - Proxy copy or Cisco: Meraki - API (Selective) copy appears.
Click the Actions icon () for the credential copy and select Edit. The Edit Credential modal page appears.

Supply values in the following fields:

Name. Type a new name for your Meraki credential.

All Organizations. Toggle on (blue) to align the credential to all organizations, or toggle off (gray) and then select one or more specific organizations from the What organization manages this service? drop-down field to align the credential with those specific organizations.
Timeout (ms). Keep the default value.

Content Encoding.Keep the default value.
Method. Keep the default value.

HTTP Version. Keep the default value.
URL. Keep the default value of "https://api.meraki.com".

HTTP Auth User. Keep the default value.

HTTP Auth Password. Type the Meraki API key.

Proxy Settings

You must complete the Proxy Settings fields only if you connect to the Meraki API through a third-party proxy server. If you do not use a proxy to connect to Meraki, then you can leave these fields blank.

Hostname/IP. Type the server's hostname or IP address.
Port.Type the port on the proxy server to which you will connect.
User. Type the username used to access the proxy server.
Password. Type the password used to access the proxy server.

HTTP Headers

proxy_url_protocol:http. Edit this header if you want to connect a proxy using a different protocol, such as http or https. The default value is "http".
Add a header. Click Add a header once if you want to include tag values for SL1 to match when it discovers Meraki devices, or click Add a header twice if you want to include tag values and specify that tag-matching should be case-insensitive. In the blank fields that appear, do one or both of the following:

Type "tags:" in the first field, followed by one or more tag values. You can include multiple tag values in a string, using comma separators and no spaces. For example: "tags:value1,value2,value3".
Type "regex:IGNORECASE" in the second field if you want SL1 to match the tag values regardless of case.

If you are using a tag to discover a device and want to discover that device's network, the device and its network must have the same tag applied.

Tag values can include wildcard characters.

After initial discovery, you can add more tag values and run discovery again to discover additional component devices. However, if you remove tag values and then run discovery again, the component devices that had been discovered based on the removed tag values will be updated to an unavailable state.

Click Save & Close.

Creating a SOAP/XML Credential in the SL1 Classic User Interface

Two example SOAP/XML credentials that you can edit for your own use are included in the PowerPack:

Cisco: Meraki - API - Proxy, for users who connect to Meraki through a third-party proxy server

Cisco: Meraki - API (Selective), for users who want to discover only some selected devices based on tag values

To define a SOAP/XML credential:

Go to the Credential Management page (System > Manage > Credentials).

Locate the Cisco Meraki example credential that you want to use and click its wrench icon (). The Credential Editor modal page appears:

Enter values in the following fields:

Basic Settings

Profile Name. Type a new name for your Meraki credential.

HTTP Auth Password. Type the Meraki API key.

You can use the default values for the remaining Basic Settings fields. You must use the default value in the URL field.

Proxy Settings

Hostname/IP. Type the server's hostname or IP address.

Port. Type the port on the proxy server to which you will connect.
User. Type the username used to access the proxy server.
Password. Type the password used to access the proxy server.

HTTP Headers

proxy_url_protocol:http. Edit this header if you want to connect a proxy using a different protocol, such as http or https. The default value is "http".

Add a header. Click Add a header once if you want to include tag values for SL1 to match when it discovers Meraki devices, or click Add a header twice if you want to include tag values and specify that tag-matching should be case-insensitive. In the blank fields that appear, do one or both of the following:

Type "tags:" in the first field, followed by one or more tag values. You can include multiple tag values in a string, using comma separators and no spaces. For example: "tags:value1,value2,value3".
Type "regex:IGNORECASE" in the second field if you want SL1 to match the tag values regardless of case.

If you are using a tag to discover a device and want to discover that device's network, the device and its network must have the same tag applied.

Tag values can include wildcard characters.

Click the Save As button, and then click OK.

Testing the Cisco Meraki API Credential

The Cisco: Meraki [API] PowerPack includes a credential test for Cisco Meraki credentials. Credential tests define a series of steps that SL1 can execute on demand to validate whether a credential works as expected.

The Cisco Meraki credential tests can be used to test the Basic/Snippet and SOAP/XML credentials for monitoring the Cisco Meraki API using the Dynamic Applications in the Cisco: Meraki [API]PowerPack.

The Cisco: Meraki [API] (Basic/Snippet) Credential tester performs the following steps:

Test Meraki Reachability. Performs an ICMP ping request to the host specified in the credential.
Test Meraki Port Availability. Performs an NMAP request to the TCP port specified in the credential on the host specified in the credential.
Test Meraki Organization Request. Performs a check to see if the Meraki organization request has been collected appropriately.

The Cisco: Meraki [API] (SOAP/XML) Credential tester performs the following steps:

Test Meraki Reachability. Performs an ICMP ping request to the host specified in the credential.
Test Meraki Port Availability. Performs an NMAP request to the TCP port specified in the credential on the host specified in the credential.
Test Meraki Organization Request. Performs a check to see if the Meraki organization request has been collected appropriately.

To test the Cisco Meraki credential:

Go to the Credentials page (Manage > Credentials).
Locate the credential you wish to test, select the Actions button () next to it and click Edit/Test. The Edit Credential modal page appears:

In the Credential Tester pane on the right, fill out the following fields on this page:

Select Credential Test. Select Cisco: Meraki [API] (Basic/Snippet) Credential tester or the Cisco: Meraki [API] (SOAP/XML) Credential tester, depending on which credential you are testing.
Collector. Select the All-In-One Appliance or Data Collector that will run the test.
IP or Hostname to Test. Enter "api.meraki.com" or the IP address of your Meraki system.

Click the Run Test button to run the credential test. The Testing Credential window appears.

The Testing Credential window displays a log entry for each step in the credential test. The steps performed are different for each credential test. The log entry for each step includes the following information:

Step. The name of the step.
Description. A description of the action performed during the step.
Log Message. The result of the step for this execution of the credential test.
Status. Whether the result of this step indicates the credential and/or the network environment is configured correctly (Passed) or incorrectly (Failed).
Step Tip. Mouse over the question mark icon () to display the tip text. The tip text recommends what to do to change the credential and/or the network environment if the step has a status of "Failed".

Testing the Cisco Meraki API Credential in the SL1 Classic User Interface

The Cisco: Meraki [API] (Basic/Snippet) Credential tester performs the following steps:

Test Meraki Reachability. Performs an ICMP ping request to the host specified in the credential.
Test Meraki Port Availability. Performs an NMAP request to the TCP port specified in the credential on the host specified in the credential.
Test Meraki Organization Request. Performs a check to see if the Meraki organization request has been collected appropriately.

The Cisco: Meraki [API] (SOAP/XML) Credential tester performs the following steps:

Test Meraki Reachability. Performs an ICMP ping request to the host specified in the credential.
Test Meraki Port Availability. Performs an NMAP request to the TCP port specified in the credential on the host specified in the credential.
Test Meraki Organization Request. Performs a check to see if the Meraki organization request has been collected appropriately.

To test the Cisco Meraki credential:

Go to the Credential Test Management page (System > Customize > Credential Tests).

Locate the Cisco: Meraki [API] (Basic/Snippet) Credential tester or the Cisco: Meraki [API] (SOAP/XML) Credential tester, depending on which credential you are testing, and click its lightning bolt icon (). The Credential Tester modal page appears:

Supply values in the following fields:

Test Type. This field is pre-populated with the credential test you selected.

Credential. Select the credential to test. This drop-down list includes only credentials that you have access to that can be tested using the selected credential test.
Hostname/IP. Enter "api.meraki.com" or the IP address of your Meraki system.
Collector. Select the All-In-One Appliance or Data Collector that will run the test.

Click the Run Test button to run the credential test. The Test Credential window appears.

The Test Credential window displays a log entry for each step in the credential test. The steps performed are different for each credential test. The log entry for each step includes the following information:

Step. The name of the step.

Description. A description of the action performed during the step.
Log Message. The result of the step for this credential test.
Status. Whether the result of this step indicates the credential or the network environment is configured correctly (Passed) or incorrectly (Failed).
Step Tip. Mouse over the question mark icon () to display the tip text. The tip text recommends what to do to change the credential or the network environment if the step has a status of "Failed".

Creating a Cisco Meraki Virtual Device

To monitor your Cisco Meraki devices, you must create a virtual device that represents the Meraki Cloud Controller. A virtual device is a user-defined container that represents a device or service that cannot be discovered by SL1. You can use the virtual device to store information gathered by policies or Dynamic Applications.

If you want to discover more than one Meraki account, you must create a virtual device for each API key that you want to use.

To create a virtual device that represents your Meraki Cloud Controller:

Go to the Device Manager page (Devices > Device Manager).

Click Actions and select Create Virtual Device from the menu. The Virtual Device modal page appears.

Enter values in the following fields:

Device Name. Enter a name for the device.

Organization. Select the organization for this device. The organization you associate with the device limits the users that will be able to view and edit the device. Typically, only members of the organization will be able to view and edit the device.
Device Class. Select Cisco Systems | Meraki Cloud Controller.
Collector. Select the collector group that will monitor the device.

Click Add to create the virtual device.
Repeat these steps for each Meraki API key that you want to use.

Manually Aligning the Cisco: Meraki Organizations Discovery Dynamic Application

After creating the Cisco Meraki virtual device, you must manually align the "Cisco: Meraki Organizations Discovery [API]" Dynamic Application to the Cisco Meraki virtual device.

To manually align the Cisco Meraki Dynamic Application:

Go to the Devicespage (Devices > Device Manager).

Locate your Cisco Meraki virtual device and click its name.
In the Device Investigator, click the Collections tab.
Click the Edit button at the top of the page, then click the Align Dynamic App button.

In the Align Dynamic Application modal, click Choose Dynamic Application.
Locate "Cisco: Meraki Organizations Discovery [API]" and click Select.

In the Align Dynamic Application modal, de-select the Use Device SNMP Credential box. Click the Choose Credential option that appears.
Select the Cisco Meraki credential you created and click Select.

Click Align Dynamic App to align the Dynamic Application with the Cisco Meraki virtual device.

After aligning the "Cisco: Meraki Organizations Discovery [API]" Dynamic Application, your Cisco Meraki component devices will be discovered and classified.

The Poll Frequencyof the "Cisco: Meraki Organizations Discovery [API]" Dynamic Application should be set to 5 minutes.

Assigning a Device Class to a Discovered Device

As of version 111 of the Cisco: Meraki API PowerPack, the parameters used to assign a device class to a device have been updated. The device's model name is split into two parts when SL1 assigns a device class:

The first two characters of the model name are assigned to the Class Identifier 1 component identifier on the Class Identifier collection object. If the Cisco: Meraki device's model name starts with a "v", the next two characters after the "v" are assigned to this collection object instead.
The rest of the characters in the model name are assigned to the Class Identifier 2 component identifier on the Class Identifier 2 collection object.

SL1 will assign a device class based on the information in the Class Identifier 1 and 2 fields:

If the information in the Class Identifier 1 and 2 fields matches the Class Identifier 1 and 2 of a device class in the PowerPack exactly, that device class is assigned to the device.
If the information in the Class Identifier 1 field matches, but no match occurs on the Class Identifier 2 collection object, one of 15 fallback device classes is assigned. The fallback device class matching Class Identifier 1 with the lowest weight will be assigned.
If no match occurs in either of the Class Identifier fields, the "Cisco Systems | Meraki Device" default device class is assigned to the device.

This process is standard SL1 functionality that is in the Configuring Collection Objects as Component Identifiers section.

Manually Aligning the Cisco: Meraki Organizations Discovery Dynamic Application in the SL1 Classic User Interface

After creating the Cisco Meraki virtual device, you must manually align the "Cisco: Meraki Organizations Discovery [API]" Dynamic Application to the Cisco Meraki virtual device.

To manually align the Cisco Meraki Dynamic Application:

Go to the Device Manager page (Devices > Device Manager).

Click the wrench icon () for your Cisco Meraki virtual device.
In the Device Administration panel, click the Collections tab. The Dynamic Application Collections page appears.
Click the Actions button and select Add Dynamic Application from the menu.

In the Dynamic Application Alignment window, from the Dynamic Applications field, select the "Cisco: Meraki Organizations Discovery [API]" Dynamic Application.
In the Credentials field, select the Cisco Meraki credential you created.

Click Save to align the Dynamic Application with the Cisco Meraki virtual device.

After aligning the "Cisco: Meraki Organizations Discovery [API]" Dynamic Application, your Cisco Meraki component devices will be discovered and classified.

The virtual device named "Cloud controller" must remain in SL1 in order to discover new organizations, as they are created in the Meraki account aligned to the credential on this device. This virtual device can be deleted, but no new Meraki organizations will be discovered.

The Poll Frequency of the "Cisco: Meraki Organizations Discovery [API]" Dynamic Application should be set to 5 minutes.

Bulk Unaligning a Dynamic Application from Devices

You can unalign a Dynamic Application from devices manually, or bulk unalign the Dynamic Application from multiple devices.

Upgrading from a prior version of the Cisco: Meraki API PowerPack to version 112 will align the "Cisco: Meraki Uplink Performance [API]" Dynamic Application to both Meraki networks and network devices. To avoid this, ScienceLogic recommends unaligning the "Cisco: Meraki Uplink Performance [API]" Dynamic Application from Meraki networks before upgrading to version 112.

Upgrading to version 112 will cause you to lose historical data for the "Cisco: Meraki Uplink Performance [API]" Dynamic Application. Additionally, Dynamic Applications aligned to "network" devices will stop collecting.

To bulk unalign a Dynamic Application from multiple devices:

Go to the Dynamic Applications Manager page (System > Manage > Applications).
Type "Cisco: Meraki uplink Performance [API]" in the Dynamic Application Name column.
Click the wrench icon () and then select the Subscribers tab. The Application Subscribers page appears.
Select the checkbox for each device you want to apply the action to. To select all checkboxes for all devices, select the checkbox icon () at the top of the page.
In the Select Action drop-down list, select Unalign Device and Remove Collection Data. This option unaligns the selected device from the Dynamic Application and deletes all historical data collected by the Dynamic Application from the device. The device is no longer considered a subscriber to the Dynamic Application. If you perform this option and later want to subscribe to this Dynamic Application again, you must re-align the device with the Dynamic Application.
Click the Go button to apply the action to all selected devices.

Configuring Dynamic Applications to Hide Empty Rows

If you have a device that is no longer being monitored and a configuration Dynamic Application is returning empty rows in the Configs tab of that device, you can use the Hide row setting in the Dynamic Applications to hide those empty rows.

To do this:

Go to the PowerPack Manager page (System > Manage > PowerPacks).
Located the Cisco: Meraki [API] PowerPack and click its wrench icon ().
In the pane on the left, select Dynamic Applications.
For each Dynamic Application with "Configuration" in it's Type, click its wrench icon ().
In the Dynamic Applications Properties Editor, click the Null Row Option dropdown and select Hide row.
Click Save.

Viewing Cisco Meraki Component Devices

In addition to the Devices page, you can view your Cisco Meraki devices in the following places in the user interface:

The Device Investigator Map page (click Map in the Device Investigator page) displays a map of a particular device and all of the devices with which it has parent-child relationships. Double-clicking any of the listed devices reloads the page to make the selected device the primary device.

The Device Components page (Devices > Device Components) displays a list of all root devices and component devices discovered by SL1. The Device Components page displays all root devices and component devices in an indented view, so you can easily view the hierarchy and relationships between child devices, parent devices, and root devices. To view the component devices associated with a Cisco Meraki device, find the device and click its plus icon (+).

The Component Map page (Classic Maps > Device Maps > Components) allows you to view devices by root node and view the relationships between root nodes, parent components, and child components in a map. This makes it easy to visualize and manage root nodes and their components. SL1 automatically updates the Component Map as new component devices are discovered. The platform also updates each map with the latest status and event information. To view the map for a Cisco Meraki device, go to the Component Map page and select the map from the list in the left NavBar. To learn more about the Component Map page, see the section on Maps.

Creating Events from Cisco Meraki Emails

The Cisco: Meraki [API] PowerPack includes Event Policies that can generate events in SL1 based on emails that Cisco Meraki sends to SL1. On SL1 version 11.2 and greater, Webhooks can be configured to handle these same events.

For SL1 to process events from inbound emails, you must configure your Meraki devices to send email to SL1 using certain formatting rules.

If configured properly, when SL1 domain receives an email with body text that matches a Meraki network component device name and a subject that matches the regular expression (RegEx) pattern of one of the PowerPack's Event Policies, SL1 will generate an event aligned to that network component device.

Events from email are always aligned to network devices, even when the email includes references to one or more sub-component devices below the network device.

The email Event Policies included in the Cisco: Meraki [API] PowerPack each have an expiry delay setting that specifies the amount of time after which an active event is automatically cleared from SL1 if the event has not reoccurred. However, SL1 clearing an event for reaching its expiry delay setting does not mean that the initial condition that caused the event has been resolved.

Formatting Inbound Emails

Inbound emails must meet the following requirements to be processed as events by SL1:

The email must be sent to the following address:

notify@SL1-domain-name

Where "SL1-domain-name" is one of the fully qualified domain names of the Database Server or All-In-One Appliance that is entered in the Authorized Email Domains field in the Email Settings (System > Settings > Email) page.

The "from" address used by the external device must be "alerts-noreply@meraki.com" for non-maintenance events, "support-noreply@meraki.com" for maintenance events, or otherwise match an address defined in the Originator Address field in an email redirection policy on the Emailer Redirection page Events > Inbound Email, or Registry > Events > Inbound Email in the SL1 classic user interface).
The email subject line must begin with "Alert for" or "Scheduled maintenance for" and match the regular expression (RegEx) pattern of one of the Event Policies included in the Cisco: Meraki [API] PowerPack.

The email body must include the name of a network device monitored by the SL1 system.

The following RegEx patterns are used:

For scheduled maintenance emails:

(Scheduled maintenance for)\s((network\s|\d\snetworks\sin\sorganization\s)"([a-zA-Z0-9_\-\.]+).*")

For all other emails:

(Alert for)\s*([a-zA-Z0-9_\-\.]+)\s*

There must be a space between the RegEx pattern and the IP address, hostname, or device ID.

The Event Policies included in the Cisco: Meraki [API] PowerPack do not include RegEx patterns "out of the box". Users can add or modify Event Policy RegEx patterns to best suit their needs.

Emails that do not match the RegEx pattern of any Meraki Event Policy will generate a message in the system log. Emails that do not match the name of any component device in SL1 will not generate any events or messages.

You can specify how an Event from Email policy will match a RegEx to a device name in the Behavior Settings page (System > Settings > Behavior). For more information, see the Events from Email section.

Enabling Inbound Email Alerts

After you have ensured that inbound Meraki emails are formatted correctly, you must enable SL1 to generate events from the inbound Meraki emails.

To do so:

Go to the Emailer Redirection page (Events > Inbound Email, or Registry > Events > Inbound Email in the SL1 classic user interface), and then click the Create button. The Add Policy modal page appears.

Complete the following fields:

Originator Address. Type "alerts-noreply@meraki.com".

Alignment Type. Select If device not found, discard unmatched email.
Regex Pattern. Type "Alert for" or "Scheduled maintenance for network".
Regex Pattern Type. Select Advanced.
Regex Type. Select Subject.

Click Save.

For more information about generating events from inbound emails, see the Events from Email section.

Manually Executing the Cisco: Meraki Reboot Device run book action policy

The "Cisco: Meraki Reboot Device" is a manual only run book action policy that allows you to reboot a Meraki device. This action policy is disabled by default.

The "Cisco: Meraki Reboot Device" run book action policy will allow SL1 to reboot devices. This action policy is experimental and should be turned on only by a user with extensive knowledge of the effects that these actions will have on your network and devices. ScienceLogic recommends caution when enabling this action policy in a production environment.

In order to execute this experimental action policy, you need to meet the following prerequisites:

Enable the "Cisco: Meraki Reboot Automation [Manual Execution]" run book automation policy
Enable the "Cisco: Meraki Reboot Device" run book action policy
User credentials with the permissions to perform an http POST request

Enabling the Cisco: Meraki Reboot Automation run book automation policy

To enable the "Cisco: Meraki Reboot Automation [Manual Execution]" automation policy:

Go to the Automation Policy Manager page (Registry > Run Book > Automation).
Type "Cisco: Meraki Reboot Automation [Manual Execution]" in the Automation Policy Name column.
Click the wrench icon (). The Automation Policy Editor window appears.
In the Active State field, select Enabled, and then click Save.

Enabling the Cisco: Meraki Reboot Device run book action policy

Once the automation policy is enabled, you also need to enable the "Cisco: Meraki Reboot Device" action policy:

Go to the Action Policy Manager page (Registry > Run Book > Actions).
Type "Cisco: Meraki Reboot Device" in the Action Policy Name column.
Click the wrench icon (). The Action Editor window appears.
In the Active State field, select Enabled, and then click Save.

Modifying the Cisco: Meraki Reboot Device action policy

Once the action policy is enabled, you can update the Snippet Code of the "Cisco: Meraki Reboot Device" action policy to manually reboot devices.

To modify the action policy:

Go to the Action Policy Manager page (Registry > Run Book > Actions).
Type "Cisco: Meraki Reboot Device" in the Action Policy Name column.
Click the wrench icon (). The Action Editor window appears.
In the Snippet Code field, go to the "Update Values Here to Run Manually" section.
Enter the following details:
- serial_number: This is the serial number of the switch that needs to be rebooted.
- api_key: This is the API key for the PowerPack user to access the switch and reboot it.
Click Save.

Executing the Cisco: Meraki Reboot Device action policy

Once the "Cisco: Meraki Reboot Device" action policy has been modified correctly, you need to execute the action:

Go to the Events page.
Choose any event in the list and click on the message under the Message column. This will open the event.
Select the Cisco: Meraki Reboot Automation [Manual Execution] policy from the Tools drop-down menu. The View Logs link will appear.
Click View Logs to verify that the action policy was executed correctly. In the window that appears, all action policies that have been executed are listed for review.

Using Custom Device Classes with Cisco Meraki API

If you have Cisco Meraki devices whose device classes do not match those contained in the Cisco Meraki API PowerPack, you can create and add custom device classes to the pack in order to discover them in SL1.

Creating a Custom Component Device Class

The Cisco Meraki API PowerPack includes device classes for many Cisco Meraki devices, but you can create custom device classes for devices that do not meet the criteria of the device classes in the PowerPack

To create a custom Component Device Class:

Go to the Device Class editor page (System > Customize > Device Classes).
Click [Reset] to clear the fields in the Device Class Editor pane.
Configure the device class as follows:

Device Type. Select "Component".
Device Class. Enter the name of the Device Class.
Class Identifier 1. Enter the first two characters of the model name in lower case letters here. For example, if the model name is "zx-d2", enter "zx".
Class Identifier 2. Enter the rest of the characters of the model name in lower case letters here. Do not begin this field with a "-" character. For example, if the model name is "zx-d2", enter "d2"
Device Category. Select the appropriate category from the drop-down list. This field specifies a logical categorization of devices by primary function, which allows SL1 to group related devices in reports and views.
Root Device. Select this checkbox if you will have additional tiers under this component device.
Weight. Select a value from the drop-down menu. A lower number should be assigned to a device class with a specific model( For ex , c9200-MXPOX) , A higher number should go to fallback or catch-it-all device classes.
Description. Enter a description for the device.
Device Icon. Select an icon that you created or select a generic icon.

Click Save to save your changes to the device class.

Adding Custom Device Classes to the PowerPack

ScienceLogic does not recommend creating and adding your own device classes on your own. Failure to send custom device classes to your client success manager may affect billing.

If you have created custom device classes for your Cisco Meraki devices, you can add them to the PowerPack.

For more information on how to create device classes, see the Creating Device Classes section.

To add device classes to the PowerPack:

Go to the PowerPack Manager page (System > Manage > PowerPacks).
Locate the Cisco: Meraki [API] PowerPack and click its wrench icon ().
From the PowerPack Properties page, click Device Classes in the Navbar on the left side of the page.
To add a device class, go to the Available Device Classes pane at the bottom of the page. Find the device class you want to include and click its lightning bolt icon (). The content will be moved to the top pane and included in the PowerPack.

NOTE: If a device is no longer collecting, check to see if the device tags have been changed and no longer match the tags in the credential for selective discovery.