Dear all Consider: 1 Organization, 4 Config Templates for 4 regions, 100+ Networks/Sites mapped to 4 regions.  Some SSIDs with Meraki's built-in splash page , some with Sponsored-Guest, Some with 802.1X, Radius and certificates. From using Meraki's built-in splash-pages for the guest SSID, we came to understand that authentication state of a Meraki user account is sync'd across the whole organization, but authorization state is only for a network, or for a config template, if the network is using a config template.  We have raised a feature request with our Meraki representatves to allow either org-wide authorization or to allow self-operated re-authorization when a user tries to reauth in another region under a different config template (... or under a different network). QUESTION: Considering an iPSK w/o RADIUS solution for the same customer - what authentication/authorization scope of an "account" (I know, it's not actually an "account" as such) can we expect? Documantaion seems to suggest  that the scope is certainly network wide.  https://documentation.meraki.com/Wireless/Design_and_Configure/Configuration_Guides/Encryption_and_Authentication/IPSK_Authentication_without_RADIUS)  I don't expect we could expect organization wide - but what about the scope of the config template?  (We are aware, iPSK with RADIUS would be one way to avoid such limitations, and the automation things could help to sync iPSKs across networks, that's all part of the ideas we're rolling around in our heads). Thanks for your thoughts and pointers to more info. ... View more

Dear all   A prospecitve customer (group company) is facing (conservatively guesstimated) 10-20 sms authenticated guests across 100 sites (sub-companies) per day, all year round. With european sms prices (Twilio calls a list price of USD 0.07 per msg), that will sum up to quite the amount of money per year for the parent/group company.  They're looking for a means to split/forward that bill "downstream" to the individual site or regional directors.  We (the MSP) absolutely want to avoid setting up 100 networks for 100 sites within that organization, and no one is looking forward to maintaining 100 Twilio sub-accounts with each their Account SIDs and Auth Tokens  Question: Can (selectable) meta information be passed along the with the API request to Twilio? For example, the AP's system name would nicely identify the site. But I'm also thinking of tags we could set per site or billing region for the AP. Once the information is with Twilio, the customer could sort out their split billing with Twilio directly.  The answers I got from Twilio's AI chatbot seem to suggest that their API might be able to ingest such information. Or: Do such things this happen already, and some AP related or other meta information is already going to Twilio by  default? Thanks for your thoughts and pointers. ... View more