jthompson

IIRC the software needs to be run from a location that the user is able to write to, specifically to facilitate updates. I think that's why it installs to C:\Users\Public by default, to allow the user to modify the program's files as and when needed. The location you install it to would also need to dovetail with whatever AppLocker rules you might have to allow said user to run the software as well. For our setup, I created an MST transform file to use with the deployed MSI. The transform file specifies a custom install dir (e.g. C:\surpass_WJEC). This works well for us, as we recently had to deploy a separate instance of SecureClient for Cambridge admissions tests, so we just created another transform to use to install it to a different location again, allowing for the two separate instances to co-exist. To make the tansform file I used orca, loaded up the MSI and created a new transform. In the Property table, for the property CMDLINE specify your desired install dir. note that there is a leading space before that first /. /DEFAULT_INSTALL_DIR="C:\Surpass" That's a command line parameter that's supported by the SecureClient devs.

That's great, thank you. As I suspected but you know when you just want to know that it's not something funky with your network.

Hi all We've spotted something strange when adding a particular web link as a material in Google Classroom. When adding a link, GC will gather a bit of metadata from it and use that to present the link with the page title. For one particular link, https://cinemontage.org/editing-selma-union-legacy-martin-luther-king/, GC is displaying a Viagra advert as the page title. Other pages from the same site appear to work fine. I can't see where it might be getting that dodgy page title from, as the proper page title appears in the page's source, and gets displayed as expected by the web browser. Would other mind checking to see if GC behaves the same elsewhere when fed that same URL?

But what colour is that plane? I've shown it to a bunch of my friends and half of them say that it's blue and red but half of them are saying that it's definitely white and gold!

Agreed. Using a SENCO class also keeps usage in line with how the platform was intended to be used, and so Google end-user support articles, etc. will all be pertinent and useful. Any new staff coming into the arrangement down the line can then just be told "we're using Google Classroom".

That would also work, but I think you'd want to go a step further and transfer ownsership of the folder to the pupil, as well. That then avoids anyone losing work if/when the SENCO leaves the organisation and their account is suspended.

It perhaps depends on how much the existing teachers are already using Classroom, and whether the work that SENCO wants to see is predominantly being set by the SENCO in the first place. If it's work that is predominantly being set by the SENCO, then a dedicated SENCO Classroom class would perhaps be preferable, with the other teachers added to it as well to allow them to see the work. That also gives scope for those other teachers to set assignments just for SEN pupils, without having to bother with managing Classroom for the rest of their pupils if they don't want to be doing that. I'm pretty sure that all the work would need to be off the back of assignments.

I think it's so that it feels and looks more natural on a touchscreen. In terms of the comparison to MacOS lifecycle, I don't see it as too much of a departure from that. It's certainly not as bad as Android in that regard (both in terms of UI changes and hardware support).

Shared Drives for each class would expose pupils' work to one another, so probably don't do that. Might another option be for the SENCO to guide each SEN pupil through creating a suitably named folder in their Google Drive (e.g. "Billy B's Work"), share that with SENCO and teachers as required, and drill the pupil to do all their work in that folder? SENCO/teachers would then see work magically appearing in "Billy B's Work" in their "Shared with me" items.

This seems like the approach to take, since it'll be pretty robust and won't be placing any extra responsibility on invigilators. Obviously, it depends on what firewall capabilities you have at your disposal. Invigilators being able to reliably spot web browsing during a Dreamweaver-based task could be a problem.

Some of that stuff would be a great way to provide a hi-res virtual tour of all our school. All the scruffy paintwork, wonky doorframes and water-stained ceiling tiles might make it feel more like a game of Half-Life 2, however

Maybe try it in serveral smaller chunks?

As a slightly off-topic aside, this got me thinking about sender reputation and I've noticed that Google and MS both offer some sender reputation reporting tools. https://www.gmail.com/postmaster/ and https://sendersupport.olc.protection.outlook.com/snds/. Not used them before but maybe worth exploring.

Well, copy and paste directly in Bcc is easier than a mail merge, but I guess it depends on the volume involved and whether incoming replies might start to confuse matters down the line.

Depending on how many addresses there are, you might be able to just copy and paste the cells containing addresses into the Bcc field of a message in OWA. Definitely double-check that you've used Bcc if doing it this way! I don't use OWA but that works in Gmail. Obviously if you have hundreds of addresses, they won't all go in one email as there will be limitations on how many addresses you can send to in one go. Probably okay for a few dozen.

That seems fine to me. Migrating it to a Google or O365 native document might simplify things though, and lessen the risk of somebody storing a copy of somewhere less secure.

It can get a bit complicated, but we were in the same position as you with regard to our main website being managed for us (i.e. no access to manage files on the web server). We have an account with Krystal for hosting a couple of other little bits, and so we've hosted our MTA-STS file on there. The domain is added to our Krystal account as an add-on domain, and then we've made the relevant DNS entries to point to Krystal servers. The MTA-STS DNS record for you domain can point to wherever you need it to: that doesn't necessarily have to be the same servers as your www site.

Love that! I've always felt like we needed a decent cartoony or illustrative map, a bit like you might get at a museum, or a zoo, for guests, open days and such.

Haven't used an actual, swirly pattern screensaver in years. Rather I set display sleep timeouts, which can lock the desktop anyway.

The solution is to turn on 2-Step Verification for the Google account(s) in question, and you can then create app-specific passwords for them that will be accepted like normal by Gmail SMTP services.

I'd double-check in GCDS that you've not typo'd the FQDN of your domain controller to miss of the h. For the LDAPS certificate gubbins, we've had to do the following because the domain controllers' LDAPS certificates are issued by our own internal CA. The bundled Java runtime needs to have the CA cert added and then ahave a couple of checks disabled. This has also needed to be repeated after updating GCDS. The required certificate will be the public root CA certificate for the certificate authority that issued the domain controllers' certificates. On the server hosting GCDS, copy the certificate to a temporary location and open an administrator prompt. Run the following commands: cd "C:\Program Files\Google Cloud Directory Sync\jre" bin\keytool.exe -keystore lib\security\cacerts -storepass changeit -import -file C:\your_CA_cert.cer -alias someAlias_CA N.B. the default keystore password is literally "changeit". Then, edit these two files… C:\Program Files\Google Cloud Directory Sync\config-manager.vmoptions C:\Program Files\Google Cloud Directory Sync\sync-cmd.vmoptions …to add the following lines: -Dcom.sun.net.ssl.checkRevocation=false -Dcom.sun.security.enableCRLDP=false

GCDS encrypts the config file that it stores all your sync config into. It can therefore only be opened or used by whatever user account it was originally created by. We have a dedicated AD account that we use for all things GCDS. I don't know if that explains the error message you've shared (i.e. attempting to open the config from a different user account), but something to bear in mind when putting together your setup. Exclusions take a bit of careful consideration in GCDS, as you need to be sure whether it's AD items being excluded, or Google Workspace items being excluded. If you've got a whole bunch of existing Google accounts that you don't want GCDS to touch, you ought to be able to set exclusions in GCDS to ignore whatever Google OUs and Google Groups that it should just ignore and leave alone. Generally speaking, in GCDS parlance, I think exclusions will be referring to excluding Google items from being affected, and search rules will be referring to which items from AD to work with. RE: LDAPS, AD these days I think is going to require it (or at least, it's highly recommended). GCDS will be able to do cope with that, but there are a few certificate-related hoops to jump through in order to make the Java stuff happy. There will be posts about that on here somewhere, but happy to share my notes on that with you. It's something that you would need to repeat whenever you install a new GCDS version, also.

We do it by setting registry items under User Configuration. Chrome and Edge then both take their cue from that, so we're not setting anything browser-specific. This guide looks like it covers it, although in addition to setting ProxyEnable, ProxyServer and ProxyOverride, we also set AutoDetect. Doing it this way, you can also make use of item-level targeting to get clever with different proxy settings for members of certain security groups, etc. if needed, all in the same GPO.

Could browser or proxy cache be behind that phenomenon?

I went crazy during lockdown and wrestled with QGIS until I had something good. The scale will be completely out of whack and not at all correct in terms of proper GIS work, but the various options for layers and labelling was nice and powerful. I worked from architectural plans originally, importing images of those to then build up floorplans in various layers over them. I have corridors, stariwell, etc. in separate layers to the rooms, so that they can be shaded differently. That helps to make a readable map, when it's clear where the internal corridors are compared to outside spaces. The rooms are each separate shapes within a layer, and with their respective names in metadata. Map labelling rules then govern how/when those labels are displayed on the map.