Forum Widgets
Latest Discussions
Get-EXOMailbox -Filter returns empty when $WarningPreference = 'SilentlyContinue'
Get-EXOMailbox -Filter returns empty when $WarningPreference = 'SilentlyContinue' under UAMI app-only auth Module version: ExchangeOnlineManagement 3.x (PS7, Azure Automation sandbox) Auth method: Connect-ExchangeOnline -ManagedIdentity -ManagedIdentityAccountId <UAMI ClientId> Reproduction steps: $WarningPreference = 'SilentlyContinue' Connect-ExchangeOnline -ManagedIdentity ` -ManagedIdentityAccountId "<UAMI-ClientId>" ` -Organization "yourtenant.onmicrosoft.com" ` -ShowBanner:$false # Returns empty — mailbox provably exists Get-EXOMailbox -Filter "ExternalDirectoryObjectId -eq '<EntraOID>'" # Restore and retry — returns correctly $WarningPreference = 'Continue' Get-EXOMailbox -Filter "ExternalDirectoryObjectId -eq '<EntraOID>'" Expected: Mailbox object returned regardless of $WarningPreference Actual: Returns $null when $WarningPreference = 'SilentlyContinue' Notes: Only affects -Filter parameter under app-only/UAMI auth -Identity and -UserPrincipalName are not affected Delegated auth sessions are not affected $WarningPreference = 'SilentlyContinue' is a common pattern in Azure Automation runbooks, making this a significant undocumented breaking behaviour for automation scenarios
Outlook - Online mode address book search fails with "Operation failed" when Name only is ticked.
I hope you had this issue and managed to solve 😂 pulling my hair already. Symptom: In classic Outlook for Windows, open the Address Book → set Search to Name only → type any single character → "The address book operation failed." Switch to More columns and the exact same search works fine. Ctrl+K resolution in the To: field works. OWA people search works. Mail flow is fine. It's only the Name-only ANR seek in the dialog. Environment: Exchange hybrid, mailbox in Exchange Online, dir-syncedfrom on-prem AD via Entra Connect Classic Outlook for Windows, online mode (Cached Mode is not permitted here — this is the constraint, I can't just flip it) Affects all users, all machines What I've already ruled out: Test Result Other address lists (Contacts, All Users) Same failure Ctrl+K in To: field Works Safe mode (outlook.exe /safe) Same failure — not add-ins Multiple accounts / multiple machines Same failure Brand-new mail profile Same failure — not profile corruption Addressing order (Tools > Options) GAL set first, not "Choose automatically" Off corporate network (5G) Same failure AddressBookPolicy / OfflineAddressBook on mailbox Both blank (inherit defaults) Get-OfflineAddressBook Default OAB, IsDefault: True, web dist enabled Get-GlobalAddressList Default GAL, IsDefaultGlobalAddressList: True, stock default RecipientFilter
Dynamics 365 App for Outlook is not supported Cross Tenant
Hello, I am referring to the disclaimer here which clearly says that Dynamics 365 App for outlook is not supported when the excahange online is on a tenant separate from the Dynmics 365 Sales tenant. This seems to be true even after properly registering the Dynamics 365 as an application in the Azure Tenant of the Exchange Online instance and then configuring the profile etc. all correctly. It is mentioned that the incoming-outgoing emails and appt/contact/task sync will all work through server-side synchronization. But when will this be available for Dynamics 365 App for Outlook in cross-tenant scenario for customers ? As most customers prefer to have their exchange on a dedicated usually the corp hq tenant for better management and then all business apps in different separate tenants based on region/department/child companies ? Please also suggest if there are any workarounds. And kindly give me any pointers to other forums that will be more appropriate for this question, just in case…. Many Thanks https://learn.microsoft.com/en-us/power-platform/admin/connect-exchange-online-server-profile-oauth
HCW - Hybrid Configuration Wizard for Hybrid Certificate
I've gone through about 5 Microsoft Exchange Support Engineers for last two years with Exchange on-line migration and 80% of time running HCW, it caused email outages where the engineers did not know what to do. They've also gave conflicting information on how to correctly run HCW for adding server and to replace certificate. Some say use powershell and some says do not use powershell. Now, I need to replace the hybrid certificate, do I uncheck everything and check only "Update Secure Mail Certificate for connectors" in a centralized transport setup (email flows through on-prem servers) ? I assume uncheck everything will not roll back configurations. I have Microsoft Exchange engineers says it will and some say it won't and they all say they have 20+ experience.Microsoft Blocks EWS Access for Kiosk Users
A December 2 announcement says that Exchange Online will block access to Exchange Web Services for users with kiosk or frontline worker licenses from March 2026. In fact, the Exchange Online service description has always excluded EWS access for these licenses, but the necessary code to enforce the exclusion was never implemented. It will be in March. Time to check licenses… https://office365itpros.com/2025/12/05/exchange-web-services-kiosk/HVE for Microsoft 365: When to Use It, When Not To, and Who Should Be Allowed to Send at Scale
Microsoft recently announced the General Availability of High Volume Email for Microsoft 365, also known as HVE, in Exchange Online. This is an important and long-awaited capability for organizations that need to send large volumes of internal email from applications, devices, or line-of-business systems without using regular user mailboxes as bulk-sending engines. But HVE should not be misunderstood. It does not mean that every mailbox in Exchange Online should now be used for mass email. It does not mean Exchange Online has become a general-purpose marketing platform. And it does not remove the need for proper outbound email governance. Why HVE Matters For years, many organizations have used regular Exchange Online mailboxes, shared mailboxes, or service accounts to send automated messages from applications, scanners, monitoring platforms, ticketing platforms, and custom business applications. That approach creates several problems. Standard mailboxes are designed for human and business communication, not for sustained high-volume automated traffic. Exchange Online has recipient limits, message rate limits, outbound spam protections, and tenant-level controls to protect the service and reduce abuse. HVE introduces a more appropriate model for specific high-volume scenarios. Instead of using a normal mailbox for automated traffic, organizations can create dedicated HVE accounts and use specific SMTP endpoints, admin controls, reporting, and governance for approved high-volume internal messaging scenarios. What HVE Is Designed For HVE is designed for automated, operational, and transactional messaging at scale, primarily for internal recipients within the tenant. Examples include: Internal application notifications. Line-of-business system messages. Device-generated messages. Operational alerts. Security advisories. Internal workflow communications. Monitoring platform alerts. IT service notifications. Large-scale internal announcements generated by systems. This is especially relevant when the organization needs to send messages at scale but still wants to keep the workload within Microsoft 365 governance and Exchange Online mail flow. In practical terms, HVE is useful when the sender is not a human user, but a controlled business system. What HVE Is Not HVE is not a replacement for marketing platforms. HVE is not a general-purpose internet bulk email engine. HVE is not a way to bypass Exchange Online sending limits for external campaigns. HVE is not the correct platform for newsletters, promotional campaigns, large-scale customer communication, or high-volume external transactional email. For external transactional, marketing, or customer-facing bulk email, organizations should evaluate platforms designed for that purpose, such as Azure Communication Services Email, SendGrid, Amazon SES, Mailchimp, Brevo, or another specialized delivery platform. When to Use HVE Use HVE when the workload matches these characteristics: The sender is an application, device, service, or business system. The recipients are primarily internal users in the Microsoft 365 tenant. The volume is higher than what should be sent from a standard mailbox. The workload is operational, automated, or transactional. The organization needs centralized Microsoft 365 administration and reporting. The organization wants to avoid impacting user mailbox sending limits. The use case is approved, documented, monitored, and governed. Good examples: A security platform sending internal security advisories. A monitoring system sending infrastructure alerts to internal teams. A business workflow system sending high-volume approval or status notifications. An IT service platform sending internal notifications. A service management platform sending ticket updates to internal users. A device management system sending operational messages to internal teams. When Not to Use HVE Do not use HVE when the workload is external bulk email. Avoid HVE for: Marketing campaigns. Newsletters to customers. Promotional email. Mass external invitations. External transactional email at scale. Customer invoices and receipts in high volume. OTP or password reset flows for external users. External portal notifications. Any workload where deliverability, bounce handling, reputation management, unsubscribe handling, analytics, or customer consent management are required. Those workloads require a platform designed for external delivery, reputation management, suppression lists, opt-out, tracking, bounce handling, and compliance. Who Should Be Allowed to Use HVE HVE should not be enabled casually for every team or every application. It should be treated as a controlled platform capability. Recommended eligible senders: Approved line-of-business applications. Corporate systems owned by IT, Security, Operations, Facilities, or Service Management teams. Managed devices or services with a clear business purpose. Internal platforms that send operational messages to employees. Applications with documented ownership, authentication, monitoring, and expected volume. Recommended non-eligible senders: Normal users. Shared mailboxes used by humans. Marketing teams sending to external audiences. Unmanaged scripts. Legacy systems with no owner. Applications with unknown volume. Systems that send to external recipients at scale. Any application using HVE just to avoid standard mailbox limits. The core principle is simple: HVE should be enabled for workloads, not for convenience. Governance Model Before enabling HVE, organizations should define a governance model. At minimum, each HVE account should have: A named business owner. A technical owner. A documented purpose. Expected daily and monthly volume. Recipient scope. Authentication method. Monitoring process. Incident response path. Decommissioning criteria. Review frequency. HVE accounts should not become invisible service accounts that nobody owns. They should be treated as privileged communication identities. Security and Authentication HVE supports OAuth authentication, and Microsoft provides guidance for restricting OAuth authentication to specific Microsoft Entra ID applications. This is important because organizations should avoid broad, uncontrolled access. They should restrict which applications can send through each HVE account, monitor usage, and separate workloads by purpose. For example: One HVE account for security alerts. One HVE account for monitoring systems. One HVE account for IT service notifications. One HVE account for internal operational communications. This separation improves visibility, investigation, accountability, and risk containment. HVE vs Standard Exchange Online Mailboxes A standard Exchange Online mailbox should be used for normal human communication. A shared mailbox should be used for collaborative business processes. An HVE account should be used for approved high-volume internal system email. A dedicated external delivery platform should be used for marketing, bulk external communication, or high-volume transactional email. Scenario Recommended Platform Human business email Exchange Online mailbox Team or department mailbox Shared mailbox Low-volume application notifications Standard Exchange Online, if approved High-volume internal system notifications HVE Internal operational alerts at scale HVE Marketing campaigns Marketing platform External transactional email Transactional email service Customer newsletters Marketing automation platform OTP/password reset for external users Dedicated transactional platform External bulk email Dedicated bulk email provider HVE and the Mailbox External Recipient Rate Limit Cancellation Microsoft also announced that the Mailbox External Recipient Rate Limit in Exchange Online was cancelled indefinitely. However, that cancellation should not be interpreted as permission to use Exchange Online for uncontrolled bulk sending. Microsoft was clear that other limits remain unchanged, including the existing Recipient Rate Limit and the Tenant-level External Recipient Rate Limit. That distinction is important. The cancellation of one mailbox-level external recipient limit does not remove the need for proper architecture. Exchange Online still has service limits. Outbound spam controls still apply. Tenant-level protections still matter. And HVE is still not a marketing engine. Practical Architecture Decision Before enabling HVE, ask these questions: Who is sending? Is the sender a human, shared mailbox, application, or device? Who are the recipients? Are they internal or external? What is the expected volume? Is the workload operational, transactional, promotional, or human communication? Does the business need Microsoft 365 mail flow and governance? Does the use case require bounce handling, unsubscribe, tracking, or reputation management? Is the application properly authenticated and monitored? Who owns the account? Who approves the sending pattern? Who responds if the account is abused? If the workload is internal, automated, high-volume, and business-approved, HVE may be the right answer. If the workload is external, promotional, customer-facing, or marketing-driven, use a dedicated email delivery platform. Recommended Enablement Approach Organizations should enable HVE in phases. First, identify existing systems currently using user mailboxes, shared mailboxes, or SMTP AUTH for automated sending. Second, classify each workload as internal, external, operational, transactional, marketing, or human communication. Third, migrate only approved internal high-volume workloads to HVE. Fourth, move external high-volume workloads to dedicated email delivery platforms. Fifth, monitor usage and review HVE accounts regularly. This avoids turning HVE into another uncontrolled sending layer. Conclusion High Volume Email for Microsoft 365 is an important addition to Exchange Online. It gives organizations a native way to support high-volume internal system messaging without using standard mailboxes for automated high-volume traffic. But HVE is not a free pass for bulk email. It is not a marketing platform. It is not a replacement for transactional email services. And it should not be enabled for every mailbox or every application. The right approach is workload classification. Use Exchange Online for corporate communication. Use HVE for approved high-volume internal system messaging. Use dedicated platforms for external bulk, marketing, and transactional email. The question is not only: “Can this system send email through Microsoft 365?” The better architectural question is: “What type of email is this, who is the audience, and what is the correct platform for this workload?” That is where proper email architecture begins.Will server to server migration work cross-domain/cross-active directory?
Back in 2016, I upgraded a client from Exchange 2008R2 to Exchange 2016. The way I did it was "the textbook way" I built the new Exchange 2016 server on the same network as the 2008R2 server, and migrated the mailboxes from the old server to the new server, using the migration tool in the ECP interface, then deinstalled the server. It was a pretty cake migration except for one problem - the internal AD domain name was "wonkulating.com" however the client had failed to maintain public registration for that domain, and had registered "wonkulatinggronkulator.com" for use on the Internet. So I set it up so that all internal and external access was to "email address removed for privacy reasons" User were happy, and the IT dept was able to kick the migration can down the road again. Well fast forward a decade. Now I'm an employee for the former client and worse I manage the IT group there - so my can-kicking bandaid has come back to haunt me now that it's time to update to exchange SE. (it also adds to the fun that there's a couple hundred more users on the network than there were a decade ago) I decided to cut the Gordion knot and kill off "wonkulating.com" since there's not a snowball's chance in hades we could afford to buy it now. So I built a new AD for wonkulatinggronkulator.com, and did the jiggery pokery with the DNS servers and setup trust between the forests and so on and now, servers on both domains are happy happy, I can apply both wonkulating.com and wonkulatinggronkulator.com security objects to server filesystems, users can login to either domain at any workstation regardless of what domain the workstation was joined to, and so on, and we are getting ready to migrate the users and workstations off the old AD and on to the new AD. My question to all of you is this. I'm planning on installing Exchange SE into the new AD forest wonkulatinggronkulator.com and we will move the users over in groups of 10 or 20 or so, so that staff can make sure everyone is happy, can login, get at their files, etc. But what I am wondering is if the exchange servers will cooperate with each other. I'm not using ADMT or any of that to move user objects over to the new server so userIDs will exist in parallel for some time to allow a gradual migration of file and application servers. (we are too big now for the come-in-on-weekend-and-hose-everything-up-in-a-mad-rush-migration-fueled-with-pizza-and-mountain-dew routine) It would be very nice to just kick off a migration job on one of the mailservers and have the inbox copied over, but if I have to I can tear out the mailbox on the old server into a PST file and jam it into the new server via import. Documentation on microsoft.com seems to say at some points the servers will cooperate with each other and at other points it seems to say each mailserver is atomic. Like most orgs we have a bastion host mailserver that touches the actual Internet, the exchange server is only allowed to provide OWA services to the Internet, while the bastion host server (running Linux, by the way) does the actual heavy lifting of spam scanning and filtering out scam mails. Only cleaned mail is passed to the on-prem exchange server. So if the servers -won't- cooperate cross-forest, then I can adjust mail routing on a per-user basis on the bastion host to send incoming mail to the server in wonkulating.com or the server in wonkulatinggronkulator.com depending on which server they are on. Technically, the ACTUAL user ID on the old AD is WONKULATING\exampleuser while on the new AD it will be WONKULATINGGRONKULATOR\exampleuser, so the servers SHOULD be smart enough to know they are different userIDs - except that the server on wonkulating.com was hacked up by me a decade ago to believe it was authoritative for BOTH "email address removed for privacy reasons" and "email address removed for privacy reasons" email addresses and that they were the same userID basically. So, I don't know what's going to happen until I try it and all of the documentation I can find on this matter is pretty fluffy, as it assumes you are moving from a domain name you own to a different domain name you own because you bought a company or something, or you are moving from one mailserver to the other inside of the same forest/domain. Lastly, suggestions to install Exchange SE into wonkulating.com then move it later into wonkulatinggronkulator.com will be /dev/nulled immediately, I'm done kicking the can down the road. There's more than 20 years of garbage in the wonkulating.com AD and the nonsense described here is just the tip of the iceberg. (you should see the GPO's in wonkulating.com, simply horrifying) Thanks!Import Bulk PST to Office 365 Step by Step | Stellar Migrator for Outlook
Learn how to import bulk PST files to Office 365 (Exchange Online) step by step using Stellar Migrator for Outlook. This tutorial walks you through automating the migration of multiple PST mailboxes to Exchange Online — no manual uploads, no scripting. Stellar Migrator for Outlook automates bulk PST-to-Office 365 migration, letting you map source PSTs to target Office 365 mailboxes (Primary, Archive, or Public Folder), apply filters, and run the whole job with minimal effort — without worrying about duplicate emails. It's a reliable way to move legacy mailboxes into Office 365. Using a CSV file, you can migrate unlimited PST files to Office 365 users from the same system or across networked systems. The software also supports incremental migration, so you can resume or re-run a job and only new items get imported — no duplicates, no reprocessing what's already migrated. Learn more: https://www.stellarinfo.com/import-pst-to-office-365.phpExchange Online PowerShell Updates to 3.10.1 to Fix CBA
Microsoft rushed out version 3.10.1 of the Exchange Online management PowerShell module to fix a problem with certificate-based authentication. It seems like a change in an internal Microsoft identity platform caused the tokens issued after a successful connection to Exchange Online to not authorize the execution of further cmdlets. To their credit, Microsoft fixed the issue, but is this the kind of thing that should be caught in testing? https://office365itpros.com/2026/07/27/exchange-online-management-3-10-1/
