Can't Remove Old Exchange UCC Certificate - Certificate Bound to Send Connector

I've been running into this a lot lately where an old certificate can't be removed from Exchange as it is bound to a send connector and most commonly it's on a hybrid-mode Exchange configuration.

Here's how to get rid of it easily on Exchange and then delete the old certificate.

First, run the command to get the certificates on the Exchange server.:

Get-ExchangeCertificate | fl

This will return a full list of all certificates on the server.  Make a note of the Thumbprint of the certificate you want to keep.  That's the only one needed.

Now, shut off the "Microsoft Exchange Transport" service using Exchange PowerShell:

net stop "Microsoft Exchange Transport" or Stop-Service -Name MSExchangeTransport whichever you prefer.

Next is to get the name of your Send Connector shown in the error when trying to remove the certificate.  You'll need that name in the next command to remove any certificates that are bound to the connector:

Set-SendConnector -Identity "Outbound to Office 365 - 5c10806d-35cb-6645-8b8f-fde431830769" -TlsCertificateName $Null

At this point you can now delete the old certificate(s) as they're no longer bound to the connector.

Now run these two commands to set the variables for the certificate you want to keep.  This is where having the Thumbprint for the new certificate is needed.

$cert = Get-ExchangeCertificate -Thumbprint 6B6CB53DF162724D4F3AD97E508C5BBF072DCE8

$tlscertificatename = "<i>$($cert.Issuer)<s>$($cert.Subject)"

Do not change the syntax on the 2nd command.  That's used to pickup that variable for the final command.

Use this command finally to assign the new certificate only to the Send Connector:

Set-SendConnector -Identity "Outbound to Office 365 - 5c10806d-35cb-6645-8b8f-fde431830769" -TlsCertificateName $tlscertificatename

Finally, restart the Microsoft Exchange Transport service and you're finished.

net start "Microsoft Exchange Transport" or Start-Service -Name MSExchangeTransport

This completes the removal of any old certificates bound to the Send Connector so you can delete them from the server.  As a precaution, always test your mail flow service to make sure everything is working properly.

Good luck!

 Tonight I was trying to fully clear our older MSA 2040 SAN that is getting a new storage lease on life.  To my surprise when trying to clear the volumes and vdisks off this SAN, I found one disk group that had been quarantined and the GUI would not let me remove this no matter what process I tried.  This MSA is not under warranty there was no way to contact HPE support to help me. HPE forums always finished with "contact support" and "I can't share the special commands in a forum".  Beyond frustrating.

Just a note, the MSA family is a rebrand of Dot Hill (now Seagate) AssuredSAN. Lenovo and Dell both have the same products. It's the same CLI in the Lenovo at least.

To force a disk deletion:

From CLI, create a new user with the role of "diagnostic"

# show users (to verify existing user accounts and roles)

# create user <new username> role diagnostic

The admin will be immediately prompted for a new password, use a complex password (one special character, one number, A-Z, a-z)

Verify the new user has been created by entering “show users” CLI command

After the new user account is created, log into the A controller CLI using the new diagnostic user account.

From CLI prompt, enter the "show disk-groups" command to verify disk-groups and to identify the foreign disk group you want to remove. Unfortunately, your existing disk group and the foreign disk group have the same name, capacity and RAID version so your approach to removing based upon SN is the best way to specify the appropriate disk-group for deletion.

From CLI, enter the following command:

# set advanced-settings virtual-pool-delete-override on

User will be prompted, enter “yes”

Enter “show advanced-settings” to confirm the configuration successfully entered:

User should observe “Virtual Pool Delete Override: Enabled” near the bottom of the list; it is only listed when properly enabled.

After entering the above command to enable virtual-pool-delete-override, you will only have 15 minutes to complete delete operations, otherwise, you will need to re-enable under diagnostic user and continue where you left off.

After virtual-pool-delete-override is turned on, continue to attempt to remove the disk group using the SN approach you previously attempted.

Get the vdisk or disk-group serial number if you don't have it.  When running the "show disk-group" command the serial shows as the very long hex number.

Execute removal:

# remove disk-groups diskgroupserialnumer or

# remove vdisks diskgroupserialnumer

Restart both controllers (MC and SC).

# restart mc both

#restart sc both

This was done on a HPE MSA 2040, with storage firmware GL220P008-01. This process worked perfectly for me and allowed me to fully clear and recover all disks in the SAN.  What was only 6TB before this process is now allowing me to use the full 11TB after configuring the new disk groups and volumes.

Credits: https://forums.lenovo.com/t5/Enterprise-Storage/S2200-3200-dequrantine-diskgroup/m-p/3682552

Hard to believe a Lenovo post helped me resolve this issue on a HPE 2040 SAN.

Entra ID Set User Account Password to Never Expire

 I ran into this one recently as a user account for Cisco CUC had been created in Entra ID only and not on-premise and allowed to sync.  It's just a few PS commands and you can set the password to never expire.

NOTE:  You must be a global admin or password administrator to perform these changes.

I ran all of these commands from an Exchange 2019 on-premise server running in hybrid mode.

1. Connect to Exchange Online

Connect-ExchangeOnline

2. Connect to Microsoft Graph PowerShell and to the required scopes.

Connect-MgGraph -Scopes "User.ReadWrite.All","Group.ReadWrite.All"

3. To check a user's account to see if the password expiration is set run this command: 

Get-MGuser -UserId <user id or UPN> -Property UserPrincipalName, PasswordPolicies | Select-object UserPrincipalName,@{N="PasswordNeverExpires";E={$_.PasswordPolicies -contains "DisablePasswordExpiration"}}

4. To set the password of one user to never expire, run this command:

Update-MgUser -UserId <user ID> -PasswordPolicies DisablePasswordExpiration

These commands will allow you to set the password policy to never expire for just a single user account as needed.  For more details on how to change it for all users and check for all users, you can reference the official Microsoft Learn article HERE.

Good luck!

"The namespace cannot be queried. Access is denied" error when you try to create a domain-based DFS namespace

Working on setting up a new DFS Namespace today.  Ran directly into this issue.  When you sign in to Windows by using an account that belongs to the Domain Admins group, and then you try to create a domain-based namespace on any Distributed File System (DFS) namespace server, the operation fails. Windows returns an error message that resembles the following:

\\domainname.com\Public The namespace cannot be queried. Access is denied.

However, when this error occurs, you can still successfully create a standalone namespace.

The fix is to remove your account from the Protected Users group.

If you're curious, here's why it doesn't work:  When you create a new domain-based namespace, the computer queries the Domain Name System (DNS) server for domain information. The DNS server responds by sending a list of the A records of the domain controllers for that domain. The computer then contacts one of the domain controllers and tries to use your account credentials to authenticate by using NTLM authentication.

If your account belongs to the Protected Users group, your account can't use NTLM authentication. In this situation, authentication fails and generates a STATUS_ACCOUNT_RESTRICTION error.

Is Port 80 Needed for On-Premise Exchange?

 Simply put...NO! 

Now if you go digging you will see the official Microsoft documentation stating that it is needed for failback for some HTTPS services.  From a security standpoint if the HTTPS services aren't working then I will refuse to go back to an unencrypted service just to keep it working.

Some will say if you're keeping Exchange patched and updated then having port 80 open to Exchange is no big deal.  While that may be true why risk it?

I had a customer recently that was asking why their Exchange server was showing C&C callbacks being blocked from the outside, why are there other items being blocked from the outside.  Each thing in the endpoint protection logs showed this server was being attacked on port 80.

I connected to their Cisco ASA and disabled the rule allowing port 80 to the Exchange server.  Guess what, a week went by with no further attacks being blocked.  Even though the endpoint protection was stopping them, it would only be a matter of time before an exploit is found via port 80 and then there goes the server's security posture.

I don't see a need to expose this port in 2023 on the modern Internet with all of the risks we already face daily.

Just be smart and disable port 80.  If your application won't work without it then it's time to update the application or get one that is more focused on security.  Don't compromise your network security to accommodate old software.

My $.02.  

Good luck!