Planning the Monitoring of my hybrid environment.
Hello folks, By now you may have read that I’ve rebuilt my demo environment to look like what a typical hybrid environment would look like. I did it slowly without having to rip and replace everything in my on-prem environment. Started out with establishing a site-to-site VPN, then a solution to remote into all the servers in my environment, configured a resilient way of resolving the names of all servers in my hybrid deployment, and lastly, configuring an Azure Arc Private Link Scope so that all my on-prem machines could connect to Azure using the VPN and not the open internet. Now as I look at all the operational tasks I need to implement (monitoring/insights, patch management, change management, etc...) To support all these operational requirements, I need the common underpinning provided by the Azure Log Analytics workspace.
Recycle Bin and Site Content Hidden for Site Members and Site Visitors
I posted this before but made a mistake with my write up, so I am reposting. I have a requirement that the Recycle bin and Site Contents should be be hidden from the Site Members and Site Visitors. Please how can I achieve this because the Server Infrastructure activation is not working for me. Any workarounds? Please helpDynamic Mandatory Fields
In a SharePoint library, I have folders which are = a. Admin b. Events c. Furniture and Moves d. Janitorial and Maintenance e. Parking and Transportation f. Shipping and Receiving g. Supplies and Equipment h. Waste and Recycling I have Meta data across the library whose data type are all choices and are: a. Document Type = Contract, Financial, planning b. Building = Gym, Garage, Heating c. Asset Category = Office, Playground d. Fiscal Year = FY23, FY24, FY25, FY26, FY27 e. Vendor = Maple Leaf, Canadian Tire, Home Depot f. Status = Active, Pending, Not Active g. Retention Label = 3 years, 5 years h. Service Type = Admin, Events, Furniture and Moves, Janitorial and Maintenance, Parking and Transportation, Shipping and Receiving, Supplies and Equipment, Waste and Recycling Service Type and Retention Label are mandatory fields, with the Rule below for all the files in the various folders: IF Folder Name = Admin, then Service Type = Admin and Retention Label = 5 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Events, then Service Type = Events and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year, Building and Vendor IF Folder Name = Furniture and Moves, then Service Type = Furniture and Moves and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Building IF Folder Name = Janitorial and Maintenance, then Service Type = Janitorial and Maintenance and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Parking and Transportation, then Service Type = Parking and Transportation and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Shipping and Receiving, then Service Type = Shipping and Receiving and Retention Label = 3 years; the mandatory fields should be Document Type, Status IF Folder Name = Supplies and Equipment, then Service Type = Supplies and Equipment and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Fiscal Year IF Folder Name = Waste and Recycling, then Service Type = Waste and Recycling and Retention Label = 3 years; the mandatory fields should be Document Type, Status and Vendor I have used Column Default Value Settings for SharePoint to display Auto-Display the Service Type and Retention Label, but I cannot seem to perform the conditional mandatory fields using Validations setting for the other requirements. Please helpHVE 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.
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.Build, deploy, and govern sovereign AI with Foundry Local on Azure Local
Not every AI workload can run in the cloud. For many of our customers, data needs to stay within defined boundaries, connectivity may be limited or absent, and latency, governance, and auditability are non-negotiable. With Foundry Local on Azure Local, you can use the same model catalog, developer workflows, and governance capabilities you know from Azure, while running AI entirely within your own environment where your data resides. Foundry Local provides the model catalog and developer experience. Azure Local provides the customer-managed infrastructure. Azure Arc provides unified policy, governance, and lifecycle management across cloud and local environments. This gives developers a consistent way to build, deploy, and operate AI. The same az commands, the same model catalog, the same Arc policies, all running on hardware you control. Expansion of Foundry Local on Azure Local We're expanding the Foundry Local model offering on Azure Local, with support for multi-node deployments and new agents and tools that run locally, in preview. Deploy and run AI models locally. Run models with Foundry Local in customer-managed environments on Azure Local, across sovereign, private, and edge scenarios, including fully disconnected operation. Choose from a flexible, high-performance model catalog. Access proprietary and community models through Foundry Local, now expanded with vLLM-optimized models alongside ONNX-based offerings. You explore and deploy through the same catalog API experience, then operate locally on Azure Local. Build for production realities. Bring governance, identity, and auditability into your applications while keeping execution inside your controlled boundary. See what’s new in Foundry Local on Azure Local in the Tech Community blog. From intelligence to action: agents and tools inside the enterprise boundary Most production AI use cases need two things: grounded answers and the ability to act on them, without sending data outside the environment. Here's how we're enabling that locally. Preview: Agentic retrieval with Foundry Local: Ground agents in enterprise data using retrieval-augmented generation across local Microsoft 365 services, including Exchange and SharePoint. Read the Tech Community blog to learn more. Preview: Agents and tools with Foundry Local: Build AI systems that reason, retrieve information, and take action within customer-controlled environments. Learn more. Preview: Developer acceleration templates: Jump-start local AI application development with new Foundry solution templates, including local chat experiences and video agents, powered by Azure AI Video Indexer. Read the Tech Community to learn more. GitHub Enterprise Local: Now available in public preview Sovereign AI is also about how systems are built and secured, not just where they run. With GitHub Enterprise Local on Azure Local, you can bring your full software development lifecycle on-premises: Source control and repositories CI/CD pipelines Security and DevSecOps workflows GitHub Enterprise Local deploys entirely within customer-owned infrastructure, so teams get the developer tools they expect without compromising on data residency or operational control. This extends modern DevSecOps practice into sovereign environments and pairs naturally with the AI development workflows above: build, secure, and ship your AI applications within the same boundary where they run. Read the tech community blog to learn more about GitHub Enterprise Local and how to join the preview. Accelerating High-performance AI at the Edge with NVIDIA We are expanding our collaboration with NVIDIA to deliver high-performance AI capabilities directly at the edge. At Build, we are bringing: Azure Local and Foundry Local on NVIDIA-powered GPUs, including NVIDIA RTX PRO 6000 Blackwell Server Edition, with expanded GPU support coming soon Integration with Nemotron models, optimized for enterprise performance A scalable foundation for data-intensive, low-latency workloads This partnership ensures that organizations can run advanced AI workloads where data is generated - without dependency on centralized cloud infrastructure. Hardware options: AI factory configurations are available now in the catalog Alongside our hardware partners, we’re bringing integrated solutions to customers building AI within sovereign environments. The Azure Local hardware catalog now includes AI factory configurations from our OEM partners, including NVIDIA-certified 8xH100 systems, with options from DataON, Dell, HPE, and Lenovo. These configurations are sized for the performance that model serving and agentic workloads require on customer-managed infrastructure. Together with Microsoft, we are advancing sovereign AI by bringing the open NVIDIA Nemotron model family to Microsoft Foundry Local on Azure Local. This collaboration gives organizations a production-ready AI platform that enables them to deploy AI where their data resides while maintaining the governance, control, and performance needed to scale AI across the enterprise.” Kari Briski, VP Generative AI Software Products, NVIDIA ”Sovereign AI is becoming increasingly important for governments, regulated industries, and enterprises that want to use AI while maintaining control of their data, location, and operations. Lenovo’s ThinkAgile MX Series delivers trusted, enterprise-grade infrastructure with global deployment expertise to help customers run AI wherever their data resides. Co-engineered with Foundry Local and Azure Local, this solution provides an optimized platform to deploy, run, and scale AI locally with greater simplicity, consistency, and control, while helping meet strict data residency, security, and compliance requirements." Scott Patti - VP Infrastructure Solutions Group (ISG), Lenovo From AI models to trusted, mission-critical systems: what this unlocks for developers and operators AI is evolving from systems that answer questions to systems that plan, reason, and take action across workloads. These capabilities move AI from a cloud-only assumption to something you can deploy where sensitive work actually happens, with governance and operational controls intact. For our customers, this means you can now: Keep data, identities, and audit trails inside your sovereign boundary. Run AI inference and agentic workloads in connected, intermittently connected, or fully disconnected modes. Apply consistent policy and governance across cloud and local environments through Azure Arc. Use the same Foundry catalog and developer experience you already know, on infrastructure you own. Build, secure, and ship your AI applications with GitHub Enterprise Local, keeping source control, CI/CD, and DevSecOps workflows inside the same sovereign boundary. Resources Join us at Build OD837 Shipping physical AI to the edge with Azure Local and Foundry Local https://github.com/microsoft/build26-OD837 OD839 Foundry Local: AI solutions for industrial and sovereign needs https://github.com/microsoft/build26-OD839 LTG425 Expanding horizons: Foundry Local for devices and on-prem https://build.microsoft.com/en-US/sessions/LTG425 Request to join the Foundry Local on Azure Local preview Hands-on walkthrough: Your first model deployment on Foundry Local on Azure Local: from catalog to inference in 10 minutes | Microsoft Community Hub Read our Tech Community blogs: Foundry Local announcing multi-node and vLLM support Agentic Retrival with Foundry Local blog: https://aka.ms/AgentsAndToolsBuildBlog2026 Code sample / model catalog blog: https://aka.ms/foundry-local-model-catalog-blog For more details on the expanded capabilities of Foundry Local for highly secure environments, contact your Microsoft account team Discover Microsoft Sovereign Cloud Explore product documentation at: Foundry Local models on Azure Local: https://aka.ms/FoundryLocalonAzureLocal_documentation Local Agentic retrieval with Foundry Local: https://aka.ms/edge-agentic-retrieval-docsPlan for Upcoming Changes to Extended Security Updates on Azure Local
Beginning April 1 2026, Microsoft introduced a consistent pricing model for Extended Security Updates (ESU) for SQL Server and Windows products, including SQL Server 2016, Windows 10 Enterprise LTSB 2016 and Windows Server 2016. This update aims to simplify the Extended Security Update pricing so that customers pay the same list price for ESUs regardless of deployment location (Azure, on-premises, or other public clouds) or purchasing channel (Microsoft Customer Agreement, Enterprise agreements, Cloud Solution Provider program, or other licensing programs). ESUs on Azure Local This pricing change affects any new Extended Security Update offerings starting on or after April 1, 2026, including Windows 10 Enterprise LTSB 2016 (reaching end of support October 13, 2026) and Windows Server 2016 (reaching end of support January 12, 2027). Existing ESU offerings, including Windows Server 2012 or Windows 10 version 22H2, are not affected by this pricing change. This means that customers who already leverage ESUs will continue to have them available on Azure Local at no cost through Azure Verification for VMs. Next Steps As products reach end of support, it is recommended to upgrade your servers to the latest release available. For customers needing to remain on older versions after the end of support date has passed, further guidance on pricing and availability of ESUs will be shared in the coming months. Keep an eye on Extended Security Updates on Azure Local for more details. For More Information Microsoft Services: Pricing Consistency Update | Microsoft Licensing Resources Plan for Windows Server 2016 and Windows 10 2016 LTSB end of support - Windows IT Pro Blog
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?"
