Merge branch 'main' into patch-15

Author: paisvivekanand

exchange/docs-conceptual/client-advanced-settings.md

@@ -317,11 +317,11 @@ Use this advanced setting in conjunction with *ScannerMinCPU* to limit CPU consu
 
 - Value: \<number>**
 
-The value is set to **100** by default, which means there is no limit of maximum CPU consumption. In this case, the scanner process will try to use all available CPU time to maximize your scan rates.
+The value is set to **100** by default, which means there is no limit of maximum CPU consumption. In this case, the scanner process tries to use all available CPU time to maximize your scan rates.
 
-If you set **ScannerMaxCPU** to less than 100, the scanner will monitor the CPU consumption over the last 30 minutes. If the average CPU crossed the limit you set, it will start to reduce the number of threads allocated for new files.
+If you set **ScannerMaxCPU** to less than 100, the scanner monitors the CPU consumption over the last 30 minutes. If the average CPU crossed the limit you set, it starts to reduce the number of threads allocated for new files.
 
-The limit on the number of threads will continue as long as CPU consumption is higher than the limit set for **ScannerMaxCPU**.
+The limit on the number of threads continues as long as CPU consumption is higher than the limit set for **ScannerMaxCPU**.
 
 ## ScannerMinCPU
 
@@ -334,7 +334,7 @@ Used only if *ScannerMaxCPU* is not equal to 100, and cannot be set to a number
 
 We recommend keeping **ScannerMinCPU** set at least 15 points lower than the value of *ScannerMaxCPU*.
 
-The value is set to **50** by default, which means that if CPU consumption in the last 30 minutes when lower than this value, the scanner will start adding new threads to scan more files in parallel, until the CPU consumption reaches the level you have set for *ScannerMaxCPU*-15.
+The value is set to **50** by default, which means that if CPU consumption in the last 30 minutes when lower than this value, the scanner starts adding new threads to scan more files in parallel, until the CPU consumption reaches the level you have set for *ScannerMaxCPU*-15.
 
 ## ScannerConcurrencyLevel
 
@@ -361,17 +361,17 @@ Set-LabelPolicy -Identity Scanner -AdvancedSettings @{ScannerConcurrencyLevel="8
 
 By default, the information protection scanner scans all relevant files. However, you might want to define specific files to be skipped, such as for archived files or files that have been moved.
 
-Enable the scanner to skip specific files based on their file attributes by using the **ScannerFSAttributesToSkip** advanced setting. In the setting value, list the file attributes that will enable the file to be skipped when they are all set to **true**. This list of file attributes uses the AND logic.
+Enable the scanner to skip specific files based on their file attributes by using the **ScannerFSAttributesToSkip** advanced setting. In the setting value, list the file attributes that enable the file to be skipped when they are all set to **true**. This list of file attributes uses the AND logic.
 
 Example PowerShell commands, where your label policy is named "Global".
 
-**Skip files that are both read-only and archived**
+**Skip files that are both read-only and archived**:
 
 ```PowerShell
 Set-LabelPolicy -Identity Global -AdvancedSettings @{ ScannerFSAttributesToSkip =" FILE_ATTRIBUTE_READONLY, FILE_ATTRIBUTE_ARCHIVE"}
 ```
 
-**Skip files that are either read-only or archived**
+**Skip files that are either read-only or archived**:
 
 To use an OR logic, run the same property multiple times. For example:
 

exchange/docs-conceptual/connect-exo-powershell-managed-identity.md

@@ -68,7 +68,7 @@ The first command in the PowerShell runbook must be the `Connect-ExchangeOnline.
 Connect-ExchangeOnline -ManagedIdentity -Organization contoso.onmicrosoft.com
 ```
 
-After that, as a test, you can start with as simple, low-impact command in the runbook before moving on to more complex commands or scripts. For example:
+After that, as a test, you can start with as simple, low risk command in the runbook before moving on to more complex commands or scripts. For example:
 
 ```powershell
 Get-AcceptedDomain | Format-Table Name
@@ -118,7 +118,7 @@ Connect-ExchangeOnline -ManagedIdentity -Organization contoso.onmicrosoft.com -M
 
 You get the ManagedIdentityAccount value from [Step 3: Store the user-assigned managed identity in a variable](#step-3-store-the-user-assigned-managed-identity-in-a-variable).
 
-After that, as a test, you can start with as simple, low-impact command in the runbook before moving on to more complex commands or scripts. For example:
+After that, as a test, you can start with as simple, low risk command in the runbook before moving on to more complex commands or scripts. For example:
 
 ```powershell
 Get-AcceptedDomain | Format-Table Name
@@ -285,7 +285,7 @@ To verify that the module imported successfully, run the following command:
 Get-AzAutomationModule -ResourceGroupName ContosoRG -AutomationAccountName ContosoAzAuto1 -Name ExchangeOnlineManagement
 ```
 
-During the import, the ProvisioningState property will have the value Creating. When the module import is complete, the value will change to Succeeded.
+During the import, the ProvisioningState property has the value Creating. When the module import is complete, the value changes to Succeeded.
 
 For detailed syntax and parameter information, see [New-AzAutomationModule](/powershell/module/az.automation/new-azautomationmodule).
 

exchange/docs-conceptual/connect-to-exo-powershell-c-sharp.md

@@ -207,7 +207,7 @@ void ParallelConnectionsToExchangeOnline()
 
         // Set the ThreadOptions to reuse the same threads for the runspaces so that
 
-        // the Exchange Online cmdlets will be available after running Connect-ExchangeOnline in each runspace.
+        // the Exchange Online cmdlets are available after running Connect-ExchangeOnline in each runspace.
 
         pool.ThreadOptions = PSThreadOptions.ReuseThread;
 

exchange/docs-conceptual/exchange-online-powershell-v2.md

@@ -3,7 +3,7 @@ title: About the Exchange Online PowerShell V3 module
 ms.author: chrisda
 author: chrisda
 manager: deniseb
-ms.date: 07/31/2025
+ms.date: 08/08/2025
 ms.audience: Admin
 audience: Admin
 ms.topic: article
@@ -269,28 +269,79 @@ Now you can do the [regular PowerShell prerequisites](#prerequisites-for-the-exc
 
 - **Windows PowerShell 5.1**:
   - All versions of the module are supported.
-  - Version 2.0.5 (May 2021) or later versions of the module require the Microsoft .NET Framework 4.7.2 or later to connect. Otherwise, you get a `System.Runtime.InteropServices.OSPlatform` error. For more information about versions of Windows that support the .NET Framework 4.7.2, see [this article](/dotnet/framework/migration-guide/versions-and-dependencies#net-framework-472).
-
-  > [!TIP]
-  > Current versions of Windows include the required versions of .NET and/or the .NET Framework, so you don't need to install .NET or the .NET Framework to use the module in Windows PowerShell 5.1.
+  - Current versions of Windows include the required versions of the .NET Framework, so you don't need to install the .NET Framework to use the module in Windows PowerShell 5.1.
 
 - **PowerShell 7**:
-  - Module versions 3.5.1 (July 2024) or later require PowerShell 7 version 7.4.0 (November 2023) or later. Earlier versions of PowerShell 7 might encounter compatibility issues due to missing .NET 8.0 assemblies (v3.5.1 is built on .NET 8.0).
-  - Module versions 2.0.4 (February 2021) to 3.5.0 (May 2024) are supported in PowerShell 7 version 7.0.3 (July 2020) or later.
+  - Module versions 3.5.0 (May 2024) or later require PowerShell 7.4.0 (November 2023) or later due to .NET 8.0 assembly dependencies. Earlier versions of PowerShell 7 might encounter compatibility issues (PowerShell 7.3.6 is more compatible than 7.3.7).
+  - Module versions 3.0.0 (September 2022) to 3.4.0 (October 2023) require PowerShell 7.2.0 (November 2021) or later due to .NET 6.0 assembly dependencies in REST API cmdlets and connections.
+  - Support for the module in PowerShell 7 started with version 2.0.4 (February 2021) in PowerShell 7.0.3 (July 2020).
+
+Specific module version support in Windows depends on Windows PowerShell support and .NET Framework and/or .NET support as described in the following list:
+
+> [!TIP]
+> As stated previously, only REST API connections are supported in Exchange Online PowerShell and Security & Compliance PowerShell:
+>
+> - Version 2.0.4 of the module (February 2021) supports the REST API only for the [nine exclusive **Get-EXO\*** cmdlets](#cmdlets-in-the-exchange-online-powershell-module).
+> - Version 2.0.5 of the module (May 2021) offers partial support for REST API cmdlets only in Exchange Online PowerShell.
+> - Version 3.0.0 (September 2022) is the first version of the module that fully supports REST API cmdlets in Exchange Online PowerShell.
+> - Version 3.2.0 (June 2023) is the first version of the module that fully supports REST API cmdlets in Security & Compliance PowerShell.
+
+- **Windows 11**:
+
+  |Module version|PowerShell version|.NET requirement|
+  |---|---|---|
+  |2.0.5 or later|5.1|.NET Framework 4.7.2 (4.8.x is included, so you don't need to install the .NET Framework)|
+  |3.5.0 or later|7.4.0 or later|.NET 8.0<br/>Included in 24H2 or later.|
+  |3.0.0 to 3.4.0|7.2.0 to 7.3.7 (or later)|.NET 6.0 (7.2.x)<br/>.NET 7.0 (7.3.x)|
+
+  PowerShell 7.2.0 is the earliest supported version in Windows 11.
+
+- **Windows Server 2022**:
+
+  |Module version|PowerShell version|.NET requirement|
+  |---|---|---|
+  |2.0.5 or later|5.1|.NET Framework 4.7.2 (4.8 is included, so you don't need to install the .NET Framework)|
+  |3.5.0 or later|7.4.0 or later|.NET 8.0|
+  |3.0.0 to 3.4.0|7.2.0 to 7.3.7 (or later)|.NET 6.0 (7.2.x)<br/>.NET 7.0 (7.3.x)|
 
-Windows PowerShell requirements and module support **in older versions of Windows** are described in the following list:
+  PowerShell 7.2.0 (.NET 6.0) is the earliest supported version in Windows Server 2022.
 
-- Windows 10¹
-- Windows 8.1² ³
-- Windows Server 2012 or Windows Server 2012 R2² ³
-- Windows 7 Service Pack 1 (SP1)² ⁴ ⁵
-- Windows Server 2008 R2 SP1² ⁴ ⁵
+- **Windows 10**:
 
-¹ Windows 10 Anniversary Update (version 1607 from August 2016) is the earliest version of Windows 10 that's reliably compatible with the .NET Framework 4.7.2 (v2.0.5 or later versions of the module in Windows PowerShell 5.1).<br/>
-² Support for this version of Windows is over. This version of Windows is supported only in Azure virtual machines.<br/>
-³ PowerShell 7 on this version of Windows requires a compatible version of .NET Core or .NET runtime and the [Windows 10 Universal C Runtime (CRT)](https://support.microsoft.com/topic/c0514201-7fe6-95a3-b0a5-287930f3560c). The last officially supported version of PowerShell 7 on this version of Windows is 7.2 (7.2.19 from August 2024), which means the last supported version of the module in PowerShell 7 is v3.5.0 (May 2024).<br/>
-⁴ The latest version of the module supported on this version of Windows is v2.0.3 (September 2020).<br/>
-⁵ Windows PowerShell 5.1 on this version of Windows requires the .NET Framework 4.5 or later and the Windows Management Framework 5.1. For more information, see [Windows Management Framework 5.1](https://aka.ms/wmf5download).
+  |Module version|PowerShell version|Supported Windows version|.NET requirement|
+  |---|---|---|---|
+  |2.0.5 or later|5.1|Anniversary Update (version 1607; August 2016) or later|.NET Framework 4.7.2<br/>April 2018 Update (version 1803) or later includes the .NET Framework 4.7.2, so you don't need to download it.|
+  |3.5.0 or later|7.4.0 or later|October 2018 Update (version 1809) or later |.NET 8.0|
+  |3.0.0 to 3.4.0|7.2.0 to 7.3.7 (or later)|October 2018 Update (version 1809) or later|.NET 6.0 (7.2.x)<br/>.NET 7.0 (7.3.x)|
+  |2.0.4 and 2.0.5|7.0.3 to 7.1.5 (or later)|Anniversary Update (version 1607; August 2016) or later|.NET Core 3.1 (7.0.x)<br/>.NET 5.0 (7.1.x)|
+
+- **Windows Server 2016** and **Windows Server 2019**:
+
+  |Module version|PowerShell version|.NET requirement|
+  |---|---|---|
+  |2.0.5 or later|5.1|.NET Framework 4.7.2<br/>Included in Windows Server 2019.|
+  |3.5.0 or later|7.4.0 or later|.NET 8.0|
+  |3.0.0 to 3.4.0|7.2.0 to 7.3.7 (or later)|.NET 6.0 (7.2.x)<br/>.NET 7.0 (7.3.x)|
+  |2.0.4 and 2.0.5|7.0.3 to 7.1.5 (or later)|.NET Core 3.1 (7.0.x)<br/>.NET 5.0 (7.1.x)|
+
+- **Windows 8.1**, **Windows Server 2012**, and **Windows Server 2012 R2**:
+
+  |Module version|PowerShell version|.NET requirement|
+  |---|---|---|
+  |2.0.5 or later|5.1|.NET Framework 4.7.2|
+  |3.0.0 to 3.4.0|7.2.x|.NET 6.0|
+  |2.0.4 and 2.0.5|7.0.3 to 7.1.5 (or later)|.NET Core 3.1 (7.0.x)<br/>.NET 5.0 (7.1.x)|
+
+  PowerShell 7.2.22 (.NET 6.0) is the latest supported version in Windows 8.1, Windows Server 2012, and Windows Server 2012 R2.
+
+- **Windows 7.1 SP1** and **Windows Server 2008 R2 SP1**:
+
+  |Module version|PowerShell version|.NET requirement|
+  |---|---|---|
+  |2.0.3|5.1|.NET Framework 4.7.1|
+
+  > [!NOTE]
+  > Although you can install this version of the module, you can't connect to Exchange Online PowerShell, because version 7.0.3 lacks support for REST API connections.
 
 ### Prerequisites for the Exchange Online PowerShell module
 
@@ -317,6 +368,8 @@ For more information about execution policies, see [About Execution Policies](/p
 
 As of October 2023, REST API connections replaced basic authentication (remote PowerShell) connections in [Exchange Online PowerShell](https://techcommunity.microsoft.com/blog/exchange/deprecation-of-remote-powershell-in-exchange-online-%e2%80%93-re-enabling-or-extending-r/3779692) and [Security & Compliance PowerShell](https://techcommunity.microsoft.com/blog/exchange/deprecation-of-remote-powershell-rps-protocol-in-security-and-compliance-powersh/3815432). REST API connections don't require Basic authentication in WinRM.
 
+Version 3.2.0 (June 2023) and later version of the module fully support REST API cmdlets in Exchange Online PowerShell and Security & Compliance PowerShell.
+
 <a name='powershellget-for-rest-api-connections-in-windows'></a>
 
 ### PowerShellGet required in Windows
@@ -591,7 +644,7 @@ Unless otherwise noted, the current release of the Exchange Online PowerShell mo
 - **Get-VivaModuleFeature** now returns information about ParentFeature, ChildFeature, and PolicyModes. These values represent parent and child features of a Viva app feature along with available enablement modes for future policies.  
 - New parameters _IsUserOptedInByDefault_ on the **Add-VivaModuleFeaturePolicy** and **Update-VivaModuleFeaturePolicy** cmdlets and the corresponding property value in all **\*-VivaModuleFeaturePolicy** cmdlets. The value indicates if users are opted in or out by the policy, as long as the user doesn't set a preference.
 
-  You can use this parameter to keep the feature enabled in your organization while opting out the impacted users by default, effectively soft disabling the feature for those users.
+  You can use this parameter to keep the feature enabled in your organization while opting out the affected users by default, effectively soft disabling the feature for those users.
 
 - Deprecated the **Get-VivaFeatureCategory** cmdlet, all category-related parameters, and return values (_CategoryId_, _IsCategoryEnabled_).