The End-of-Life Deadline for Windows 10 – Why It Matters
The End-of-Life Deadline for Windows 10 – Why It Matters The countdown has begun: Windows 10 support officially ends on 14 October 2025 After this date, Microsoft will no longer provide security updates, bug fixes, or technical support, leaving businesses and individual users exposed to cyber threats, software incompatibility, and operational disruptions. While October 2025 may seem far off (to some people): Waiting too long to upgrade could put your security, compliance, and productivity at risk IT managers, business owners, and everyday users must act now to ensure a smooth transition before it’s too late. In this post, we’ll break down what Windows 10’s End-of-Life (EOL) means, why upgrading to Windows 11 – or exploring alternative solutions – is essential, and what hardware and software considerations you need to address. Now is the time to prepare. Let’s dive in What Does End-of-Life (EOL) Mean for Windows 10? When Microsoft ends support for an operating system, it doesn’t just stop providing updates it leaves millions of devices vulnerable to security threats, software failures, and compliance risks. After 14 October 2025, businesses and individual users still relying on Windows 10 will face serious challenges that go far beyond outdated software. For Windows 10 users, this means: No More Security Patches – Newly discovered vulnerabilities will remain unpatched, leaving devices, networks, and sensitive data open to cyberattacks. No Technical Support – Microsoft will no longer provide assistance for Windows 10 issues. Reduced Software Compatibility – Over time, new applications, drivers, and security tools built for Windows 11, lead to performance issues, missing features, and software incompatibilities on Windows 10. Significant Compliance Risks – Businesses in regulated industries could fail security audits or face legal consequences for running an unsupported OS. With these risks in mind, businesses and users must start preparing now to ensure a secure and seamless transition. Compliance Risks For businesses holding Cyber Essentials, Cyber Essentials Plus, or ISO 27001:2022 certification, continuing to use Windows 10 after its End-of-Life (EOL) isn’t just a security risk, it could lead to non-compliance, financial penalties, and loss of certification. These accreditation frameworks require up-to-date, secure systems, meaning that running an unsupported OS can have serious consequences for security standards, risk management, and overall business operations. Cyber Essentials / Cyber Essentials Plus Mandates supported and up-to-date software – Running Windows 10 beyond its EOL date directly violates Cyber Essentials’ security requirements, putting certification at risk. Increased risk of cyber threats – Without security patches, ransomware and malware attacks become a major risk, potentially leading to cyber insurance complications and breach of contract obligations. For businesses handling sensitive data or operating in regulated industries, running Windows 10 past its EOL could lead to certification loss, compliance failures, and even contract terminations. Beyond Windows 10: The Bigger Picture The Windows 10 End-of-Life (EOL) isn’t just about retiring an operating system – it’s part of a larger shift that businesses must navigate to stay secure and efficient. Alongside Windows 10, Microsoft Office 2016 and Office 2019 are also reaching their own EOL deadlines, increasing the urgency for organisations to modernise their IT environments before support ends. Office 2016: Support ends on 14 October 2025, the same day as Windows 10’s EOL. Office 2019: While mainstream support has already ended, extended support ends on 14 October 2025. Businesses still relying on these versions will face challenges on two fronts: outdated operating systems and unsupported productivity software, increasing risks across their IT infrastructure. The Risks of Ignoring These Deadlines With multiple Microsoft products reaching their EOL, businesses must act now to avoid serious disruptions. Failing to upgrade both Windows 10 and legacy Office applications can result in: Security Threats: Unsupported software is a prime target for cybercriminals. Compliance Issues: Organisations accredited with Cyber Essentials or Cyber Essentials Plus must use supported software to maintain compliance or they could face certification loss, fines, or reputational damage. Compatibility Headaches: Modern applications and services, including Microsoft 365, will increasingly rely on newer operating systems and software. To stay secure, compliant, and efficient, businesses must begin planning their transition now before these critical deadlines arrive. Why Businesses and IT Managers Need to Act Now The Windows 10 End-of-Life (EOL) deadline isn’t just a routine software update; it’s a turning point that will impact business security, compliance, and operational stability. After 14 October 2025, Windows 10 will officially become obsolete, forcing organisations to upgrade or face significant risks. Businesses must begin planning their transitions now, considering upgrades to Microsoft 365, Office 2021, or newer cloud-based solutions. With the simultaneous EOL dates for both Windows 10 and Office 2016/2019, organisations should take a holistic approach to ensure seamless updates across their IT environments. It isn’t just about compliance it’s an opportunity to enhance security, improve productivity, and unlock modern collaboration tools. A last-minute Windows 11 upgrade is not a viable strategy. Businesses must assess hardware compatibility, application readiness, licensing implications, and deployment plans well in advance to avoid major disruptions. Key Challenges Businesses Must Address Successfully upgrading to Windows 11 requires careful planning across multiple areas, including hardware, applications, and user adoption. Key challenges include: Assessing device compatibility: Many older laptops and desktops do not meet Windows 11’s strict hardware requirements and may need replacing. Evaluating application compatibility: Will legacy software function correctly on Windows 11, or will it require upgrades or replacements? Deployment planning: Businesses must plan device rollouts, licensing transitions, and data migration to ensure a smooth transition with minimal downtime. Without a proactive upgrade plan, organisations risk downtime, cybersecurity vulnerabilities, and rising IT costs all of which could have been avoided with early preparation. What to Expect Navigating Windows 10’s End-of-Life transition can be complex, but this guide will break it down into four key sections to help your business prepare smoothly and effectively: Windows 11 Benefits vs Windows 10: Why Windows 11 is not just an upgrade but a fundamental improvement in security, performance, and features. Upgrade
Segmenting Your Microsoft 365 Global Address List for Multi-Domain Organisations
Segmenting Your Microsoft 365 Global Address List for Multi-Domain Organisations In an era where mergers, acquisitions and multi-academy consolidations are commonplace, centralising multiple domains into a single Microsoft 365 tenant delivers undeniable efficiencies in security, licensing and administration. Yet with consolidation comes the hidden risk of an unwieldy Global Address List (GAL) – a single directory that exposes every mailbox, group and resource across your entire tenant. For an education trust of a dozen schools, this can mean a teacher accidentally emailing safeguarding records to the wrong academy. For a merged enterprise, it may result in sensitive financial forecasts landing in a newly acquired subsidiary’s inbox. This article presents a fully-up-to-date approach – using native Exchange Online Address Book Policies (ABPs) – to carve a monolithic GAL into secure, domain or division specific views You’ll gain: An understanding of why a single GAL poses security, compliance and productivity challenges A clear description of ABP components and their interplay Detail and plain-English explanations of PowerShell implementation patterns Expanded sections on Security & Compliance, Extending Segmentation into Teams and Beyond, and Governance Wherever possible, I’ve drawn directly from Microsoft’s latest documentation to ensure accuracy. Why a Single GAL Becomes a Liability Many organisations believe a centralised directory is inherently beneficial: one search bar to rule them all. In practice, users endure information overload when they must sift through hundreds or thousands of irrelevant entries to find a colleague or resource. Worse, autocomplete treats internal and external addresses the same, so a slip of the finger can expose confidential data to unintended recipients. For multi-academy education trusts, safeguarding student information is non-negotiable. A misplaced click can send pupil assessment data or pastoral notes to the wrong school, risking GDPR breaches and parental complaints. In corporate scenarios – say, a company acquiring a competitor – financial controllers might inadvertently share year-end bonus details with executives of the acquired entity. These are not hypothetical concerns; every mis-addressed email carries reputational damage, regulatory fines and erosion of stakeholder trust. IT helpdesks bear the brunt of this chaos, fielding reported incident tickets such as “Why can’t I find Mrs Jones in my academy?” or “Why am I seeing rooms from the finance department?” These repetitive queries divert valuable IT capacity from strategic projects – be it rolling out a new learning-management system or deploying advanced security analytics. As tenant scale grows, so too do the hidden costs of a monolithic GAL. Address Book Policies: Virtual Segmentation Rather than fragment your environment into separate tenants – an approach that multiplies licences, security boundaries and operational overhead – Exchange Online’s Address Book Policies (ABPs) offer a “virtual partition” within your existing tenant. An ABP bundles together four filtered directory view components so that users see only the objects assigned to their business unit or academy all while retaining centralised governance and compliance controls. At its core, an ABP comprises: A Global Address List (GAL) scoped by a recipient filter, defining which mail-enabled objects appear in name-resolution requests. An Offline Address Book (OAB) downloaded by Outlook clients in cached mode, ensuring offline users browse the same filtered directory. A Room List, for filtering resource mailboxes (meeting rooms, shared equipment) to prevent cross-unit booking conflicts. Custom Address Lists, enabling category-based browsing (e.g. by department or faculty) within the defined scope. By tagging mailboxes using a custom attribute or SMTP domain suffix you drive these filters automatically, so new users immediately inherit the correct ABP without manual reassignment. The Address Book Policy Routing agent further enforces isolation by marking out-of-scope lookups as “external” ﹘ preventing misleading “internal” display names in autocomplete once you enable it with: Set-TransportConfig -AddressBookPolicyRoutingEnabled $true Dissecting the Four ABP Pillars Global Address List (GAL) When a user types a name into the To: field in Outlook or OWA, the directory lookup consults the GAL. A domain-specific GAL (e.g. GAL_Contoso) ensures that Division A staff resolve only their own colleagues, distribution lists and contacts. This scoping is driven by a recipient filter, most commonly mapping CustomAttribute1 to a division code, such as “Contoso”. Offline Address Book (OAB) Outlook’s cached-mode clients download the OAB every eight hours by default. When you create an OAB that points to the same filtered GAL and address lists (e.g. OAB_Contoso), offline users maintain the same segmented experience even when disconnected from the network. This is critical for remote or bandwidth-constrained environments where cached-mode Outlook is the norm. Room List Resource mailboxes (meeting rooms, hot desks, equipment) often clutter the global directory. By creating a Room List object filtered on both the RecipientDisplayType (e.g. ConferenceRoomMailbox) and your division tag, you surface only the relevant rooms in meeting-room pickers preventing double bookings and administrative friction across units. Custom Address Lists Under each GAL, you can present one or more Custom Address Lists for instance, “Finance Teams” or “Faculty Staff” using the same division filter. These lists appear as categories in Outlook’s address-book pane, enabling structured browsing rather than free-form search. Together, all four components weave a seamless, tailored directory experience for each business unit. Security & Compliance: Fortifying Your Boundaries Segmentation does more than improve usability – it underpins your security and compliance strategy with multiple, reinforcing controls. Data Loss Prevention (DLP) becomes markedly more precise With a monolithic GAL, DLP policies must blanket the entire tenant, triggering false positives when users legitimately email across divisions. By contrast, ABP segmentation lets you craft targeted DLP rules that apply within each directory silo. For example, exam results can circulate freely within an academy but are blocked when addressed outside its ABP, sharply reducing administrative overhead in policy tuning and alert triage. eDiscovery and legal-hold scenarios Segmented GALs shrink your search scope. Compliance officers can restrict Content Searches to a single ABP, slashing processing time and data volumes. In education trusts, this ensures that subject-access requests remain tightly confined to the relevant academy, a critical requirement under GDPR and UK data-protection regulations. Auditability improvement Exchange’s Admin Audit Logs record
Microsoft Graph vs Azure PowerShell: Key Differences & Capabilities
Microsoft Graph vs Azure PowerShell: Key Differences & Capabilities Introduction I have been asked a number of times by connections and in DMs over the last few weeks about Microsoft Graph and Azure PowerShell – so I figured I would put together a post on this topic – afterall knowledge sharing is knowledge learned. Both Microsoft Graph and Azure PowerShell are powerful tools for managing Microsoft cloud services, but they serve different purposes. Microsoft Graph is the unified REST API that spans across Microsoft 365 services (Azure AD, Teams, Exchange, SharePoint, etc.), while Azure PowerShell refers to the PowerShell modules for managing Azure resources (and previously Azure AD) in a command-line context. Understanding the differences is important for administrators, especially as Microsoft is moving more functionality to Graph (and deprecating some older Azure PowerShell modules). In this post, I will compare their key differences, see how each can be used in practice, and discuss transitioning from Azure PowerShell (AzureAD/MSOL) to Microsoft Graph. Comparison Table: Microsoft Graph vs Azure PowerShell Below is a comparison of key aspects of Microsoft Graph (PowerShell SDK) and Azure PowerShell (specifically the AzureAD PowerShell module for Azure Active Directory tasks, as an example): Practical Scenario & PowerShell Script Examples To illustrate the difference in execution, consider a practical scenario: Creating a new user in Entra ID (Azure AD). Below are two script snippets that achieve the same goal – one using Microsoft Graph PowerShell and one using the AzureAD PowerShell module. Both will create a new user account, but notice the differences in how they authenticate and the cmdlet syntax: Using Microsoft Graph PowerShell: # Connect to Microsoft Graph with the necessary scope (permission) for user management Connect-MgGraph -Scopes “User.ReadWrite.All” # Define a password profile for the new user $passwordProfile = @{ Password = “P@ssw0rd!” } # Create a new user via Microsoft Graph API (through the Graph PowerShell SDK) New-MgUser -DisplayName “John Doe” ` -UserPrincipalName “john.doe@contoso.com” ` -MailNickname “john.doe” ` -AccountEnabled $true ` -PasswordProfile $passwordProfile # The above commands connect to Microsoft Graph and then create a new Azure AD user named John Doe with the specified UPN and password. # Benefit: This uses Microsoft Graph’s up-to-date API, allowing access to the latest Azure AD features and ensuring compatibility with future updates (Graph is the modern approach). Using Azure PowerShell (AzureAD module): # Connect to Azure AD using the AzureAD module Connect-AzureAD # Prepare a password profile object for the new user (AzureAD module requires a specific object type) $newUserPassword = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphPasswordProfile $newUserPassword.Password = “P@ssw0rd!” # Create a new user using AzureAD PowerShell module New-AzureADUser -DisplayName “John Doe” ` -UserPrincipalName “john.doe@contoso.com” ` -MailNickname “john.doe” ` -AccountEnabled $true ` -PasswordProfile $newUserPassword # This connects to Azure AD and creates the same user. # Benefit: AzureAD cmdlets are simple and were purpose-built for Azure AD tasks, which made them easy to use for administrators familiar with PowerShell. Explanation In the Graph script, we use Connect-MgGraph with an OAuth scope, reflecting Graph’s need for consent to specific permissions. We then call New-MgUser – a Graph cmdlet – to create the user. In the AzureAD version, we simply do Connect-AzureAD (which uses your account’s credentials) and then New-AzureADUser. One immediate difference is authentication; Graph encourages a scoped OAuth token (more secure and fine-grained), whereas AzureAD module uses your account context directly. Also, Graph’s cmdlet is part of a broader SDK that can manage more than just users, whereas New-AzureADUser is from a module solely focused on Azure AD. # Update Note # Original $newUserPassword in the AzureAD module was: $newUserPassword = New-Object -TypeName Microsoft.Open.AzureAD.Model.PasswordProfile # Changed to: $newUserPassword = New-Object -TypeName Microsoft.Graph.PowerShell.Models.MicrosoftGraphPasswordProfile # Change Reason: #Microsoft.Open.AzureAD.Model.PasswordProfile was the part of Azure AD for Graph (Azure AD v2), and Azure AD for Graph (Azure AD v2) is deprecated. Migration & Best Practices With Microsoft’s shift toward Graph, many organisations are transitioning from AzureAD/MSOL PowerShell modules to Microsoft Graph PowerShell. In fact, Microsoft Graph PowerShell is the official replacement for the AzureAD and MSOL modules. Here are some key points and best practices for migrating and working across both tools: Plan the Migration: Start by identifying all scripts and processes that use the AzureAD or MSOL modules. These legacy modules are deprecated and may run the risk of stopping entirely after the retirement date (30 March, 2025). List out those scripts – for each, there should be an equivalent approach using Microsoft Graph PowerShell SDK (https://tinyurl.com/4rwp8c4y). Map Out Equivalent Cmdlets: The Graph PowerShell SDK cmdlet names are different from AzureAD module cmdlets. For example, Get-AzureADUser becomes Get-MgUser, New-AzureADGroup becomes New-MgGroup, etc. Microsoft has provided a migration guide (https://tinyurl.com/2s3p3cyh) to help find Graph equivalents. Update your scripts by replacing old commands with the new Graph commands. Keep in mind that parameters might differ slightly, and Graph cmdlets may require specifying properties or filters to get the same data. Modernise Authentication: One of the key differences when migrating is how you handle authentication. The AzureAD module allowed using Azure AD credentials (often with less granular permissions). In Graph, you should use Connect-MgGraph with the appropriate scopes, or set up an app registration for app-only access in automation scenarios. This means possibly updating how your scripts authenticate – e.g., using certificate-based auth for unattended scripts or interactive device login for ad-hoc runs. The benefit is improved security (MSAL and modern auth with token scopes) compared to legacy ADAL-based auth. Ensure your environment is ready for this (you might need to register an Azure AD app and grant it admin-consent for certain Graph scopes). Test Thoroughly: Because the output objects and behaviors can differ, test your updated scripts in a non-production environment. For instance, Graph cmdlets might return different default properties than AzureAD cmdlets did. Verify that the new scripts perform the intended tasks (create the users, update the groups, etc.) and that all required data is being handled. Pay attention to any Graph-specific considerations, like throttling limits or required permission consent – adjust your approach if needed