Best Practices for Service Providers

Standard Service: Organization per Service, Network per Customer

The standard service model is the most popular and common structure used by MSPs and is highly recommended by Meraki as it enables multiple operational benefits for the MSP. In the Standard Service model, the MSP portal is structured around services offered. This Standard Service is based on the notion of the MSP offering a uniform service to all customers, and in this model, an MSP will typically create separate organizations for each service offering. Generally, organizations could represent tiers of service such that Basic, Intermediate and Advanced services provided by an MSP would each warrant one organization.

When a customer wants to change their service model, they can move to the Meraki organization that is already set for the service they want to move to, which allows organizations to function as templates for service offerings. This eliminates the overhead required to create organization configurations from scratch to suit each customer.

Bespoke/Tailored Service: One Organization per Customer

Sometimes, customers require having an organization-per-customer model, as in cases when the end customer owns their own equipment or requires full management of their own network. In a Tailored Service model, usually, each end customer owns hardware equipment and the MSP generally provides IT services or consulting. The Tailored Service model is best used for customers that require custom environments, customers that manage their own equipment, or customers whose contracts require their own access. This model is only recommended if the customer’s network structure requires it, because it does not scale as well as the Standard Service model. This structure should be used if customers own equipment, as it allows the freedom for customers to be treated in a modular manner and can be separated from the MSP if necessary, and the customers can be granted full management access. This model is best suited for small MSPs, or large bespoke MSPs with locally-managed locations.

SD-WAN as a Service: One Organization per Customer

In a Standard Service model, MSPs have multiple customers in the same organization for ease of management. This structure should not be used if SD-WAN is the service that is delivered to the customers because the scope of an organization defines the connectivity domain for AutoVPN. Each SD-WAN customer will therefore need to be assigned to its dedicated organization. This model is typically optimized for mid-sized to large end-customers with multiple locations/branches.

 

• Ideal structure for an MSP portal also has:

  • One or more totally empty organization(s) for cloning purposes (no devices or licenses, ever)

  • One shutdown organization with a shutdown network, used to keep devices that are currently unused

  • Separate networks under each organization, generally organized by physical location

 

• Note that an ‘MSP Portal’ is tied to an account. Multiple accounts under the same MSP company do not necessarily have the same MSP portal. Another account could potentially see a different set of customers if their account has not been added to the same organization admin lists.

Firmware Upgrades

Firmware can either be centrally managed across thousands of networks vs. individually per organization, depending on your structure model.

 

Network-per-Customer

The Firmware Upgrades tool in the dashboard allows organization admins to quickly and easily manage firmware versions on a per-network and per-device type (MX vs MR) basis. Additionally, the Firmware Upgrades tool can be used to schedule, reschedule, and cancel bulk upgrades of networks, view firmware changelog notes, view firmware version numbers, and to rollback the firmware on a recently upgraded network.

 

Organization-per-Customer

There is no mechanism to manage firmware across multiple organizations. If using an organization-per-customer model, remember that each customer organization will have to be accessed individually for firmware management.

Search Function

Generally, you will find that there are more flexible and direct search criteria across a single organization. If your organizations are split per customer, you will not be able to easily search multiple customers across different organizations in the dashboard, and will likely need to rely on an API solution with an account that spans multiple organizations.

 

Network-per-Customer

This models allows for a scalable search function, including the ability to search by network name, network tags, hardware serial or MAC address.

 

Organization-per-Customer

In this model, the top level search can only be used for searching by organization name. Multi-organization API accounts will be necessary to search/query across multiple organizations.

Cloning Function

The cloning function allows users to make copies of networks when creating new networks. This is very useful for creating large numbers of identical or nearly identical networks.

 

Network-per-Customer

It is possible to clone a network with most network and device-level configurations.

 

Organization-per-Customer

It is only possible to clone a organization without device-level configurations.

Organization-level settings which are cloned:

• Organization administrators
• Organization administrators created through SAML
• Configuration templates
• Settings previously enabled by Meraki Support
• Dashboard branding policies
• Branding updates for in-life customers would be manually applied to each organization. Not possible to copy settings between organizations.
• Splash page themes

Configuration Templates

Updates to the standard customer template cannot be replicated across multiple organizations. Note that while configuration templates are an option for MSPs, it is generally strongly recommended to use the cloning function instead, as it scales much better for larger deployments and is more easily programmable via API.

Configuration templates can allow many Cisco Meraki devices to be deployed following a single base configuration. Sites as part of a template can have exceptions to the configuration, and devices that need to be treated differently can be bound to a template. Otherwise a template is created per customer.

 

Network-per-Customer

Templates could be shared across multiple customers.

When updating a service design (e.g. turn on new feature), you can clone a template and replicate for each customer.

 

Organization-per-Customer

Once an organization is created, any changes to the template must be individually applied for each customer - no ability to copy/replicate settings between organizations.

Claiming of Devices and Licenses

Generally, orders should be made on a per-organization basis. That is, one order per organization, at each time of purchase. Split purchases mean split order numbers, which makes claiming more complicated and prone to error.

 

Network-per-Customer

A bulk order can be claimed by a single license key or order number. Licensing will be shared across the networks as it is scoped on a per-organization basis.

 

Organization-per-Customer

A bulk order will need to be processed through a bespoke mechanism to provide individual license keys for each customer organization. Each key will be claimed to their respective organization.

Usage Reporting

There is minimal visibility of usage across multiple organizations.

 

Network-per-Customer

The Organization > Overview page will display a usage summary of all customers. You can also use Network Tags aross your organization to, for example, filter for customers with different tiers of service, such as 30Mb vs 1Gb customers.

 

Organization-per-Customer

There is no usage reporting in the MSP portal.

Administrator Management

Network-per-Customer

One single administrator portal for add/modify/remove of roles and access across different customers.

 

Organization-per-Customer

No ability to copy administrator settings between organizations. Unless an API is used, each customer organization must be accessed for maintaining customer and admin access privileges.

Re-purposing a Device

Network-per-Customer

Devices can be moved between networks without any extra license workflows

 

Organization-per-Customer

While devices can be moved between networks, Meraki Support must be contacted to move a license between organizations.

Changelog

The Meraki dashboard changelog is a running list of configuration changes that have been made in an organization. 

 

Network-per-Customer

Changelog will include changes to all customers' networks.

 

Organization-per-Customer

Changelog will be scoped by customer, and changes for each customer will need to be viewed on a per-organization basis.

Security Center

The Security Center is scoped by organization and shows a visual summary of security events, analytics and notifications across an organization, including intrusion detection, intrusion prevention, and malware events.

 

Network-per-Customer

Centralized security view across all customers.

 

Organization-per-Customer

Each organization must be accessed to view security reporting.

Dashboard API and SNMP Access

A unique set of parameters must be maintained for each organization you wish to access if configuring or monitoring customers outside of the dashboard website.

Minimum Admin Accounts per Organization

The Meraki dashboard administrator accounts for each organization should include:

• At least 1 ‘primary’ organization Admin shared account for the MSP company, such as example@msp.com
• One backup organization Admin account for recovery purposes in case you get locked out of the Primary Admin account
• At least one account for the customer, even if the customer does not log in. If the customer does not log in or is not given these credentials, they should at least be given the credentials for the account when/if the MSP-Customer relationship has ended. The customer account should be a full organization Admin (read/write) if the customer owns their equipment. The account should be read-only or network-only if the customer leases their equipment from the MSP

 

2-Factor Authentication should always be used for MSPs for security purposes, and be sure to make a physical copy of your 1-time 2FA recovery codes.

Creating New Organizations/Adding New Customers and Branding

Keep at least one completely empty organization to use for cloning if new organizations need to be created. This cloning organization should be used as a template to create new organizations that will include the source organization’s:

 

Branding

Branding must be applied organization-by-organization, so the fastest way to apply branding to all your customer organizations is to clone them from a source organization with your MSP’s branding.

Note that branding is not retroactively applied to all organizations under an MSP portal, so it must be applied to each individual organization if organization cloning is not used upon creation.

 

Admins

Cloned organizations will keep the source organization’s admins list, so you can easily copy MSP admins to each organization.

 

SAML Access

In the same way that admins carry over when an organization is cloned, SAML access is also carried over. Keep this in mind, in case of privacy concerns if you do not want certain SAML admins from the source organization to be able to log into customer organizations after cloning

This organization must never have licenses or devices added to it, or it will eventually go out of licensing compliance. It should always be kept empty.

Adding an Organization to your MSP Portal

Adding an organization to your MSP Portal only requires adding your account email to the admins list for that organization. Keep in mind that this means that adding an individual account under an MSP domain will not add the same organization to that domain’s generic account. Email addresses are the only differentiator.

SAML Admin Accounts

Using SAML admin accounts will make it much easier to distribute permissions to your end users and network admins. Organization changelogs will record which SAML account was used to make changes, which is essential for most MSPs to keep track of network changes made by their network admins or end-customers.

Orders

It is best to make separate orders based on separate organizations. Even though devices can be easily split by order, licensing is generally bundled in a single key for each order, so if a single order is made for multiple organizations, the licensing will not be separate as-delivered and may require a call to Meraki to split/move.

Unused Devices and Inventory

Devices that are not being used by anyone should be kept in a totally separate shutdown organization, in a network. This will prevent the devices from being claimed by anyone else, as devices are only protected from being claimed if they are in a network. Devices that are in inventory, but not in a network can still be claimed in another organization. This organization should not have any licensing, and all the devices should be kept in a network that might be labeled something like “Unused Inventory.” The licensing for this organization will expire and go out of compliance, but the licensing warnings can be ignored, as the inventory can still be managed. This organization and network should only be used for unused inventory.

Support Cases

Cases opened with Meraki Support should always follow the following two rules:

• MSPs calling/emailing support should always use their MSP customer number

• Customers under an MSP calling/emailing support should always use their own customer number, not the MSP’s customer number

Cases are visible on a per-Meraki-Customer-Number basis. This means that if end-customers share a customer number, they will be able to see each others’ cases. This can be a privacy concern, so you should ensure that separate customers that should not be able to see each others’ cases do not have the same customer number.

Do not share your MSP customer number with your end customers. Always keep a record of your end customers’ Meraki Customer Numbers, and be ready to provide it if requested by support.

Adding/Acquiring new End Customers

When you acquire and add an end customer that is an existing Meraki customer under your MSP Portal, it is best to contact your sales representative and let them know. They can update their records to ensure your cases and accounts reflect this change, which ensures the correct contacts and accounts are listed for each group.

API Key

Note that your API key is based on your account, as is your MSP portal. Each organization you create using the same account will share the same API key. Keep this in mind when considering the visibility and permissions of your API key.