And what I specifically was hoping someone had a link for was to MS's license or T&C saying that "no you can't share an account for multiple people".
Obviously this doesn't exists since the way the software is procured is per user.
Right, they won't repeat it because they have it in writing already. But you can always show that it is 1) assigned to a named user 2) at the time of procurement you have to agree to a single human.
That messages means a lot of things but yeah Whitelist on their Spam Filter end, Adding your IP to your SPF record, check if there is anything on the body of the message triggering the block on their end (i.e. URL or site link).
It is Office 365 with Exchange - I have created all the records that Microsoft wanted me to.
So, just to be clear, this is 100% not on my end, correct?
It shouldn't be on your end, the message is coming from the recipient's end server.
I believe if PowerShell is your method, you will not be able to do what you are trying to achieve. The only way now is to use the one that has just been advised.
Now that we can mark them, I'm going to slowly try to work through getting them all closed.
I was going to unmark as question - since it was so old. I don't know if you can do that, but on topics of a certain age, you may do this rather then bringing them forward.
I like the ability of a OneNote document, hosted in SharePoint, but don't like the lack of organization of it. I like Wiki's for documentation, because you can browse the wiki, copy/paste to/from it without accidentally deleting content. Once multiple people have their hands on a shared OneNote, in my opinion, it just becomes to easy to accidentally delete something.
That's one of the reasons why I'm looking for a 100% client-side wiki that just uses HTML5/JS. Just place that into a SharePoint doclib/dropbox/whatever
Not a bad idea.
Plus we don't need any proprietary software like OneNote, just a modern browser. Don't get me wrong, OneNote is a great tool, but I would like to have a wiki for my core documentation / admin KB.
I don't look at it as bleakly as you do. You in no way told the receiver they couldn't receive it, you told them they have to use a different method to receive it. Is it a good experience - I'm not going to argue that point, frankly I don't care as long as it works.
But you did... you sent them an email and the email didn't include the payload, it told you to go look in another system for the payload that didn't arrive (the princess is in another castle.) Why did you need the email if email isn't delivering the message? It's obviously similar to failure... two systems are being used for a single thing. All they want is the payload, not a message telling them about a payload elsewhere.
We ran into this issue again after updating to the most recent version of Azure AD Sync. We needed to set the mailnickname attribute in AD for the mail users to be created again. This was in addition to having the targetAddress declared.