jthompson

A browser profile for my work account serves that function for me, as well as having an Android Work profile turning on/off on a schedule. When I close my work account Chrome profile, I'm done.

For surnames we remove any spaces and truncate it to 12 characters.

Almost the same here, but we add the final two digits of their admission number to the end as well. We'd have had a few name clashes in recent years without those extra digits. Two J Smiths being enrolled at the same time would become 23SmithJ54 and 23SmithJ55, for instance. If another J Smith joined that cohort later and happened to end up with an admission number ending in 54 or 55, then we'd just pick some different digits to use at random instead. The extra digits also help to prevent anyone 'guessing' at email addresses, since they're essentially arbitrary. Staff therefore have to use the directory and are less likely to make addressing errors.

WUfB isn't really geared to servers. Machines running Windows Server won't appear in the stats, for instance. Azure Update Manager would be the server equivalent of WUfB. That will give you dashboard reports for checking compliance and what updates are pending, etc. You can either schedule auto-installations via that, do them manually, or some combination of both (e.g. autoinstall definition updates each night, autoinstall critical updates each weekend, and leave everything else to be done manually). I gave up ages ago with holding updates back on servers. Even when still using WSUS, it was auto-approve for critical and security updates, with a 7-day deadline and a weekend install window. At which point there's no real need to point servers at WSUS any more. Regarding having different auto-install/restart schedules for different servers, that could be achieved using GPOs targeting different servers as required (regardless of whether they're being pointed at WSUS or not).

Am seeing a smiilar lack of matching details on quarantined messages. Not exactly as you've shown in your screenshot, but here's a couple of examples: one shows a matching reason (albeit lacking in informative specifics) with another being blank.

Admin > Apps > Google Workspace > Gmail > Compliance > Content compliance. Create rules there (they can either be at the root or at a specific OU). Rules include an option to quarantine matching messages. A rule can be set as disabled, but then overridden to be enabled at a child OU (or vice versa), which offers another layer of logic to rule building.

Yeah, I get that. I'd have preferred Google groups to by more akin to vanilla distribution lists by default, but with the option to extend them to have web posting, digest options, membership requests, etc. rather than the other way around. There's one option which you'll want to be aware of that still isn't available in the gui afaik. That is the option to prevent members from removing themselves from a group (quite important in a school). That's still only available to set via the API I think (i.e. using GAM). As janky as it might at first seem, don't let that put you off Google Workspace too much. IMHO it's a noticeably more cohesive and better documented admin experience than Microsoft's, even if not quite as flexible at times, and Gmail's spam-filters are in a league of their own.

You can allow users to opt in to SSO against Microsoft or Google accounts, which makes things simple, but their manual SIMS ID login remains available, so they'll still need to have 2fa enabled for them in SIMS ID, I would say. That would mean that when signing in using SIMS ID creds, they would be prompted for 2FA, but if they choose the MS/Google sign-in option, they just go straight in. In SIMS ID, you can set 2fa as mandatory for everyone or just for select groups and/or users, so it's nice and granular on that front. The 2FA options are T-OTP or memorable passphrase (e.g. charaters 2, 4 and 7 from a passphrase). https://id.sims.co.uk/support/wiki/46

Maybe before restarting the host, just try restarting the Hyper-V management service instead? Shouldn't affect any running guests. I've not encountered that particular issue in the OP before, though.

The built-in spam/phishing rules in Gmail are kept deliberately opaque by Google, I think. If you were to add some specific rules of your own that directed mail into a quarantine, then you would likely see those rule names listed in the matching info. Here's an example of a message quarantined by one of the built-in rules (we have enhanced spam settings turned on). And here's one quarantined by a custom rule (a rule named "Students - Quarantine Twitter"). Doesn't really explain why you're not seeing any rule name there. Maybe a browser page issue? Clear cache or test in a private window?

Google Groups are a bit strange if what you're used to is Exchange-style distribution lists. By default they are web-based discussion boards, and so to use them like distribution lists instead, you have to turn off web posting and conversation history. If you want org users who aren't necessarily a member of that group to be able to send mail to it, then you can use this workaround - /forums/cloud-services/224024-google-gmail-allowing-teachers-send-year-group-distribution-lists.html

I must admin that I thought that it was, but it looks as though Chrome Sync isn't available to select for in Context-Aware Access (i.e. you can't actually say that Chrome Sync becomes unavailable if a device isn't company-owned and/or admin approved). If you wanted to allow sync but prevent passwords from being included, the option for that is Admin > Devices > Chrome > Settings > User and browser settings > Other settings > Chrome Sync and roaming profiles (Chrome Browser – Cloud managed). Set it to Allow Chrome Sync but tick to exclude Passwords. There's an equivalent option alongside it for Chrome Sync (Chrome OS), too. Drive for Desktop also has an option to limit it's use to company-owned devices.

If I was feeling ungenerous I'd quip that 80-90% of compromises involve a Microsoft email account at some point too, on the attack and/or target side. I can't cite any actual stats, but it feels about right. We're not big users of M365 here, and so our licensing doesn't include the sorts of security features that Microsoft will be promoting as essential in order to actually operate securely. Conditional access and endpoint verification stuff will help to allow 'safe enough' use of unmanaged devices, I should think. Like "refuse sign-ins from devices with an unsupported OS". I, too, would be interested to here from those who are actually doing this stuff.

Making use of managed devices and endpoint verification can help keep things clean and tidy on this front. The usefulness of Chrome sync is fairly massive.

This can be fixed. You'll need to update the ImmutableID of each of the affected O365 accounts with the ImmutableID of their new respective local AD accounts. This will match the Azure accounts back up with their new local counterparts, and your syncs will then be happy again. From your local server with AD management tools installed, run the following. You'll need to have a working web connection available, so that PowerShell can talk to Azure. Import-Module ActiveDirectory Import-Module AzureAD Connect-AzureAD The save the following as a ps1 script and run it. Adjust the value of $OUpath to be what you need (assuming that all your affected accounts are in a particular OU.) $OUpath = 'OU=Intake2023,OU=Students,DC=your,DC=internal,DC=schooladdomain,DC=tld' $users = Get-ADUser -Filter * -SearchBase $OUpath foreach ($user in $users) { $immutableid = [system.convert]::ToBase64String($user.ObjectGUID.tobytearray()) Set-AzureADUser -ObjectId $user.UserPrincipalName -ImmutableId $immutableid }

This news did sadden me when i saw it. I've watched through the whole of Friends a couple of times in recent years, and I still find it a good watch. The gender politics and social attitudes at times has not aged well, and the women are noticably 90's thin, but the cast are so good.

That makes sense. Our www CNAME points to a name for our website host, but our domain root has an A record pointing to their IP. For a larger-scale hosting provider, I can see why relying on an IP address remaining static could end in something breaking when IPs get churned about. I think the OP was specifically asking about having an A record on the domain root(s) and whether that would break anything for them. I can only see it breaking something if they're already needing those naked domains to point to somewhere else, which I suspect that they're not.

A CNAME on the root domain? Doesn't that wipe out any A or MX records also on the root?

The MX records for your domain(s) will govern where emails are routed to. Other related maily things like SPF, DKIM, etc. will have their own specific TXT records, so none of that will get upset by the changes that your web-hosting provider is suggesting. We have a bunch of different things all hanging off our domain name: our Google and M365 tenancies, as well as additional DKIM records for other mail senders (sendgrid, freshworks, etc.). Our naked A record points to our website host.

I'm not an expert in this by any means, but as I understand it from discussions with our data manager, some things need to be retained until an individual reaches a certain age, rather than imply for X years after they leave the school. Probably not much difference for most in practice, but worth noting the distinction. Regarding staff emails/files, the retention period for those may depend on the role(s) they've held.

Is that the user that your volume licensing contract was registered against? If not, try it under that account instead.

I can see ours in... admin.microsoft.com > Billing > Your products > Volume licensing > View downloads and keys.

Have a look at Azure > Microsoft Entra ID > User settings. The toggles under the heading "Default user role permissions" might be governing this behaviour.

We're primarily a Google school, too, but have an M365 tenancy with accounts for everyone. Accounts are synced using Azure AD Connect (or whatever it's new name is). We minimise the use of 365 but there are a few things where we make use of it (PowerBI being one). It also means that external Teams invitations are a little smoother. The way we do it is to have a staff group on 365, apply the 365 faculty license to that group and then toggle the various apps on/off within that. Azure > Microsoft Entra ID > License > All products > Office 365 A1 for faculty > Licensed groups > {assign to a suitable group to include all your staff} > Select the group name > Licenses > Office 365 A1 for faculty > toggle all your options to disable/enable features (the key one for you being to disable 'Exchange online'). You can do that same for student accounts, if you're also including them in your tenancy. Not sure if that solves your SharePoint/OneDrive shadow file storage problem.

Yeah, this is the vibe I'm getting from fruitless web searching.