toffee_paul

Has anyone managed to do this yet? Seems like editing an existing VPP token isn't supported (greyed out), and creating a new DDM-based VPP token with the same Apple VPP email address leads a "Duplicate" error. Deleting the original MDM-based VPP makes it sound like all apps linked to that VPP will be removed from devices? Obviously don't want that but don't trust that pushing out the DDM-based token straight after will stop that from happening.

@CHiLL Sorry I meant to say did Senso ever fix it, not Impero. We use Impero and adding ai.exe into the injection exclusion list didn't resolve it for us. We are on v8.6.32 which isn't the latest so it may be a newer version fixed this. The changelog doesn't seem to mention it though. Looking at Senso as a potential Impero replacement, are you happy with it?

@CHiLL Did Impero ever fix this, do you know?

Just to provide a final update for the original issue (inability to access our MIS), this was confirmed not to be a Smoothwall issue and was in fact a DNS issue. Our ISP was failing to resolve the domain cdn.ravenjs.com that hosts JavaScript library necessary for Arbor to load. After opening a ticket with our ISP about a week ago despite some initial to and fro with them, this is finally resolved and the domain now resolves correctly with their DNS forwarders.

Hi, Anyone else on 3CX and Smoothwall? Can get to our hosted sign-in page ok and as soon as clicking Login button we get a "Disconnected - try again in xx seconds" error. Had to create a HTTPS inspection policy and set it to 'do not inspect' to restore access, after Developer tools in the browser was saying there was issues with WebSockets. Followed this guide: https://kb.smoothwall.com/hc/en-us/articles/360003342820-Allow-access-for-WebSockets Ticket open with 3CX so maybe they've changed something their end, as I was accessing the site fine at the back end of last week. Only thing I've changed is our DNS forwarders from our ISPs own to fix an issue accessing Arbor.

No, DNS queries can be cached just like the JavaScript files and other content can be cached locally on machines.

Yep, that setting was the first thing I tried, made no difference.

Following a call with Smoothwall they believe it to be an issue with DNS. Upon changing the DNS forwarders to Google's (8.8.8.8 / 8.8.4.4) on our on-prem appliance, access to Arbor is now working fine. May be worth changing yours temporarily and see if it makes a difference. @5nowman you mentioned you're on BT Fibre so maybe your issue is different as you mentioned slowness rather than an out-and-out inability the resource itself. Thanks to Alan @ Smoothwall for highlighting this.

Out of interest what ISP are you both using?

@SeeFights Try adding the IP of an affected device Guardian > Web Filter > Exceptions page and leaving it a minute or two for it to take effect. Adding IP an exception - site loads fine.. removing the IP and doing a hard refresh (Ctrl+Shift+R) and it's blocked again. Hard refresh forces it to go out and load the JavaScript from the site, and not use a locally cached copy. What's equally frustrating for me is trying to get a response to my ticket. I was asked by the second line support manager for details which I replied back to within a couple of hours and I've heard diddly squat back since then. Even contacted our account manager last week too to see if they could give it a push along and got no response. Really disappointing. Just need someone to remote on and take a look.

@andy_b Thanks Andy but we're not using any ad-blocking extensions. @SeeFights I'm struggling to think it's NOT a Smoothwall issue to be honest. The fact other Arbor customers have the same issue and they're all on Smoothwall is the primary reason, along with the fact that if I add the IP of an affected device to The Web Filter > Exceptions page it loads Arbor no problem.

Some screenshots attached. I tried adding the IP address that's returned when pinging cdn.ravenjs.com to Destination exceptions on the Smoothwall but it didn't make a difference.

@5nowman Use Developer Tools and you'll see that it reaches out to various sites and pulls things in. In the case of Arbor they use the JavaScript library at ravenjs.com. @simpsonj I'm on Edge (chromium) and I can only see the domain, not an IP address. This is what it tries to load: https://cdn.ravenjs.com/3.16.1/raven.min.js @tom_newton Arbor have told me four customer have reported the same issue occurring at the same time. Maybe it's something unique to the on-prem config of all five schools then? All I know if our web policies haven't changed in quite a while, and we can get to Arbor when bypassing the Smoothwall.

Is anyone else experiencing an issue whereby Arbor is inaccessible due to Smoothwall blocking it? I've narrowed this down to a JavaScript library (ravenjs.com) that Arbor use and which is loaded from cdn.ravenjs.com when our Arbor site is accessed. We have a category named 'App - Arbor' containing all the recommended URLs Arbor say should be whitelisted. This has been added to a web filtering policy and set it to ‘Do Not Filter’. Also added a HTTPS Inspection Policy and set that to 'Do Not Inspect'. Arbor have told me they have multiple customers affected by this and the common denominator is that all are using Smoothwall. We have a ticket open with Smoothwall but they haven't responded since Thursday. Access to our Arbor site works perfectly when: - accessed from a mobile device using a mobile data connection. - when I add the IP address to Web Filter > Exceptions page thereby giving unfiltered access to the internet. I can't be giving unfiltered access to the internet to staff for obvious reasons. Arbor have told me that another school who raised a ticket with them for the same problem had a Smoothwall engineer tell them they're blocking an IP address because they see it as malicious. I've not been able to get a response from Smoothwall to my ticket and my account manager is on annual leave so we are stuck with no access to Arbor and an inability to send comms to parents.

@PaperCutterAl What's the new method and is it in available yet? We have the .bat file method in use (Logon script, deployed by Group Policy). As we use AppLocker I created a Publisher rule to exclude the blocking of the executables.