Hi @MRCUR,   The priority selected acts as a multiplier for the priority numeric value of the ticket (based primarily on time since last update). This means that tickets marked 'High' priority will receive a response before tickets marked 'low' priority, but all responses will still be within our email/dashboard SLA times; <4 hours for the initial response and  <24 hours for all subsequent responses.   This is why we always encourage our customers to call in whenever they are facing critical issues. Calling in will get you a response within a couple of minutes vs a couple hours with a 'high' priority Dashboard ticket.   - Rodrigo ... View more

  Hey @PhilipDAth,   I think you touch on some fantastic points and I'm going to take this chance to shamelessly highjack this thread to talk about the Meraki Support structure (in the context of the points raised) and hopefully add a little more   color   as to why we operate the way that we do.    There needs to be some kind of formal escalation process.   As I mentioned in my previous response, there is absolutely an escalation process defined on our end and if you ever receive any pushback, please ask to speak to a manager. We are here to ensure everything goes swimmingly and we will make any necessary adjustments to ensure things get back on track!      Can I make some more suggestions: * When you ring in, change the IVR is ask if this is a "Network down" emergency (like Cisco TAC).  Give priority to "network down" events.   Historically speaking, here at Meraki, we do everything in our power to avoid adding 'extra steps' to anything we do... including support! We want to make our service as simple and effective as the products we sell. To us, that mean that we want to prioritize every call as if it were a network down call. In fact, if you look at our numbers for FY18 you will find that the average hold time is just over 2 minutes! Support should be fast for everyone, not just people in critical situations! 😃   * An escalation request should trigger an automatic review by a manager.  That manager should probably ask the customer if they would like the ticket "re-keyed" for a different engineer to look at. To further expand on my original post, the minute you request a case be escalated, the first thing your Support Engineer will do is speak with a manager and make sure that (1) All relevant parties are brought in on the case and (2) that there are clear next steps defined and proper goals are set. As for the re-keying bit, although we might not get on the phone by default (avoiding more of those 'extra steps') if you want your case re-assigned or wish to speak with the manager taking point, all you have to do is ask and we are happy to oblige!    * Managers should have a pool of much more experience engineers to draw on ("consultants" if you like) to seek their feedback.  These people may or may not need to get involved in the actual case. So similarly to my point about how fast support should be available to everyone not just the people in critical states, the best and brightest minds of Meraki should   be available to everyone, not just people who asked for their case to be escalated. We don't have a team to take escalations because we have our best and brightest   front and center taking cases to make sure you don't have to escalate your case or ask for a next tier engineer to get your issue resolved.    That being said, note that our Engineers are never alone when working a case. In fact, one of the reasons we are able to have all our engineers support our entire product line is because of how effectively our department communicates. One of our mantras   at Meraki Support is that teamwork makes the dream work! If you ever get a chance to visit any of our offices, you will note that there is not a single cubicle or office in the entire building. We have a 100% open floor plan, because we understand that no one person has all the answers and that communication is paramount to solving problems effectively. When you open a ticket with us it's not a single engineer taking care of you, our entire department is actively working to ensure you problem gets fixed.    Having said this, there is a small team of 'Meraki Wizards' at support who's main purpose is to review bug reports our engineers put together to ensure they are robustly written and contain enough information to be actionable on the developers end. However, they are some of the nicest folk here at Meraki and do a great deal of consulting with all our engineers. In other words, consulting with the veterans is not something gated by escalations, these are resources that get leveraged on every case that needs it!     I'm well connected on the Meraki side of things (if I do say so myself) so I can turn to other channels, but not all customers/engineers have other accessible channels like this.   I wanted to save this snippet for last, because I think I can neatly wrap up my thoughts while addressing it.   If there is one thing I would like people to take away from this post is that   no one should ever feel like they need to have special connections to get   what they need. Here at Support we see ourselves as your allies and we want everyone to be confortable bringing things up with us. Our entire Support organization is built to make sure that whether you have a single AP, or thousands of full stack networks across the globe, you get   100% of our resources and 100% of our attention. If you ever feel we could be doing better, let us know and we are happy to kick it up a notch. 😉     I hope this help answer some of the communities questions on how meraki support opperates and please don't hesitate to keep the questions coming if there are any more left.     Cheers to all, Rodrigo ... View more

/Gotcha.   At this time the only way to apply group policy to specific users would be though Active Directory.  /:   That being said, you might be able to make the process a lot less time-consuming with one of the following options:   1) Use Sentry Policy (SM enrolled devices only): If your devices are enrolled in SM you can give users specific tags and apply group policy to an SM tag. Again, this would require SM enrollment for the devices in question [Relevant KB]   2) Apply Policy to Specific VLANs: If you use separate SSIDs and VLANs for the users you want to have on a schedule, you can apply the group policy to the entire VLAN rather than user-by-user. For example, having a Teachers/Faculty VLAN and a Students/Visitors VLAN means you can apply scheduling to the  Students/Visitors VLAN without having to apply the policy to all students manually. [Relevant KB]   3) Apply Policy by Device Type: If all students are given Chromebooks (for example) and you want to limit student access at specific times, you can apply group policy to any Chromebook that connects. [Relevant KB]     The viability of these options varies depending on what devices/users you are looking to regulate. ... View more

Hi @amacleod,   Could you elaborate a little more on what the end goals for your policies are? Are you looking to apply policy to students vs teachers, bandwidth abusers, policy breaking users, members of different departments...?   At this time, it is not possible to assign group policy to specific G suite users, but depending on what you are trying to do, you might be able to get away with using per VLAN policy, per device type policy, manual assignment or even SM to achieve your end goals.   Relevant KBs: https://documentation.meraki.com/MX-Z/Group_Policies_and_Blacklisting/Creating_and_Applying_Group_Policies https://documentation.meraki.com/MX-Z/Group_Policies_and_Blacklisting/Integrating_Active_Directory_with_Group_Policies   ... View more