Microsoft Exchange – Connecting to remote server failed with the following error message

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.

Recently there was this discussion on PowerShell Group on Facebook about issue posted by one user. While the subject doesn’t matter for this post, few people commented on the idea that he was using Format-Table in the middle of the pipeline to do something. They all said Format-Table should be used as last in the pipeline. Otherwise, you would get the wrong output. But should it? Well, it depends!

In Active Directory when you change something, it’s replicated to other Domain Controllers regularly. It’s a standard procedure that happens automatically in the background for you. It’s a handy feature because you can have multiple DC’s all over the world and have your users data in sync. You can change almost anything on DC nearest to you and be sure it will be the same value all over the place. But is it always the same? Well, it should be unless it isn’t. Today I was given a new migration from  Exchange to Office 365. I started with ADConnect installation and wanted to make sure that UserPrincipalNames have all UPNSuffixes in place.

I work a lot with Active Directory-related tasks. One of the tasks is to know the group membership of critical Active Directory Groups such as Domain Admins, Enterprise Admins, Schema Admins, Event Log Readers, and a few others that are a bit less known. As I did it, I got bored of typing the group names repeatedly and decided that enough was enough and there must be an easier way for me to do that.

I had this little issue today when I tried to schedule the Microsoft Graph script to run as a service account on a certificate. To my surprise, even tho I had all permissions required, I was getting this error message: Connect-MgGraph: Keyset does not exist. Something that didn’t show up for my user.

Azure AD Connect allows three ways to make sure the user password is the same in Active Directory and Office 365. Those are Password Hash Sync, Pass-Thru Authentication, and ADFS. While my preferred option to go with would be Pass-Thru Authentication, only Password Hash Synchronization is the easiest and least resource-intensive. It synchronizes user password to Office 365, and even if your Active Directory is down, you can still log in to Office 365. It’s perfect for small and even more significant companies that don’t have resources or can’t guarantee that their infrastructure will stay 100% time online so users can authenticate based on their Active Directory.

I must admit that it was a bit embarrassing to see my Administrator password expired when I tried to log in as Domain Admin to Domain Controller. I got this little message saying This user account’s password has expired. The password must change to logon. Please update the password or contact your system administrator or technical support.

If you don’t know this yet, I use PSWriteHTML a lot. That means I get to test it under a lot of different conditions. I use it in reports, emails for small, medium, and large companies. Today’s blog post summarizes the work I did in the last few weeks over different areas of PSWriteHTML.

If you’re using VSCode with Powershell extension, you probably got used to PSScriptAnalyzer giving you all kind of tips on optimizing things. It makes your code better. Chris Bergmeister does a great job working on it. One of the tips PSScriptAnalyzer gives you when you use $null on the right side of the comparison.

I’ve been in IT for a longer time now. I’ve made my fair share of mistakes and misconfigurations. One of those misconfigurations was removing Authenticated Users from Security filtering in Group Policy Objects. While it worked fine at some point Microsoft rolled out a Hotfix MS16-07 on June 14th 2016.