yeah, that is it! Thanks a lot, Raphael, this is great! ... View more

You will have to convert the existing firewall rule from your csv into json format and use the API's update PUT operation to apply the firewall rules. If you are not sure what fields are needed in the json file, you can find one by doing a GET to retrieve it from the MX. ... View more

I think the firmwareUpgrades API works for me, and it displays the shortName that is matching on the dashboard.   I am still not sure why the firmware data returns at the devices/{{serial}} doesn't return the same value. If it doesn't work well, I prefer it does not return the fimware value.    Thanks for providing the workaround.   Byron ... View more

Well, our branches are small with one MX and one MS. I will check out the API you suggested and report back.   Thanks ... View more

the devices I have issued with are mostly MX64w. I will have to do some cross checking on what firmwares are showing in the dashboard ... View more

Thanks Inderdeep for the quick response. Very nice article. Looks like it does support scaling out.    BZ ... View more

I think PowerShell is one of the most powerful things in the Windows environment. I love using it. Since Python has the best support from the Meraki community, I think I will take the advice, at least to test it out in Python. Hopefully it won't take long to migrate my almost 1000 lines PowerShell script over.   Thanks everyone here. ... View more

@PhilipDAth    Are you using /devices/{serial}/switchPorts in your scripts? Mine doesn't work anymore.   I do believe Python has better support with Meraki API. I am working in a Windows shop, and PowerShell is more of a natural fit for other tasks. For many simple tasks like,reading a csv file, extract data from it, manipulate it, it is very straightforward. Of course, it could be just me not know the tricks in Python.        ... View more

@John-K ,   Thanks a lot for sharing all those reasons behind the versioning. It helps a lot. Just had a rough day after chasing those errors.   The interactive document site looks very nice. I will kick some tires on it. I normally use Postman to test the API. Now I got a new tool to test it.   One thing I am still not clear is: when should I be using v0, and v1? It is very confusing to me.   An example is the switch ports configuration. I found that /devices/{serial}/switchPorts no longer works regardless it is v0 or v1 that I tested with. Finally, I changed it to v1 with /devices/{serial}/switch/ports and it works.   Another one is if I use v1 on /organizations/$OrganisationID/networks to create a new network, it failed. If I changed it back to v0, it works.   Unfortunately, PowerShell Invoke-RestMethod doesn't really return the error stream nicely to let me know why it failed with v1 except saying it is a 400 error. Anyway, the workaround I have is that I am using both v0 and v1 in my PowerShell script. It is just getting messy.     ... View more

I do not see where to set the bitrate neither, so it is the default settings, and we are not using band steering neither.    The devices we have are Windows 10, but at one point I did ask a branch user to use her smartphone, and she was seeing the same symptom of being able to see SSID1, but not SSID2. I didn't check if it is Android, or iOS, but definitely not Windows 🙂   It seems it needs to meet certain conditions before you are able to see this issue.    I will see if I can manually reproduce it in my office.     ... View more

Whatever the date rate is, it is the default setting. I do not see the option to change it.   I leave the channels settings at the default of auto for both 2.4 and 5Ghz. We have two devices in each of those branches, and all of them behave the same way. I even asked the branch user to use their smartphone to check the wifi, and they were not able to see the SSID2, but were able to see SSID1. I thought it only happens to this one branch, but now as our project goes on, we are seeing more and more branches are having this issue.    This symptom only happens to some of our branches, which probably needs to meet certain condiction. But regardless, it is telling me the not all SSID in an MX equal.  ... View more

This is 14.39 on both of the MX60W and MX64W I just tried. I ran into this on a 67W too, but forgot which location I put it in since it was a couple of weeks ago before the new year, will need to look for it.   It could be a bug. That is why I am checking to see if anyone else out there has similar experience.   Thanks   Byron ... View more

Thanks @NolanHerring. That was how I understood it since it is from the same device. However, that is not what I observed. In some of our branches, some devices are able to see SSID1, but not SSID2. I even opened the ticket about it and it didn't go anywhere. So I played around with it, and here is what I found.    1) I changed the channels from Auto to some static channels, sometimes it works. But it stopped working again after one or two weeks.   2) If I disable SSID1, and keep SSID2 enabled, the devices are still not able to see SSID2.   3) If I swap the configuration of SSID1 and SSID2, the device is able to connect SSID1 regardless SSID2 is enabled or disabled.   This tells me SSIDs in MX are not equal. It seems SSID1 has a stronger signal than SSID2. I haven't tested with other SSID#, but this is what I observed so far.    Does this make sense to you?   Thanks   Byron ... View more

In my MX, the SSID number seems working correctly. It does have an hidden ssid 0 that is not avaialbe in the web page. When I ran PUT against ssid 2, the second SSID in the web page does get updates. ... View more

I tried like you suggested in postman, and it didn't generate any error. It was able to update everything, except for the VLAN assignment field. I tried to include "defaultVlanId": 14, and I got the same result without any error, but it just won't update the VLAN assignment field.    { "name":"My SSID", "enabled":true, "authMode": "open", "ipAssignmentMode": "Bridge mode", "useVlanTagging": true, "vlanId": 14 }   Thanks   ByronZ ... View more

Thanks DillonofAnch17 . Do you have any samples of the json data for assigning a VLAN? I tried to follow the document, but just not able to make it work.   Thanks   ByronZ ... View more

Thanks PhilipDAth.   When I do a GET, it is this, with useVlanTagging as false. But in the web interface, I can confirm it is assigned to a non-default VLAN.    { "number": 2, "name": "TestWiFi", "enabled": true, "splashPage": "None", "ssidAdminAccessible": false, "authMode": "psk", "psk": "TestPassword", "encryptionMode": "wpa", "wpaEncryptionMode": "WPA2 only", "ipAssignmentMode": "Bridge mode", "useVlanTagging": false, "minBitrate": null, "bandSelection": "Dual band operation", "perClientBandwidthLimitUp": 0, "perClientBandwidthLimitDown": 0 }   I am really scratching my head on why it behaves like this. I have tried to use PUT to update with both useVlanTagging,vlanId, and defaultVlanId, but it won't update. Maybe I am put the attributes in the json file wrong? I don't know...   Thanks   ByronZ ... View more