Merge pull request #109853 from BethWilke/branch4

Adding new file for managing O365

Author: American-Dipper

articles/automation/TOC.yml

@@ -17,13 +17,15 @@
       displayName: certificate renewal
     - name: Configure authentication with AWS
       href: automation-config-aws-account.md
-    - name: Encryption of secure assets in Azure Automation
+    - name: Use Azure AD in Azure Automation to authenticate to Azure
+      href: automation-use-azure-ad.md
+    - name: Manage Office 365 services using Azure Automation
+      href: manage-office-365.md
+    - name: Encrypt secure assets in Azure Automation
       href: automation-secure-asset-encryption.md
     - name: Manage role-based access control
       href: automation-role-based-access-control.md
       displayName: RBAC
-    - name: Use Azure AD in Azure Automation to authenticate to Azure
-      href: automation-use-azure-ad.md
     - name: Move your Automation Account to another Subscription
       href: how-to/move-account.md
     - name: Automate onboarding of Automation Services
@@ -327,9 +329,9 @@
       href: shared-resources/credentials.md
     - name: PowerShell modules
       items: 
-      - name: Modules
+      - name: Manage modules in Azure Automation
         href: shared-resources/modules.md
-      - name: Using Az modules in Azure Automation
+      - name: Az module support in Azure Automation
         href: az-modules.md
       - name: Update Azure PowerShell modules
         href: automation-update-azure-modules.md

articles/automation/automation-secure-asset-encryption.md

@@ -1,6 +1,6 @@
 ---
-title: Encryption of secure assets in automation
-description: Azure automation protects secure assets using multiple levels of encryption. By default, the encryption is done using Microsoft-managed keys. Customers can configure their automation accounts to use customer-managed keys for encryption. This article describes the details of both modes of encryption and how you can switch between the two.
+title: Encrypt secure assets in Azure Automation
+description: Azure Automation protects secure assets using multiple levels of encryption. By default, the encryption is done using Microsoft-managed keys. Customers can configure their automation accounts to use customer-managed keys for encryption. This article describes the details of both modes of encryption and how you can switch between the two.
 services: automation
 ms.service: automation
 ms.subservice: process-automation
@@ -11,12 +11,12 @@ ms.topic: conceptual
 manager: kmadnani
 ---
 
-# Secure assets in Azure Automation
+# Encrypt secure assets in Azure Automation
 
 Secure assets in Azure Automation include credentials, certificates, connections, and encrypted variables. These assets are protected in Azure Automation using multiple levels of encryption. 
 Based on the top-level key used for the encryption, there are two models for encryption:
--	Using Microsoft-managed keys
--	Using customer-managed keys
+-    Using Microsoft-managed keys
+-    Using customer-managed keys
 
 ## Microsoft-managed Keys
 

articles/automation/automation-use-azure-ad.md

@@ -90,7 +90,7 @@ You can use the Azure portal to create the credential asset. Do this operation f
 
 ### Create the credential asset with Windows PowerShell
 
-To prepare a new credential asset in Windows PowerShell, your script first creates a `PSCredential` object using the assigned username and password. The script then uses this object to create the asset through a call to the [New-AzureAutomationCredential](https://docs.microsoft.com/powershell/module/servicemanagement/azure/new-azureautomationcredential?view=azuresmps-4.0.0) cmdlet. Alternatively, the script can call the [Get-Credential](https://docs.microsoft.com/powershell/module/microsoft.powershell.security/get-credential?view=powershell-7) cmdlet to prompt the user to type in a name and password. See [Credential assets in Azure Automation](shared-resources/credentials.md). 
+To prepare a new credential asset in Windows PowerShell, your script first creates a `PSCredential` object using the assigned user name and password. The script then uses this object to create the asset through a call to the [New-AzureAutomationCredential](https://docs.microsoft.com/powershell/module/servicemanagement/azure/new-azureautomationcredential?view=azuresmps-4.0.0) cmdlet. Alternatively, the script can call the [Get-Credential](https://docs.microsoft.com/powershell/module/microsoft.powershell.security/get-credential?view=powershell-7) cmdlet to prompt the user to type in a name and password. See [Credential assets in Azure Automation](shared-resources/credentials.md). 
 
 ## Managing Azure resources from an Azure Automation runbook
 

articles/automation/az-modules.md

@@ -1,6 +1,6 @@
 ---
-title: Using Az modules in Azure Automation
-description: This article provides information using Az modules in Azure Automation
+title: Az module support in Azure Automation
+description: This article provides information about using Az modules in Azure Automation.
 services: automation
 ms.subservice: shared-capabilities
 ms.date: 02/08/2019
@@ -9,58 +9,60 @@ ms.topic: conceptual
 
 # Az module support in Azure Automation
 
-Azure automation supports the ability to use the [Azure Powershell Az module](/powershell/azure/new-azureps-module-az?view=azps-1.1.0) in your runbooks. The Az module is not imported automatically in any new or existing Automation Accounts. This article discusses how to use Az modules with Azure Automation.
+Azure Automation supports the use of [Azure PowerShell Az module](/powershell/azure/new-azureps-module-az?view=azps-1.1.0) in your runbooks. The Az module is not imported automatically in any new or existing Automation accounts. 
 
 ## Considerations
 
-There are many things to take into consideration when using the Az module in Azure Automation. Runbooks and modules can be used by higher-level solutions in your Automation Account. Editing runbooks or upgrading modules can potentially cause issues with your runbooks. You should test all runbooks and solutions carefully in a separate Automation Account before importing the new `Az` modules. Any modifications to modules can negatively affect the [Start/Stop](automation-solution-vm-management.md) solution. We don't recommend altering modules and runbooks in Automation Accounts that contain any solutions. This behavior isn't specific to the Az modules. This behavior should be taken into consideration when introducing any changes to your Automation Account.
+There are many things to take into consideration when using the Az module in Azure Automation. Runbooks and modules can be used by higher-level solutions in your Automation account. Editing runbooks or upgrading modules can potentially cause issues with your runbooks. You should test all runbooks and solutions carefully in a separate Automation account before importing the new `Az` modules. Any modifications to modules can negatively affect the [Start/Stop](automation-solution-vm-management.md) solution. We don't recommend altering modules and runbooks in Automation accounts that contain any solutions. This behavior isn't specific to the Az modules. This behavior should be taken into consideration when introducing any changes to your Automation account.
 
-Importing an `Az` module in your Automation Account doesn't automatically import the module in the PowerShell session that the runbooks use. Modules are imported into the PowerShell session in the following situations:
+Importing an `Az` module in your Automation account doesn't automatically import the module in the PowerShell session that the runbooks use. Modules are imported into the PowerShell session in the following situations:
 
 * When a cmdlet from a module is invoked from a runbook
 * When a runbook imports it explicitly with the `Import-Module` cmdlet
 * When another module depending on the module is imported into a PowerShell session
 
 > [!IMPORTANT]
-> It is important to make sure that runbooks in an Automation Account either only import `Az` or `AzureRM` modules into the PowerShell sessions used by runbooks and not both. If `Az` is imported before `AzureRM` in a runbook, the runbook will complete, but an [error referencing the get_SerializationSettings method](troubleshoot/runbooks.md#get-serializationsettings) will show in the job streams and cmdlets may have not been properly executed. If you import `AzureRM` and then `Az` your runbook will still complete, but you will see an error in the job streams stating that both `Az` and `AzureRM` cannot be imported in the same session or used in the same runbook.
+> It is important to make sure that runbooks in an Automation account either only import `Az` or `AzureRM` modules into the PowerShell sessions used by runbooks and not both. If `Az` is imported before `AzureRM` in a runbook, the runbook completes, but an error referencing the [Get_SerializationSettings](troubleshoot/runbooks.md#get-serializationsettings) cmdlet shows up in the job streams and cmdlets might not be properly executed. If you import `AzureRM` and then `Az`, your runbook still completes, but you receive an error in the job streams stating that both `Az` and `AzureRM` can't be imported in the same session or used in the same runbook.
 
 ## Migrating to Az modules
 
-It's recommended you test the migration to using Az modules instead of AzureRM modules in a test Automation Account. Once that Automation Account has been created, you can use the following steps to ensure your migration goes smoothly:
+It's recommended that you test the migration to Az modules in a test Automation account. Once that Automation account has been created, you can use the instructions in this section to work with the modules.
 
-### Stop and unschedule all runbook that uses AzureRM modules
+### Stop and unschedule all runbooks that use AzureRM cmdlets
 
-To ensure that you do not run any existing runbooks that use `AzureRM` cmdlets, you should stop and unschedule all runbooks that use `AzureRM` modules. You can see what schedules exist and which schedules must be removed by running the following example:
+To ensure that you do not run any existing runbooks that use `AzureRM` cmdlets, you should stop and unschedule all runbooks that use `AzureRM` modules. You can see what schedules exist and which schedules must be removed by running code similar to this example.
 
   ```powershell-interactive
   Get-AzureRmAutomationSchedule -AutomationAccountName "<AutomationAccountName>" -ResourceGroupName "<ResourceGroupName>" | Remove-AzureRmAutomationSchedule -WhatIf
   ```
 
-It's important to review each schedule separately to ensure you can reschedule it in the future for your runbooks if necessary.
+It's important to review each schedule separately to ensure that you can reschedule it in the future for your runbooks if necessary.
 
 ### Import the Az modules
 
-Only import the Az modules that are required for your runbooks. Don't import the rollup `Az` module, as it includes all of the `Az.*` modules to be imported. This guidance is the same for all modules.
+Only import the Az modules that are required for your runbooks. Don't import the rollup `Az` module, as it includes all `Az.*` modules. This guidance is the same for all modules.
 
-The [Az.Accounts](https://www.powershellgallery.com/packages/Az.Accounts/1.1.0) module is a dependency for the other `Az.*` modules. For this reason, this module needs to be imported into your Automation Account before you import any other modules.
+The [Az.Accounts](https://www.powershellgallery.com/packages/Az.Accounts/1.1.0) module is a dependency for the other `Az.*` modules. For this reason, this module needs to be imported into your Automation account before you import any other modules.
 
-From your Automation Account, select **Modules** under **Shared Resources**. Click **Browse Gallery** to open the **Browse Gallery** page.  In the search bar, enter the module name (such as `Az.Accounts`). On the PowerShell Module page, click **Import** to import the module into your Automation Account.
+From your Automation account, select **Modules** under **Shared Resources**. Click **Browse Gallery** to open the **Browse Gallery** page.  In the search bar, enter the module name (such as `Az.Accounts`). On the PowerShell Module page, click **Import** to import the module into your Automation account.
 
-![Import modules from Automation Account](media/az-modules/import-module.png)
+![Import modules from Automation account](media/az-modules/import-module.png)
 
-This import process can also be done through the [PowerShell Gallery](https://www.powershellgallery.com) by searching for the module. Once you find the module, select it and under the **Azure Automation** tab, click **Deploy to Azure Automation**.
+This import process can also be done through the [PowerShell Gallery](https://www.powershellgallery.com) by searching for the module for import. Once you find the module, select it and under the **Azure Automation** tab, click **Deploy to Azure Automation**.
 
 ![Import modules directly from gallery](media/az-modules/import-gallery.png)
 
-## Test your runbooks
+## Testing your runbooks
 
-Once the `Az` modules are imported in your Automation Account, you can now start editing your runbooks to use the Az module instead. The majority of the cmdlets have the same name except for `AzureRM` has been changed to `Az`. For a list of modules that do not follow this process, see [list of exceptions](/powershell/azure/migrate-from-azurerm-to-az#update-cmdlets-modules-and-parameters).
+Once the `Az` modules are imported into your Automation account, you can start editing your runbooks to use the Az modules. The majority of the cmdlets have the same names except that `AzureRM` has been changed to `Az`. For a list of modules that do not follow this naming convention, see [list of exceptions](/powershell/azure/migrate-from-azurerm-to-az#update-cmdlets-modules-and-parameters).
 
-One way to test your runbooks before modifying your runbook to use the new cmdlets is by using `Enable-AzureRMAlias -Scope Process` at the beginning of a runbook. By adding this to your runbook, your runbook can run without changes.
+One way to test the modification of a runbook to use the new cmdlets is by using `Enable-AzureRMAlias -Scope Process` at the beginning of the runbook. By adding this command to your runbook, the script can run without changes.
 
-## After migration details
+## After-migration details
 
-After the migration is complete, don’t start runbooks using `AzureRM` modules on the account any longer. It's also recommended don’t import or update `AzureRM` modules on this account. Starting from this moment, consider this account migrated to `Az`, and operate with `Az` modules only. When a new Automation Account is created the existing `AzureRM` modules will still be installed and the tutorial runbooks will still be authored with `AzureRM` cmdlets. These runbooks should not be run.
+After the migration is complete, don't try to start runbooks using `AzureRM` modules on the Automation account any longer. It's also recommended to not import or update `AzureRM` modules on the account. Consider the account migrated to `Az`, and operate with `Az` modules only. 
+
+When a new Automation account is created, the existing `AzureRM` modules are still installed. You can still update the tutorial runbooks with `AzureRM` cmdlets. You should not run these runbooks.
 
 ## Next steps