Merge branch 'main' into docs-editor/Set-CsTeamsCallingPolicy-1772727701

Author: emilykirby

.github/workflows/AutoIssueAssign.yml

@@ -0,0 +1,25 @@
+name: (Scheduled) Auto issue assign
+
+permissions:
+  issues: write
+      
+on:
+  schedule:
+    - cron: "0 17 * * *"
+
+  workflow_dispatch:
+  
+
+jobs:
+
+  stale-branch:
+    if: github.repository_owner == 'MicrosoftDocs'
+    uses: MicrosoftDocs/microsoft-365-docs/.github/workflows/Shared-AutoIssueAssign.yml@workflows-prod
+    with:
+        PayloadJson: ${{ toJSON(github) }}
+        ExcludedUserList: '["user1", "user2"]'
+
+    secrets:
+        AccessToken: ${{ secrets.GITHUB_TOKEN }}
+        PrivateKey: ${{ secrets.M365_APP_PRIVATE_KEY }}
+        ClientId: ${{ secrets.M365_APP_CLIENT_ID }}

.github/workflows/AutoPublish.yml

@@ -1,3 +1,4 @@
+
 name: (Scheduled) Publish to live
 
 permissions:
@@ -7,8 +8,8 @@ permissions:
 
 on:
   schedule:
-    # - cron: "25 2,5,8,11,14,17,20,22 * * *" # Times are UTC based on Daylight Saving Time (~Mar-Nov). Scheduling at :25 to account for queuing lag.
-    - cron: "25 3,6,9,12,15,18,21,23 * * *" # Times are UTC based on Standard Time (~Nov-Mar). Scheduling at :25 to account for queuing lag.
+    - cron: "25 2,5,8,11,14,17,20,22 * * *" # Times are UTC based on Daylight Saving Time (~Mar-Nov). Scheduling at :25 to account for queuing lag.
+    # - cron: "25 3,6,9,12,15,18,21,23 * * *" # Times are UTC based on Standard Time (~Nov-Mar). Scheduling at :25 to account for queuing lag.
 
   workflow_dispatch:
 
@@ -25,4 +26,4 @@ jobs:
     secrets:
         AccessToken: ${{ secrets.GITHUB_TOKEN }}
         PrivateKey: ${{ secrets.M365_APP_PRIVATE_KEY }}
-        ClientId: ${{ secrets.M365_APP_CLIENT_ID }}
+        ClientId: ${{ secrets.M365_APP_CLIENT_ID }}

exchange/docs-conceptual/app-only-auth-powershell-v2.md

@@ -1,6 +1,6 @@
 ---
 title: App-only authentication in Exchange Online PowerShell and Security & Compliance PowerShell
-ms.date: 02/27/2026
+ms.date: 03/11/2026
 ms.audience: Admin
 audience: Admin
 ms.topic: article
@@ -18,7 +18,7 @@ description: "Learn how to configure app-only authentication (also known as cert
 
 Auditing and reporting scenarios in Microsoft 365 often involve unattended scripts in Exchange Online PowerShell and Security & Compliance PowerShell. In the past, unattended sign in required you to store the username and password in a local file or in a secret vault accessed at run-time. But, as we all know, storing user credentials locally isn't a good security practice.
 
-Certificate based authentication (CBA) or app-only authentication as described in this article supports unattended script and automation scenarios by using Microsoft Entra apps and self-signed certificates.
+Certificate based authentication (CBA) or app-only authentication as described in this article supports unattended script and automation scenarios by using Microsoft Entra apps and certificates.
 
 > [!NOTE]
 >
@@ -151,16 +151,16 @@ For a detailed visual flow about creating applications in Microsoft Entra ID, se
 
    An application object has the **Delegated** API permission **Microsoft Graph** \> **User.Read** by default. For the application object to access resources in Exchange, it needs the **Application** API permission **Office 365 Exchange Online** \> **Exchange.ManageAsApp**.
 
-3. [Generate a self-signed certificate](#step-3-generate-a-self-signed-certificate)
+3. [Generate a certificate](#step-3-generate-a-certificate)
 
    - For app-only authentication in Microsoft Entra ID, you typically use a certificate to request access. Anyone who has the certificate and its private key can use the app with the permissions granted to the app.
 
-   - Create and configure a self-signed X.509 certificate, which is used to authenticate your Application against Microsoft Entra ID, while requesting the app-only access token.
+   - Create and configure an X.509 certificate, which is used to authenticate your Application against Microsoft Entra ID, while requesting the app-only access token. The certificate can be self-signed.
 
-   - This procedure is similar to generating a password for user accounts. The certificate can be self-signed as well. See [this section](#step-3-generate-a-self-signed-certificate) later in this article for instructions to generate certificates in PowerShell.
+   - This procedure is similar to generating a password for user accounts. See [this section](#step-3-generate-a-certificate) later in this article for instructions to generate certificates in PowerShell.
 
      > [!NOTE]
-     > Cryptography: Next Generation (CNG) certificates aren't supported for app-only authentication with Exchange. CNG certificates are created by default in modern versions of Windows. You must use a certificate from a CSP key provider. [This section](#step-3-generate-a-self-signed-certificate) section covers two supported methods to create a CSP certificate.
+     > Cryptography: Next Generation (CNG) certificates aren't supported for app-only authentication with Exchange. CNG certificates are created by default in modern versions of Windows. You must use a certificate from a CSP key provider. [This section](#step-3-generate-a-certificate) section covers two supported methods to create a CSP certificate.
 
 4. [Attach the certificate to the Microsoft Entra application](#step-4-attach-the-certificate-to-the-microsoft-entra-application)
 
@@ -334,27 +334,36 @@ Choose **one** of the following methods in this section to assign API permission
 
 6. Close the current **API permissions** page (not the browser tab) to return to the **App registrations** page. You use the **App registrations** page in an upcoming step.
 
-### Step 3: Generate a self-signed certificate
+<a name="step-3-generate-a-self-signed-certificate"></a>
 
-Create a self-signed x.509 certificate using one of the following methods:
+### Step 3: Generate a certificate
 
-- (Recommended) Use the [New-SelfSignedCertificate](/powershell/module/pki/new-selfsignedcertificate), [Export-Certificate](/powershell/module/pki/export-certificate), and [Export-PfxCertificate](/powershell/module/pki/export-pfxcertificate) cmdlets in an elevated (run as administrator) Windows PowerShell session to request a self-signed certificate and export it to `.cer` and `.pfx` (SHA1 by default). For example:
+> [!NOTE]
+> Cryptography: Next Generation (CNG) certificates aren't supported for app-only authentication as described in this article. CNG certificates are created by default in modern Windows versions. You need to use a certificate from a CSP key provider.
+>
+> You can use a self-signed certificate, a certificate issued by an internal public key infrastructure or PKI (for example, Active Directory Certificate Services or AD CS), or a certificate issued by a trusted commercial certificate authority (CA).
+>
+> The only requirements for the X.509 certificate are an exportable and available private key (.pfx) and public certificate (.cer).
 
-  ```powershell
-  # Create certificate
-  $mycert = New-SelfSignedCertificate -DnsName "contoso.org" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange
+For a **self-signed certificate**, use one of the following methods:
 
-  # Export certificate to .pfx file
-  $mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password
+- (Recommended): Use the [New-SelfSignedCertificate](/powershell/module/pki/new-selfsignedcertificate), [Export-Certificate](/powershell/module/pki/export-certificate) and [Export-PfxCertificate](/powershell/module/pki/export-pfxcertificate) cmdlets in an elevated PowerShell session (a PowerShell window you opened after selecting **Run as administrator**) to request a self-signed certificate and export the certificate's private and public keys to files (SHA1 by default). For example:
 
-  # Export certificate to .cer file
-  $mycert | Export-Certificate -FilePath mycert.cer
-  ```
+    ```powershell
+    # Create a self-signed certificate
+    $mycert = New-SelfSignedCertificate -DnsName "contoso.org" -CertStoreLocation "cert:\CurrentUser\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange
+
+    # Export the X.509 certificate and the associated private key to a password-protected .pfx file
+    $mycert | Export-PfxCertificate -FilePath mycert.pfx -Password (Get-Credential).password
+
+    # Export the X.509 public certificate to a .cer file
+    $mycert | Export-Certificate -FilePath mycert.cer
+    ```
 
 - Use the [Create-SelfSignedCertificate script](https://github.com/SharePoint/PnP-Partner-Pack/blob/master/scripts/Create-SelfSignedCertificate.ps1) script to generate SHA1 certificates.
 
   ```powershell
-  .\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2021-01-06 -EndDate 2022-01-06
+  .\Create-SelfSignedCertificate.ps1 -CommonName "MyCompanyName" -StartDate 2026-01-06 -EndDate 2027-01-06
   ```
 
 ### Step 4: Attach the certificate to the Microsoft Entra application
@@ -375,12 +384,10 @@ After you register the certificate with your application, you can use the privat
 
    ![Select Upload certificate on the Certificates & secrets page.](media/exo-app-only-auth-select-upload-certificate.png)
 
-   In the dialog that opens, browse to the self-signed certificate (`.cer` file) that you created in [Step 3](#step-3-generate-a-self-signed-certificate).
+   In the **Upload certificate** flyout that opens, browse to the public certificate (`.cer` file) you exported in [Step 3](#step-3-generate-a-certificate), and then select **Add**.
 
    ![Browse to the certificate and then select Add.](media/exo-app-only-auth-upload-certificate-dialog.png)
 
-   When you're finished, select **Add**.
-
    The certificate is now shown in the **Certificates** section.
 
    ![Application page showing that the certificate was added.](media/exo-app-only-auth-certificate-successfully-added.png)
@@ -405,19 +412,17 @@ For more information about the URL syntax, see [Request the permissions from a d
 
 You have the following options:
 
-- **Option 1: Assign Microsoft Entra roles to the application**: Use built-in Microsoft Entra roles to grant all permissions of the role. You can't customize or scope these roles.
- 
-- **Option 2: Assign custom role groups to the application using service principals**: We recommend this option in the following scenarios:
+- [Option 1: Assign Microsoft Entra roles to the application](#option-1-assign-microsoft-entra-roles-to-the-application): Use built-in Microsoft Entra roles to grant all permissions of the role. You can't customize or scope these roles.
+
+- [Option 2: Assign custom role groups to the application using service principals](#option-2-assign-custom-role-groups-to-the-application-using-service-principals): We recommend this option in the following scenarios:
   - You need to restrict the available commands in your application.
   - You need to use a Write scope to limit which recipients can be modified.
 
- - **Option 3: Combine Microsoft Entra roles with custom role groups**: We recommend this method to extend a built-in Microsoft Entra role (for example, the **Exchange Recipient Administrator** role) by granting extra permissions from a custom role.
+- <u>Option 3: Combine Microsoft Entra roles with custom role groups</u>: RBAC combines permissions from all sources. We recommend this method to extend the capabilities of a built-in Microsoft Entra role. For example, you can extend the capabilities of the **Exchange Recipient Administrator** role by granting extra permissions from a custom role.
 
 These options are described in the following subsections.
 
 > [!NOTE]
-> RBAC combines permissions from all sources. For example, you can use the **Exchange Recipient Administrator** role in Microsoft Entra and also assign your custom RBAC role to extend the permissions.
->
 > For multitenant applications in **Exchange Online** delegated scenarios, you need to assign permissions in each customer tenant.
 
 <a name="assign-microsoft-entra-roles-to-the-application"></a>

exchange/docs-conceptual/media/exo-app-only-auth-certificate-successfully-added.png

@@ -13,7 +13,7 @@ title: Complete-MigrationBatch
 ## SYNOPSIS
 This cmdlet is available in on-premises Exchange and in the cloud-based service. Some parameters and settings might be exclusive to one environment or the other.
 
-Use the Complete-MigrationBatch cmdlet to finalize a migration batch for a local move, cross-forest move, or remote move migration that has successfully finished initial synchronization.
+Use the Complete-MigrationBatch cmdlet to finalize a migration batch that has successfully finished initial synchronization.
 
 For information about the parameter sets in the Syntax section below, see [Exchange cmdlet syntax](https://learn.microsoft.com/powershell/exchange/exchange-cmdlet-syntax).
 
@@ -32,17 +32,22 @@ Complete-MigrationBatch [[-Identity] <MigrationBatchIdParameter>]
 ```
 
 ## DESCRIPTION
-After a migration batch for a local or cross-forest move has successfully run and has a status state of Synced, use the Complete-MigrationBatch cmdlet to finalize the migration batch. Finalization is the last phase performed during a local or cross-forest move. When you finalize a migration batch, the cmdlet does the following for each mailbox in the migration batch:
+After a migration batch has successfully run and has a status of Synced or SyncedWithErrors, use the Complete-MigrationBatch cmdlet to finalize the migration batch. When you finalize a migration batch, the cmdlet does the following for each mailbox in the migration batch:
 
 - Runs a final incremental synchronization.
 - Configures the user's Microsoft Outlook profile to point to the new target domain.
 - Converts the source mailbox to a mail-enabled user in the source domain.
 
-In the cloud-based service, this cmdlet sets the value of CompleteAfter to the current time. It is important to remember that any CompleteAfter setting applied to the individual users within the batch overrides the setting on the batch, so the completion for some users might be delayed until their configured time.
+In the cloud-based service, this cmdlet sets the CompleteAfter value to the current UTC time, which signals the migration service to complete the batch as soon as possible. This is equivalent in intent to running `Set-MigrationBatch -CompleteAfter (Get-Date)`, but without timezone conversion ambiguity.
+
+Note the following behavior when using this cmdlet in Exchange Online:
+
+- Any CompleteAfter setting applied to individual users within the batch overrides the batch-level setting, so completion for some users might be delayed until their configured time.
+- If you run this cmdlet multiple times within 8 hours after the batch has already been signaled for completion, the migration service may not re-process the request. This behavior is by design to prevent repeated calls from starving the service. If the batch appears stuck after running the cmdlet, check for unapproved skipped items (use `Set-MigrationUser -ApproveSkippedItems`).
 
 When the finalization process is complete, you can remove the batch by using the Remove-MigrationBatch cmdlet.
 
-If a migration batch has a status of Completed with Errors, you can re-attempt to finalize the failed users. In Exchange Online, use the Start-MigrationBatch cmdlet to retry migration for failed users. In Exchange 2013 or Exchange 2016, use the Complete-MigrationBatch to retry these failed users.
+If a migration batch has a status of Completed with Errors, you can re-attempt to finalize the failed users. In Exchange Online, use the Start-MigrationBatch cmdlet to retry migration for failed users. In Exchange 2013 or later, use the Complete-MigrationBatch to retry these failed users.
 
 You need to be assigned permissions before you can run this cmdlet. Although this article lists all parameters for the cmdlet, you might not have access to some parameters if they aren't included in the permissions assigned to you. To find the permissions required to run any cmdlet or parameter in your organization, see [Find the permissions required to run any Exchange cmdlet](https://learn.microsoft.com/powershell/exchange/find-exchange-cmdlet-permissions).
 
@@ -159,7 +164,6 @@ Default value: None
 Accept pipeline input: False
 Accept wildcard characters: False
 ```
-
 ### -Partition
 
 > Applicable: Exchange Online
@@ -184,7 +188,11 @@ Accept wildcard characters: False
 
 > Applicable: Exchange Server 2016, Exchange Server 2019, Exchange Server SE, Exchange Online
 
-The SyncAndComplete switch specifies whether to trigger a synchronization immediately followed by a completion of the migration batch if the synchronization was successful. You don't need to specify a value with this switch.
+The SyncAndComplete switch specifies whether to trigger a final incremental synchronization immediately followed by completion of the migration batch if the synchronization was successful. You don't need to specify a value with this switch.
+
+When this switch is used, the batch must have zero failed, corrupted, or stopped items; otherwise, the cmdlet returns an error.
+
+**Note:** For Public Folder migration batches, this switch is enabled by default unless the CompletePublicFolderMigrationWithDataLoss switch is also specified.
 
 ```yaml
 Type: SwitchParameter
@@ -222,13 +230,27 @@ This cmdlet supports the common parameters: -Debug, -ErrorAction, -ErrorVariable
 ## INPUTS
 
 ### Input types
-To see the input types that this cmdlet accepts, see [Cmdlet Input and Output Types](https://go.microsoft.com/fwlink/p/?linkId=616387). If the Input Type field for a cmdlet is blank, the cmdlet doesn't accept input data.
+To see the input types that this cmdlet accepts, see [Cmdlet Input and Output Types](https://go.microsoft.com/fwlink/p/?linkId=616387). If the Input Type field for a cmdlet is blank, the cmdlet does not accept input data.
 
 ## OUTPUTS
 
 ### Output types
-To see the return types, which are also known as output types, that this cmdlet accepts, see [Cmdlet Input and Output Types](https://go.microsoft.com/fwlink/p/?linkId=616387). If the Output Type field is blank, the cmdlet doesn't return data.
+To see the return types, which are also known as output types, that this cmdlet accepts, see [Cmdlet Input and Output Types](https://go.microsoft.com/fwlink/p/?linkId=616387). If the Output Type field is blank, the cmdlet does not return data.
 
 ## NOTES
 
+In Exchange Online, this cmdlet is supported for the following migration types:
+
+- Exchange Local Move
+- Exchange Remote Move
+- Gmail
+- Google Resource
+- Local Relocation
+- Folder Move
+- PST Import
+- Public Folder
+- Public Folder to Unified Group
+
+In Exchange Online, this cmdlet isn't supported for IMAP, staged Exchange Outlook Anywhere (cutover), or Bulk Provisioning migrations, which don't have a finalization step.
+
 ## RELATED LINKS

exchange/docs-conceptual/media/exo-app-only-auth-select-upload-certificate.png

@@ -29,6 +29,8 @@ Get-Label [[-Identity] <ComplianceRuleIdParameter>]
 ```
 
 ## DESCRIPTION
+**Note**: If your organization has more han 1000 sensitivity labels, the timeout settings set for the Powershell session may cause performance issues. Use the SkipValidations parameter to retrieve labels more efficiently.
+
 To use this cmdlet in Security & Compliance PowerShell, you need to be assigned permissions. For more information, see [Permissions in the Microsoft Purview compliance portal](https://learn.microsoft.com/purview/microsoft-365-compliance-center-permissions).
 
 ## EXAMPLES
@@ -113,7 +115,13 @@ Accept wildcard characters: False
 
 > Applicable: Security & Compliance
 
-{{ Fill SkipValidations Description }}
+The SkipValidations switch specifies whether to skip the retrieval of encryption properties configured in sensitivity labels. You don't need to specify a value with this switch.
+
+Organizations with more than 1000 labels can use this switch to reduce the time required to fetch the labels, which helps prevent timeout issues with Get-Label cmdlet.
+
+**Note**: Using this switch doesn't skip validations when you retrieve labels. It only skips the the retrieval of encryption template properties if they're configured for a label. You can get those properties individually by using the Identity parameter in the Get-Label command.
+
+This switch doesn't affect label application or distribution. The limitation exists only when fetching labels for CRUD operations.
 
 ```yaml
 Type: SwitchParameter