tb1's questions

We have an old AD user account with a static password that is used on several machines for a scheduled task and a service. I know gMSA is better and separately am in the process of getting that in place, but this account needs to be up for a little while longer.

Back to this account: I want to change the password to meet current password strength critera and ensure the AES hash, but I wasn't sure if I needed to change it 2x with a 10 hour pause in-between, or if I can just change it back-to-back and push out the password update to the affected endpoints.

If anyone can clarify the 2x, 10-hour gap reset method or whether it can be back-to-back for this purpose, I'd be grateful.

Thanks!

We have an Exchange 2019 Hybrid server to remote mail-enable our AD users and send outbound to our mailboxes from certain legacy apps. Though our users are all AD-bound, we create some mailboxes (e.g. shared ones) directly in EOL/M365 (aka no AD object).

The hybrid server reliably sends mail to all of our AD-bound remote mailboxes, but as soon as we change the recipient to a shared mailbox created in EOL directly (no AD object), we get something like this:

<550 4.4.7 QUEUE.Expired; message expired in unreachable destination queue. Reason: A matching connector cannot be found to route the external recipient>

Also, for what it's worth, I noticed in the message tracking logs that when we address to "[email protected]" the successful deliveries do a routing source resolve to "[email protected]". Our shared mailboxes are created in EOL directly and would only have "[email protected]" by default.

As I was writing this up, I tried adding a secondary SMTP of "[email protected]" through EOL, and sending another test message, but the hybrid host still considers the shared mailbox as an external recipient.

If anyone has experienced this and has a suggestion, I'd be grateful. Thanks!

We are running Exchange Hybrid Mode with remote mailbox and archive in M365. One of our employees left many months ago and so their mailbox went to soft deletion/retention. Their AD object was only disabled (never deleted), so when it got restored and synced back through Entra Connect, a new M365 user with same alias but (empty) mailbox was created (which was fine).

Our issue is that the AD user still has the prior msExchArchiveGUID for the user, and this archive is still soft deleted in EOL, but again, the user in M365 is a different version of the user. I need to figure out how to tell AD to create a new (empty) archive for the M365 user now active.

Details:

In EAC:

If I run: Get-RemoteMailbox returningUser | fl displayname, ArchiveGuid it reports from the msExchArchiveGUID property in AD.:

ArchiveGuid : some-legit-archive-guid-number

In EOL:

If I run: Get-Mailbox returningUser | fl archiveguid I get:

ArchiveGuid : 00000000-0000-0000-0000-000000000000

However, if I run: Get-EXOMailbox -SoftDeletedMailbox -Archive | where { $_.alias -eq 'returningUser' } | select Guid

I get:

Guid 
---
some-legit-archive-guid-number

What I've tried: Deleting the Hybrid-based archive, syncing, then re-adding:

In EAC: Disable-RemoteMailbox returningUser -Archive, run Entra Connect, everything looks good. msExchArchiveGUID in AD is empty. When I run Enable-RemoteMailbox returningUser -Archive the pesky prior msExchArchiveGUID returns.

I've read a lot of examples of mismatches where the solution is telling EAC to use the EOL version of the Archive GUID, but in this case it seems to be that EOL can't use the EAC version of the GUID because it's soft deleted and tied to a prior artifact user.

If anyone knows how to tell EAC to stop looking (wherever it is looking) for that prior ArchiveGUID and just issue a new archive, I'd be grateful!

Thanks!

Last note: If I run this:

Get-MsolUser -HasErrorsOnly | fl DisplayName,UserPrincipalName,@{Name="Error";Expression={($_.errors[0].ErrorDetail.objecterrors.errorrecord.ErrorDescription)}}

The error is:

{The value "some-legit-archive-guid-number" of 
property "ArchiveGuid" is used by another recipient object. 
Please specify a unique value.}

(aka same soft deleted GUID)

We are an M365 tenant in Hybrid mode, with only Exchange Online mailboxes, synching mailbox attributes through Entra Connect. We have acquired another firm (not an M365 tenant). We have taken over their DNS and copied their old firm mailboxes into EOL mailboxes on our tenant, which already use our own custom domain as their primary address.

At this point we just want to add their old domain email addresses as a secondary smtp so they can receive mail replies to old threads directly in our tenant.

Initial testing: If we add their old addresses now through Set-ADUser userMailbox -add @{ProxyAddresses='smtp:[email protected]'} and sync EntraConnect, we do not see that extra alias in the M365 admin panel (but no surprise, we see in local Exchange Hybrid).

Obviously, we still need to add their custom domain to our M365 tenant for the admin panel to "see" that domain, but the question is whether, after that point, adding these proxyAddresses through Set-ADUser will sync into EOL, or whether we have to do something else with EntraConnect, or whether we can just run a separate Set-Mailbox userMailbox -EmailAddresses @{add="[email protected]"} to match it up?

Separate note: I know we can add UPN suffixes in AD Domains and Trusts and sync the domain suffix that way, but this is purely for a mailbox alias, not identity; no one will be signing into AD or M365 with that domain as their UPN... https://learn.microsoft.com/en-us/answers/questions/781907/add-new-email-domain-to-office-365-hybrid

Thanks in advance, anyone who has done this!

When importing a device certificate/private key through CERTLM, the GUI seems to choose a deprecated Cryptography Service Provider (CSP) called "Microsoft Strong Cryptographic Provider"; I'm wondering if there is a way to change this to "Microsoft Software Key Storage Provider" through the wizard or group policy or (other means).

More details: A vendor asked me to import a PFX to a Windows 11 local machine certificate store through the following line command syntax:

certutil -csp "Microsoft Software Key Storage Provider" -importpfx MyPathToCertificate.pfx NoExport

This worked great with their software, however when I had previously tried to import the same PFX, I had used CERTLM (GUI) to import the certificate to same place (local machine / personal store). This seemed to work at the time (certificate appeared there) but caused decryption errors as indicated in the vendor's logs.

Here's how I had imported through the CERTLM:

1. I launched Command Prompt via UAC / Choose Certificates (local machine)
2. I imported the PFX using the default options to the Personal store

After running the following command: Certutil -store My

I noticed the certificate had the following line: Provider = Microsoft Strong Cryptographic Provider

whereas the certutil command explicitly chose "Microsoft Software Key Storage Provider"

According to https://www.pkisolutions.com/understanding-microsoft-crypto-providers/ "Microsoft Strong Cryptographic Provider" is a deprecated legacy provider whereas "Microsoft Software Key Storage Provider" is a modern, preferred choice for working with new keys.

The different CSP explains why the vendor's app was not working after the original import, and I understand why MS would choose an "old" provider as a default for backward compatibility, but I'm curious if there are ways to specify the CSP when performing the import through CERTLM going forward.

If you use Exchange 2016 Hybrid, but only for cloud mailbox management and outbound relay, is it "worth" swapping in an Exchange 2019 Hybrid host instead?

More details: A while back, someone helped us initially set up Azure AD Connect and an Exchange 2016 Hybrid, used for cloud mailbox setup and relay outbound from copiers and legacy apps. No clients or services have ever accessed the hybrid host except for SMTP Auth (and again it is all internal outbound to EXO). We have no public folders or anything else that someone coming from prior on-prem Exchange hosting might have. (We do manage distribution lists internally, but that syncs through AADConnect). That person is gone, and I have been keeping up the Cumulative Updates and keeping both AADConnect and EX2016 hybrid running smoothly, as is.

Exchange 2016 extended support ends October 2025. Now that Exchange 2019 CU12 has a free hybrid license and supports Windows 2022 Server, I cannot tell if it is worth the risk of swapping this in for future-proofing protection.

Since I did not directly set up the initial environment, I'm concerned I'm over-simplifying what would be needed. My understanding of the process is as follows:

1. Leave EX2016 alone: On a separate host, install Windows 2022 and Exchange 2019 CU12 - this process obviously involves extending the AD schema for EX2019
2. Run the latest online Hybrid Configuration Wizard ("HCW") just long enough to get the free license
3. Configure 3rd party SSL cert, (re)create receive connectors, test relay out from internal apps
4. Re-run HCW, continue through to transfer the connection to this new EX2019 host versus EX2016 one

Things I don't know:

• Whether we must export the certificate(s) from 2016 and import to 2019 manually, or does HCW handle using the current cert on the 2019 box
• Whether HCW pulls in prior receive connector or any other useful settings from EX2016 to EX2019
• Whether we need to re-run the separate AADConnect setup again after the hybrid host changes
• Which MS entity handles support? Exchange Online support does not include Hybrid questions (even though we are only using a Hybrid box for EXO relay and cloud mailbox connectivity). Since we don't host on-prem Exchange, that team also does not handle support.

If anyone has performed "the swap" from 2016 to 2019, please let me know how far off base I am.

I know I have time - and the other obvious plan is to reduce any need for internal relay over the next two years while more and more legacy apps and devices start to catch up with changes to SMTP Auth (e.g. OAuth). Thanks!