u/maxcoder88

Running an AD Health Assessment on our Windows 2019 forest and it flags ~40 Linux/Unix computer accounts as PasswordNeverExpires=True (userAccountControl bit 65536 set). Before I blindly clear the flag, I want to understand what's actually going on.

Environment:

• Mixed Linux estate: RHEL 7/8/9, Ubuntu, some legacy CentOS, plus NetApp/QNAP appliances
• Join methods vary: realm join (SSSD), Samba/Winbind, some old Centrify leftovers
• Some boxes have PasswordLastSet going back 5+ years but are actively authenticating users via Kerberos
• SSSD configs I've checked either have ad_maximum_machine_account_password_age = 0 or the parameter is missing entirely

Questions:

1. Is PasswordNeverExpires=True actively set by the Linux join tooling, or did sysadmins set it manually years ago to prevent breakage? Does realm join / adcli / net ads join set bit 65536 by default?

2. If I clear the flag on a Linux box where SSSD rotation is disabled, does anything actually break? My understanding is the GPO doesn't actively expire passwords — the client initiates the change. So clearing the flag on a non-rotating box should be functionally a no-op while making the health report happy. Am I missing something?

3. What's actual best practice in 2026 for Linux machine password rotation? Enable ad_maximum_machine_account_password_age = 30 everywhere? Cron adcli update? Or just accept Linux passwords don't rotate and document the exception?

Looking for war stories from anyone running mixed Windows/Linux AD at scale. Bonus if you've tested what happens when clearing the flag on a non-rotating box.

Title: DHCP audit log size — what's your sweet spot for ~250 scopes?

Hey everyone,

I'm planning to tune the audit log settings on our Windows DHCP

servers and wanted to get a sanity check from the community before

I commit to a number.

Our setup:

- Windows Server DHCP, hot standby failover mode

- ~250 active scopes

- Mixed environment (corporate, manufacturing sites, guest networks)

- IPv4 only, no IPv6 yet

The default MaxMBFileSize of 70 MB feels way too low for our scale,

and I've already seen the logs roll over faster than I'd like for

forensic/troubleshooting purposes. I'd like enough retention to go

back at least a couple of weeks if we need to chase down a lease

issue or investigate a rogue device.

Currently leaning toward:

- MaxMBFileSize: 1024 MB

- MinMBDiskSpace: 1024 MB

- Path moved off C: to a dedicated log volume

A few questions for those running similar or larger environments:

1. What MaxMBFileSize do you run in production? Did you hit anygotchas at higher values?
2. Do you ship the DHCP logs off to a SIEM / syslog collector, ordo you just rely on the local files? If you ship them, do youstill keep large local retention as a fallback?
3. Anyone hit the "DHCP stops handing out leases when log is full /disk space below MinMBDiskSpace" scenario? Curious how youmonitor for that proactively.
4. For those running hot standby failover like us — do you sizelogs identically on both nodes, or differently based on whichis primary?

Appreciate any war stories or just a quick "we run X MB on Y

scopes, works fine." Trying to avoid both extremes (default 70 MB

loss of history, and runaway disk usage).

Thanks!

Hi everyone,

I'm dealing with a tricky hybrid Exchange scenario and would appreciate some input.

Background:

• User was disabled in AD
• ~30 days later, their EXO mailbox was soft-deleted (no hold applied)
• Now the user is back, AD account re-enabled, license re-assigned
• Admin center shows: "Exchange: An unknown error has occurred. Refer to correlation ID..."

Current state:

On-prem AD:

• msExchRecipientTypeDetails: 1 (UserMailbox)
• msExchRemoteRecipientType: 8 (DeprovisionMailbox)
• msExchMailboxGuid: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx (GUID-A)

On-prem Exchange:

• Get-Mailbox shows the user as a real UserMailbox in an on-prem database
• Get-MailboxStatistics shows ~5GB of content
• ExchangeGuid: GUID-A (same as above)

Exchange Online:

• No active mailbox
• Soft-deleted mailbox EXISTS with a DIFFERENT ExchangeGuid: yyyyyyyy-yyyy-yyyy-yyyy-yyyyyyyyyyyy (GUID-B)
• WhenSoftDeleted: ~11 days ago (still within 30-day window)
• IsInactiveMailbox: False
• LitigationHoldEnabled: False
• InPlaceHolds: empty

My questions:

1. The on-prem mailbox shows 5GB of content but RemoteRecipientType says "DeprovisionMailbox". Is this real content or just stale attributes from a previous state?

2. The two ExchangeGuids (GUID-A on-prem vs GUID-B in cloud soft-deleted) don't match. Which is the "real" mailbox to keep?

3. What's the cleanest path forward:

   • Disable-Mailbox on-prem + Enable-RemoteMailbox + Set-RemoteMailbox -ExchangeGuid <cloud GUID> to recover soft-deleted?
   • Or treat on-prem as primary and use New-MailboxRestoreRequest to migrate to cloud?
   • Or use Set-User -PermanentlyClearPreviousMailboxInfo and start fresh?

I've read the Microsoft KB on "Mailbox exists in both EXO and on-premises" but the 5GB on-prem content is making me hesitant to disable it.

Environment: Exchange 2019 CU on-prem, hybrid with EXO, AD Connect for sync.

Any advice from anyone who has dealt with this before? Thanks!

Title: Hybrid: EXO message trace returns nothing for primary SMTP, but finds the message under tenant.mail.onmicrosoft.com — expected?

Body:

Quick sanity check from the hybrid Exchange folks here.

Internal app → on-prem Exchange → Outbound connector → EXO. On-prem trace looks perfect, message leaves the send connector to O365.

In EXO message trace:

• Search by user@customdomain.com → no results
• Search by user@tenant.mail.onmicrosoft.com → message found

I'm assuming on-prem is rewriting the envelope recipient to the routing address (the user's mail user / remote mailbox has tenant.mail.onmicrosoft.com as a proxy / targetAddress) and EXO trace just indexes by envelope, not by resolved primary SMTP.

Is that the consensus / documented behavior? Or is there something off in my HCW config / remote domain setup that's causing the rewrite to be more aggressive than it needs to be?

Mail delivers fine end-to-end — just a message-trace UX annoyance. Curious how others deal with it.

Thanks.

Hi all,

I have an enterprise app (ChatGPT connector) in Entra ID with Assignment required = true. A user requested delegated permissions like Mail.ReadWrite, which triggers the admin consent prompt.

I understand admin consent is tenant-wide by default — once granted, any assigned user can use those permissions. User consent isn't an option in our tenant (disabled by policy).

Is there a supported way to grant delegated permissions for only one specific user instead of tenant-wide? I know I could technically create an Oauth2PermissionGrant with ConsentType: Principal via Graph API, but I'm not sure if this is supported or reliable for third-party apps like ChatGPT.

Currently considering just keeping the assignment group limited to that one user as a workaround, but curious if there's a cleaner approach.

Any guidance appreciated. Thanks!

Exchange 2019 hybrid + EXO. Migration batch completed successfully for 2 users, mailboxes are active in M365.

Problem: in on-prem ECP these users still show "Mailbox Type: User" instead of Remote Mailbox. As a result:

• Internal mail (from another on-prem user) → delivered to the on-prem mailbox (Outlook)
• External mail → delivered to the EXO mailbox (OWA)

My theory: RecipientTypeDetails is still UserMailbox instead of RemoteUserMailbox, and targetAddress is missing/wrong, so the Hub Transport doesn't route internal mail to EXO.

Planned fix:

1. Grab ExchangeGuid from EXO
2. Disable-Mailbox on-prem
3. Enable-RemoteMailbox with <tenant>.mail.onmicrosoft.com as routing address
4. Set-RemoteMailbox -ExchangeGuid <guid>
5. Delta sync

Has anyone hit this before? Is this the right approach or is there a cleaner way? Any risks I should know about with the ExchangeGuid matching step?

Thanks!

We're seeing Event ID 2889 on our AD DCs (Windows Server, mixed 2019/2022 environment). After enabling the diagnostic logging, the logs show unsigned LDAP bindings (BindingType=0) are coming exclusively from Windows 11 Enterprise end-user workstations — not from servers or service accounts (except one unresolved service account entry).

The affected users are regular domain users logging into their own machines. No custom applications are installed on these PCs beyond standard corporate tools.

Questions:

• Is it normal for Windows 11 clients to generate 2889 events just from standard domain activity (logon, Group Policy, etc.)?
• What's the best way to identify which process on the client is making the unsigned LDAP call — short of running Wireshark on each machine?

Hi,

I have a Windows Server 2022 Workgroup (non-domain) server running DNS role only as a forwarder. It forwards all queries to 2 internal DC/DNS servers. Clients point directly to this server for DNS resolution.

What happened:

Last night I manually installed the April 2026 Cumulative Update and rebooted the server. After reboot I noticed Event ID 404 in the DNS Server event log:

"The DNS server could not bind a Transmission Control Protocol (TCP) socket to address 172.x.x.x"

The DNS service was in Running state after reboot, but forwarder was not working — clients couldn't resolve anything.

Environment:

Windows Server 2022 Workgroup (not domain joined)

DNS role configured as forwarder-only

Forwards to 2 internal DC/DNS servers

Primary DNS on NIC is set to 127.0.0.1

DC/DNS IPs are only in DNS Manager forwarder list — NOT configured in NIC settings

TCP port 53 to both DC/DNS servers is reachable (Test-NetConnection confirmed)

What I've checked:

Test-NetConnection -Port 53 to both forwarder targets → TcpTestSucceeded: True

DNS Service status → Running

Event ID 404 logged once at boot time, never seen before this CU

No Event 404 in logs prior to this CU

Questions:

Could the April 2026 CU have changed DNS service startup behavior causing it to bind before the NIC is ready?

Is setting Primary DNS to 127.0.0.1 on a Workgroup forwarder-only DNS server a problem?

Why would the forwarder stop working even though the service is running and port 53 is reachable on both targets?

Would switching DNS service startup to Automatic (Delayed Start) prevent the Event 404 on future reboots?

Any insights appreciated. Thanks!

Background: Our Azure AD Connect server is running version 2.5.79.0. AutoUpgrade was previously suspended due to UpgradeAbortedInsufficientDiskSpace, and I manually disabled it afterward. I've since freed up disk space and want to re-enable AutoUpgrade.

My concern: Before I run Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled, I want to understand when the upgrade actually triggers — specifically:

1. Does Azure AD Connect AutoUpgrade run at a random time, a scheduled time, or does Microsoft control the timing remotely?
2. Is there any guarantee it won't run during business hours? We can't afford sync interruptions between 08:00–18:00.
3. How long does an AutoUpgrade typically take, and does it cause sync to stop during that window?
4. Is there a way to restrict the upgrade to a specific maintenance window (e.g., nights/weekends) without fully disabling AutoUpgrade?
5. Are there any known issues with version 2.6.3.0 specifically? Any reports of failed upgrades, sync breaks, or post-upgrade problems after AutoUpgrade lands on that version?

What I've tried: I couldn't find a clear official answer on timing behavior in the Microsoft docs — most articles just say "AutoUpgrade runs in the background" without specifying the schedule logic.

Running on Windows Server, SQL LocalDB, single AAD Connect instance (no staging server).

Any real-world experience appreciated!

Background: Our Entra Connect server is running version 2.5.79.0. AutoUpgrade was previously suspended due to UpgradeAbortedInsufficientDiskSpace, and I manually disabled it afterward. I've since freed up disk space and want to re-enable AutoUpgrade.

My concern: Before I run Set-ADSyncAutoUpgrade -AutoUpgradeState Enabled, I want to understand when the upgrade actually triggers — specifically:

1. Does Entra Connect AutoUpgrade run at a random time, a scheduled time, or does Microsoft control the timing remotely?
2. Is there any guarantee it won't run during business hours? We can't afford sync interruptions between 08:00–18:00.
3. How long does an AutoUpgrade typically take, and does it cause sync to stop during that window?
4. Is there a way to restrict the upgrade to a specific maintenance window (e.g., nights/weekends) without fully disabling AutoUpgrade?
5. Are there any known issues with version 2.6.3.0 specifically? Any reports of failed upgrades, sync breaks, or post-upgrade problems after AutoUpgrade lands on that version?

What I've tried: I couldn't find a clear official answer on timing behavior in the Microsoft docs — most articles just say "AutoUpgrade runs in the background" without specifying the schedule logic.

Running on Windows Server, SQL LocalDB, single AAD Connect instance (no staging server).

Any real-world experience appreciated!

Hi,

Microsoft released OOB updates this month (KB5091572, KB5091573, KB5091575, KB5091157) to fix DC reboot loops caused by the April 2026 Patch Tuesday updates.

My question: are these OOB updates only recommended for Domain Controllers, or should they also be applied to non-DC servers (member servers, file servers, app servers, etc.)?

Hi all,

We're running Exchange Server SE on-premises with a Hybrid configuration (Exchange Online coexistence). We have 4 Exchange servers — 2 Prod, 2 DR.

A security assessment flagged that AllowNonProvisionableDevices = True on our Mobile Device Mailbox Policies (both Default and some non-default ones). We want to set this to False.

Before we do, I want to make sure we don't break anything. Here's our environment:

• Exchange Server SE (latest CU)
• Hybrid setup with Exchange Online
• ~500 mailboxes, mix of on-prem and cloud
• Users have iOS, Android devices — mix of native mail apps and Outlook Mobile

My questions:

1. Will this affect Outlook Mobile users? I know Outlook Mobile uses REST not EAS, but want to confirm
2. Will Exchange Online mailboxes (hybrid users) be impacted differently than on-prem mailboxes?
3. What's the safest way to identify which devices will break before flipping the switch?
4. Should I create a separate policy for legacy/non-provisionable devices and assign it to specific users before setting Default to False?
5. Any specific iOS or Android versions known to be non-provisionable with Exchange SE?
6. Is there a way to test this in DR first before applying to production?
7. What's the rollback procedure if users start complaining?

What I've done so far:

• Ran Get-MobileDeviceStatistics — most devices are modern iOS/Android
• Found several stale device partnerships (2018-2019) — planning to clean those up first
• Confirmed Default policy has AllowNonProvisionableDevices = True

Any advice or gotchas appreciated. Thanks!