You should be able to set up the users with access to certain cameras and/or feeds, so that they can log in and access the Vision Portal and leave it up. I know this is 4+ years after you posted this, and you may already know this, but there was some problem that was just resolved in ver. 1.22.1 of the Vision Portal that was either still a problem causing idle timeouts, or had been previously fixed, then returned as problem -- https://documentation.meraki.com/MV/Viewing_Video/Meraki_Vision_Portal_Changelog ... View more

There did wind up being an issue that was supposedly resolved with ver. 1.22.1 regarding the Vision Portal and timeouts, so perhaps that was my issue -- https://documentation.meraki.com/MV/Viewing_Video/Meraki_Vision_Portal_Changelog "[New] Fixed issue with users being logged out of full screen video wall view after idle timeout" Of course, as circumstances ended up playing out, I had ended up thinking that getting the Display licenses and Apple TV would be the better solution, but that is proving to be doing the same type of thing that *was* happening when they were just using the Vision Portal in fullscreen mode on a computer.... I cannot win with something that I would think should be relatively straightforward. ... View more

Was there any definite solution that was determined for this issue?   After setting up some Meraki cameras for one of my locations, and attempting to just use the Vision portal on a computer to have cameras simply display their feeds via one of the video walls we had created for the site, we found that the Organization timeout period was causing the account that was being used to sign in and view those video walls was automatically signing the account out when the timeout period was met, since the computer was not actively being used for anything other than displaying the camera feeds.   We found out about Meraki Display and the use of an Apple TV, so we purchased the licensing for Display, along with an Apple TV and set it all up. While at first it seemed to be a solution, my users at the site are finding that the problem seems to remain. Although it is not going by the Organization timeout, the cameras do appear to "freeze" after about a day. When you try to back out, then select the same or a different video wall, we are being presented with the "error fetching video wall session is not authenticated" message, and being forced to sign in once again, despite the literature on Display indicating that a re-authentication for the account being used should only be necessary once every 30 days. ... View more

I tried both modes repeatedly, and wound up getting the same result. After adjusting the timeout period to be longer, I did find that it would delay the sign out to more or less match the timeout period. However, it would never fully resolve the problem. ... View more

Interesting. I tried using the Theater and Fullscreen modes, but it still ultimately times out and forces the user account back to the login, whether I try to use the Meraki Vision application, or the web portal. I'm going to get a quote for the licensing to use with an ATV box, just to explore that avenue. I can empathize with my user base being annoyed about the frequent log-ins/log-outs. It just seems utterly ridiculous that camera administrators can not be set to a different timeout, or have no timeout configured whatsoever.   ... View more

Hmm, that's basically what everyone in this thread probably wants/needs. Thanks for the pointer in a direction, albeit one that is paywalled by yet more hardware and licensing - lol. I guess the question at the forefront of my mind with that is, the Org Timeout period does not effect the operation of that solution actually staying signed in and just showing the darn camera feeds?   ... View more

That's actually an interesting thought.   Did you ever go through a trial of testing that, to see if it did in fact keep a session alive?   That could be a decent workaround to at least provide a bit of reprieve, if the organization timeout period is set to be only 20 or 30 minutes.   EDIT: at least from an initial test yesterday, this didn't seem to change the fact that the organization timeout would cause it to log out the account if no activity from the user account which was used to sign in was detected. I'm going to ensure the browser is updated, and try again, but I do not have a lot of hope that will make any difference.     ... View more

Did this ever get turned into a reality of any sort?   We have Meraki cameras deployed throughout our environment, but we seem to have no option to allow for users who are solely set up to access the cameras to have any different sign-out period than Network or Organization Administrators.   To me, I would think that it would make sense to have separated time out options for those user accounts that are simply assigned access to Cameras, versus doing anything else, read- or modification-wise, for the underlying network infrastructure.   Can this please be added?! It is silly to only have an option to increase the time-out period for an entire organization, thereby providing more opportunity for a malicious entity to gain control to an organization's network infrastructure just so users do not have to repeatedly log in throughout a given day just to look at the cameras that have to be logged in to view.   ... View more

Thank you! Would you happen to know why that note wouldn't have been in there already? Just seemed odd that there was info relating to virtual MACs on switches, but not on MX appliances. In any case, much appreciated for getting it added. Hopefully it will help someone in the future 😄 ... View more

Out of curiosity, is this something that Meraki even details in official KBs or docs anywhere? The closest things that I could find for virtual MACs didn't detail those specific "cc:03:d9" octets as the tell-tale indicator to be mindful of if one found themselves hunting. I happened upon this thread as I was trying to track down what is apparently a virtual MAC. It was only after I got a reply on a case I had opened about this mysterious address that I was told it was a virtual MAC associated with one of my MX devices. After searching, your answer was the top result time and again.   ... View more

So I had gotten an update from Meraki with the case I've had open that there was a permanent fix as part of the current stable release candidate firmware, ver. 18.105. I updated one of my smaller networks to it last night, which is running an MX64, and to my surprise,  there are no longer spammy event logs in the Meraki dashboard for that network's "Security Appliance" section as there have been. Additionally, none of the DCs that I have configured in the "Active Directory" tab for that network are showing a "WMI error message", but shockingly are showing "Success". Finally, I'm not seeing spammy logs on any of those DCs detailing the DistributedCOM source, nor the associated "The server-side authentication level policy does not allow the user <User> <SID> from address <address> to activate DCOM server. Please raise the activation authentication level at least to RPC_C_AUTHN_LEVEL_PKT_INTEGRITY in client application." I have yet to test this to confirm that it is actually the fix, but if anyone else has time to weigh in if they get a chance to test it, I think many people would be most appreciative. Meraki may have nipped this in the nick of time. ... View more

Here we all are, over a year into many of us having this issue, and Microsoft is going to begin enforcing this in March - DCOM changes first released in June of 2021 become enforced. See https://msrc.microsoft.com/update-guide/en-US/vulnerability/CVE-2021-26414 and https://support.microsoft.com/en-us/topic/kb5004442-manage-changes-for-windows-dcom-server-security-feature-bypass-cve-2021-26414-f1400b52-c141-43d2-941e-37ed901c769c.   Are we all just basically screwed if they don’t get this figured out, since there will be no way to disable it, and since we are all likely past the point of using a firmware version that did work? I cannot fathom how they haven’t worked this out ... View more

If you're referring to your post from 6-22-2022, I did actually try that, as Meraki had recommended something similar, while simultaneously referencing their https://documentation.meraki.com/MX/Content_Filtering_and_Threat_Protection/Configuring_Active_Directory_with_MX_Security_Appliances#Create_an_Active_Directory_Site article and suggesting that it was something mis-configured on our DCs.   It did not change anything in terms of the behavior, and Meraki has acknowledged months ago (at least to me on my case) that this was a known issue related to their firmware that they are still working on. ... View more

Been seeing the same thing since July of this year, and have had a case open since then.   Was most recently advised to update to the stable beta candidate of 17.10.1, problem persists. Something I did notice was that for a 2016 DC that I have, there were "connected to domain controller" event logs that started populating within Meraki after updating the associated network to 16.16.5. However, it did not change the fact that there are still persistent event logs showing up on the DC itself, nor the fact that within the Dashboard, the DC in question still shows a "WMI error" status. On a related note, I also have a 2022 DC that is in the same network as the 2016 DC, and after the upgrade to the 16.16.5 firmware, it was still spamming "cannot connect to Domain Controller" events in Meraki, as well as the "server-side authentication level policy" / "RPC_C_AUTHN_LEVEL_PKT_INTEGRITY" messages on the DC itself. Anyone else having any luck ? ... View more