When you’re using Office 365 and want to send an email, you have two choices SMTP or Microsoft Graph API, which is a “new” kid on the block. For some time, I’ve used Microsoft Graph exclusively to send emails in favor of SMTP as it’s much easier to manage and generally works over HTTPS. If you type in google “Send email graph API PowerShell,” you will get lots of hits as bloggers, and Microsoft has already covered this topic. It’s even more critical than ever because Basic Authentication is deprecated in Office 365. To help out with the transition, Microsoft even released its PowerShell module. With Send-MgUserMail proposed as a way to send emails via Graph API, you will notice it’s far from being easy & user-friendly. Over two years ago, I released a PowerShell module called Mailozaurr (some people may not like my modules’ naming – but that’s how I roll!). In a blog post, Mailozaurr – New mail toolkit (SMTP, IMAP, POP3) with support for oAuth 2.0 and GraphApi for PowerShell, I’ve shown a basic functionality on how to send emails using SMTP OAuth 2.0 or Graph API, which aims to be drag & drop replacement over Send-MailMessage and is supposed to be as simple as possible to send an email with a low effort and high readability. You can also read on sending emails using Graph API by Tony Redmond in his blog post Moving on from Send-MailMessage: Sending Email from PowerShell using the Graph API.
I’ve been managing mail service for users for a lot of years now. I don’t do it daily but I’ve spent my fair share of time analyzing spam emails. Mail vendors are doing what they can fighting spam, but it’s not easy. Each month, each year spam is getting more sophisticated. Spam emails either look like a legit email, or worse someone is targeting your company trying to get them to transfer money into a wrong account. While most of those end up in spam, there are those that come thru. It’s even worse if the company you work with has not implemented SPF or their SPF is configured to soft fail which can’t be treated as spam.
One of the tasks I often get when setting up new Office 365 tenant or installing Exchange Servers is to change the visibility of Room Mailboxes or in some cases even standard users. There’s nothing hard about it, and there are plenty of articles about it. It’s just three simple steps.
Recently I’m doing yet another migration between Office 365 tenants using Bittitan Migration Wizard. It’s a great tool and takes away a lot of headaches when dealing with the migration of mailboxes or OneDrive data. Unfortunately, like with many blogs on my website I had to hit yet another error. This time error occurred when I tried to assign User Migration Bundle license to users on the Migration Wizard.
Working with Office 365 is my bread and butter in the last few months. I’m a System Architect and I am dropped in multiple projects, both new and old, to fix certain aspect and get out before anyone sees me. One of the common tasks I get is to provide some data about users stored in Office 365.
Last few months I’m responsible for the migration of Office 365 to Office 365. While doing so, we came into a situation where users have their old mailbox as Primary Account and new Mailbox as their secondary account. This is a quite common scenario that people are running into and something that is expected. Usually, my recommendation is: Please create a new profile for user and topic is closed. It’s also quite easy to achieve this in an automated way where you delete all profiles and Outlook just goes with autodiscovery adding new account as required. That’s how I have always done this till now. My Client has gone thru setting up 1000+ users with their second account in Outlook and deleting a whole profile, recreating would cause lots of downloading of emails from Office 365 that my Client wanted to avoid.
Last few weeks I’m responsible for migrating from Office 365 to Office 365. Part of this migration process is to set up new Exchange 2016 server that will work as relay instead of using IIS server. I’ve setup hybrid, added accepted domains, prepared connectors, but there’s one thing missing. Any time an email is sent via relay to a user that exists on Office 365 and at the same time exists in Active Directory email never gets there.
MigrationWiz from Bittitan is one of the best tools on the market allowing for migration of user mailboxes. Whether it’s a google account, exchange account or IMAP, it will help you out. Last few months I’m part of migration project that is using Bittitan at its core. One of the signature features of this tool is the ability to migrate mailboxes from Office 365 tenant to Office 365 tenant. This is not something that every application can do. Another feature (and something I want to address today) is the ability to ask users for their logins and password to migrate their data from one tenant to another tenant. While in general, you shouldn’t do that and you should use migration accounts with proper permissions sometimes you have no other choice.
It’s been less than 24 hours since I’ve released PSBlackListChecker with support, among other improvements, for Microsoft Teams and Slack and I’m now adding Discord to the mix. Discord was a popular request (well not really, just one person asked, but let’s pretend everyone loves PSBlackListChecker so much that they are too shy to ask for feature requests!).