I built a free, open-source M365 security assessment tool - looking for feedback
I work as an IT consultant, and a good chunk of my time is spent assessing Microsoft 365 environments for small and mid-sized businesses. Every engagement started the same way: connect to five different PowerShell modules, run dozens of commands across Entra ID, Exchange Online, Defender, SharePoint, and Teams, manually compare each setting against CIS benchmarks, then spend hours assembling everything into a report the client could actually read. The tools that automate this either cost thousands per year, require standing up Azure infrastructure just to run, or only cover one service area. I wanted something simpler: one command that connects, assesses, and produces a client-ready deliverable. So I built it. What M365 Assess does https://github.com/Daren9m/M365-Assess is a PowerShell-based security assessment tool that runs against a Microsoft 365 tenant and produces a comprehensive set of reports. Here is what you get from a single run: 57 automated security checks aligned to the CIS Microsoft 365 Foundations Benchmark v6.0.1, covering Entra ID, Exchange Online, Defender for Office 365, SharePoint Online, and Teams 12 compliance frameworks mapped simultaneously -- every finding is cross-referenced against NIST 800-53, NIST CSF 2.0, ISO 27001:2022, SOC 2, HIPAA, PCI DSS v4.0.1, CMMC 2.0, CISA SCuBA, and DISA STIG (plus CIS profiles for E3 L1/L2 and E5 L1/L2) 20+ CSV exports covering users, mailboxes, MFA status, admin roles, conditional access policies, mail flow rules, device compliance, and more A self-contained HTML report with an executive summary, severity badges, sortable tables, and a compliance overview dashboard -- no external dependencies, fully base64-encoded, just open it in any browser or email it directly The entire assessment is read-only. It never modifies tenant settings. Only Get-* cmdlets are used. A few things I'm proud of Real-time progress in the console. As the assessment runs, you see each check complete with live status indicators and timing. No staring at a blank terminal wondering if it hung. The HTML report is a single file. Logos, backgrounds, fonts -- everything is embedded. You can email the report as an attachment and it renders perfectly. It supports dark mode (auto-detects system preference), and all tables are sortable by clicking column headers. Compliance framework mapping. This was the feature that took the most work. The compliance overview shows coverage percentages across all 12 frameworks, with drill-down to individual controls. Each finding links back to its CIS control ID and maps to every applicable framework control. Pass/Fail detail tables. Each security check shows the CIS control reference, what was checked, what the expected value is, what the actual value is, and a clear Pass/Fail/Warning status. Findings include remediation descriptions to help prioritize fixes. Quick start If you want to try it out, it takes about 5 minutes to get running: # Install prerequisites (if you don't have them already) Install-Module Microsoft.Graph, ExchangeOnlineManagement -Scope CurrentUser Clone and run git clone https://github.com/Daren9m/M365-Assess.git cd M365-Assess .\Invoke-M365Assessment.ps1 The interactive wizard walks you through selecting assessment sections, entering your tenant ID, and choosing an authentication method (interactive browser login, certificate-based, or pre-existing connections). Results land in a timestamped folder with all CSVs and the HTML report. Requires PowerShell 7.x and runs on Windows (macOS and Linux are experimental -- I would love help testing those platforms). Cloud support M365 Assess works with: Commercial (global) tenants GCC, GCC High, and DoD environments If you work in government cloud, the tool handles the different endpoint URIs automatically. What is next This is actively maintained and I have a roadmap of improvements: More automated checks -- 140 CIS v6.0.1 controls are tracked in the registry, with 57 automated today. Expanding coverage is the top priority. Remediation commands -- PowerShell snippets and portal steps for each finding, so you can fix issues directly from the report. XLSX compliance matrix -- A spreadsheet export for audit teams who need to work in Excel. Standalone report regeneration -- Re-run the report from existing CSV data without re-assessing the tenant. I would love your feedback I have been building this for my own consulting work, but I think it could be useful to the broader community. If you try it, I would genuinely appreciate hearing: What checks should I prioritize next? Which security controls matter most in your environment? What compliance frameworks are most requested by your clients or auditors? How does the report land with non-technical stakeholders? Is the executive summary useful, or does it need work? macOS/Linux users -- does it run? What breaks? I have tested it on macOS, but not extensively. Bug reports, feature requests, and contributions are all welcome on GitHub. Repository: https://github.com/Daren9m/M365-Assess License: MIT (free for commercial and personal use) Runtime: PowerShell 7.x Thanks for reading. Happy to answer any questions in the comments.Azure AD Graph API retirement: action required for older versions of Azure CLI and Azure PowerShell
Summary Azure AD Graph API (the legacy graph.windows.net API, not to be confused with Microsoft Graph) entered its retirement process in September 2024, with the general shutdown completed on July 1, 2025. Azure CLI and Azure PowerShell completed their migration away from Azure AD Graph well ahead of that deadline. az ad and the Az module's Microsoft Entra ID (Azure AD) cmdlets have been backed by Microsoft Graph for some time now. If you're running a current version of Azure CLI or Azure PowerShell, no action is required on your part for this specific retirement. Because Azure CLI and Azure PowerShell are Microsoft first-party clients, their Azure AD Graph application identities have remained available temporarily to provide a transition path for legacy releases that still call Azure AD Graph. However, those legacy releases have long been out of maintenance and are no longer supported; the temporary availability of the application identities does not mean the old releases remain supported. Beginning after October 6, 2026, the Microsoft Entra team will progressively disable this remaining legacy access over a two-month buffer period. Users of current versions are not affected, but anyone still running an old release should upgrade now. This post explains what changed, why, and how to confirm you're unaffected. Terminology This post uses the following terms: Azure AD Graph API (https://graph.windows.net) — the legacy, now-retired API for reading and writing Microsoft Entra ID (formerly Azure Active Directory) objects: users, groups, applications, service principals, and directory roles. Microsoft Graph (https://graph.microsoft.com) — Microsoft's current, unified API surface for Entra ID and the broader Microsoft 365 ecosystem, and the only supported path going forward for any identity/directory operation. If your Azure CLI or Azure PowerShell still uses legacy Azure AD Graph, migrate as soon as possible Azure CLI has used Microsoft Graph for az ad commands since version 2.37.0, and the identity-related cmdlets in Azure PowerShell have used Microsoft Graph since Az.Resources version 5.1.0. These migrations were completed years before the Azure AD Graph retirement. Azure CLI releases earlier than 2.37.0 and Az.Resources releases earlier than 5.1.0 have long been out of maintenance and are no longer supported. The temporary availability of the tools' first-party Azure AD Graph application identities was retained only to provide a transition path for those legacy releases; it does not mean that the releases are maintained or supported. We are notifying users who still use legacy Azure AD Graph versions We are sending notifications in phases to tenants where telemetry indicates that calls may still be reaching Azure AD Graph endpoints. Some of this traffic comes from legacy Azure CLI or Azure PowerShell releases using the tools' temporarily retained first-party Azure AD Graph identities; other cases typically trace back to one of the following: An old, unsupported version of Azure CLI or the Az/AzureAD/MSOnline PowerShell modules still in use (for example, pinned in a long-lived CI/CD image or automation runbook that hadn't been updated). Custom scripts or tooling calling the legacy graph.windows.net endpoint directly via Invoke-RestMethod/curl/a hand-rolled SDK client, independent of az/Az entirely. The standalone legacy AzureAD or MSOnline PowerShell modules (distinct from the Az module), which were already deprecated separately from this effort and have their own migration path to Microsoft.Graph PowerShell cmdlets. These notifications are intended to help close out any remaining migration gaps and continue the original retirement communication. Beginning after October 6, 2026, the Microsoft Entra team will progressively disable the remaining legacy first-party access over a two-month buffer period. Old Azure CLI or Azure PowerShell releases that still depend on Azure AD Graph may stop working at any point during this phased shutdown. How to check whether your automation still uses Azure AD Graph Checking the version actually running in each environment is the most reliable way to identify legacy Azure CLI or Azure PowerShell usage. Check developer machines as well as CI/CD agents, automation runbooks, scheduled jobs, and container images, which often remain pinned to an older version after interactive environments have been updated. You may need to work with your tenant, subscription, infrastructure, or automation administrators to locate the system that is generating the legacy traffic. The source may be a developer machine, VM, self-hosted build agent, automation worker, scheduled task, or container host that you do not manage directly. Use the tenant information from any targeted notification together with your organization's sign-in logs, automation inventory, pipeline logs, and VM or container inventory to identify the execution environment, then upgrade it or stop the obsolete job. Azure CLI Run the following command in the same environment and execution account used by your automation: az version Azure CLI 2.37.0 replaced the Azure AD Graph implementation used by az ad with Microsoft Graph. If the reported version is lower than 2.37.0, upgrade to the latest Azure CLI release and test your scripts before the phased shutdown begins. Also check pipeline definitions, package installation steps, and container image tags for an explicitly pinned Azure CLI version; checking only the version on your local workstation does not verify the version used by automation. For installations that support the built-in updater, run: az upgrade Otherwise, update Azure CLI through the same package manager or installation method originally used, then run the version check again. After upgrading, review the documented Microsoft Graph migration changes because some command arguments, behavior, and output properties changed. For example, Microsoft Graph directory object output uses id, while the corresponding Azure AD Graph property was objectId. This can affect scripts that parse command output. If you encounter a problem after upgrading, report it in the Azure CLI GitHub repository and include the output of az version, the affected command, and a minimal reproduction with secrets removed. Azure PowerShell The Entra ID cmdlets discussed in this post are provided by Az.Resources, so check that module's version rather than relying only on the version of PowerShell itself: Get-Module Az.Resources -ListAvailable | Sort-Object Version -Descending | Select-Object -First 1 Name, Version, Path Az.Resources 5.1.0 introduced the Microsoft Graph implementation for the identity-related cmdlets. If the reported version is lower than 5.1.0, update to the latest Az module, restart the PowerShell session, and test your scripts. Check automation accounts, hosted agents, module caches, and container images separately. Also look for scripts that load a specific old version with Import-Module Az.Resources -RequiredVersion or declare a fixed module version in #Requires. If Az was installed from the PowerShell Gallery, update it with: Update-Module -Name Az -Force Restart PowerShell after the update so that the session does not continue using an older module already loaded in memory. To confirm which module version provides a cmdlet in the current session, run: (Get-Command Get-AzADUser).Module | Select-Object Name, Version, Path After upgrading, review the documented Azure PowerShell migration changes because parameter names, input and output types, and object properties changed. If you encounter a problem after upgrading, report it in the Azure PowerShell GitHub repository and include the Az.Resources version, PowerShell version, affected cmdlet, and a minimal reproduction with secrets removed. Check for direct endpoint calls Tool versions do not identify custom code that bypasses az ad or the Az cmdlets. Search your repositories, pipeline definitions, runbooks, and configuration files for graph.windows.net. Pay particular attention to calls made through az rest, curl, Invoke-RestMethod, or custom HTTP and SDK clients. Any direct call to that host must be migrated to Microsoft Graph regardless of the installed Azure CLI or Azure PowerShell version. If you need help upgrading, locating the source of Azure AD Graph traffic, or troubleshooting an issue related to the retirement, you can ask a question in the Azure CLI GitHub repository or the Azure PowerShell GitHub repository, as appropriate. Include the available version information, affected command or cmdlet, execution environment, error message, and a minimal reproduction or relevant logs with all secrets and personal or tenant-sensitive information removed. The Azure CLI and Azure PowerShell teams can then help you investigate and provide guidance. What you should do Make sure you're on a current, supported version of Azure CLI or Azure PowerShell. Run the checks above and update if you're on an old release. Do not rely on the two-month buffer period: legacy access will be progressively disabled after October 6, 2026, so an old release may stop working before the end of that period. If you use the standalone legacy AzureAD or MSOnline PowerShell modules, these are a separate deprecation track from Az and need their own migration to the Microsoft.Graph PowerShell SDK. This is not something updating the Az module alone resolves — see the dedicated migration guidance referenced below. If you have custom code or scripts calling graph.windows.net directly, those calls will fail outright post-retirement regardless of what version of Azure CLI/PowerShell you run, since this isn't a CLI/PowerShell-specific concern — it's any direct caller of the retired endpoint. Migrate those calls to the Microsoft Graph SDK/API directly. If you received a targeted notification referencing a specific tenant ID, that means telemetry showed residual traffic from that tenant specifically — check any automation, scheduled scripts, or older images/containers associated with that tenant for one of the causes above. References Migrate from Azure AD Graph to Microsoft Graph - Microsoft 365 Developer Blog Azure AD Graph to Microsoft Graph migration FAQ - Microsoft Graph | Microsoft Learn Impact of Microsoft Graph migration in Azure CLI Azure AD to Microsoft Graph migration changes in Azure PowerShell Install Azure CLI / Install Azure PowerShell Migrate from the AzureAD and MSOnline PowerShell modules to Microsoft Graph PowerShell
Force a specific default lock screen and logon image
Dear, I currently have a DC deployed on Windows Server 2019. i want to configure a specific default image on lock screens on Windows 10 pro clients via group policy. Is this possible or is it only compatible with Enterprise or Education editions? Thanks in advance,
Updating Purview DLP Sensitive Service Domain Groups with PowerShell
Introduction Microsoft Purview Data Loss Prevention (DLP) can use Sensitive Service Domain Groups to organize websites and other network destinations that are referenced by endpoint DLP rules. Administrators can manage these settings in the Purview portal, while PowerShell is useful when changes must be repeatable, reviewed, and validated before they are committed. This article demonstrates how to retrieve the tenant policy configuration, identify an existing group, add new URL entries only when they are not already present, validate the change, commit it, and verify the final configuration. Important The SiteGroupsPsws object contains tenant-wide endpoint restriction settings. Test the script in a non-production tenant first, export the original configuration, and use change control. Microsoft documents Get-PolicyConfig and Set-PolicyConfig for viewing and modifying endpoint restrictions, but the internal shape of individual hashtable entries can evolve. Prerequisites Requirement Guidance Permissions Use an account assigned the required Microsoft Purview permissions for the configuration being changed. Microsoft states that Get-PolicyConfig and Set-PolicyConfig require permissions in Security & Compliance PowerShell. PowerShell module Install or update the ExchangeOnlineManagement module. Security & Compliance PowerShell uses this module for connectivity. Connection Connect to Security & Compliance PowerShell by using Connect-IPPSSession before running the policy configuration cmdlets. Existing group The target Sensitive Service Domain Group must already exist. This script updates a group named Claude; it does not create the group. Change controls Run the discovery and backup commands first, use -WhatIf before commit, and retain the exported JSON for rollback analysis. Step 1: Install the module and connect Install-Module -Name ExchangeOnlineManagement -Scope CurrentUser Import-Module ExchangeOnlineManagement Connect-IPPSSession Confirm that the policy configuration can be retrieved: Get-PolicyConfig | Format-List Step 2: Discover available group names List the names exposed in SiteGroupsPsws and confirm that the target group exists before making any change. (Get-PolicyConfig).SiteGroupsPsws | Where-Object { $_.ContainsKey("Name") } | ForEach-Object { $_.Name } Step 3: Back up the current configuration Export the current SiteGroupsPsws representation before modifying the in-memory object. $BackupPath = ".\SiteGroupsPsws-backup-{0}.json" -f (Get-Date -Format "yyyyMMdd-HHmmss") (Get-PolicyConfig).SiteGroupsPsws | ConvertTo-Json -Depth 20 | Set-Content -Path $BackupPath -Encoding UTF8 Write-Host "Backup written to $BackupPath" -ForegroundColor Cyan Step 4: Define the target group and URLs $GroupName = "Claude" $NewUrls = @( "claude1.com", "chatgpt2.com", "claude3.com" ) Replace the sample values with the approved production URLs. Use only the domain or wildcard format supported by your DLP design. Step 5: Retrieve and validate the target group $PolicyConfig = Get-PolicyConfig $Groups = $PolicyConfig.SiteGroupsPsws $TargetGroup = $Groups | Where-Object { $_["Name"] -eq $GroupName } if (-not $TargetGroup) { $AvailableGroups = $Groups | Where-Object { $_.ContainsKey("Name") } | ForEach-Object { $_.Name } throw "Sensitive Service Domain Group '$GroupName' was not found. Available groups: $($AvailableGroups -join ', ')" } Complete script # Target Sensitive Service Domain Group $GroupName = "Claude" # URLs to add $NewUrls = @( "claude1.com", "chatgpt2.com", "claude3.com" ) $PolicyConfig = Get-PolicyConfig $Groups = $PolicyConfig.SiteGroupsPsws $TargetGroup = $Groups | Where-Object { $_["Name"] -eq $GroupName } $Addresses = $TargetGroup["Addresses"] | ConvertFrom-Json foreach ($Url in $NewUrls) { if ($Addresses.Url -notcontains $Url) { $Addresses += [pscustomobject]@{ Url = $Url MatchType = "UrlMatch" } } } $TargetGroup["Addresses"] = $Addresses | ConvertTo-Json -Compress # Validate Set-PolicyConfig -SiteGroupsPsws $Groups -WhatIf # Commit Set-PolicyConfig -SiteGroupsPsws $Groups Step 6: Verify the change Retrieve a fresh copy from the service rather than validating only the modified local object. $VerifiedGroups = (Get-PolicyConfig).SiteGroupsPsws $VerifiedTarget = $VerifiedGroups | Where-Object { $_["Name"] -eq $GroupName } $VerifiedAddresses = @($VerifiedTarget["Addresses"] | ConvertFrom-Json) $Verification = foreach ($Url in $NormalizedNewUrls) { [pscustomobject]@{ Group = $GroupName Url = $Url Present = ($VerifiedAddresses.Url -contains $Url) } } $Verification | Format-Table -AutoSize if ($Verification.Present -contains $false) { throw "Verification failed: one or more URLs were not found after the update." } Write-Host "Verification passed for all requested URLs." -ForegroundColor Green Step 7: Optional full configuration views # Writable PowerShell representation (Get-PolicyConfig).SiteGroupsPsws | ConvertTo-Json -Depth 20 # Service view (Get-PolicyConfig).SiteGroups Sample output The sample is illustrative. Actual service output and formatting can vary by module version and tenant configuration. Troubleshooting Symptom Recommended check Get-PolicyConfig or Set-PolicyConfig is not recognized Confirm that the ExchangeOnlineManagement module is installed and that the session was connected with Connect-IPPSSession. Access denied or authorization error Verify the administrator account has the required Purview role-group permissions, then reconnect after role propagation. Target group not found Run the discovery command and use the exact group name returned by SiteGroupsPsws. Addresses cannot be parsed Inspect the raw Addresses property before changing anything. Restore from the exported JSON if the object shape is unexpected. -WhatIf succeeds but verification fails Retrieve Get-PolicyConfig again, check for service-side errors, and confirm no competing administrator update overwrote the configuration. Summary PowerShell provides a controlled way to update Microsoft Purview DLP Sensitive Service Domain Groups at scale. The safest pattern is to discover the exact group name, export the current configuration, validate the target object, normalize and de-duplicate input, run Set-PolicyConfig with -WhatIf, commit the change, and then verify it through a fresh Get-PolicyConfig call. This validation-first workflow improves repeatability and reduces the risk of unintended tenant-wide configuration changes. References Get-PolicyConfig cmdlet reference https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/get-policyconfig?view=exchange-ps Set-PolicyConfig cmdlet reference https://learn.microsoft.com/en-us/powershell/module/exchangepowershell/set-policyconfig?view=exchange-ps Security & Compliance PowerShell overview https://learn.microsoft.com/en-us/powershell/exchange/scc-powershell?view=exchange-ps Configure Endpoint DLP settings https://learn.microsoft.com/en-us/purview/dlp-configure-endpoint-settings
PowerShell DSC Pullserver stops working with SQL database
After updating Windows Server 2025, our DSC Pull Server stopped communicating with its SQL backend database. The issue was not present before the update, and reverting to the previous version of Microsoft.PowerShell.DesiredStateConfiguration.Service.dll immediately restored normal functionality. With the newer DLL version, the service starts successfully and the endpoint remains available, but no connection is established to the SQL Server database. As a result, database initialization does not occur, required tables are not created or updated, and node registration fails. No database sessions are observed on the SQL Server during registration attempts, indicating that the service does not reach the SQL connection phase. We compared the previous working DLL version with the updated version and confirmed that the regression is introduced by the newer DLL. Replacing the updated DLL with the earlier version consistently restores SQL database connectivity and normal Pull Server Operation.
Active Directory Schema Attributes vs Version
Hi all, i'm searching documentations about the attributes used in active directory schema based on its version. My versions range is from "Windows 2008 R2" (v47) to "Windows 2019" (v88). The target of my search is a document/wiki that i can use to check if an attribute exist in my versions range, or, if the usage change in some versions, to prevent exception when a software try to access to it. At the moment, i find only this wiki: https://docs.microsoft.com/en-us/windows/win32/adschema/attributes-all Here i can find all attributes vs schema version and the related information (data type, name, access, etc), but seems not cover the newer schema versions. For example, if i want to check the attribute "department", i can go to the detailed description: https://docs.microsoft.com/en-us/windows/win32/adschema/a-department an see the implementation in older versions (typically the newer is windows server 2012). Exist a list that include newer versions (from windows server 2012 r2 to 2019)? Thanks for any info Stefano
Error while running New-VHD cmdlet on Windows Server 2019
Hi, I am trying to create an empty .vhd file using the PowerShell cmdlet New-VHD on Windows Server 2019 virtual machine hosted on Hyper-V. I am seeing the attached error while running the cmdlet: I suspected that it could be related to Hyper-V role on the machine. But, it seems to be all good. Here is the screenshot of what I see on my machine. Strangely I don't see the Hyper-V Services feature on the Windows Server 2019 VM that I am working on. I see Hyper-V Services feature on other VMs on the same Hyper-V for example Windows 10 VM. Any help here will be greatly appreciated. Thanks, Yojana
Azure VM Agent Status not ready
I have created a red hat openshift private cluster but the VMS are stuck in the state of "agent status not ready." I have followed these troubleshooting steps: Linux Virtual Machine Agent Status "Not Ready" - Microsoft Community Hub However, all of them seem to point to trying to check and see what is on the VM itself. I am unable to do this because I can't SSH into the machine. Has anyone else ran into this issue and been able to resolve it? I am deploying it via CLI as I was not able to do it via GUI for some reason. This is my script: #az login az account set --name "accountnamehidden" #az provider register -n Microsoft.RedHatOpenShift --wait #az provider register -n Microsoft.Compute --wait #az provider register -n Microsoft.Storage --wait #az provider register -n Microsoft.Authorization --wait $LOCATION= "eastus" # the location of your cluster $RESOURCEGROUP= "sample-rg" # the name of the resource group where you want to create your cluster $CLUSTER= "K8sDev1test" # the name of your cluster $arovnet= "sample-vnet" $mastersubnet = "k8sDev1-master-ue-snet" $workersubnet = "k8sDev1-worker-ue-snet" az aro create --resource-group "samplerg" --vnet-resource-group "sample-vnet-rg" --name $CLUSTER --vnet $arovnet --master-subnet "k8sDev1-master-ue-snet" --worker-subnet "k8sDev1-worker-ue-snet" --apiserver-visibility Private --ingress-visibility Private --fips true --outbound-type UserDefinedRouting --client-id hidden --client-secret hidden
Strict users to use specific software windows server 2022
I have MT5 installed on (C:\Program Files\MetaTrader 5) there are the meta trader 5 terminal64.exe and MetaEditor64.exe applications, mt5 data folder as follow C:\Users\Administrator\AppData\Roaming\MetaQuotes\Terminal\ MT4 on (C:\Program Files (x86)\MetaTrader 4) there are applications terminal.exe and metaeditor.exe and data folder as follow C:\Users\Administrator\AppData\Roaming\MetaQuotes\Terminal\ I use windows server 2022 and I want to create user accounts each account have access only to MT4 or MT5 and the meta editor and data folder only and each user can use the software MT4 or MT5 based on assigned group, users can use the same software at the same time in their own accounts I need 2 windows powershell scripts 1-create 2 user groups for MT4 and MT5 with the access restrcicted to all windows software and features execpt the MT4 or MT5 and the meta editor, and the data folder and desktop showing these icons/shortcuts and webview2 runtime to installed be allowed because it is needed by meta trader ( user cannot see windows bar cannot use any windows software, and the most important that the MT4 or MT5 software to be always running and start always after windows reboot/restart not when user log on, these software run trading algoeithms and must be working around the clock even if the user is not logged in 2- interactive script that use to create the users
