jthompson

I've never tried it, but I'm wondering if Windows SMTP Server might solve this problem for you. e.g. https://phoenixnap.com/kb/windows-smtp-server. Configure that on one of your servers to accept messages from your FSRM server(s), relaying them on to the Google service. Never used it myself, since we've already got a postfix server running that serves this purpose.

We run an on-prem postfix server which is basically relaying up to a Google SMTP relay service. Postfix configured to not require any auth, but to accept incoming connections only from certain local IPs. It then relays up to Google, using a generic account from our Google domain to authenticate. As long as the on-site stuff (like FSRM) that can't do the auth are pointed to the postfix server, and the sender address includes our domain name, it all works. I originallyworked from this guide: https://www.howtoforge.com/tutorial/configure-postfix-to-use-gmail-as-a-mail-relay/

It might be simpler than that, even. https://support.google.com/a/answer/176600?hl=en&fl=1&sjid=4498946212216932989-NA

In Google Admin, you can create an "SMTP relay service". https://support.google.com/a/answer/2956491?hl=en&fl=1&sjid=4498946212216932989-NA There are various options available when configuring an SMTP relay service, most of which are security-related, with Google nudging you away from having the relay service left too open. It's worth having a generic user in your Google domain that you just use for authenticating with the mail relay from your onsite systems that need to send mail. Turn on 2FA for that account and then create an app-specific password (which is what you'd then configure onsite systems with that need to authenticate with your Google SMTP relay service).

The extra MS rule isn't listed for us, but then we haven't received that email, either. Hopefully it's still going to be configurable to 'OFF' even with our licensing.

If this is for Windows machines, Group Policy might do it. Just looking in the Google Chrome administrtive templates and I can see a setting named "Configure the color of the browser's theme" which if configured will lock users out of changing the colour. There's also a setting named "Allow users to customize the background on the New Tab page". If managing the browsers from the cloud, the equivalent options are "Admin > Devices > Chrome > Settings > User and browser settings > General > Custom theme colour" and "Admin > Devices > Chrome > Settings > User and browser settings > Start-up > New tab page background".

It would be nice if the location-based conditional access was available without having to pay for it. Then they'd have a significantly higher uptake of 2FA, since that's the only reason I haven't got it turned on for student accounts yet.

I'm not familiar with your application at all, but that looks like it might be a .NET issue. Maybe the version of .NET currently required by the app isn't present on the server?

Oh, and you'll need to make sure that your domain's DNS stuff includes the bits needed for Gmail to be able to send successfully (adding Google's bits for SPF, etc.).

Hopefully that works and your test users discover far less spam waiting for them.

Not too familiar with 365 on the mail front, but you 'll need to see whether you can configure 365 with some kind of transport rule that will route mail for those particular users onto Google. Something like option 3 from this article (https://support.google.com/a/answer/176600?hl=en&fl=1&sjid=14219050958726383395-NA) whereby you route the message on to aspmx.l.google.com and google will then just route the messages internally to the relevant Gmail mailboxes. That's assuming that your 365 and Google domains are using the same domain name. Gmail will need to be enabled for the users, otherwise things will bounce.

And in case management still want the old domain killed off, you can kinda do that by adding rules to quarantine or reject emails sent to it, whilst retaining the option not to should the need arise!

Possibly that was felt to be the 'cleanest' solution? As long as you control the old domain name and can update its DNS and MX records, you can add it to your Google tenacny as a domain alias. When you do that, Google will give you a wizard spelling out exactly wha DNS changes you need to make, and will confirm that it's set up correctly, etc. Every user in your Google tenancy will then automatially get an alias with that other domain, so that emails to their old addresses will arrive in their Gmail mailbox as normal. You won't need to do anything on the 365 front I don't think. 365 will simply stop seeing email arrive, so you can leave that old domain attached to it no issue. Plenty of schools have the same domain name registered with both platforms.

Yeah, so I think you'll be wanting to match your old domain in "Any envelope recipients" for incoming emails. Prepend the subject with [olddomainname]. Nothing too cumbersome since it'll get included in any replies/forwards that people send thereafter.

Would advise considering that, too. A bit of setup but it softens and solves your problem for good, and gives everyone an easier time of it.

I'd have thought that the messages you want to match will have been sent to the old domain, not from it? If that's the case, you' may need to match against "Any envelope recipient" rather than envelope sender.

Yeah, that's specific to the Admin console pages and likely not configurable.

Looking again, why would a dynamic group not suit? The "Parent organisational unit" condition would likely give you what you want, and at a quick glance I can't see that the other available group properties differ from regular groups at all.

Not that I'm aware of, no. I just do it using AD groups synced to Google Groups via GCDS. We maintain lots of groups, particularly for staff, so it's not really any extra work for us to also include those bigger groups which could otherwise potentially map to OUs. If I was wanting to automate an OU > Group membership mapping, I'd definitely look to use Apps Script. I appreciate that you're not really wanting a scripting solution at the mo, though. I already have a function which fetches users' details for a particular OU (only about 20 lines), which would be the first step. Syncing that list to a Group's membership wouldn't be much more complicated.

Interesting that name changes are a sticking point for some. We've documented the manual changes that we need to make whenever a name change occurs, and whilst there are a few things to do and one or two systems need an overnight sync to catch up, it's pretty painless. IMHO it's worth observing that people don't change their name if it isn't quite important to them, so. We write MIS IDs and admission numbers into Active Directory when provisioning accounts, which can help a bit on this front with custom scripts that we've got going on. We either script against MIS ID, admission number or Wonde ID.

What's that guy photocopying?

Our users' accounts, and therefore their email addresses, have a display name of Firstname Lastname. Anything else would get a bit chaotic, I think. Annoyingly, that means that it's also in their public Google profile, too. In theory, that's not going to appear outside of whatever systems the school is using anyway, and students emailing randoms on the Internet is not really a display name issue.

For the 'special' folders that you've added in in recent times, you can get away with moving those out into separate, distinct shares, which you then present to users via shortcuts in a 'main' share, rather than as additional mapped drives. For each of those, consider creating dedicated security groups that you'd use for providing either read or write access to them. For instance, for an "SLT" folder, you can have that as its own share, with a couple of dedicated security groups (e.g. "fileshare_slt_r" and "fileshare_slt_rw") granted privileges to it in both the filesystem and share ACLs. You would then add users to the relevant security groups as required, so that you'll never have to adjust the folder's ACLs ever again. Ideally, you can add another layer of abstraction to that by instead having security groups representing roles in the organisation (e.g. "role_teacher", "role_slt") that will make managing the membership of those "filesystem_..." security groups even more hands-off.

I'm sure I won't be alone in this, but there are times where all I want from a product website is some actual screenshots of the product, but instead you get those Corporate Memphis style cartoons. It's particularly annoying in video form, where it typically has a ukulele accompanyment and far too much bon-homie for a UK audience. For instance, what is going on here?! Answer: it can produce invoicing, apparently, but who knows what that might look like.

Whatever you choose, I'd recommend scanning through any list of new usernames with human eyeballs, just to pick out any unfortunate P00, etc. that might need a bit of tweaking before being distributed.