What is the difference between firmware and dashboard

Firmware upgrades can be rolled back to their previous version up to 14 days after an upgrade takes place. Follow the steps below to roll back a firmware upgrade. Change log notes are maintained on a per-firmware version basis and include information about new features, bug fixes, and known issues that are associated with a particular firmware version.

Follow the steps below to view the firmware change log notes. Note: The firmware change log can also be viewed from the All networks tab; click on the firmware version links listed in the "Current firmware version" column.

Firmware upgrades can be scheduled on a per-device type basis for each dashboard network. To elect to run beta firmware, select Try beta firmware and select Yes.

Firmware upgrade barriers is a built-in feature to prevent certain upgrade paths on devices running older firmware versions trying to upgrade to a build that would otherwise cause compatibility issues. Having devices use intermediary builds defined by Meraki will ensure a safe transition when upgrading your devices.

Here is an example of when firmware upgrade barriers come into effect. You might find yourself in a situation where you are unable to upgrade a device for an extended period of time due to uptime or business requirements. There is a switch in the network that is running MS 9. Attempting to upgrade from 9. In order to complete the upgrade from the current version to the target version, two manual upgrades will be required. The first from your current to the intermediary version, and another from the intermediary to your target version.

Cisco Meraki is committed to delivering powerful yet easy-to-manage firmware updates for all Meraki products via the firmware upgrades tool in the dashboard. In order to further simplify and streamline the firmware update process, we are introducing Firmware Status for Meraki firmware. Warning Yellow status means that a newer stable major firmware or newer minor beta firmware is available that may contain security fixes, new features, and performance improvements.

We recommend that you upgrade to the latest stable or beta firmware version. We highly recommend that you upgrade to the latest stable and latest beta firmware release. The number of Networks with firmware matching "Warning" and "Critical" status will appear on the overview tab of the firmware upgrades page. A: This date is an end-of-support date for that particular firmware version.

Once the end-of-support date has passed, the firmware will go into "Critical" status. We highly recommend updating the firmware before it reaches "Critical" status. A: You might experience performance degradation, stability issues, and be exposed to the security vulnerabilities addressed in the latest stable or latest beta firmware. Overview Firmware upgrades allow network administrators to utilize the latest features and security enhancements on their Meraki devices.

Certifying and signing the update package. Fundamentals Reliability Testing Prerequisites. View test results and log files. Create a submission package. System and device firmware updates via a firmware driver package.

Windows Hardware Certification blog. Windows UEFI firmware update platform. Feedback will be sent to Microsoft: By pressing the submit button, your feedback will be used to improve Microsoft products and services.

Privacy policy. Skip to main content. This browser is no longer supported. Download Microsoft Edge More info. Contents Exit focus mode. Note While submitting the firmware update driver package, make sure to select Windows 8 or later as the applicable OS.

Is this page helpful? It is highly recommended that customers plan for maintenance windows in accordance with the scale and complexity of the deployment where the upgrades are being performed.

For example, more time should be allotted for upgrading a VPN concentrator supporting spoke sites and leveraging a dynamic routing connection between the concentrator and datacenter, than for a VPN concentrator with only 10 spoke sites. If beta firmware is being tested on a VPN concentrator, it is best to plan for time in the maintenance window to allow for the upgrade to complete and validate the operational state after the upgrade has been completed.

It is also recommended to allocate an additional window of time for rolling back to the previous build, in case you run into unmanageable issues. When concentrators are configured in HA, they will follow the steps mentioned above. VPN tunnels will begin establishing to the spare appliance while the primary is upgrading. However, the primary appliances typically complete the upgrades fast enough that spoke sites have minimal interactions with the spare concentrator.

In general, even with equipment in HA, it is best to always be prepared for some amount of downtime and impact for spoke sites. In almost all cases these are simply a matter of seconds as spoke sites fail between concentrator pairs, but the impact can become more noticeable if there are WAN connectivity problems between the data center and spoke locations. One of the key advantages of being a cloud managed device company is that Meraki is able to leverage full internal automated testing, while also being able to utilize our cloud to monitor key device performance metrics across our entire installed user base.

To ensure robust and reliable firmware development, Meraki follows a consistent software release process to validate and deploy consistent and reliable firmware. Meraki's firmware development process has four stages: alpha, beta, stable release candidate RC , and stable.

Every firmware version is created and released with the goal of graduating to stable. If a particular build fails to pass our key metrics at any stage of the development process, a new build is created and the process begins anew. The following sections go over each of the stages in more detail. With all new Meraki firmware including both major and minor releases, we start out every new build by running it through our full alpha testing process.

Each product line has automated and manual testing specific to the product, that are designed to ensure Meraki minimizes the chance of regressions as we continue to create and expand on our software feature set. As part of our core philosophy, after a new build has successfully passed the testing phase, we deploy the new firmware release on our own personal and engineering networks.

We believe it is important that we deploy and run our own firmware before any of our customers deploy our firmware. During this process we will run this firmware in our real world deployments for one or more weeks before we consider releasing the build as a new beta version.

If a build successfully passes all of our release criteria, we will start to make the new build available to our customer base. If any issues are discovered that need to be resolved, we will start the process over once the issue has been addressed before moving the release forward.

In some more rare cases, we will move forward with a build with a known regression, due to complexity or timing of the fix, and in this scenario we will note the regression in the release notes for that version. Firmware is made available for production use at first under "Beta. Beta firmware has already gone through internal regression, stability, and performance testing to limit risks when applied to production networks.

Customers that opt into beta firmware via the Try beta firmware configuration option on dashboard will be automatically notified and scheduled to upgrade to these versions as they are released. These upgrades can be canceled, modified, and reverted using the firmware upgrades tool in the dashboard. Customers can also manually upgrade their networks at any time to beta firmware by using the firmware upgrade tool.

The latest beta firmware is fully supported by our Support and Engineering teams. Older betas are supported with best effort; an upgrade to the latest beta will ensure full support. As a new firmware version matures from beta, it has the opportunity to graduate into a stable release candidate.

After the formal review, a beta may be reclassified as a "Stable Release Candidate. Once a new stable release candidate is available, Engineering will begin scheduling a limited set of customers for upgrade. These upgrades can be canceled, modified, or reverted using the firmware upgrade tool as well. The latest stable release candidate firmware is fully supported by our Support and Engineering teams. Older stable release candidates are supported with best effort; an upgrade to the latest beta, stable release candidate, or stable will ensure full support.

A stable release candidate matures into a stable version over time as it is slowly rolled out to devices globally. For point releases, the determination will be made on a case-by-case basis. Again, the same KPIs are analyzed as used in the stable release candidate review. Upon completion of these processes the firmware can be promoted to "Stable. The latest stable version is also the version that is used for all newly created dashboard networks for a particular device.

To make all of the best practices above simple to manage, you can use the Meraki firmware upgrade tool. We have built this tool to allow organizations to easily manage all Meraki firmware across the product portfolio in a single dashboard.

As with all of our cloud features, we are continuing to build more functionality in the firmware upgrade tool to increase usability and simplify firmware management. On the Overview tab, customers find a variety of information, such as a list of recent upgrades in the dashboard organization, pending upgrades that have been automatically or manually scheduled, the ability to cancel or reschedule these upgrades as well as a list of firmware versions that are available in beta, stable release candidate, or stable form for a given Meraki product.

Included with the available beta, stable release candidate, and stable firmware versions available in dashboard is a list of changelog notes. These notes allow customers to be fully aware of any new features, bug fixes, and existing known issues found between their existing firmware in use and the version planned for upgrade.

Customers leveraging configuration templates may also enjoy the benefits of the firmware upgrade tool. If there is a specific version of firmware that is needed for reasons of compatibility, then it can be requested from Meraki Support. Please note that any problems that are encountered while running versions of firmware that are not either stable or release candidate will not be supported and Meraki Support may need to recommend upgrading to the latest version of firmware in order to continue troubleshooting.

In general, it is discouraged to upgrade firmware on specific devices rather than upgrading the entire network. However, during the course of troubleshooting, Meraki Support may find it necessary to try a particular version of firmware on a specific device.

Addition or removal of locked firmware cannot be scheduled, please call Meraki Support to have this completed. In addition to this best practices document please reference our other documentation to help you best deploy your Meraki products:. Introduction to Meraki Firmware Cisco Meraki has always prided itself on delivering powerful networking and IT solutions in a simple, easy to manage fashion.

Simplified Firmware Updates In the early days of Meraki, the only firmware configuration required was to specify a convenient maintenance window for your network, such as late at night on a weekend, for example.

Meraki Firmware Conventions Meraki firmware nomenclature is the same across products and consists of a major and minor number as part of the name. Minor Versions A new minor firmware version is released to fix any bugs or security vulnerabilities encountered during the lifecycle of a major firmware release.

General Firmware Best Practices Meraki was built on the promise of making management of devices intuitive, and this extends to Meraki firmware management. Templates With configuration templates it is possible to push a standard configuration against multiple sites at the same time.

Best Practice for Multi-Branch Deployments Now that we understand how the Meraki firmware system works, let's talk about how you can leverage this to confidently manage firmware on your network. Test Network s Beta It is recommended to have designated network s to test beta firmware when released. Why you Should Test Beta Firmware Although all Meraki beta firmware undergoes rigorous testing as described in the beta release process, we recommend testing the new beta code in your designated test networks.

Beta Feedback Mechanisms If bugs are encountered during beta firmware rollout, you should contact Meraki Support to ensure the issue is documented internally, using our defined process. Release Candidate Network s Validate Once beta firmware is tested, you can choose to wait until the major version reaches release candidate RC status or roll out beta firmware to the remaining networks if you are satisfied with the validated beta firmware.

Stable Release Network s Full Deployment Once a firmware is marked as stable, customers can roll out firmware to all the remaining networks either using the firmware upgrades tool or, optionally, using the automatic upgrade process to roll out firmware.

Best Practice for MR Firmware As our wireless portfolio grows, Meraki continues to focus on delivering the high performance and high availability network that modern deployments require. Best Practice for Large Scale Wireless Networks Traditionally, when running large scale campus wireless networks, upgrading wireless firmware has been considered risky.

This part of our deployment is an ideal choice for a few reasons: The area includes six Meraki access points, which ensures we have a reasonable number of access points to test on The area provides us with a diverse group of client devices, as people will bring many different smartphones and laptops to this area Almost all employees frequent this area of the building at some point during the day Because this is not a business-critical area, the impact of a potential wireless issue will be more manageable to the users Once you have validated and are comfortable with the current firmware in the test environment, you can confidently deploy the update to the rest of your network.

Best Practice for MS Firmware When you move farther up the networking stack to switching there are additional things you need to take into consideration. Two unique aspects of managing Meraki switch firmware is that we support both: Staged upgrades to allow you to upgrade in logical increments.