HappyAdmin

Hi ass17, Thanks for getting involved to help with this. I've just tried inserting as the last line in the runtime section, and we are down to sub 10s start times following a reboot! I have spent so long battling this, that is AMAZING! Going to go copy that file into place on all 10 machines and I should be able to sign this off - 2nd set of Y11 mocks should go more smoothly now! Thanks again.

No - not something I often need, so I hadn't thought of that. I'm on with some other things today - I'll try to give that a go later in the week. Good idea.

Thanks midweek - that's really interesting, and reassures me that I'm not going insane!

Hi Hive Mind, (I know there's an ExamWritePad sticky thread - but it is huge, and this is a discrete, complex issue, so I thought it would be better in a separate post.) I've got a really weird issue with ExamWritePad (up to date, paid) starting slowly when on the network and I wonder if anyone has any ideas: I have 10 exam laptops - basic Windows 10 install, domain joined. They need to be on WiFi for printing, but not to have internet access because exams :-) Everything about EWP is local to the SSD: program, license, config file, saving, autosave location... The config is set not to check for updates on startup. I have IP reservations for the WiFi MACs of these laptops, and our Fortigate is set not to allow them to see the internet, limiting them to the internal network - but see below. When I boot and log in with normal internet access (wired connection, or WiFi but with IP set outside the exam laptop range by changing the reservation) EWP starts in ~5 seconds When I boot and log in with no internet access (IP reserved into exam range) EWP takes about 28s to run. I've therefore logged all the web traffic from the time of plugging into the wired network until EWP is run (via our Fortigate) and allowed traffic to all the sites accessed from the exam laptop IP range, except for bing.com - they are mostly ocsp related, which I believe is related to certificate checking. However, this made no difference - still a 28s EWP startup time. When I use a normal internet connection and get the 5s EWP startup I can then revert to the connection with the internet blocked and close EWP or even reboot and still get the 5s startup for some time. However, a few hours later (I'm not sure of exact timing) it reverts to 28s until the next time it is given unfiltered internet access. I know 28s isn't that much, but there's no indication on screen that anything is happening (no "eggtimer" animation except in the first and last couple of seconds) and it is long enough to be confusing, meaning users click multiple times etc. Plus it's the principle of thing! Has anyone got any ideas of what is causing this or what to try? I think I'm at a loss now. Thanks in advance if anyone has any ideas (other than disconnecting from the network - now we are printing via it instead of USB sticks I'd rather wait 28s for startup than go back!) Ben

The last one, with /api/ As I say, I just started from the Smoothwall article - I did understand that it was intended for unblocking individual videos, but it seemed likely to give something of a shortcut to what we were trying to do.

We've taken the decision to allow Vimeo embedded videos but not the Vimeo site itself. This isn't perfect, of course, but it is likely that inappropriate videos are embedded in sites that will be blocked anyway. I've done this on Netsweeper by taking the list in the Smoothwall article that is easily found with a Google search, and then just adding 1 entry that turned out to be needed in our case. I make no warranty as to the correctness of this list, but I'm putting it here in case it is useful to anyone as a starting point, and I can confirm that it is, on top of our standard setup, having the desired affect as described at the head of my post. Allowing the following: player.vimeo.com/crossdomain.xmlav.vimeo.com/crossdomain.xmla.vimeocdn.com/p/2.1.18/js/player.jsvimeocdn.coma.vimeocdn.com/p/2.1.18/css/player.cssplayer.vimeo.com/play_redirectplayer.vimeo.com/video/vimeo.com/api/ Ben

Looks like an interesting one, with the security talk and the Windows 10 deployment workshop in the afternoon. Ticket booked.

No, sorry Dropbox - after I picked the lock I just left it at that. Ben

Thanks guys, I'll look into it further when I've got time again. B

Thanks for the heads up that the series had started - I watch so little broadcast TV that I hadn't spotted it. Thank goodness for iPlayer. I'm not so sure about the early knockout battles - with 4 in the arena, things can be a little random - but I love the everyone-fights-everyone format that follows. Watching the slow attrition as they try to repair them after each battle is great, and the randomness of one bad fight is reduced. Can't wait for the rest of the series!

Hi All, I took over here (a Lancashire high school) about 18 months ago and YouTube is blocked on our Curriculum network. Any attempt to access youtube from that network gives an error. On Chrome this is "This site can't be reached. The connections was reset. ... ERR_CONNECTION_RESET". Similarly inaccessible on IE. We are connected to our County's fibre, which has Lightspeed as part of the package, but this is NOT the error which results from a standard Lightspeed block - that is a page I've customised in Lightspeed with our school logo etc., inviting me to log in and override. I've had a look through Lightspeed, and I can't see anything there which seems likely to be causing this. I want to turn on YouTube for students, in restricted mode, by using the DNS CNAME method (see https://support.google.com/a/answer/6214622). I can then use GAPPS to give staff approval privileges for individual videos and channels, HOWEVER, I can't work out how the above total ban has been enforced. I bet this is a known education admin trick, and I'm hoping someone can give me a clue... I initially thought it must be in DNS, but I can't see anything that doesn't refer to the local network in DNS on the (Windows Server 2012 R2) DNS server for this network. I receive a basically similar error on Windows machines or Chromebooks connected to this network, so this can't be AD group policy related. Can anyone throw me a bone on where to start looking to un-pick the old block before configuring the new semi-block? Many thanks if you can! Ben

We are smaller than you, only 600 or so on roll, but looked last summer at Cunninghams, NRS and LCR. We went with NRS, and haven't regretted it, except at one point during the install when they got mixed up and told us they couldn't do something previously promised - some "talking to managers" got it back! To us, Cunninghams seemed very clunky, and LCR seemed good, but lacking a couple of features we needed - still in the development pipeline, apparently. Just my 2p worth... Good luck - and I'm glad they have involved you. Much better than being told what is happening at the end. I was involved from day 1, and I think my perspective was a useful contribution. Ben

Assistant ICT Technician Whitworth Community High School, Rossendale, Lancashire, OL12 8TS (Just outside Rochdale) Full time, term time + 5 days. £15941-£17372 pro rata. Full details can be found at Whitworth - Looking forward to your applications :-)

Another +1 for the Saharas. I started using them about 6 months ago to replace old sets as they fail, and I'm liking them so far. I can't personally report on longevity yet, but I've started using them as they seem to have a good long-term reputation. The optional wired remote is well worth it, and very handy, and they sound pretty decent.

Hi, Well, I documented it for myself in case I ever have to do it again, so here it is copied and pasted. I've just obscured IPs. --- Make sure power saving is off on the laptop. Connect Android phone to Ubuntu laptop via USB. Turn on USB tethering on the phone, in settings. Connect in Network Manager in Ubuntu to the usb tethered connection. (This actually required no action - it automatically connected, although I did rename the connection for clarity.) Plug the laptop into the Admin network with an ethernet cable. Configure the connection eth0 (via network manager) to: IP - a free address on your internal network, let's call it default route as the IP of usb0, the tethered connection, found from ifconfig, lets call it DNS 8.8.8.8 and 8.8.4.4 (Google’s public DNS) [*]Set up iptables to forward traffic, as per the relevant parts of http://ubuntuforums.org/showthread.php?t=2179393 sudo iptables -A FORWARD -o usb0 -i eth0 -s /24 -m conntrack --ctstate NEW -j ACCEPT sudo iptables -A FORWARD -m conntrack --ctstate ESTABLISHED,RELATED -j ACCEPT sudo iptables -t nat -F POSTROUTING sudo iptables -t nat -A POSTROUTING -o usb0 -j MASQUERADE The first rule allows forwarded packets (initial ones). The second rule allows forwarding of established connection packets (and those related to ones that started). The third rule does the NAT. Save the iptables: sudo iptables-save | sudo tee /etc/iptables.sav To make this permanent you could: Edit /etc/rc.local and add the following lines before the "exit 0" line: iptables-restore < /etc/iptables.sav but I haven’t at the moment, but the above line could be manually applied. Enable routing would be done by: sudo sh -c "echo 1 > /proc/sys/net/ipv4/ip_forward" but this was already set (I checked using cat /proc/sys/net/ipv4/ip_forward). [*]This was then tested by setting one PC manually to use as default gateway, with google’s DNS set above - worked fine. [*]Server changes then made (after recording original values): Set default route ("003 Router") to Set DNS forwarders to 8.8.8.8 and 8.8.4.4 Change DHCP to give out a default gateway of (NB: do not change DNS in DHCP - this must remain pointed at the server, or the domain will break.) [*]Network DHCP refresh Reboot PCs, or just run ipconfig /renew [*]TO CHANGE SERVER BACK TO NORMAL Change default route back to what it was before you started Set DNS forwarders back to what they were before you started Change DHCP to give out a default gateway of what it was before you started [*]Then DHCP refresh clients. ----- I can't fully take credit for the iptables commands - I only basically understand them, and it would have taken me ages to work them out from scratch, but Google was my friend. Who knows, might help someone some time. Ben