Cazale

I'm not doubting that is sometimes true, but in our case I don't think it is the issue. We control updates (with WSUS, to state the obvious) and we'd have noticed the correlation. I should have said in the OP; this isn't something new, we've been seeing it for years. I think it's become more of an issue for us in this past year because there's been a lot more home working due to covid, and as a result of covid schools have more buying more devices, so we're just seeing it happen more frequently.

Does anyone else get the above error regularly from the Windows Smoothwall VPN client? (a Windows error box that pops up saying "Smoothwall VPN: Can't connect to the ssl vpn service: shutting down"). We look after several schools, and there's barely a day goes by where we don't have this issue with at least one school, or even have the issue ourselves. Whenever we get the error the service is running. Fixing it is simple enough, we remove the Smoothwall client via add/remove programs, reboot, reinstall it, reboot and then it works. It's just a bit of a faff having to do that nearly everyday. The reason I ask is because I tried to open a support ticket with Smoothwall, and their support said it seems to be a unique problem to us, so they wouldn't escalate it as a software problem. I just find that really difficult to believe, because as I said above, we see it regularly with several clients (different schools, different premises, different devices, different Windows versions, different Smoothwalls, etc). We (as a company) also have dedicated VMs that we use to remote into schools hosted on our own server, and it occasionally happens to us too. Anyone else get this issue? (I'm hoping to build up a case of it happening so I can throw it back to them as a bug).

That makes complete sense and yes, that's almost certainly how I've done it on every other occasion. Many thanks!

I've probably set up 100 servers and dozens of domains and never had this problem before. It's something I've either forgotten how to do, or I've missed a step as I've been setting the DC up. Google isn't helping so I thought I'd ask here. To cut a long story short I've had to setup a new domain. I've got the usual security groups: Leadership Office Teachers Pupils (and so on) Each of the above exist as a security group and also have their own OUs, with users being placed in the correct OU and the corresponding security group being placed in each correct OU and each user being placed into a member of the security group. We also have mapped drives (again, the usual type of shares that seem to exist in most schools): an O: drive mapped to \\server\office P: mapped to \\server\pupils L: mapped to \\server\leadership T: mapped to \\server\teachers and so on. Each of the mapped drives is done with a GPO, and that is applied to the corresponding OU (so for example, there's a GPO in the Office OU that applies the Office Share drive to users in that GPO). Here's the thing that's puzzling me (and that I've obviously missed something!): sometimes a user will require access to a mapped drive in another group. I.E. we might have a teacher that covers the office sometimes, so they need the \\office share, or an office manager who also needs access to the Leadership mapped drive. Every time I've set this up before all I needed to do was add them to the corresponding security group and they'd automatically get the share. i.e. I'd add a teacher to the office security group (but they would remain in the teacher OU!) and the next time they logged in they'd get the mapped office drive (because I'd added them to the office security group). That isn't' working. I'm having to create them their own OU and create a new GPO which manually maps both the office and teacher drives using a brand new GPO. Thankfully at the the minute I'm still only a couple of days into building the domain, so this hasn't been a major issue (only a couple of users have come to me and said they require access to resources outside of their OU), but obviously this can't continue otherwise we end up with 50+ security groups and OUs for each combination of user that requires access to drives outside of their current OU. I feel like a dunce because I've obviously missed something really obvious! Any suggestions?

I'm more surprised they have the power to run malware than I am that they have malware on them.

Thanks

Guardian reporting the GeoBooks have malware on them. Anyone else found this? https://www.theguardian.com/education/2021/jan/21/malware-reportedly-found-laptops-children-england

They just replied to me on Twitter with the same statement.

I asked on Twitter the same time as I posed this thread, no reply.

I've found Smoothwall to be fine until recently. Our support tickets are now taking over a month (!!!) to get answered. It's an absolute joke. We are also now thinking of moving elsewhere.

I suspect bad! (but very much hope I'm wrong)

According to this blog.. ParentPay have been a victim of Sunburst! https://blog.prevasio.com/2020/12/sunburst-backdoor-part-ii-dga-list-of.html Is anyone on here from ParentPay? Can you confirm/deny? Has there been any data loss?

Some more info on the potential impact on WiFi networks here.

Sorry if this has been mentioned before. I had a quick look but couldn't see anything: Apple has introduced a feature called "private address" feature in IOS14, iPadOS 14 and watchOS 7, this is ENABLED by default! This feature effectively creates a virtual MAC address and, instead of using the hardware MAC, uses the this new fake MAC address to connect to WiFi networks. As this is enabled by default (unless you limit it with MDM), this means the MAC addresses of ALL of your devices have changed! There is some conflicting stories out there that say these MAC addresses change every 24 hours (with some very limited testing: that's not something I can see on our network). However, this does still seriously affect DHCP (effectively every Apple device is going to get, at least, a second DHCP lease, that can have serious effects if your pool isn't big enough!), BYOD, IP whitelisting and of course, MAC address filtering. To provide a real world example: if you've created an IP space for a set of iPads so they can print without authentication, or so teachers can bypass a filter (etc), all of those iPads now have a different MAC address, so will now also have different IP addresses. Of course, it also means that if you manage multiple WiFI networks, the same device will have different MAC addresses/IPs/etc across the networks. This is quite a major change that anyone with IOS devices needs to know about!

Not if we want to use them on the school WiFi we can't, every https page (pretty most of the internet these days) just generates an error if we try. Appreciate we can put them in a reservation space on DHCP and exclude them from the filter, it's just a lot of faffing, and I also suspect the school would prefer to be alerted if someone tries doing something they shouldn't. It's not the end for the world. They'll be going out to parents soon. We just wanted to test what we could/couldn't do with them in the meantime.