Merge branch 'master' into CAPR-chrisda

Author: chrisda

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

@@ -13,7 +13,6 @@ ms.collection: Strat_EX_Admin
 ms.custom:
 ms.assetid:
 search.appverid: MET150
-ROBOTS: NOINDEX, NOFOLLOW
 description: "Learn about using the Exchange Online V2 module in scripts and other long-running tasks with modern authentication and app-only authentication."
 ---
 
@@ -41,7 +40,7 @@ The following examples show how to use the Exchange Online PowerShell V2 module
   ```
 
   When you use the _CertificateThumbPrint_ parameter, the certificate needs to be installed on the computer where you are running the command. The certificate should be installed in the user certificate store.
-  
+
 - Connect using a certificate object:
 
   ```powershell
@@ -50,11 +49,17 @@ The following examples show how to use the Exchange Online PowerShell V2 module
 
   When you use the _Certificate_ parameter, the certificate does not need to be installed on the computer where you are running the command. This parameter is applicable for scenarios where the certificate object is stored remotely and fetched at runtime during script execution.
 
+> [!TIP]
+>
+> - In the **Connect-ExchangeOnline** commands, be sure to use an `.onmicrosoft.com` domain in the  _Organization_ parameter value. Otherwise, you might encounter cryptic permission issues when you run commands in the app context.
+>
+> - App-only authentication does not support delegation. Unattended scripting in delegation scenarios is supported with the Secure App Model. For more information, go [here](https://docs.microsoft.com/powershell/partnercenter/multi-factor-auth#exchange).
+
 ## How does it work?
 
 The EXO V2 module uses the Active Directory Authentication Library to fetch an app-only token using the application Id, tenant Id (organization), and certificate thumbprint. The application object provisioned inside Azure AD has a Directory Role assigned to it, which is returned in the access token. Exchange Online configures the session RBAC using the directory role information that's available in the token.
 
-## Setup app-only authentication
+## Set up app-only authentication
 
 An initial onboarding is required for authentication using application objects. Application and service principal are used interchangeably, but an application is like a class object while a service principal is like an instance of the class. You can learn more about this at [Application and service principal objects in Azure Active Directory](https://docs.microsoft.com/azure/active-directory/develop/app-objects-and-service-principals).
 
@@ -73,7 +78,7 @@ For a detailed visual flow about creating applications in Azure AD, see <https:/
    - Create and configure a self-signed X.509 certificate, which will be used to authenticate your Application against Azure AD, while requesting the app-only access token.
 
    - This is similar to generating a password for user accounts. The certificate can be self-signed as well. See the [Appendix](#step-3-generate-a-self-signed-certificate) section later in this topic for instructions for generating certificates in PowerShell.
-   
+
      > [!NOTE]
      > Cryptography: Next Generation (CNG) certificates are not supported for app-only authentication with Exchange. CNG certificates are created by default in modern Windows versions. You must use a certificate from a CSP key provider. The [Appendix](#step-3-generate-a-self-signed-certificate) section covers two supported methods to create a CSP certificate.
 
@@ -121,25 +126,27 @@ If you encounter problems, check the [required permssions](https://docs.microsof
 
 You need to assign the API permission `Exchange.ManageAsApp` so the application can manage Exchange Online. API permissions are required because they have consent flow enabled, which allows auditing (directory roles don't have consent flow).
 
-1. Select **API permissions**.
-
-2. In the **Configured permissions** page that appears, click **Add permission**.
-
-3. In the flyout that appears, select **Exchange**.
-
-   ![Select Exchange API permssions](media/app-only-auth-exchange-api-perms.png)
-
-4. In the flyout that appears, click **Application permissions**.
+1. Select **Manifest** in the left-hand navigation under **Manage**.
 
-5. In the **Select permissions** section that appears on the page, expand **Exchange** and select **Exchange.ManageAsApp**
+2. Locate the `requiredResourceAccess` property in the manifest, and add the following inside the square brackets (`[]`):
 
-   ![Select Exchange.ManageAsApp permssions](media/app-only-auth-exchange-manageasapp.png)
+   ```json
+   {
+       "resourceAppId": "00000002-0000-0ff1-ce00-000000000000",
+       "resourceAccess": [
+           {
+               "id": "dc50a0fb-09a3-484d-be87-e023b12c6440",
+               "type": "Role"
+           }
+       ]
+   }
+   ```
 
-   When you're finished, click **Add permissions**.
+3. Select **Save**.
 
-6. Back on the **Configured permissions** page that appears, click **Grant admin consent for \<tenant name\>**, and select **Yes** in the dialog that appears.
+4. Select **API permissions** under **Manage**. Confirm that the **Exchange.ManageAsApp** permission is listed.
 
-7. Close the flyout when you're finished.
+5. Select **Grant admin consent for org** and accept the consent dialog.
 
 ## Step 3: Generate a self-signed certificate
 
@@ -149,7 +156,7 @@ Create a self-signed x.509 certificate using one of the following methods:
 
 ```powershell
 # Create certificate
-$mycert = New-SelfSignedCertificate -DnsName "example.com" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(1)
+$mycert = New-SelfSignedCertificate -DnsName "example.com" -CertStoreLocation "cert:\LocalMachine\My" -NotAfter (Get-Date).AddYears(1) -KeySpec KeyExchange
 
 # Export certificate to .pfx file
 $mycert | Export-PfxCertificate -FilePath mycert.pfx -Password $(ConvertTo-SecureString -String "1234" -Force -AsPlainText)

exchange/docs-conceptual/basic-auth-connect-to-eop-powershell.md

@@ -61,7 +61,7 @@ The following introductory video shows you how to connect to and use Exchange On
   **Note**: You must temporarily enable WinRM to run the following commands. You can enable it by running the command: `winrm quickconfig`.
 
   To verify that Basic authentication is enabled for WinRM, run this command **in a Command Prompt** (not in Windows PowerShell):
-  
+
   ```dos
   winrm get winrm/config/client/auth
   ```
@@ -124,7 +124,7 @@ If you receive errors, check the following requirements:
 
 - A common problem is an incorrect password. Run the three steps again and pay close attention to the user name and password you enter in Step 1.
 
-- To help prevent denial-of-service (DoS) attacks, you're limited to three open remote PowerShell connections to your Exchange Online Protection organization.
+- To help prevent denial-of-service (DoS) attacks, you're limited to five open remote PowerShell connections to Exchange Online Protection.
 
 - TCP port 80 traffic needs to be open between your local computer and Microsoft 365. It's probably open, but it's something to consider if your organization has a restrictive Internet access policy.
 

exchange/docs-conceptual/basic-auth-connect-to-exo-powershell.md

@@ -64,7 +64,7 @@ The following introductory video shows you how to connect to and use Exchange On
   **Note**: You must temporarily enable WinRM to run the following commands. You can enable it by running the command: `winrm quickconfig`.
 
   To verify that Basic authentication is enabled for WinRM, run this command **in a Command Prompt** (not in Windows PowerShell):
-  
+
   ```dos
   winrm get winrm/config/client/auth
   ```
@@ -134,7 +134,7 @@ If you receive errors, check the following requirements:
 
 - A common problem is an incorrect password. Run the three steps again and pay close attention to the user name and password you enter in Step 1.
 
-- To help prevent denial-of-service (DoS) attacks, you're limited to three open remote PowerShell connections to your Exchange Online organization.
+- To help prevent denial-of-service (DoS) attacks, you're limited to five open remote PowerShell connections to Exchange Online.
 
 - The account you use to connect to Exchange Online must be enabled for remote PowerShell. For more information, see [Enable or disable access to Exchange Online PowerShell](disable-access-to-exchange-online-powershell.md).
 

exchange/docs-conceptual/basic-auth-connect-to-scc-powershell.md

@@ -23,15 +23,15 @@ Security & Compliance Center PowerShell allows you to manage your Security & Com
 
 > [!NOTE]
 > The procedures in this topic won't work if:
-> 
+>
 > - Your account uses multi-factor authentication (MFA).
-> 
+>
 > - Your organization uses federated authentication.
-> 
+>
 > - A location condition in an Azure Active Directory conditional access policy restricts your access to trusted IPs.
-> 
+>
 > In these scenarios, you need to download and use the Exchange Online PowerShell V2 module (EXO V2 module) to connect to Security & Compliance Center PowerShell. For instructions, see [Connect to Security & Compliance Center PowerShell using the EXO V2 module](connect-to-scc-powershell.md).
-> 
+>
 > Some features in the Security & Compliance Center (for example, mailbox archiving) link to existing functionality in Exchange Online. To use PowerShell with these features, you need to connect to Exchange Online PowerShell instead of Security & Compliance Center PowerShell. For instructions, see [Connect to Exchange Online PowerShell](connect-to-exchange-online-powershell.md).
 
 ## What do you need to know before you begin?
@@ -133,7 +133,7 @@ If you receive errors, check the following requirements:
 
 - Verify that your account has permission to access the Security & Compliance Center. For details, see [Give users access to the Security & Compliance Center](https://docs.microsoft.com/microsoft-365/security/office-365-security/grant-access-to-the-security-and-compliance-center).
 
-- To help prevent denial-of-service (DoS) attacks, you're limited to three open remote PowerShell connections to the Security & Compliance Center.
+- To help prevent denial-of-service (DoS) attacks, you're limited to five open remote PowerShell connections to the Security & Compliance Center.
 
 - TCP port 80 traffic needs to be open between your local computer and Microsoft 365. It's probably open, but it's something to consider if your organization has a restrictive Internet access policy.