chaplic

if they have a stale entry for the user with an invalid x400: address present, it absolutely does matter and would cause this behaviour. I can't think of any other cause, but all the best with MS.

why do they need a personal contact at all? delete it, and in the to: field start to type their email then when the system suggests the address, press the X at the end of it to delete the address and re-type it.

Do they have that person as a contact in their personal address book, which also has an old x400/x500 address associated with it? nuke the contact

it's really, really unfriendly for any sort of corporate style internet. If you can put it on a guest wifi with no captive portal and any-any outgoing it's fine.

plumbing wise this is what to do : A service principal would be created in the same azure sub as ACS with the rights Microsoft.Communication/EmailServices/Write Microsfoft.CommunicationServices/Read Microsoft.Communication/CommunicationServices/Write In O365 Id have a connector triggered by a transport rule. The connector would ship mail to smtp.azurecomm.net. The username is ACSName.ApplicationID.TenantID and the password the secret key, relevant to the service principal and ACS instance above From there, we just need a transport rule to determine what to send down the connector However, re-reading your requirement this is complete bobbins as it will still count these as outgoing messages. Emails to accepted domains are not counted. So you could have @list.myorg.com as an accepted domain but sent to internal relay, then a route to Exchange on prem where the DLs are held (and not synced to Office365). This would have a similar connector (not transport rule generated) to send to ACS. Then in O365 you have contact object representing the DL on prem. Wrap around it some controls so that unauthorised users cant use it. It's a pretty crappy solution...

Microsoft has Azure Communication Services (ACS) which does just that, and it makes use of the Office 365 SPF ranges. And can do basic auth It has some rather interesting oddities to it, but does the job (if you happen to be in Glasgow, I’m speaking about it in a few weeks!)

You can write a scheduled task thats triggered on change of network. Script that runs then decides if it can see the school proxy, and if so, turns it on..

I had a solution for a while where I deployed IIS running locally on each PC, and hosted the proxy pac on that, then configured pac settings as http://localhost/proxy.pac. The pac file also made use of myipaddress to determine if it was in school (as the subnets in use there were unusual). Sounded bonkers, but it worked. intune can configure the proxy settings per WiFi (so I assume will be doable other ways) , so if you can get away with simply proxy exclusions and not need clever pac stuff then that could be an option as could a remote web server with the pac file making use of myipaddress.

My biggest piece of advise would be get on and do it, go play. Vnet, NSG, ASG, RSG, RG will all start to make sense after you've built a few things and if you are careful need not cost much, certainly far less than any formal training. For example, build a dummy on-prem server and download azure migrate to migrate it, creating a subsciption ,vnet, subnet and resource group to host it, and see the various bits and bobs it creates Create a site-to-site VPN to an azure VPN gateway Create some vnets and peering and route traffic between then Create two webservers and load balance with azure load balancer.

This is either the domain set as UPN in question isnt registered in azure AD, or something has gone funky ad there's a clashing account name. As it seems you have multiple domains, I wonder if someone had previously written a custom rule to remap upn to another field. For example if domainA has school.com then domain B cannot have school.com as well. but you might want that for logins into Office365. So in DomainB decide on an attribute for UPN (e.g. Extensionattribute1) and map that to UPN for that domain Looking at an affected user in the sync service may render some clues, as would a full dump of all AD users and fields in the problem domain

Chances are a legit system is sending some emails to your mail server, so look at incoming emails with a from address of your domain.

You haven’t indicated a wish so receiving mail servers will make their own mind up. In my experience, you tend to get some background noise of spoofers using your domain especially if you are a well known domain, but a repeated attempt from the US sounds legit, if poorly setup. Could you track emails to you from these IP addresses to see if it gives a clue.

Well, I'm a consultant and, yes I'm in it for myself. Which is why it's baffling to issue a fundamentally flawed 'make do and mend' piece of advise as you're never going to get much repeat business from a school even if you say what they paymaster wants, and why on earth would you issue such advise that's got a real, tangible, possibility of blowing up in your face. Of course we dont know a) why said consultant was chosen (it does feel like dave built his own gaming PC) b) what the scope/ question was asked c) what the actual advice was

This is not true. The latest CU of Exchange 2019 allows powershell cmdlets to be run without an Exchange server, meeting the criteria for using a supported tool as per that link, but not needing an Exchange server. In decommissioning the last server is not uninstalled as that removes various buts of config still needed.

You dont need to be in exchange hybrid at all if you dont want/ make use of if for things like smtp relay or perhaps critical the rules that auto generate email addresses if thats not done by third party tooling At this moment, your exchange 2019 environment is basically a gui to AD for modifying email properties (and this remains the same post removal of HCW). I would move system mailboxes to them and decom 2013