jthompson

That took me a while to spot.

This is a cut-down version of a script I use. Save it as resetPassword.ps1 and use it like in the example block. Test it first, obviously. <# .DESCRIPTION Script to reset the password for user accounts based on CSV input. .PARAMETER InputFile The path to a CSV file containing the details of users and passwords to be applied. The CSV file must include columns named 'Username' and 'Password'. .EXAMPLE resetPasswords.ps1 -InputFile users.csv #> [CmdletBinding()] param( [Parameter(Mandatory)] [string] $InputFile ) $Users = Import-CSV $InputFile foreach ($User in $Users) { if ($User.Username -and $User.Password) { # Username and password are both present in the row. Set-ADAccountPassword -Identity $User.Username -Reset -NewPassword (ConvertTo-SecureString -AsPlainText $User.Password -Force) } else { # A username and/or password is missing from the row. Write-Host "A row of the input file is missing a username or password". } }

That code is all on one line. Is it like that in your script? I wonder if it's reading the Set-ADAccountPassword command as part of your ConvertTo-SecureString command (i.e. not on a new line).

Yep, I would agree about carefuly setup. If I were setting up a new GW tenancy today, I'd be going through every single option in turn and working out what it needs to be set at for each OU. But then I say that without being able to actually point to anything much in particular, as it turns out, since I haven't built a new Google domain for years. So I don't know how helpful that is for this research!

Google Workspace certainly has a feel of being too liberal by default. It feels like Google have designed it with the assumption that users are responsible, professional, adult employees, so things are allowed by default unless more restrictive configuration is opted for. As schools, we prefer to work on a "restrict by default" basis where users can not be considered to be particularly responsible agents. The biggest issue for me is that all of the various kinds of third-party add-ons, extensions and apps that can use Google Workspace data are allowed by default, when schools really ought to have all of that restricted with an allowlist. That's mainly a data protection thing, but it's also a security thing as well. It would be easy for Google to block all of that and then allow admins to opt in to third-party integrations. I can imagine Google having a strong business case for not doing that, however. Edit: I take that back. It appears that third-party apps are blocked by default for Education tenancies. https://apps.google.com/supportwidget/articlehome?hl=en-GB&article_url=https%3A%2F%2Fsupport.google.com%2Fa%2Fanswer%2F6089179%3Fhl%3Den-GB&assistant_id=generic-unu&product_context=6089179&product_name=UnuFlow&trigger_context=a Another example off the top of my head is Admin > Gmail > End-user access > Automatic forwarding, which is on by default. Perhaps more of a data protection thing again, but an example of a default configuration being too liberal for schools. I can't remember what the default configuration is for Drive/Docs sharing outside of the domain, but if that were to allow sharing outside of the domain (or collaboration on external content), then that would be too liberal as well. Gmail security can be tightened up in various ways. The various anti-spam settings are not especially strict by default. Some of the Gmail security is not really able to be done by Google alone, though. DKIM, DMARC and MTA-STS are all things that schools can definitely benefit from, and tbf Google does a good job of promoting those features and guiding admins through getting them configured.

Similar here, although more aligned with use cases: Computers - Classrooms - 01 - 02 - Offices - Careers Office - Exams Office - Staff Laptops The idea of having security groups for each of the user roles in school is a good one. We adopted it a few years ago and it offers loads of flexibility whilst at the same time meaning far less fiddling with GPOs and file provileges whenever personnel changes happen.

I'd recommend each piece of software that's being deployed via Group Policy to have its own GPO, that just deploys that bit of software and does nothing else. Same for printer deployments. Mapped drive assignments can make use of item-level targeting, so your Inventry drive, for instance, although applied at a high level, might only be getting applied for members of a particular security group. That's an okay way to do it, assuming that the security group(s) being used are also reasonably manageable.

For me, I like to have GPOs separated out and named according to their function, with a reasonably consistent naming convention. Some examples: AppLocker - General BitLocker - Allow adding of BitLocker protection to removable media Drive Maps - Staff Drive Maps - Students Power - General Defaults Power - Exam Computers Keep Awake Software - MuseScore Students - Windows Lockdown Web Browsers - Google Chrome - General Computer Settings Web Browsers - Google Chrome - General User Settings Web Browsers - Students - Site Notification Settings Windows - General Computer Settings Windows Update - WUFB - Fast Rollout So you could work through your existing GPOs and duplicate their settings in a new set of more granular GPOs, rather than starting from scratch. Once you've done that, you'll have hopefully ironed out the sort of messy duplication that you're currently plagued with, and you'll have an easier time of knowing what each GPO is actually doing.

To update this for the version being seen currently (e-Marker2®-e2-p-010), we've needed to add one more AppLocker rule. The rule is a script hash rule. During a failed installation, follow the error message to locate the install.log file. Alongside install.log will be EULApackage\EulaAccepted.bat. Add that bat file to the AppLocker script hash rule. The batch is a one-liner that literally just runs echo "Successfully Installed". The latest version of the other variant, CMIPlus Marker, is still an MSI that installs to Program Files, and it still requires TLS 1.0 to be enabled in order for the user to sign in, etc.

I wonder how many people within Microsoft are begging them to get on with making Edgebooks already. A more constructive comment from me would be to say that this looks to be trying to replicate the sort of device management experience we get with Chromebooks, which can only be a good thing.

My old Fiesta had a gap at the rear of the handbrake lever just large enough for the keys to slither down out of reach into the dark underworld below the actual interior. This happened to me in a [busy] car wash. Thankfully one of the attendants found a length of electrical cable that they fashioned into a hook to retireve them, and therefore unblock the car wash.

AQA stipulate that it needs to either be BitLocker or a zip file encrypted using 7-Zip with AES-256. They specifically say not to use the ZipCrypto option.

Agreed. Besides, I reckon that regular, more gradual shifts are perceived less in the long term than larger, less frequent step changes.

I imagine that the former example would be more effective as a means to trick people, since it's also attempting to undermine users' hover checks. RE: real world. No, probably not actually worth my time working on blocking stuff, but I guess I'd like to know that I can get in ahead of any black swans (i.e. be able to allowist domains of particular TLDs).

Annoyingly, the Chrome/Edge URL blocklist policy option can't be used to block a particlar tld. The wildcard isn't flexible enough to match *.zip and will not accept it as a valid pattern. Could block it at the network level but that won't do anything when devices are being used off site. We don't have cloud filtering.

I appreciate that there are tonnes of TLDs out there, but it's the .zip one in particular that has a huge scope for misleading end users.

But then that would allow http:// dontclickonme .zip

I agree, but it would need to be done in such a way that only .zip domains are blocked, not example.com/file.zip.

Reading that, I'm wondering how browser policy options (specifically, this https://www.chromium.org/administrators/url-blocklist-filter-format/) will work to block *.zip as a match to just the host portion of a URL, but not match against the path portion of a URL (which could block legitimate zip file downloads).

Seeing quite a few articles this morning reacting to the news that Google is now offering .zip as a TLD. https://domains.google/tld/zip/ My first reaction is to imagine new phishy ways to trick people into clicking on "pictures.zip" to download malicious files without having to get a malicious file attachment delivered to their mailbox. Perhaps blocking .zip URLs in filters and browser policies to head off any such tactic? EDIT: but that could prevent legitimate zip file downloads.

My car has a button inside the top of the gear stick that when I press it machine guns pop out of the headlights, and when I drive it into the sea it turns into a submarine.

Not sure how to generate barcodes in Excel, but Google Sheets has barcode fonts that make it easy to format cell data as a barcode: http://www.edugeek.net/forums/how-do-you-do/177638-one-line-very-brief-helpers-13.html#post1969613

Admin > Directory > Users > [user] > Security > Security keys

Same. We're using the 'gateway server' method of deployment: https://learn.microsoft.com/en-us/windows-server/manage/windows-admin-center/plan/installation-options

I don't believe that users can set any preferencial order for their 2SV methods. I've never encountered Google Prompts going off on a Chromebook before though. Is that because you're running Android apps on your Chromebooks? N.B. you can always select an alternative method during a sign-in, but I guess you'll know that already and are just wanting to avoid users having to do that.