I have developed and refined a tagging system for my company's Systems Manager-enrolled mobile fleet, consisting of ~200 iPhones and iPads. I decided to summarize my system here, because not only are tags my favorite feature of Meraki SM, IMHO a good tagging system is far superior to a group-only system, as many MDMs unfortunately rely upon.   My philosophy in creating tags was this: Make it simple, keep it simple, then make it even more simple. For example, what do you think this tag does?   app-dropbox   As you probably guessed, that tag installs the Dropbox app. But about these tags?   team-security wifi-corpnet restriction-0-none   Even if you don't yet know the nuances, you can probably guess what their purposes are: team-security deploys settings and provisions to Security team devices; wifi-corpnet gets a device on the Corpnet wifi; and, restriction-0-none allows a device to be used without any big restrictions.   Below I will delve deeper into how my tagging system works, as well as use cases and best practices.   Creating the Tags   In creating the tags, my high level thinking was that a tag can give a thing to a device, a tag can restrict a thing from a device, but a tag cannot do both. When I started at my position, each department tag was used to assign apps, as well as restrict settings and apps. This caused an enormous headache for troubleshooting, because removing the department tag would undo virtually all changes to the device.   In addition, I wanted my tags to be readable by others. If another tech doesn't often use Meraki SM, they may not have their bearings on all the ins and outs of the portal (especially when the UI changes). If the tech is trying to, say, give a single user the Dropbox app, the tech doesn't have to wonder 'Wait, do I scroll to D for Dropbox? I forgot.' The process is consistent across all devices: begin by typing the tag prefix (in this case, app), then the tag field will show all tags that begin with 'app'. Alphabetically, app-dropbox is right there between app-chrome and app-duo. The Tags   Below is each tag type (a.k.a. tag prefix), as well as use cases, and my philosophy behind tag design. All tags are classified as device tags in Meraki SM.   team app no-app wifi single-app alert restriction null   Summaries & Use Cases   team   Ex: team-landscape, team-hr, team-golf   Short version: It pushes the same apps to all devices assigned to a team.   Longer version: For devices assigned to teams, departments, or fleets. My company uses wall-mounted iPads for timeclocks, so I use the team tag on those as well. Originally, I was going to have a separate tag for fleets of unassigned iPads, such as the timeclock kiosks, but the line became blurred between devices assigned to staff teams and unstaffed teams, so I simplified by just using the team tag.   Use case: The Building Maintenance manager wants the field staff iPads to include OneDrive, Outlook, and Verizon Push-to-Talk.   I confirm each app has the scope 'with any of the following tags', then I add team-building-maintenance. Going forward, I add the tag team-building-maintenance to all devices assigned in the department.   app   Ex: app-outlook, app-chrome, app-teams   Short version: For assigning a single app (i.e. a la carte).   Longer version: For situations when a user needs an app that is not otherwise included in a team tag.   Use case: A call center employee wants to use the Calculator app on their iPad, but the iPad doesn't include a native Calculator app. After adding the app through ABM, I confirm the Meraki SM app page has the scope 'with any of the following tags', then I add app-calculator tag. Going forward, I add the tag app-calculator tag to all devices that require that app.   Note: Every single app has an app tag. I don't have to know which employees need an app for me to assign the app an app tag.   no-app   Ex: no-app-meraki-sm   Short version: For when I need to keep an app from being installed, especially for troubleshooting purposes.   Longer version: In 99.9% of cases, I don't believe in having a deployment scope of 'All Devices'. If I'm troubleshooting a possible conflict, then I may need to see a device without a particular app. Normally this isn't an issue with the team tags and app tags. For example, if I suspect app-onedrive is conflicting with app-dropbox, then I can remove those tags, then procees with troubleshooting. But what about an app that everyone must have at all times? That's what this tag allows.   Use case: In virtually every situation, a mobile device in production must include the Meraki SM mobile app (installed via VPP). What's more, this app often needs to be the first app installed on a new device. I confirm the Meraki SM mobile app has the scope 'without any of the following tags', then assign the no-app-meraki-sm tag. Going forward, I need only apply the no-app-meraki-sm tag when troubleshooting a possible conflict with the Meraki SM mobile app. (This has never happened with the Meraki SM mobile app, but that's beside the point.)   wifi   Ex: wifi-gust, wifi-corpnet   Short version: Assigns an SSID to a mobile device.   Longer version: Basically what the short version says. This tag saves so much time when getting a mobile device connected to wifi.   Use case #1: A new iPad is on an LTE connection and needs to connect to the Guest SSID, so I apply the wifi-guest tag. The iPad now has the Guest SSID and password saved, which allows the iPad to auto-join the wifi network.   Use case #2: I have just added several wifi-only iPads to ABM. The iPads are completing the initial setup menus, and now I must connect them to the Corpnet SSID. (For our purposes, let's assume I already used Apple Configurator to add them to ABM, then synced the devices to Meraki SM via ADE/DEP.) The iPads are still plugged into to the Mac running Apple Configurator, and the Mac is set to share its internet connect with connected USB devices, such as the iPads. After completing the setup processes, including the auto-installation of the Meraki SM mobile app, the Meraki Dashboard can now push apps and profiles to the iPads. Since the iPads have a temporary internet connection via the Mac, the app-corpnet allows them to receive the SSID configuration.   Note: Having multiple wifi tags usually do not cause conflicts, but like in many other situations, a device may not know which saved SSID the user wants to connect to (which isn't really an issue that is unique to Meraki SM).   restriction   Ex: restriction-0-none, restriction-5-high   Short version: Restricts the user from having access to certain apps or settings.   Longer version: This is the most experimental tag I use, so please bear with me. Each restriction tag uses some combination of options from the Meraki Dashboard SM Settings section (Systems Manager → Manage → Settings → <profile name> → Restrictions).   Level 0 has virtually no restrictions. Level 1 has a couple more restrictions, level 2 has a couple more, and so on, until we reach level 5, which is the most restrictive. When I first began my position, the restrction settings were integrated with the team tags, and as you can imagine, troubleshooting was a nightmare.   restriction-0-none: Most things are allowed, except removing the MDM profile. In addition, the tag enforces the options 'Allow modification of device name' (disabled) and 'Keep device name up-to-date with Dashboard' (enabled).   restriction-1-low: Level 0 but the user cannot install apps through the Apple App Store.   restriction-2-low-med: Level 1 but the user can only use managed apps and select native apps (most native apps are basically out, except for the camera).   restriction-3-med: Level 2 but the user cannot use the camera.   restriction-4-med-high: Level 3 but the only allowed apps are Phone and Messages.   restriction-5-high: The only allowed app is Phone.   Use case #1: I'm unboxing a new set of iPhones and iPads. By default I give them all the restriction-0-none tag, then swap it out for another restriction tag as needed.   Use case #2: In the winter, we get power outages pretty bad. Despite having a backup generator at the front gate, it doesn't always work correctly. In case they lose all desk phones, for urgent calls, residents can call this iPhone. To avoid any accidental taps and/or setting changes, I restricted every single element of the iPhone, except for the Messages and Phone apps.   Note: I have also linked the restriction-0-none profile to the recently-added tag. This helps if a device gets prematurely deployed before it is prepped by IT. (It happens when an over-eager manager picks up their new iPhone from the loading dock before I can get there.)   single-app   Ex: single-app-zoom-rooms-controller, single-app-push-to-talk   Short version: This puts the device in Single App mode (i.e. Kiosk mode).   Longer version: Basically what the short version says. This tag keeps the device (usually an iPad) in Single App mode, even when the device reboots or turns on after loses power.   Use case: A conference room is configured for large-scale hybrid meetings, which includes running several Zoom appliances. Outside the conference room is a wall-mounted iPad running the Zoom Rooms Controller app, which shows the upcoming meetings with associated details.   Note: When troubleshooting a mobile device in Single App mode, the very first thing I do is remove the single-app tag. This allows for easier troubleshooting, especially if the network connection is lost in the process.   alert   Ex: alert-offline   Short version: This alerts me when critical managed devices go offline or comes back online.   Longer version: The tag notifies me when the iPad loses connectivity to the Meraki Dashboard. This cuts down on tickets, as I often know when a critical device has gone offline before users do.   Use case: Near the swimming pools is the Lifeguards' office that has a timeclock iPad. Too far from our WAPs, the iPad relies on LTE for connectivity. This means that the usually WAP offline alerts don't give me a heads up that this iPad will lose connectivity. Instead, I use the alert-offline tag. As soon as the Meraki Dashboard loses connectivity with the iPad, I am notified, then I can go on site to investigate.   null   Ex: null   Short version: This is the black hole where old apps come to die. Also, it can be used for incomplete profiles that do not have an otherwise defined scope.   Longer version: This is a pretty niche tag. It is totally optional, seldom used, and never assigned to a device, so if this tag doesn't make a lot of sense, don't worry - it's really not you, it's me.   Sometimes I am working on a new profile in the Settings page, but I have not completed the work. Although I can save my progress, then return later, Meraki SM often requires me to have a defined scope before I can do so. Although I suspect other techs would set the scope to 'No devices (disabled)', I prefer to keep the scope set to 'with any of the following tags', then assign the null tag. The tag is also handy when I want to semi-retire certain apps or settings (see below for details).   Use case: The Apple App Store allows for Microsoft Office to be installed in two ways. The first is with the Microsoft Office app, and the second is with each app (e.g. Word, Excel) installed separately. Until recently, I used the first option by deploying the Microsoft Office suite to mobile devices using the app-office tag. Over time, I discovered that I preferred installing Office as a set of individual apps. On the one hand, I didn't want to completely remove the Microsoft Office suite entry from the Meraki SM app page, but on the other hand, I didn't want to give my team a way to accidentally install the original Microsoft Office suite when assigning app tags to a device. Instead, I removed all team tags and app tags from the app entry, then assigned the null tag. This allowed me to keep the app around for possible future use, as well as to technically have the same scope type as before.   Note: To reiterate, I never assign the null tag to devices.     What do you think? Any suggestions or feedback?   Thank you for reading! ... View more

I submitted a feature request and have already seen people post about this, but I wanted to create more visibility on the issue.   Currently, when someone applies a port profile to a port, the network's Switch Ports page does not reflect the new information (i.e. VLAN number). Instead, the network's Switch Ports page displays the port's individual settings, specifically showing the individually assigned VLAN. At best, this is misleading information; at worst, it is patently false information that causes confusion when troubleshooting future endpoint connectivity issues.   When applying a port profile, the Meraki Dashboard should reflect the new configuration in all salient areas. It’s fine to have a symbol or other indicator that shows the current application of a port profile; this is valuable information that needs to be reflected in the portal.   Please make fixing this a priority.   Thank you ... View more