Exchange/M365 - Who Moved Or Deleted A Folder In A Shared Mailbox?

I recently had an all-too-common request: "who deleted a folder from a Shared Mailbox?".

Technically you can audit these actions in M365 Purview/Exchange Admin Audit log, but it's cumbersome and takes forever...you know when you start a compliance search and hit refresh dozen times and it sits there in a "starting" state?

This is the method I've used for years before MS added the "audit 'move' for delegates" setting to mailboxes and it's still my go-to method over auditing. The reason being that auditing Shared Mailboxes can be hit or miss, and you can't easily tell where an entire folder was moved to; works fine for single items.

A faster, cleaner, way is to get the list of users who have Full Access into a CSV and pipe that in the Exchange Management Shell (EMS) to find the "missing" folder. 

The default way shared mailboxes function is: whoever deleted a folder/item, it goes into their Deleted Items folder, not the Shared Mailbox Deleted Items...unless you've done a registry hack to change it (which is only feasible if you have a handful of users).

In my environment, we use Security Groups to assign Full Access, so I'll show you how to grab that user list, but the method remains the same if you assign users one-by-one as well.

Create a CSV with "Identity" as the header and the email addresses below:

You can export the group members by running:

$DL = "DL"

Get-DistributionGroupMember -Identity $DL | Select primarysmtpaddress | Export-CSV "members.csv" -NoTypeInformation

**Note** Change "DL" to the distro you're working with.

Once you have your CSV exported, change the header to "Identity" like above.

Then, run:

import-csv filename.csv | foreach {Get-MailboxFolderStatistics -Identity $_.Identity | Where {$_.Name -eq "Margaret"} | Format-Table Identity,ItemsInFolderAndSubfolders,FolderAndSubfolderSize -AutoSize}

**Note** Change filename.csv to your CSV and "Margaret" to the name of the folder you're looking for.

It will spit out who has that folder in their mailbox:

Notice how it shows the folder under User\Inbox\Foldername path? The problem user inadvertently moved the folder into her Inbox. If they deleted it, it would show User\Deleted Items\Foldername

Caveat: If the user deleted the folder and emptied their Deleted Items folder, you're out of luck recovering the entire folder. You have do to some more PowerShell magic to recover those and that's beyond the scope of this article.

Now, you can contact that user and yell at them to MOVE THE FOLDER BACK!

M365/Proofpoint - Bypass Link Checking For MassMailers Like Mailchimp

One of our users sends monthly newsletter blasts to a couple thousand recipients through MailChimp. The problem is (and I've seen this issue floating around on various forums like reddit) spam filters that do URL checking skew the open and link-click rates in the MailChimp dashboard. So, when the user goes to check the reports it shows 100% clicks, which is not anywhere near accurate considering over 2,000 people received the email blast.

What's happening, is the URL defense service (in our case Proofpoint Targeted Attack Prevention and M365 Security SafeLinks) is simulating a "click" in order to scan the URLs in messages to check for any malware.

In my environment MailChimp is spoofing one of our email addresses. So setting a bypass for the actual MailChimp sender or IP or even sending host wouldn't work because bulk senders use several IPs/hosts and they use those ugly-looking bounce email addresses to send...you know those ones that are like bounce-1234567899876543221@your_own_domain_even_though_its_not_you_sending_it.com

Here's how I created a bypass on both Proofpoint and M365/Exchange Online. 

You might be asking why do we run both Proofpoint and EOP (Exchange Online Protection)? The answer is: we're stupid and gluttons for punishment...it's much more fun to chase down issues when mail takes way too many hops.

Having said that, Proofpoint support pointed fingers at MS and vice-versa...so I had to bypass both to be sure.

Proofpoint:

**Note** This the "real" full-blown Proofpoint, not Essentials.

Policy Route:

Under System > Policy Routes:

Create a policy route called something like DisableTAP

Add the sender email address (in our case the spoofed address). 

Since we're adding a spoofed address, it won't match the actual sender (i.e. envelope sender) so I had to use the "message header 'from' (address only) equals sender@exchangeitup.com" entry.

Save your changes

URL Defense:

Under Email Protection > Targeted Attack Prevention > URL Defense > Settings:

Check the box marked "Disable processing for selected policy routes..."

In the "available" list scroll till you find the DisableTAP rule you created earlier and click the >> button to add it to the "disable for any of" list.

Save your changes

TAP Dashboard:

Go to the Targeted Attack Prevention > Dashboard.

In the dashboard, click the settings gear in the left pane, then the Organization tab.

Scroll down to "Excluded Addresses".

Click "ADD EMAIL ADDRESS", input the address you used for the above Policy Route, and the drop-down to "Sender".

After all this is done, give it 15-30 minutes (sometimes Proofpoint is slow for settings take effect).

Exchange Online:

Under Mail flow > Rules:

Create a new rule called something like "Spammysender bypass SafeLinks"

Apply this if:

The Sender > address includes any of these words

input the sending address we used in the Proofpoint route

Do the following

modify the message properties > set a message header

input X-MS-Exchange-Organization-SkipSafeLinksProcessing with a value of 1

Give it a couple hours to take effect and test the inbound mail from the MailChimp sender. It should now show more accurate open and click rates.

M365 Planning Diagram: Mail Encryption Flow

If you follow my blog, you know that I like to use Visio to draw pretty pictures to use when planning out Messaging Environments, like this one here.

We're currently migrating our mail encryption from Proofpoint to M365 Purview. Like most organizations, we have steering committees filled with business leaders/stakeholders who need stuff in plain language and diagrams always help.

So, I created this encryption "flow" diagram to show what happens when one of our users encrypts an outbound message to when the recipient opens it - start to finish. This way the higher-ups can visualize how exactly mail encryption works.

M365 Mail Encryption Flow Overview

In my example below we have a user sending a message using the [secure] subjectline tag or encrypt button, which is an option that can be set in OME (Purview Message Encryption), or attaches some sensitive data containing PII/PHI (Personally Identifiable Information/Protected Health Information).

The message then flows through Purview where it detects the tag or encrypt button usage or sensitive data using DLP filters, then to the Encryption Portal where it's stored for the recipient.

A notification is sent to the recipient saying they have an encrypted message waiting.

The recipient clicks the link, which takes them to the Purview Portal to view the message.

A notification is sent to the sender that the recipient opened the message.

If the recipient replies, the message is sent back through Purview Encryption then on to the original sender.

Feel free to grab the Visio file from my Google Drive Mail Encryption Flow.vsdx to use for your environment!

Exchange - Assign Calendar Permissions In Bulk

In my current environment, we have a mix of Shared Mailbox Calendars and calendars shared out by users themselves. While I prefer to use Shared Mailboxes, some departments have high turnover depending on if they contain students and interns so managing calendar perms would be a never ending task for admins.

In this instance, a calendar managed by a user got corrupted (happens a lot on M365 for some reason) and we had to create a new calendar. The problem was, this particular calendar had over 70 users with varying permissions (editor and reviewer). So I needed a way to quickly assign those same perms to the new calendar, without the user having to do it by hand.

You may be asking, why not assign perms by group? Since this is a user-managed calendar, they have no access to AD/groups and with the turnover I mentioned, they add/remove users almost weekly so after the initial assignment, it will be done per user anyway.

As always, PowerShell to the rescue!

First, we'll build a CSV with "Name" as the heading and the list of users like so:

Or if you're copying perms from another calendar, you can export the names and access rights.

In the Exchange Management Shell (EMS) run the following:

Get-MailboxFolderPermission "Buddy Guy:\Calendar\Dept Calendar" | where {$_.accessrights -eq 'editor'} |select user,accessrights | Export-Csv C:\Scripts\caleditors.csv -NoTypeInformation

The above cmdlet will grab all users who have editor rights on the calendar.

Get-MailboxFolderPermission "Buddy Guy:\Calendar\Dept Calendar" | where {$_.accessrights -eq 'reviewer'} |select user,accessrights | Export-Csv C:\Scripts\calreviewers.csv -NoTypeInformation

The above cmdlet will grab all users who have reviewer rights on the calendar.

**Note** Change "Buddy Guy:\Calendar\Dept Calendar" to the user and calendar you're working with and the path and filename you prefer.

Then, format those CSVs like the example above, with just the names.

Next, run the following:

Import-Csv C:\Scripts\caleditors.csv | foreach {add-MailboxFolderPermission -Identity "Buddy Guy:\Calendar\NEW Dept Calendar" -User $_.name -AccessRights Editor}

This will assign editors on the new calendar.

Import-Csv C:\Scripts\calreviewers.csv | foreach {add-MailboxFolderPermission -Identity "Buddy Guy:\Calendar\NEW Dept Calendar" -User $_.name -AccessRights Reviewer}

This will assign reviewers on the new calendar.

**Note** Change "Buddy Guy:\Calendar\NEW Dept Calendar" to the user and new calendar you're working with and path and filename to the where you saved your CSVs.

Now, if you check permissions on the new calendar, you'll see that all of those editors and reviewers have been set. You can run Get-MailboxFolderPermission "Buddy Guy:\Calendar\NEW Dept Calendar" to grab all those perms.

A couple notes to finish up:

Users will still need to manually add the new Calendar to their Outlook.

If running on M365, it *may* take a while for the perms to take effect - I usually tell users to give it a day just to manage expectations - though it will usually work within a few minutes in OWA.

PS. I'll work on a script to copy and apply perms in one shot when I get a chance.

Teams - Get Team URL, Display Name and Owner

In my current environment, we do a lot of Litigation Holds...it's a medical org, so I mean A LOT of holds.

Not only do we have to do mailbox holds, but we have to place SharePoint, OneDrive and Teams on hold. SP and OneDrive are pretty easy as those URLs can be found in the Admin Center; not so for Teams URLs. We also need to find the owners of those Teams so they can be placed on hold as well.

I came up with a one-liner that will spit out all those URLs along with owners to make it easier to copy/paste them into the Hold in the eDiscovery Admin Center.

First, we'll need to make sure the results aren't truncated because some Teams can have several owners, and it will just show the "userna..." instead of the full name.

In M365 PowerShell, run:

$FormatEnumerationLimit=-1

Then, run:

Get-Team -User user@domain.com | foreach {Get-UnifiedGroup -Identity $_.groupid} |fl SharePointSiteUrl,managedby

**Note** user@domain.com is the account we're putting on hold and needing to find if they own any Teams. 

The output will look like this:

Once you have those links, you can paste them into your eDiscovery SharePoint/OneDrive/Teams holds instead of typing everything manually.

Happy holding!

M365 - Get-EXOMailbox : Error while querying REST service. HttpStatusCode=500

I previously wrote a post on how to create an M365 Remote PowerShell shortcut and would get errors when running EXOMailbox cmdlets. All other cmdlets worked fine, including Get-Mailbox, and connecting "manually" to Exchange Online worked fine. 

Btw, the reason you wanna use Get-EXOMailbox is it's a lot faster than Get-Mailbox...like, way faster.

The error I got was:

Get-EXOMailbox : Error while querying REST service. HttpStatusCode=500 ErrorMessage={"error":{"code":"InternalServerError","message":"The call to Microsoft Exchange Active Directory Topology service on server 'TopologyClientTcpEndpoint (localhost)' returned an error. Error details Active Directory server  is not available. Error message: Active directoryresponse: The LDAP server is unavailable..","innererror":{"message":"The call to Microsoft Exchange Active Directory Topology service on server 'TopologyClientTcpEndpoint (localhost)' returned an error. Error details Active Directory server  is not available. Error message: Active directory response: The LDAP server is unavailable..","type":"Microsoft.Exchange.Data.Directory.ADTransientException"}}}}

Apparently, this is a problem with the Exchange Online module 3 and above - I'm currently running 3.3.0. You'd think after 4 build updates MS would fix it but guess not.

The workaround is to connect to the Security & Compliance module before connecting to Exchange Online.

For instance, my PS Shortcut script would look like so:

$acctName="admin@domain.com"
$orgName="domain.com"
#Azure Active Directory
Connect-MsolService
#SharePoint Online
Connect-SPOService -Url https://bcmedu-admin.sharepoint.com
#Security & Compliance Center
Import-Module ExchangeOnlineManagement
Connect-IPPSSession -UserPrincipalName $acctName
#Exchange Online
Connect-ExchangeOnline -UserPrincipalName $acctName -ShowProgress $true
#Teams and Skype for Business Online
Import-Module MicrosoftTeams
Connect-MicrosoftTeams

Now, when you try to run the EXOMailbox cmdlets, it'll fire off correctly!

M365 - Create Remote PowerShell Shortcut (updated)

In a previous post, I showed how to create a Remote PowerShell shortcut for Office 365 using Remote PowerShell (RPS), to save you from having to type in the remote session every time you connect.

Since Microsoft has deprecated RPS in favor of REST API, I've created a new script that will import the needed sessions and connect to the following M365 services in one shot:

Azure AD
SharePoint Online
Exchange Online
Security & Compliance Center
Teams

First, you'll need the latest EXO (Exchange Online) module - 3.3.0 at the time of this writing - in order to connect to Security & Compliance, which you can get here.

Next, set your PowerShell execution policy - I use Unrestricted but you can use RemoteSigned:

Set-ExecutionPolicy Unrestricted

Now, we'll grab the other required modules:

MSOL

PowerShell Gallery | MSOnline 1.1.183.66

SharePoint

PowerShell Gallery | Microsoft.Online.SharePoint.PowerShell 16.0.24009.12000

Teams

Install .NET 4.7.2 or higher

Run the two following cmdlets:

Install-Module -Name PowerShellGet -Force -AllowClobber

Install-Module -Name MicrosoftTeams -Force -AllowClobber

**Note** We're using MSOL because it's more comprehensive than AzureAD

**Note** Security & Compliance uses the EXO module, so nothing is needed for that.

Next, copy the following block and paste it into Notepad:

$acctName="admin@domain.com"
$orgName="domain.com"
#Azure Active Directory
Connect-MsolService
#SharePoint Online
Connect-SPOService -Url https://bcmedu-admin.sharepoint.com
#Security & Compliance Center
Import-Module ExchangeOnlineManagement
Connect-IPPSSession -UserPrincipalName $acctName
#Exchange Online
Connect-ExchangeOnline -UserPrincipalName $acctName -ShowProgress $true
#Teams and Skype for Business Online
Import-Module MicrosoftTeams
Connect-MicrosoftTeams

**Note** Change $acctName="admin@domain.com" and $orgName="domain.com" to your admin account and domain name.

Save it as a .ps1 with a name like Connect-365.ps1 to somewhere like C:\Scripts

Next, create a PowerShell shortcut anywhere, like on your Desktop:

Right-click the Desktop > New > Shortcut

In the location field, enter:

Powershell.exe

Click Next

Give it a name like O365RemotePS and click Finish.

Right-click the new O365RemotePS shortcut, and go to Properties.

In the Target field, add the following to the end of the line:

-NoExit -File "C:\Scripts\Connect-365.ps1"

It will look like so:

C:\Windows\System32\WindowsPowerShell\v1.0\powershell.exe -NoExit -File "C:\Scripts\Connect-365.ps1"

Click OK.

Run your new shortcut as your admin user, and you'll get a windows creds prompt and then the account picker for your Microsoft 365 organization.

**Note** You will get an account picker for each service depending on your security config in M365. 

**Note** Enter creds in the username@orgname.com format.

Once it starts the remote session, you'll be able to run your M365 cmdlets.

I Wrote A Book...

 ...a second book actually! My first book Exchange 2016 Resource Forest Setup can be found here. 

My new eBook Exchange N00b is live on Amazon Kindle. 

You can grab it here: Amazon.com: Exchange N00b eBook

This book is designed to guide fledgling (n00b) Exchange Administrators through the day-to-day management of an Exchange Environment.

The book applies to Exchange 2013/2016/2019, since not much has changed in terms of the GUI interface and basic PowerShell cmdlets and is broken down into sections so you can easily refer to the scenario you find yourself in.

I'm also feeling generous, so if you want a free copy, drop me a note and I'll send ya one!

Exchange - 2016 ObjectType '9b026da6-0d3c-465c-8bee-5199d7165cba' Can't Be Resolved

After installing a Server 2016 or Server 2019 Domain Controller into your existing Exchange environment, you'll get the following error prompt when trying to edit/view Mailbox Delegation or edit a Distribution Group in the EAC.

The object exchangeitup.com / Mailboxes / Shared Mailboxes / HR Shared Mailbox has been corrupted, and it's in an inconsistent state. The following validation errors happened:

The access control entry defines the ObjectType '9b026da6-0d3c-465c-8bee-5199d7165cba' that can't be resolved ..

This is because when promoting the server it extends the Schema, which breaks Exchange ACLs. 

**Note** It extends the Schema just by promoting the DC, even when leaving the Domain/Forest Functional Level as is.

Most online resources say restart IIS or restart the Exchange Server(s). Don't do that! Bouncing IIS will cause client disconnects, and restarting a whole server? Just...no.

A quicker and safer fix is to recycle the ECP pools on each Mailbox server by running the following cmdlet in the Exchange Management Shell:

Restart-WebAppPool -Name MSExchangeECPAppPool

Now refresh or close and reopen the EAC and it works!

Exchange - Dealing With Mailbox Retention In A Resource Forest

If you follow my blog, you know I run an Exchange Resource Forest (which really sucks). A quick rundown on the innerworkings of a Resource Forest involves syncing Active Directory accounts from the Accounts Forest (your main domain) to the Resource Forest (your Exchange domain) using a dirsync service like FIM/MIM. You can also see how it's set up in my post from a while back.

The problem we have in my environment is: government regulations require a certain retention time period on mailbox and mailbox items because of the type of business we do. This causes a big problem when removing AD accounts when employees leave the company. If you delete the AD account in the Accounts Forest, you'll end up deleting the AD account and mailbox along with it in the Resource Forest as soon as MIM completes its next scheduled sync.

So, I've come up with a way to be able to delete the user in the Accounts Forest, while keeping the mailbox intact for retention/historical data...this is also helpful when an employee leaves, and you've set Full Access on their mailbox for other users (like their previous manager) who need that data.

Move the AD Account In The Resource Forest

First, we'll create an Organizational Unit (OU) in the Resource Forest that isn't included in the MIM-sync, which will be outside the sync'd container(s); we'll call it something like "Disabled Mailboxes" - clever, eh?

Then, we'll move the soon-to-be-deleted user into this new OU. This will effectively "break" the sync, since MIM in the Accounts Forest will no longer "see" the AD account in the Resource Forest, because it's not in the sync'd OU any longer.

Convert The Linked Mailbox

Next, we'll convert the Linked Mailbox to a User Mailbox. We need to do this because deleting the AD account in the Accounts Forest (also called the "Linked Master Account") will also delete the mailbox along with it. So, converting to a User Mailbox will unlink the mailbox leaving it only connected to the Resource Forest Account.

To convert the Linked Mailbox to a User mailbox, fire up the Exchange Management Shell (EMS) and run:

Get-Mailbox "Account to be deleted name" | Set-User -LinkedMasterAccount $null

**Note** Change "Account to be deleted name" to the name of the account you're deleting.

The above cmdlet will wipe the Linked Master Account from the mailbox, and if you check the mailbox in the EAC or with the EMS, it will show "User Mailbox" as the Mailbox Type, now.

Delete The Accounts Forest AD Account

Now that we have moved our Resource Forest Account and converted the mailbox, nothing is tying it to the original/main account in the Accounts Forest. You can now delete the AD account from the Accounts Forest.

Once you've deleted it, depending on your MIM sync interval (usually 30 minutes) to verify that everything still works, go check the account/mailbox in the Resource Forest and you'll see that it's still there. 

**Note** The AD account in the Resource Forest will still be disabled, as is standard with Linked Mailboxes, so Mailbox Delegation will still work, but no one will be able to directly log in to it. If that needs to happen, you can just enable the AD account.

Now, you can keep those mailboxes around for however long you need them, while keeping a clean and secure Accounts Forest!

Exchange - Set Forwarding On Mailboxes In Bulk From CSV

My company just sold off a couple of its business units and the sales agreement says offboarding users must keep their legacy email access for 6 months. But, they also need messages forwarded to their new (external) email addresses.

Normally, you could do this by OU (Organizational Unit) but in my case, not everyone in that OU is leaving and management didn't want to create a new OU since GPOs and ACLs are already linked to said OU.

So, we need to be able to import a CSV of those specific users and set the forwarding in one shot...I have about 450 users in my list, that would take a long time doing it manually :)

Create A New Send Connector

First, we need to create a dedicated Send Connector going out to the new external domain. This allows us to forward without creating External Contacts for all of the users - much easier:

In the EAC, navigate to Mail Flow, Send Connectors, +

In the New Send Connector window, give it a name like "External Forward" and click Next

Leave MX record selected and click Next

Click the + and under the FQDN type the domain name for the external contact, click Save, and Next

For the Source Server, click the + and select your Edge server if you have one, or your Mailbox servers (all of them) and click Ok, then Finish

Enable Verbose Logging on the Connector:

You'll want full logging on the connector so you can check the SMTPSend protocol logs later to verify successful sending.

In the Exchange Management Shell (EMS), run the following:

Set-SendConnector "External Forward" -ProtocolLoggingLevel Verbose

Optional:

If the external domain requires it, you'll need to enable forced TLS, else messages will be dropped.

In the EMS run the following:

Get-SendConnector "External Forward" | Set-SendConnector -RequireTLS $true

Create New Remote Domain

Next, we need to create a new Remote Domain in Exchange - this will allow incoming messages to hit our Exchange servers and forward/relay on to the new, external domain.

Fire up the Exchange Management Shell (EMS) and run:

New-RemoteDomain -DomainName *.externaldomain.com -Name ExternalDomain

**Note** Change "*.externaldomain.com" to the SMTP domain name of the external domain (using the wildcard will ensure any subdomains are included) and change "ExternalDomain" to the name of the external domain

Next, we need to allow messages to be forwarded to the new remote domain, by running:

Set-RemoteDomain "ExternalDomain" -AutoForwardEnabled $True

**Note** Change "ExternalDomain" to the name you gave it in the earlier cmdlet

Set Forwarding

Now, we'll create our CSV with Email and Forward as the headers and the users' current email and new external email address under like so:

Lastly, we'll run the cmdlet to set the forwarding on the user in the CSV:

$users=Import-csv C:\Temp\emails.csv

ForEach($user in $users){Set-Mailbox $user.email -DeliverToMailboxAndForward $false -ForwardingSMTPAddress $user.forward}

**Note** This cmdlet sets the ForwardingSMTPAddress switch, NOT ForwardingAddress. You can refer to my previous post to see the difference between those, but in a nutshell ForwardingSMTPAddress is what you use when using a dedicated Send Connector and Remote Domain.

**Note** This will set the messages to be forwarded but not delivered to the current mailboxes, which is what we want since those people are leaving the company.

Now, all incoming messages to those users will be routed to their new external domain without landing in their current mailboxes!

Skype For Business - Showing Out of Office For User Who Is Not OOF

In my Exchange 2016/SFB 2015 environment, I have a user named Mary, where OOF is showing enabled/turned on when looking her up in SFB and Outlook:

The problem is: she isn't Out Of Office, she's there, sitting at her desk.

In the Exchange Management Shell (and the ECP in "manage another user") automatic reply status shows as disabled:

Well, we know the EMS doesn't lie, so it's gotta be client-related.

We tried turning off Outlook cached mode, creating a new local mail profile, and deleting Mary's SFB cache...nothing worked.

On a hunch, I checked Mary's calendar and one of her direct reports named Laura, sent her own OOF as an invite to Mary, which added it to Mary's calendar, therefore showing Mary as OOF:

That's bad practice, and totally confusing for other users. 

To fix it, Mary needs to delete Laura's calendar event and it will remove Mary from looking like she's Out Of Office.

Exchange - Install Let's Encrypt On SpamTitan

If your company is anything like the one I work for, they really hate spending money on technology...it almost becomes a yearly fight when renewing things like certificates, even though certs are needed for almost everything regarding messaging.

One of those certs is the SSL cert on SpamTitan, which is used for the WebUI secure connections and more importantly, outbound TLS connections - meaning: external receiving servers can't verify TLS without a public cert.

Luckily, SpamTitan now supports free certs from Let's Encrypt. Now, you're prolly thinking "woah, Let's Encrypt? On production?" Let's Encrypt sometimes gets a bad rap because it expires in 90 days and depending on the system you have to jump through hoops to install/renew it. It's very easy on SpamTitan, it's free, and it will automatically request the certificate, install it, and set up TLS and HTTPS for you. Additionally, it will be automatically renewed before expiration, without ever touching it again...can't do that with a paid public cert, can ya? 😁

Here's how to install the Let's Encrypt certificate on your SpamTitan appliance.

Go to Settings > SSL

Provide all the same information as if you're requesting a cert from a public CA:

Common Name: This is the fully qualified domain name (FQDN) that will be used in the URL to access the SpamTitan UI. It must match the server name exactly, otherwise you will get a warning dialog every time you visit the site. An example, spamtitan.exchangeitup.com.

Organization: This is the name of your company or organization.

Organization Unit: Specify a specific department within your organization, like IT.

City: This is the name of the city or town where the organization is located

State/Province: This is the full name of the state or province where the organization is located.

Country: This is the two-letter country code of the location of the organization. e.g. US

**Note** For most CSR's the OU is optional....this is not so on Let's Encrypt. You must input an OU (I use "IT") or else you'll get the following error:

AcmePhp\Ssl\DistinguishedName::$organizationalUnitName expected a string. Got: ""

Notice that the "$organizationalUnitName expected a string" got an empty value.

If that happens fill out your CSR info again, with an OU this time and it will run successfully

Hit the "Run" button next to "Use Let's Encrypt to generate a Certificate"

Important: the outbound cert validation needs to be accessible over port 80 at all times, for Let's Encrypt servers to renew/validate the cert. Blocking port 80 on the firewall if you run your own SpamTitan appliance, or disabling HTTP is not recommended or else Let's Encrypt may not be able to renew the certificate every 90 days. If your security requires it, you can disable HTTP after the validation, just set yourself a reminder to to temporarily enable it in 90 days for renewal.

If you get an error that port 80 is blocked, we'll need to enable HTTP.

Go to Settings > Access/Authentication under the Web Management Protocol section and hit the "Enable" button next to HTTP. It will then show as ON

Now, run your Let's Encrypt again, it should verify successfully and be marked as active

You'll also see that its installed in the "Installed Signed Certificates" section

And if you check the cert in your browser, you'll see the Let's Encrypt Issued By "R3" , which matches the Common Name in the above screenshot.

And you'll see that the Let's Encrypt cert has been set for the HTTPS connections in the Web Management Protocol settings

And you'll see that the Let's Encrypt cert has been enabled for TLS connections under Settings > TLS

And lastly, you'll need to make sure that the Let's Encrypt cert is selected for outbound TLS connections, by going to System Setup > Mail Relay...scroll to the bottom and select the Let's Encrypt cert in the drop-down and click Save:

There you have it! An easy, FREE cert for securing your SpamTitan management and outbound communications!

Exchange - Safely Installing Security Updates Without Errors (Updated Post)

 As you probably know by now, MS is releasing out-of-band Security Updates for Exchange 2013/2016/2019 to combat regularly discovered exploits...it started last year about this time with the HAFNIUM exploit. It only affects on-prem Exchange, according to MS (though I don't know how since Exchange Online is Exchange, but that's beside the point).

I see on lots of forums where Exchange admins mess up their systems by installing the Security Updates wrong; this includes ECP being broken, services not starting, etc. So, I'll show you how to easily install them, error free.

For this, we will be using the command prompt. We WILL NOT use Windows Update and we WILL NOT run the .msp directly.

Hide/Disable The Update

First, you'll want to go to Windows Update and uncheck and hide the Security Update (right-click > hide update).

That means: DO NOT install it from Windows Update, and if you use SCCM/WSUS, stop pushing Exchange Security Updates altogether.

Download the Update

Next, you'll wanna make sure you manually download the correct update, because they are CU-dependent.

For instance, if you are currently up to date on Exchange 2016, which is CU22 as of this writing, you'll want this update:

Download Security Update For Exchange Server 2016 CU22 (KB5012698) from Official Microsoft Download Center

Install The Update

Once you have it downloaded, save it to your favorite directory on all of your Exchange Servers, like C:\Updates.

**Note** You will need to install the update on Mailbox Servers, CAS Servers (if you've spilt roles in Exchange 2013), Edge Servers, and Hybrid Servers. It's your choice if you want to install it on any Management Tools Servers, but it won't hurt to do so.

Put your server in Maintenance Mode.

**Note** I recommend Maintenance Mode even for single servers, because we don't want anything interfering with the install and since the installer will disable Exchange services, it's better to be safe.

Fire up an Elevated CMD (right-click CMD.exe > Run As Administrator).

Next, cd to the directory where you saved your install file like so:

cd C:\Updates

Next, in Windows Explorer navigate to the directory and copy the full path by selecting the .msp file and clicking "Copy Path" in the ribbon or SHIFT-Right-Click the file > Copy As Path:

In the CMD window, right-click to paste the path, including the double quotes:

Hit ENTER and the installer will ask if you want to run the file, hit OK and follow the prompts...accept the EULA, next, next a couple times and you're done.

**Note** Some machines will seem to take a loooooooong time during the "calculating space" phase; it could take an hour in some cases. For instance, one of my DAG nodes took 5 minutes, one took 30 minutes, and two took an hour. Let it do it's thing, don't mess with it...rest assured it will go on it's own.

Once the install is finished it may ask you to reboot the machine, go ahead and reboot. If it doesn't prompt you, go ahead and reboot.

Once the server comes back up, take it out of Maintenance Mode and proceed on your next server.

Updated 6/2022:

MS is now releasing SUs (Security Updates) in .EXE format instead of msp, which is supposed to negate running elevated as it automatically extracts to a temp directory and runs using UAC. 

They say you can double-click the su.exe file and it will run. Do I advise doing that? NO! It is still safer to run the .exe using the instructions above (in an elevated CMD) to make sure it runs with proper permissions...just copy the path of the exe instead of the msp.

Congrats, you're done! Now you should be patched up to date, with healthy servers...which means all services are running and ECP/OWA works!

Exchange - Removing Old/Expired Federation Certificates

I'll start off by saying Microsoft really dropped the ball on renewing an Exchange Federation Certificate. 

Following the MS instructions here, tells you how to renew it (sure, that's part of what we need) but they don't tell you how to remove the old one...which leads to the EAC screaming at you that certs are about to expire or already have. And there's no supported/built-in option like removing other self-signed certs.

If you even try to remove the old/expired Federation cert, it will throw the following error:

A special Rpc error occurs on server blah blah. Active certificates in use by Federation cannot be removed.

Well, that's weird...because we've already replaced the Fed Cert, right? Wrong...

When you renew a Federation Cert, it moves the old certificate to an ADSI attribute called "msExchFedOrgPrevPrivCertificate" and sets the new cert as the "msExchFedOrgPrivCertificate".

Notice the "PrevPriv" and "OrgPriv" in those names? 

**Note** These attributes can be found in ADSIEdit under CN=Configuration,DC=domain,DC=com > CN=Services > CN=Microsoft Exchange > CN=DOMAINNAME > CN=Federation Trusts > CN=Microsoft Federation Gateway > Properties

For some (stupid) reason, Exchange still sees the msExchFedOrgPrivCertificate as being used by Federation and MS should really fix that...I mean, do they NOT expect anyone to keep Exchange around longer than 5 years, which is when the certs expire?

In order to get around this, we need to clear that msExchFedOrgPrivCertificate attribute, after which, we can delete the cert from Exchange.

The Fix

I've come up with a PowerShell cmdlet to do just that.

Disclaimer: Modifying anything in ADSI can be destructive, so make sure you have a good AD backup or export the attribute using LDIFDE - you can find guides for that on the net.

Check The Attribute

In the Exchange Management Shell (EMS), run the following cmdlet to check our msExchFedOrgPrivCertificate value:

Get-ADObject -LDAPFilter "(objectclass=msexchfedtrust)" -SearchBase "CN=Microsoft Federation Gateway,CN=Federation Trusts,CN=EXCHANGEITUP,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchangeitup,DC=com" -Properties * | Select msExchFedOrgPrevPrivCertificate

**Note** Change "CN=EXCHANGEITUP" and "DC=exchangeitup,DC=com" to match your domain

It should output a hex value like so:

msExchFedOrgPrevPrivCertificate : {57, 52, 68, 48, 55, 52, 65, 53, 50, 69, 56, 51, 69, 49, 67, 56...}

Clear The Attribute

Next, we're going to clear the value, with the Set-ADObject, like so:

Set-ADObject "CN=Microsoft Federation Gateway,CN=Federation Trusts,CN=EXCHANGEITUP,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=exchangeitup,DC=com" -Clear msExchFedOrgPrevPrivCertificate 

What this does is search the ADSI Exchange Federation container for the "msExchFedOrgPrevPrivCertificate" attribute and uses the "-Clear" command to remove the entry.

**Note** Change "CN=EXCHANGEITUP" and "DC=exchangeitup,DC=com" to match your domain.

If you run your first cmdlet again, the value will be empty.

Delete The Certificate

Next, we'll get the cert thumbprint by running:

Get-ExchangeCertificate | Select Services,Thumbprint,NotAfter | ft -auto

You'll want to look at the Services column for "Federation" and the NotAfter column to find the old/expired cert and copy that Thumbprint.

Now, we'll remove that old certificate from Exchange by running the following for each of your Mailbox Servers:

Remove-ExchangeCertificate -Server MBX1 -Thumbprint 94D074A52E83E1C81528EE3C43FEE42266ED80A0 -Confirm:$false

**Note** Change "MBX1" to your server name(s), successively.

You can also do this in the EAC by navigating to Servers > Certificates > Select the Old Fed Cert and click the Trashcan icon

Do this on each Mailbox Server.

Now if you check the EAC, the old Federation Certificate will be gone from each of your servers, the alerts will be gone and Federation will still work!