Azure Arc Server Forum: 2026 Updates
We are excited to announce the fourth calendar year of the Azure Arc Server Forum. We are incredibly thankful to all the customers and community members, who have joined our forum and newsletter from our start back in the Fall of 2023. From January 2026, the monthly Azure Arc Server Forum will be hosted on the third Thursday of each month from 9:30 – 10:15 AM PST. Each Arc Server Forum includes live demos of new capabilities, question and answer sessions with the product group, and feedback opportunities covering Windows, Linux, and SQL Server management, licensing, and connectivity across hybrid, multicloud, and edge environments. Sessions are skipped in July and December for summer and winter holidays respectively. Forum participants also receive a monthly newsletter summarizing updates including: Announcements of General Availability, Public Preview, and Private Previews capabilities including key details and documentation Updates on agent improvements and updates on experience changes Opportunities to provide feedback to and influence the product group’s roadmap or engage in ongoing customer research studies Updates on the invitation and timing of the Arc Server Forum Recordings from the Arc Server Forum are periodically uploaded to the Azure Arc Server Forum YouTube channel: Azure Arc Server Forum - YouTube typically within 2-3 weeks of the Forum. To sign up for the Azure Arc Server Forum and newsletter, please register with contact details at https://aka.ms/arcserverforumsignup/. Thank you!
Hybrid Configuration Wizard fails to run – manifest download error on all machines
Hello, I am unable to run the Exchange Hybrid Configuration Wizard (HCW) for our Exchange 2016 environment. The issue occurs on multiple machines and networks, so it does not appear to be a local configuration problem. Environment: Exchange Server: 2016 CU23 Windows versions tested: Windows Server 2016, Windows 10 (all fully updated) .NET Framework: 4.8 (Release 528040 / 4.8.03761) TLS: TLS 1.2 enabled, SSL 3.0/TLS 1.0/1.1 disabled Network: No proxy, firewall, or other network restrictions; internet access available Problem: When attempting to run HCW via https://aka.ms/HybridWizard, the wizard fails to start. I have also tried to run HCW offline by downloading Microsoft.Online.CSE.Hybrid.Client.application, but it immediately fails. The error log shows the following repeated messages: Downloading file:///C:/Users/.../Application Files/Microsoft.Online.CSE.Hybrid.Client_17_1_3902_0/Microsoft.Online.CSE.Hybrid.Client.exe.manifest did not succeed. Could not find a part of the path 'C:\Users\...\Application Files\Microsoft.Online.CSE.Hybrid.Client_17_1_3902_0\Microsoft.Online.CSE.Hybrid.Client.exe.manifest' This occurs on all tested machines (three PCs across three different networks). ClickOnce cache has been cleared, root certificates are up-to-date, .NET is 4.8, and TLS 1.2 is active. Attempts to resolve: Ensured TLS 1.2 is enabled and default in .NET and OS Verified .NET 4.8 installation Cleared ClickOnce cache (rundll32 dfshim CleanOnlineAppCache) Updated root certificates Tried multiple machines and networks Tried to run offline using .application file and local copy of Application Files Result: HCW fails immediately with DeploymentDownloadException / DirectoryNotFoundException for the manifest. The issue is reproducible on all tested machines. Request: Please advise if there is an official offline installation method for HCW or a way to obtain a working manifest. If this is a temporary issue with the hosted distribution, please confirm expected resolution or workaround. Thank you for your assistance.
Exchange 2016 Mail Flow is Not Working
We had issues with updating to a latest Cumulative Update and messed up our EMS and some Web Config. It seems our Exchange Server is totally bricked. So, we decided to boot our Exchange Server from backup. The backup was dated September 2025. Unfortunately, after booting up the September 2025 backup, we noticed that the internal and external mail flow is not working (our Exchange 2016 is Exchange hybrid configured). The outgoing emails are stuck in Draft folder. The following troubleshooting steps have been done to no avail: -Checked if the port 25 is open -> This port is opened -Check the network settings if the Preferred DNS Address points to the correct DNS Server --> It points to the correct DNS Server -Modified the DNS lookup under Exchange Admin Center > Servers > DNS Lookups > Internal DNS Lookups --> Added the IP Address of the DNS Server -Modified the hosts file under System32 > drivers > etc --> Pointed the IP Address of the Exchange Server to the FQDN of the Exchange Server Currently, are not sure of the next steps to do in order to fix the issue. Any advice?
OL client in-app link for getting OL for iOS or Android not working
Hello! Redirected to this forum from here: https://learn.microsoft.com/en-us/answers/questions/5617563/ol-desktop-link-broken-file-get-ol-app-for-ios-and See error description and attempt to solve it by following the link. For some reason, Windows clients in our organization can not follow the Outlook desktop client in-app link for getting Outlook for iOS or Android. (hybrid, no mailboxes in MS-cloud, only on prem) The link for getting the Outlook app for iOS and Android under File when logged into Outlook app does not seem to work. Clicking on it seems to send user to the URL: go.microsoft.com/fwlink/?LinkId=2112779 but quickly redirects and ends up with https://w2.outlook.com/l/mobile?WT.mc_id=Backstage**Win32**All**Hyperlink** https://learn-attachment.microsoft.com/api/attachments/cb7d456f-ac6e-4566-a4ef-ffa912500423?platform=QnAhttps://learn-attachment.microsoft.com/api/attachments/cb7d456f-ac6e-4566-a4ef-ffa912500423?platform=QnA We haven't been able to figure out why, but since the same two different accounts mentioned in the thread above works on a private device on a private home network, is seems like something in our environment is the cause.
Scoping application Crestron to access only room mailboxes of resourcetype Workspace
We got a requirement for to enable application Crestron to be able to access Workspace resourcetype Room mailboxes only. So, we thought of directly tieing the application to these mailboxes over the usual way of assigning it to a group because we had to create a group just for to maintain this delegation. Below are the steps we performed: #Create management scope Connect-ExchangeOnline New-ManagementScope -Name "Workspace Mailboxes" ` -RecipientRestrictionFilter "((RecipientTypeDetails -eq 'RoomMailbox') -and (ResourceType -eq 'Workspace'))" #Assign the management scope to Roles New-ManagementRoleAssignment ` -App "<AppID>" ` -Role "Application Calendars.ReadWrite" ` -CustomResourceScope "Workspace Mailboxes" ` -Name "MyApp-WorkspaceOnly" New-ManagementRoleAssignment ` -App "<AppID>" ` -Role "Application MailboxSettings.Read" ` -CustomResourceScope "Workspace Mailboxes" ` -Name "MyApp-WorkspaceOnly-Settings" #Verified the assignment via: Get-ManagementRoleAssignment -App "<AppID>" | ft Name, Role, CustomResourceScope Name Role CustomResourceScope ---- ---- ------------------- MyApp-WorkspaceOnly Application Calendars.ReadWrite Workspace Mailboxes MyApp-WorkspaceOnly-Settings Application MailboxSettings.Read Workspace Mailboxes Tested the scope of the assignment with a non-workspace mailbox and a workspace mailbox, the scope resulted false for non-workspace mailbox and true for a workspace mailbox. Later, admin consented for API permissions Calendars.ReadWrite, Mailboxsettings.Read & User.Read.All and generated an application secret with validity of 180 days to the application team and shared the secret key. ISSUE: When application team tested the access from Crestron application for a workspace mailbox it is resulting in Authentication Failed. This is the actual issue. In order to test whether this is happening because of scope , performed the below steps: $TenantId = "<TenantID>" $AppId = "<AppID>" $ClientSecret = "<ClientSecret>" $Body = @{ grant_type = "client_credentials" client_id = $AppId client_secret = $ClientSecret scope = "https://graph.microsoft.com/.default" } $TokenRequest = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$TenantId/oauth2/v2.0/token" ` -Method POST -Body $Body $AccessToken = $TokenRequest.access_token $WorkspaceMailbox = "<email address removed for privacy reasons>" Invoke-RestMethod ` -Uri "https://graph.microsoft.com/v1.0/users/$WorkspaceMailbox/events" ` -Headers @{Authorization = "Bearer $AccessToken"} The expected results for this test was to receive Workspace mailbox → Returns events. Non-Workspace mailbox → Should return 403 Forbidden. However, it resulted events in both the cases, when dug further I realised that Graph API will override the management scopes created at Exchange level, so need guidance on how we can take this further.
Need to Purge DiscoveryHolds Data from Archive Mailbox in Exchange Online
Hello Team, I am working on an Exchange Online mailbox where the archive mailbox has accumulated a large amount of data (over 335 GB) under the Recoverable Items → DiscoveryHolds folder. The mailbox is not on Litigation Hold or Retention Hold, and the InPlaceHolds property shows exclusions (-mbx...), so there are no active holds preventing deletion. Environment Details Service: Exchange Online Mailbox: email address removed for privacy reasons Archive mailbox size: ~335 GB DiscoveryHolds subfolders contain the bulk of the data. Background : Initially, the user’s primary mailbox was full because more than 100 GB of data resided in the Recoverable Items folder of the primary mailbox. Since I was unable to delete the data, so as a workaround, I enabled the archive mailbox and moved the data there. I have raised multiple tickets with Microsoft, but after more than 45 days, I still do not have a proper resolution. Mailbox Hold Status PS H:\> Get-Mailbox -Identity email address removed for privacy reasons -Archive | fl *hold* LitigationHoldEnabled : False RetentionHoldEnabled : False EndDateForRetentionHold : StartDateForRetentionHold : LitigationHoldDate : LitigationHoldOwner : ComplianceTagHoldApplied : True DelayHoldApplied : False DelayReleaseHoldApplied : False LitigationHoldDuration : Unlimited SCLDeleteThreshold : SCLRejectThreshold : SCLQuarantineThreshold : SCLJunkThreshold : InPlaceHolds : {-mbx23233XXXXXX, -mbx212433XXXXXX} RecipientThrottlingThreshold : Standard PS H:\> Get-MailboxFolderStatistics -Identity email address removed for privacy reasons -Archive -FolderScope RecoverableItems | ft Name,ItemsInFolder,FolderAndSubfolderSize Recoverable Items : 0 335.2 GB DiscoveryHolds : 80495 335.2 GB DiscoveryHolds_2022 : 177 20.7 MB DiscoveryHolds_2023 : 350 88.12 MB DiscoveryHolds_2024 : 4117 1.34 GB DiscoveryHolds_2025 (multiple subfolders): 47 GB – 55 GB each Issue : I need to purge only the DiscoveryHolds data from the archive mailbox without affecting other folders. I tried using Search-Mailbox , but received: The term 'Search-Mailbox' is not recognized as the name of a cmdlet... I understand that Search-Mailbox is deprecated in Exchange Online. Also, the Content search is not very helpful.
EWS Autodiscover Process in Hybrid with "internal" Exchange Servers
Hi everyone, i really need help about the EWS Autodiscover process in a specific hybrid Environment. Customer is starting to use Exchange Online. For Full Hybrid configuration there is a seperate new Exchange SE with a valid certificate, NAT for IP Ranges from M365 and public available URLs for Autodiscover,EWS,... There are internal Exchange Servers which are used only for internal access. Those are the servers with all mailboxes. All URLs are configured for internal use (mail.contoso.internal) Migration is working, access to own calender is working, mailfllow is working. But there are problems to access other users calender. If a user which is migrated to Exchange Online (or via Teams) try to access another calender which is onPrem, there is no access. So i tried to use connectivity analyzer for teams integration to find out whats the problem. Result: Autodiscover resolves, connects to Hybrid and gets EWS URL as answer. But it gets the internal EWS URL from the internal Exchange Servers, not from the public available URLs which are configured at the hybrid server. I visualised the two scenarios. Number1: Thats how i thought it would work Autodiscover to autodiscover.contoso.com Hybrid answers with EWS URL: hybrid.contoso.com Connect from EXO to hybrid EWS URL Proxy to Internal Exchange Number2 : Thats what really happens Autodiscover to autodiscover.contoso.com Hybrid relays request to internal Exchange (Mailbox Server) Server answers with internal EWS URL: mail.contoso.internal Connect from EXO to internal EWS URL (which is obviously not working) So as you can see, the autodiscover process asks the internal Exchange for its EWS URLs and not as i expected the hybrid server's URLs. I always thought, the hybrid server works as a sort of proxy for every external connection from EXO. But it seems that the hybrid just relays the autodiscover request to the server which holds the mailbox. And this servers in this scenario cannot change their EWS URLs to a public resolvable FQDN. So my question is: Is this correct? Does the process always works like this or did i do anything wrong in the configuration? I hope you understand my explanation. Thanks in advance!!!
