Merge pull request #178132 from SGSneha/1Nov-Include-module-runbook-version

[Post-Keynote Publish] Included info - add module,note for win/linuxhybrid runbook/runtimeve…

Author: v-andreaco

articles/automation/automation-hrw-run-runbooks.md

@@ -3,7 +3,7 @@ title: Run Azure Automation runbooks on a Hybrid Runbook Worker
 description: This article describes how to run runbooks on machines in your local datacenter or other cloud provider with the Hybrid Runbook Worker.
 services: automation
 ms.subservice: process-automation
-ms.date: 09/30/2021
+ms.date: 11/01/2021
 ms.topic: conceptual 
 ms.custom: devx-track-azurepowershell
 ---
@@ -27,9 +27,19 @@ Azure Automation handles jobs on Hybrid Runbook Workers differently from jobs ru
 ### Windows 
 
 Jobs for Hybrid Runbook Workers run under the local **System** account.
+>[!NOTE]
+>  To run PowerShell 7.x on a Windows Hybrid Runbook Worker, See [Installing PowerShell on Windows](/powershell/scripting/install/installing-powershell-on-windows).
+>  Currently, we only support Hybrid worker extension based onboarding as mentioned [here.](/azure/automation/extension-based-hybrid-runbook-worker-install) 
+
+Make sure the path where the *pwsh.exe* executable is located and is added to the PATH environment variable. Restart the Hybrid Runbook Worker after installation completes.
 
 ### Linux
 
+>[!NOTE]
+> To run PowerShell 7.x on a Linux Hybrid Runbook Worker, See [Installing PowerShell on Linux](/powershell/scripting/install/installing-powershell-on-linux).
+>  Currently, we only support Hybrid worker extension based onboarding as mentioned [here.](/azure/automation/extension-based-hybrid-runbook-worker-install)
+
+
 Service accounts **nxautomation** and **omsagent** are created. The creation and permission assignment script can be viewed at [https://github.com/microsoft/OMS-Agent-for-Linux/blob/master/installer/datafiles/linux.data](https://github.com/microsoft/OMS-Agent-for-Linux/blob/master/installer/datafiles/linux.data). The accounts, with the corresponding sudo permissions, must be present during [installation of a Linux Hybrid Runbook worker](automation-linux-hrw-install.md). If you try to install the worker, and the account is not present or doesn't have the appropriate permissions, the installation fails. Do not change the permissions of the `sudoers.d` folder or its ownership. Sudo permission is required for the accounts and the permissions shouldn't be removed. Restricting this to certain folders or commands may result in a breaking change. The **nxautomation** user enabled as part of Update Management executes only signed runbooks.
 
 To ensure the service accounts have access to the stored runbook modules:
@@ -220,6 +230,9 @@ You can configure a Windows Hybrid Runbook Worker to run only signed runbooks.
 > [!IMPORTANT]
 > Once you've configured a Hybrid Runbook Worker to run only signed runbooks, unsigned runbooks fail to execute on the worker.
 
+> [!NOTE]
+>  PowerShell 7.x does not support signed runbooks for Windows and Linux Hybrid Runbook Worker.  
+
 ### Create signing certificate
 
 The following example creates a self-signed certificate that can be used for signing runbooks. This code creates the certificate and exports it so that the Hybrid Runbook Worker can import it later. The thumbprint is also returned for later use in referencing the certificate.
@@ -289,6 +302,9 @@ You will perform the following steps to complete this configuration:
 * Verify that signature validation is on
 * Sign a runbook
 
+> [!NOTE]
+>  PowerShell 7.x does not support signed runbooks for Windows and Linux Hybrid Runbook Worker.
+
 ### Create a GPG keyring and keypair
 
 To create the GPG keyring and keypair, use the Hybrid Runbook Worker [nxautomation account](automation-runbook-execution.md#log-analytics-agent-for-linux).

articles/automation/automation-runbook-types.md

@@ -54,23 +54,39 @@ You can create and edit graphical and graphical PowerShell Workflow runbooks usi
 
 PowerShell runbooks are based on Windows PowerShell. You directly edit the code of the runbook using the text editor in the Azure portal. You can also use any offline text editor and [import the runbook](manage-runbooks.md) into Azure Automation.
 
+
+The PowerShell version is determined by the **Runtime version** specified (that is version 7.1 preview or 5.1). The Azure Automation service supports the latest PowerShell runtime.
+ 
+The same Azure sandbox and Hybrid Runbook Worker can execute **PowerShell 5.1** and **PowerShell 7.1** runbooks side by side.   
+
+> [!NOTE]
+>  At the time of runbook execution, if you select **Runtime Version** as **7.1 (preview)**, PowerShell modules targeting 7.1 runtime version is used and if you select **Runtime Version** as **5.1**, PowerShell modules targeting 5.1 runtime version are used.
+ 
+Ensure that you select the right Runtime Version for modules.
+
+For example : if you are executing a runbook for a Sharepoint automation scenario in **Runtime version** *7.1 (preview)*, then import the module in **Runtime version** **7.1 (preview)**; if you are executing a runbook for a Sharepoint automation scenario in **Runtime version** **5.1**, then import the module in **Runtime version** *5.1*. In this case, you would see two entries for the module, one for **Runtime Version** **7.1(preview)** and other for **5.1**.
+
+:::image type="content" source="./media/automation-runbook-types/runbook-types.png" alt-text="runbook Types.":::
+
+
 Currently, PowerShell 5.1 and 7.1 (preview) are supported.
 
+
 ### Advantages
 
 * Implement all complex logic with PowerShell code without the other complexities of PowerShell Workflow.
 * Start faster than PowerShell Workflow runbooks, since they don't need to be compiled before running.
 * Run in Azure and on Hybrid Runbook Workers for both Windows and Linux.
 
-### Limitations
+### Limitations - version 5.1
 
 * You must be familiar with PowerShell scripting.
 * Runbooks can't use [parallel processing](automation-powershell-workflow.md#use-parallel-processing) to execute multiple actions in parallel.
 * Runbooks can't use [checkpoints](automation-powershell-workflow.md#use-checkpoints-in-a-workflow) to resume runbook if there's an error.
 * You can include only PowerShell, PowerShell Workflow runbooks, and graphical runbooks as child runbooks by using the [Start-AzAutomationRunbook](/powershell/module/az.automation/start-azautomationrunbook) cmdlet, which creates a new job.
 * Runbooks can't use the PowerShell [#Requires](/powershell/module/microsoft.powershell.core/about/about_requires) statement, it is not supported in Azure sandbox or on Hybrid Runbook Workers and might cause the job to fail.
 
-### Known issues
+### Known issues - version 5.1
 
 The following are current known issues with PowerShell runbooks:
 
@@ -79,6 +95,28 @@ The following are current known issues with PowerShell runbooks:
 * A [Get-Process](/powershell/module/microsoft.powershell.management/get-process) operation in a loop in a PowerShell runbook can crash after about 80 iterations.
 * A PowerShell runbook can fail if it tries to write a large amount of data to the output stream at once. You can typically work around this issue by having the runbook output just the information needed  to work with large objects. For example, instead of using `Get-Process` with no limitations, you can have the cmdlet output just the required parameters as in `Get-Process | Select ProcessName, CPU`.
 
+### Limitations - 7.1 (preview)
+
+-  The Azure Automation internal PowerShell cmdlets are not supported on a Linux Hybrid Runbook Worker. You must import the `automationassets` module at the beginning of your Python runbook to access the Automation account shared resources (assets) functions. 
+-  For the PowerShell 7 runtime version, the module activities are not extracted for the imported modules.
+-  *PSCredential* runbook parameter type is not supported in PowerShell 7 runtime version.
+-  PowerShell 7.x does not support workflows. See [this](/powershell/scripting/whats-new/differences-from-windows-powershell?view=powershell-7.1#powershell-workflow&preserve-view=true) for more details.
+-  PowerShell 7.x currently does not support signed runbooks.
+
+### Known Issues - 7.1 (preview)
+
+-  Executing child scripts using `.\child-runbook.ps1` is not supported in this preview. 
+  **Workaround**: Use `Start-AutomationRunbook` (internal cmdlet) or `Start-AzAutomationRunbook` (from *Az.Automation* module) to start another runbook from parent runbook.
+-  Runbook properties defining logging preference is not supported in PowerShell 7 runtime.  
+  **Workaround**: Explicitly set the preference at the start of the runbook as below -
+
+      `$VerbosePreference = "Continue"`
+
+      `$ProgressPreference = "Continue"`
+
+-   Avoid importing `Az.Accounts` module to version 2.4.0 version for PowerShell 7 runtime as there can be an unexpected behavior using this version in Azure Automation. 
+-    You might encounter formatting problems with error output streams for the job running in PowerShell 7 runtime.
+
 ## PowerShell Workflow runbooks
 
 PowerShell Workflow runbooks are text runbooks based on [Windows PowerShell Workflow](automation-powershell-workflow.md). You directly edit the code of the runbook using the text editor in the Azure portal. You can also use any offline text editor and [import the runbook](manage-runbooks.md) into Azure Automation. 

articles/automation/automation-update-azure-modules.md

@@ -31,11 +31,12 @@ If you develop your scripts locally, it's recommended to have the same module ve
 Currently, updating AZ modules is only available through the portal. Updates through PowerShell and ARM template will be available in the future. Only default Az modules will be updated when performing the following steps:
 
 1. Sign in to the [Azure portal](https://portal.azure.com) and navigate to your Automation account.
-1. Under **Shared Resources**, select **PowerShell Modules**.
+1. Under **Shared Resources**, select **Modules**.
 1. Select **Update Az modules**.
 1. Select **Module to Update**. By default, it will show Az module.  
-1. From the drop-down list, select **Module Version**.
+1. From the drop-down list, select **Module Version** and **Runtype version**
 1. Select **Update** to update the Az module to the version that you’ve selected.
+   On the **Modules** page, you can view the list as shown below:
 
    :::image type="content" source="./media/automation-update-azure-modules/update-az-modules-portal.png" alt-text="Update AZ modules page with selections.":::
 

articles/automation/media/automation-runbook-types/runbook-types.png

@@ -3,7 +3,7 @@ title: Manage modules in Azure Automation
 description: This article tells how to use PowerShell modules to enable cmdlets in runbooks and DSC resources in DSC configurations.
 services: automation
 ms.subservice: shared-capabilities
-ms.date: 04/28/2021
+ms.date: 11/01/2021
 ms.topic: conceptual 
 ms.custom: devx-track-azurepowershell
 ---
@@ -147,19 +147,29 @@ Importing an Az module into your Automation account doesn't automatically import
 
 You can import the Az modules into the Automation account from the Azure portal. Because [Az.Accounts](https://www.powershellgallery.com/packages/Az.Accounts/1.1.0) is a dependency for the other Az modules, be sure to import this module before any others.
 
+> [!NOTE]
+>  With the introduction of **PowerShell 7.1 (preview)** support, the **Browse gallery** option has been updated with the following changes:
+
+-  **Browse gallery** is available on  **Process Automation** > **Modules** blade. 
+-  The **Modules** page displays two new columns - **Module version** and **Runtime version**
+
 1. Sign in to the Azure [portal](https://portal.azure.com).
 1. Search for and select **Automation Accounts**.
 1. On the **Automation Accounts** page, select your Automation account from the list.
 1. From your Automation account, under **Shared Resources**, select **Modules**.
-1. Select **Browse Gallery**.  
-1. In the search bar, enter the module name (for example, `Az.Accounts`).
-1. On the PowerShell Module page, select **Import** to import the module into your Automation account.
+1. Select **Add a module**. In the **Add a module** page, you can select either of the following options:
+      1. **Browse for file** - selects a file from your local machine.
+      1. **Browse from Gallery** - you can browse and select an existing module from gallery.
+1. Click **Select** to select a module.
+1. Select **Runtime version** and click **Import**.
+
+      :::image type="content" source="../media/modules/import-module.png" alt-text="Screenshot of importing modules into your Automation account.":::
 
-    ![Screenshot of importing modules into your Automation account](../media/modules/import-module.png)
+1. On the **Modules** page, you can view the imported module under the Automation account.
 
 You can also do this import through the [PowerShell Gallery](https://www.powershellgallery.com), by searching for the module to import. When you find the module, select it, and choose the **Azure Automation** tab. Select **Deploy to Azure Automation**.
 
-![Screenshot of importing modules directly from PowerShell Gallery](../media/modules/import-gallery.png)
+:::image type="content" source="../media/modules/import-gallery.png" alt-text="Screenshot of importing modules directly from PowerShell Gallery.":::
 
 ### Test your runbooks