Reference Architecture for an On-Premises AI Assistant for Microsoft Exchange.
Bringing Secure AI Capabilities to On-Premises Microsoft Exchange Many organisations continue to operate Microsoft Exchange within their own data centres because of regulatory requirements, data-residency policies, security considerations, operational dependencies, or the need to maintain complete control over sensitive email information. At the same time, users increasingly expect Artificial Intelligence to help them manage growing email volumes, understand long conversation threads, locate information quickly, analyse attachments, and prepare relevant responses. This creates an important question: Can organisations introduce AI-assisted email capabilities without migrating their on-premises Exchange environment or sending email data to public AI services? With the right architecture, the answer is yes. The opportunity for AI in on-premises Exchange Users spend a significant amount of time reading lengthy email chains, searching for previous discussions, identifying action items, reviewing attachments, and preparing responses. An AI-powered email assistant can help reduce this effort while continuing to operate within the organisation’s controlled infrastructure. Such a solution can be integrated with Microsoft Exchange through an Outlook Web App, or OWA, Add-In. The Add-In provides AI-assisted capabilities within the familiar Outlook Web interface and can be centrally deployed to selected users or Active Directory groups by the Exchange administrator. The purpose is not to replace Exchange or change the way emails are managed. Instead, it introduces an intelligence layer that helps authorised users interact more efficiently with the email information they are already permitted to access. Key capabilities of an AI-powered Exchange Email Assistant 1. Email and conversation summarisation The assistant can summarise an individual email or an entire conversation thread. Instead of reading every message in a long chain, the user can receive a structured summary covering: The purpose of the conversation. Important decisions and commitments. Key action items. Deadlines and pending responses. Relevant information available in attachments. The summarisation process can consider both incoming and sent messages so that the complete context of the conversation is preserved. 2. Contextual draft reply generation The assistant can prepare a suggested response based on the complete email thread and the user’s instructions. Users may select an appropriate tone, such as: Formal. Neutral. Technical. The generated response is placed in the user’s Exchange Draft folder or displayed for review within the OWA Add-In. A critical control is that the AI assistant does not independently send the email. The user remains responsible for reviewing, editing, approving, and sending the response. This human-review approach helps organisations adopt AI while retaining accountability over external and internal communications. 3. Natural-language mailbox search Traditional mailbox search generally depends on exact keywords, sender names, subjects, or date filters. An AI-enabled search experience allows users to search their mailbox using natural-language questions, such as: “Find emails received last month regarding the infrastructure renewal.” “Show unread emails from the finance team that require my approval.” “Find the discussion where the customer confirmed the delivery date.” “Summarise emails from a particular sender concerning the purchase order.” The solution can combine semantic search with traditional keyword-based search to improve the relevance of results. Users can also apply filters such as sender, subject, date range, read or unread status, and conversation thread. 4. Attachment analysis and OCR Important information is often contained within email attachments rather than the email body itself. An on-premises AI assistant can process supported documents, including: PDF files. Microsoft Word documents. Microsoft Excel files. Scanned documents. Image-based attachments. Optical Character Recognition, or OCR, can be used to extract information from scanned or image-based documents. The extracted content can then support email summarisation, contextual draft generation, and mailbox search. For example, a user may ask the assistant to prepare a response based on the commercial terms or delivery date mentioned in an attached document. Maintaining strict mailbox privacy Mailbox privacy is one of the most important architectural considerations for an enterprise AI email assistant. Each user must only be able to access and process emails from their own authorised mailbox. Information retrieved from one user’s mailbox must never become available to another user. This isolation should be enforced across every layer of the solution, including: User authentication. Exchange access tokens. Application sessions. Search indexes. Vector embeddings. AI prompts and responses. Cache and temporary data. Audit logs. The backend should validate the authenticated user and verify mailbox ownership for every request made to Exchange. Where vector search is used, mailbox data should be stored in user-isolated collections, partitions, or namespaces. This helps prevent cross-user retrieval at the data layer rather than relying only on controls within the user interface. Operating without public cloud AI services For organisations with strict security or data-sovereignty requirements, the AI models and supporting components can be deployed within the customer’s infrastructure. A fully on-premises architecture may include: A locally hosted Large Language Model. An on-premises embedding model. A re-ranking model. A vector database. A keyword-search engine. A backend API layer. An OCR or document-intelligence service. A secured OWA Add-In. Integration with Active Directory. Audit, monitoring, and administrative controls. The entire solution can operate within an internal network without sending email content, attachments, prompts, or generated responses to public AI platforms. This model can also support air-gapped environments where internet access is either restricted or completely unavailable. Centralised deployment and administration The OWA Add-In can be deployed centrally through Exchange administration controls. Administrators can assign the Add-In only to selected users or security groups. Employees who are not assigned the solution will not see the AI assistant within their Outlook Web interface. Administrative controls may include: User and group assignment. Enabling or disabling individual AI features. Summarisation-only mode. Draft-generation controls. Attachment-size restrictions. Session and retention policies. Model and performance settings. Usage monitoring. Audit logs. Resource utilisation monitoring. These controls allow organisations to begin with a limited group of users and gradually extend the solution after validating performance, security, and user adoption. Security and governance considerations Introducing AI into an enterprise email environment requires more than deploying a language model. The complete solution should be designed around security, privacy, governance, and responsible AI principles. Important considerations include: Authentication and authorisation The solution should integrate with the organisation’s existing identity infrastructure, such as Active Directory, and enforce role-based access controls. Encryption Email content, attachments, indexes, logs, and other sensitive information should be encrypted both in transit and at rest. Data retention Organisations should clearly define whether AI prompts, generated summaries, and draft content are retained. In privacy-sensitive environments, generated content may remain available only for the active session and should not be permanently stored by the AI application. Auditability The system should record relevant operational events, such as the user identity, requested function, timestamp, and processing status. Depending on the organisation’s policy, the actual email or generated response content may be excluded from audit logs. Human oversight AI-generated responses should be treated as suggestions. The user must review and approve them before sending. The assistant should also disclose its limitations and avoid presenting uncertain outputs as confirmed facts. Performance and capacity On-premises AI processing depends on available compute, memory, storage, and GPU resources. The architecture should account for: Number of concurrent users. Average mailbox size. Volume and size of attachments. Expected response time. Model size. Search-index growth. OCR processing requirements. High availability and backup requirements. A practical adoption approach Organisations do not need to introduce all capabilities at once. A controlled proof of concept can begin with a limited number of users and a defined set of features. A practical implementation sequence may include: Phase 1: Email summarisation Start with individual email and conversation-thread summaries. This provides immediate value while keeping the initial architecture relatively focused. Phase 2: Contextual draft replies Introduce draft generation with mandatory user review and clearly defined tone controls. Phase 3: Attachment processing Enable OCR and document parsing for supported attachments. Phase 4: Intelligent mailbox search Index authorised mailbox content and introduce natural-language search with strict per-user isolation. Phase 5: Wider deployment After security testing, performance validation, and user feedback, extend the solution to additional departments or user groups. Conclusion Organisations operating on-premises Microsoft Exchange do not necessarily need to choose between maintaining control over their email environment and adopting AI-assisted productivity capabilities. A carefully designed on-premises AI email assistant can support email summarisation, contextual draft preparation, attachment analysis, and natural-language mailbox search while keeping sensitive information within the organisation’s infrastructure. The most important success factors are not limited to the AI model itself. Identity controls, mailbox isolation, human approval, auditing, infrastructure sizing, and data-governance policies are equally important. For organisations evaluating private, sovereign, or air-gapped AI, on-premises Exchange can become an effective starting point for introducing practical AI capabilities in a secure and controlled manner. Connect with us to implement this solution in your organization. About the Author Vinay Prakash is the CEO of Glorious Insight and an Ex Microsoft Employee. He works with organisations on Data, Artificial Intelligence, Microsoft cloud technologies, enterprise applications, and secure on-premises AI solutions. For technical discussions related to private or on-premises AI adoption, he can be reached at: Email: email address removed for privacy reasons
Exchange 2019 + ADFS is it possible to configure ModernAuth for third-party Android mail clients?
Hello, Our organization operates under Uzbekistan's data localization and banking secrecy regulations, which require customer and corporate data — including email — to remain on infrastructure physically located within the country and under direct regulatory oversight. This precludes the use of cloud-hosted mail services such as Microsoft 365/Exchange Online, and requires a fully on-premises Exchange deployment with local identity federation (AD FS) instead of Azure AD. Environment: Exchange Server 2019 CU14, single server (MX01), pure on-premises. AD FS is registered as an AuthServer (Type: ADFS), no Azure AD / hybrid tenant involved. The AuthServer is configured correctly: AuthorizationEndpoint and TokenIssuingEndpoint are populated, IsDefaultAuthorizationEndpoint: True, and DomainName points to our mail domain. Realm/ServiceName are configured as well. Symptom: The native iOS Mail client (account added manually, no MDM profile) correctly redirects to our AD FS login page on first setup — the full Modern Auth flow works. A third-party EAS client (Nine by NitroDesk, Android) never receives an OAuth challenge at all — it falls back to Basic authentication. Get-ActiveSyncVirtualDirectory/Set-ActiveSyncVirtualDirectory in this build simply has no -OAuthAuthentication parameter (unlike EWS/OAB). Log finding: When testing with the Nine client, the following was captured in the Exchange HttpProxy/Eas logs: S:ServiceCommonMetadata.OAuthError=Flighting is not enabled for domain 'webmail.<domain>'. S:ServiceCommonMetadata.OAuthErrorCategory=OAuthNotAvailable Questions: What exactly controls "Flighting" for EAS OAuth in a pure on-prem Exchange 2019 CU14 + AD FS scenario (no Azure AD)? Is there a documented, supported way to enable it (New-FlightOverride? something else)? Is EAS Modern Auth even supported for an arbitrary/generic OAuth client (not Apple, not Outlook) in this scenario, or is it effectively an allowlist limited to specific client_ids (Apple Native Mail / Outlook)? How does native iOS Mail get redirected to AD FS without ever receiving an authorization_uri in the EAS/Autodiscover 401 challenge — is there an undocumented discovery path (e.g., hardcoded per registered client_id)? Thank you in advance for any insight.The Demise of the OWA Light Client
On July 8, Microsoft said that they will retire the OWA Light client for Exchange Server in August 2026. But what happened to the OWA Light client for Exchange Online? It seems like Microsoft announced the retirement of OWA Light for Exchange Online in June 2024, but didn’t really make the fact clear in a blog post about consumer accounts. In any case, you can’t run OWA Light for Exchange Online, even if you wanted to. https://office365itpros.com/2026/07/17/owa-light-retirement/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!
Can we hide default address lists in Outlook Address Book and show only custom ones?
There are existing Custom Address Lists. When users use the MS Outlook App (Office 2019) and open the Address Book, is it possible to hide the other address lists (including domain-sg-GAL, Global Address List, and domain-sg-Rooms), and only display the Custom Address Lists (domain-HK-AL and domain-sg-AL) — the ones shown in green in the photo?Permission activesync on smartphone
Hi everyone, when you grant the permissions in question to manage company email from a smartphone, do these permissions, in addition to Remote Wipe, Password Enforcement and Device Encryption (I remember these as the main ones), somehow give the Exchange administrator access to my personal data? For example, photos, any documents saved on the SD card or on the smartphone itself? Thanks in advanced!
Exchange Server to Exchange Online Migration: A Pre-Migration Readiness Checklist
Over the years, I have worked on numerous Exchange Server to Exchange Online migration projects alongside Exchange administrators, IT teams, and MSPs. One consistent pattern I have noticed is that most migration issues do not originate during the migration itself — they surface because of gaps in pre-migration readiness. This checklist reflects what I have found most useful before starting any Exchange to Exchange Online migration. Inventory and Assessment Before touching any migration tooling, run a full inventory of your on-premises Exchange environment. This includes the Exchange Server version (2013, 2016, 2019), the number of mailboxes, database sizes, public folders, shared mailboxes, archive mailboxes, and any resource mailboxes such as rooms and equipment. Many teams also forget to document their distribution groups, dynamic distribution groups, and mail-enabled contacts. All of these need to be accounted for before you begin. 2. Active Directory and Entra ID Readiness Check that your Active Directory is clean: no duplicate UPNs, no lingering objects, and no ambiguous legacy Exchange attributes. Verify that Microsoft Entra Connect (formerly AAD Connect) is installed, configured, and synchronizing without errors. Confirm the UPN suffix used in AD matches a verified domain in your Microsoft 365 tenant. Attribute mismatches between on-premises AD and Entra ID are one of the most common causes of post-migration issues with authentication and mail flow. 3. Mail Flow and DNS Document all current MX records and any third-party mail filtering (SEG, anti-spam appliances). Plan whether you will cut over MX during the migration or keep a hybrid mail flow via Exchange connector. Verify SPF, DKIM, and DMARC records are in place for each domain. Applications and devices that use on-premises SMTP relay also need to be identified early — these often get missed and cause disruption after the migration window. 4. Licensing and Tenant Configuration Confirm you have sufficient Exchange Online licenses assigned or ready to assign before the migration starts. Review your tenant for any conditional access policies that may block newly migrated users. Check the Microsoft 365 admin center for any service health issues that could affect the migration window. Also confirm your tenant's default accepted domains and any aliases that need to be added. 5. Coexistence and Hybrid Considerations If you are running a hybrid migration (which is the recommended approach for most organisations with more than a few hundred mailboxes), confirm the Hybrid Configuration Wizard has been run and that the hybrid connector tests pass. Free/busy lookup, OAB distribution, and cross-premises message tracking should all be tested before you move any mailboxes. A common oversight is failing to validate OAuth configuration for modern authentication in hybrid — this affects calendar sharing and delegate access after migration. 6. Data and Backup Before migrating any mailbox, verify that a recent backup of your Exchange databases exists and is recoverable. If you are running a DAG, confirm all database copies are healthy and no replay queues are building up. It is also worth checking the size and age of any archive mailboxes — large archives can significantly extend migration time and should be planned for separately. What patterns have you seen in your environments? Are there specific pre-migration steps that have saved (or cost) you the most time? Happy to discuss further.BIMI Logos – Another Way to Stop Email Spoofing
Brand Indicators for Message Identification (BIMI) is a new industry effort to help identify email from reputable companies by displaying their logo alongside email (and potentially other items) in applications. https://office365itpros.com/2018/12/06/bimi-office365/
Offboarding mailboxes fails with “PropTagToPropertyDefinitionConversionException.”
Hybrid M365 setup, just recently upgraded the on-prem server from Exchange 2019 to Exchange SE. After doing so, migrations from Exchange Online back to Exchange On-prem fail at 10% with the error “PropTagToPropertyDefinitionConversionException.” I opened a case with M365 exchange support, and after some time, they came back to tell me that the Exchange Online portion of the process is not at fault, and that I have to engage the on-premise support team (this seems a little nuts to me, as its all connected and all supported, but I've been in this business for 30 years now, and it's not the first time I've seen buck-passing), and/or ask this community for help. Hence, this post. That error appears exactly two places on the internet, as far as I can tell: a blog (in German) from an Exchange expert doing cross-tenant migrations, and a page at https://west.jcteams.info/bhit11/docs/EX1232513.html that seems to describe my exact issue. Neither had useful suggestions - mostly, they say this: Set-MoveRequest -Identity "<UserPrincipalName>" -SkipMoving FolderRestrictions Resume-MoveRequest -Identity "<UserPrincipalName>" That didn't actually work, but when I tried the same parameters with Set-MigrationBatch, they worked as long as I ignored the message "The SkipMoving parameter is deprecated. Use the MoveOptions parameter instead. If you have any scripts that use the SkipMoving parameter, update them to use the MoveOptions parameter." So what was a simple process is now a more cumbersome workaround. Does anyone have an idea on how to troubleshoot "PropTagToPropertyDefinitionConversionException?"
