Meraki Deployment Repeatability

Getting noticed

Meraki Deployment Repeatability

Hi there,

I've recently been testing device enrollment and deployment process on Meraki MDM.

Some things I've noticed that affects the repeatability of deployments or breaks in the process and flow of deployments:
1. When the MacBook's screen is locked custom apps do not deploy and take forever to retry deployment, same goes for profiles.

2. 2/5 of the profile settings are installed most of the time, this may be because of the m_agent prerequisite for them (this is anecdotal)

3. Systems Manager agent along with other profiles all seem to have enormous install periods/delays. Seems like when an install is queued nothing else can happen in tandem between the agent the Meraki management serve everything else will just be queued.
4. If "X" install fails or automated task by tag, the retry attempt is much too long after failure.

Considering internet speed and that the MacBook is freshly install I think the above bottleneck is related to Meraki comms with the MacBook. 

My question is, are these known issues and are there any workarounds to make deployments more reliable?

3 Replies 3
Getting noticed

The strange thing about the above issues is that I have tested deployments exactly the same and had rare cases where quite literally everything from the profiles to the applications deployed perfectly.
The MacBook loads all 5 profiles, installs m_agent correctly and then begins deployments of app store apps and custom apps.
It seems very much RNG because of the deployment order and priority. I feel there should be some sort of deployment order like profiles > m_agent > app installs queued in multithreaded workload 

Getting noticed

2022-07-03 05_27_59-Devices - Meraki Dashboard.png

Good example can be seen above, where tasks are actioned in a random order. Apps are being installed without all profiles already being installed. In total 1hr30m passed for all the profiles to install and 1 hour for m_agent to install because the apps are queued before then already even though technically they should be able to be installed without m_agent.

My current theory I will be testing is that if we separate the entire process into two stages with tags. i.e enrolment which will have only the default profile and the systems manager profile to install the agent thereafter we manually add a deployment profile that should have all the tasks that require m_agent in order for them to work and m_agent should already be installed because of the first enrolment portion.

Getting noticed

I can confirm the above theory. I've tested it a few times now. Process is much more repeatable and consistent but requires much more input from admin side.

1. I've created 3 tags, one for each stage of deployment each prior tag having prerequisite tasks for the subsequent tag.
2. First tag to be used - Phase 1 - Deploys Default profile with screen timeout settings (doesnt require magent), deploys Meraki settings for "x" and Meraki System Manager to install magent
3. Second tag to be used after magent is installed successfully - Phase 2 - Deploys PPPC profile which requires magent as well as FileVault profile which also requires magent
4. Third tag apps and custom apps deployment - Phase 3 - Apps that requires both magent and PPPC configs, now inherit settings since PPPC profile was loaded prior to installing the apps

I may be wrong but this to me looks like it requires something similar to what Jamf is documeting: 

1. Execution Order of Policies - To make sure prerequisites are installed before actioning next task

2. Execution Frequency for Policies - For the long wait times that require manual intervention sometimes

Get notified when there are additional replies to this discussion.
Welcome to the Meraki Community!
To start contributing, simply sign in with your Cisco account. If you don't yet have a Cisco account, you can sign up.