Merge pull request #96163 from sdwheeler/sdw-fix-pslinks

Fix broken links to PowerShell docs

Author: American-Dipper

articles/automation/automation-linux-hrw-install.md

@@ -48,7 +48,7 @@ The minimum requirements for a Linux Hybrid Runbook Worker are:
 |Python-ctypes | Python 2.x is required |
 |PAM | Pluggable Authentication Modules|
 | **Optional package** | **Description** | **Minimum version**|
-| PowerShell Core | To run PowerShell runbooks, PowerShell needs to be installed, see [Installing PowerShell Core on Linux](/powershell/scripting/setup/installing-powershell-core-on-linux) to learn how to install it.  | 6.0.0 |
+| PowerShell Core | To run PowerShell runbooks, PowerShell needs to be installed, see [Installing PowerShell Core on Linux](/powershell/scripting/install/installing-powershell-core-on-linux) to learn how to install it.  | 6.0.0 |
 
 ### Installation
 
@@ -101,7 +101,7 @@ The following runbook types work on a Linux Hybrid Worker:
 * PowerShell
 
   > [!NOTE]
-  > PowerShell runbooks require PowerShell Core to be installed on the Linux machine. See [Installing PowerShell Core on Linux](/powershell/scripting/setup/installing-powershell-core-on-linux) to learn how to install it.
+  > PowerShell runbooks require PowerShell Core to be installed on the Linux machine. See [Installing PowerShell Core on Linux](/powershell/scripting/install/installing-powershell-core-on-linux) to learn how to install it.
 
 The following runbook types don't work on a Linux Hybrid Worker:
 

articles/marketplace/cloud-partner-portal/virtual-machine/cpp-get-sas-uri.md

@@ -1,7 +1,7 @@
 ---
 title: Get shared access signature URI for your Microsoft Azure-based VM image | Azure Marketplace
 description: Explains how to get the shared access signature (SAS) URI for your VM image.
-services: Azure, Marketplace, Cloud Partner Portal, 
+services: Azure, Marketplace, Cloud Partner Portal,
 author: pbutlerm
 ms.service: marketplace
 ms.subservice: partnercenter-marketplace-publisher
@@ -12,7 +12,7 @@ ms.author: pabutler
 
 # Get shared access signature URI for your VM image
 
-During the publishing process, you must provide a uniform resource identifier (URI) for each virtual hard disk (VHD) associated with your SKUs. Microsoft needs access to these VHDs during the certification process. This article explains how to generate a shared access signature (SAS) URI for each VHD. You will enter this URI in the **SKUs** tab in the Cloud Partner Portal. 
+During the publishing process, you must provide a uniform resource identifier (URI) for each virtual hard disk (VHD) associated with your SKUs. Microsoft needs access to these VHDs during the certification process. This article explains how to generate a shared access signature (SAS) URI for each VHD. You will enter this URI in the **SKUs** tab in the Cloud Partner Portal.
 
 When generating SAS URIs for your VHDs, adhere to the following requirements:
 
@@ -33,35 +33,35 @@ The SAS URL can be generated in two common ways using the following tools:
 
 Use the following steps to generate a SAS URI with Azure CLI.
 
-1. Download and install the [Microsoft Azure CLI](https://azure.microsoft.com/documentation/articles/xplat-cli-install/).  Versions are available for Windows, macOS, and various distros of Linux. 
+1. Download and install the [Microsoft Azure CLI](https://azure.microsoft.com/documentation/articles/xplat-cli-install/).  Versions are available for Windows, macOS, and various distros of Linux.
 2. Create a PowerShell file (`.ps1` file extension), copy in the following code, then save it locally.
 
    ``` powershell
    az storage container generate-sas --connection-string 'DefaultEndpointsProtocol=https;AccountName=<account-name>;AccountKey=<account-key>;EndpointSuffix=core.windows.net' --name <vhd-name> --permissions rl --start '<start-date>' --expiry '<expiry-date>'
    ```
-    
+
 3. Edit the file to supply the following parameter values.  Dates should be provided in UTC datetime format, for example `2016-10-25T00:00:00Z`.
    - `<account-name>` - Your Azure storage account name
    - `<account-key>` - Your Azure storage account key
    - `<vhd-name>` - Your VHD name
-   - `<start-date>` - Permission start date for VHD access. Provide a date one day before the current date. 
-   - `<expiry-date>` - Permission expiration date for VHD access.  Provide a date at least three weeks beyond the current date. 
- 
+   - `<start-date>` - Permission start date for VHD access. Provide a date one day before the current date.
+   - `<expiry-date>` - Permission expiration date for VHD access.  Provide a date at least three weeks beyond the current date.
+
    The following example shows proper parameter values (at the time of this writing).
 
    ``` powershell
        az storage container generate-sas --connection-string 'DefaultEndpointsProtocol=https;AccountName=st00009;AccountKey=6L7OWFrlabs7Jn23OaR3rvY5RykpLCNHJhxsbn9ONc+bkCq9z/VNUPNYZRKoEV1FXSrvhqq3aMIDI7N3bSSvPg==;EndpointSuffix=core.windows.net' --name vhds --permissions rl --start '2017-11-06T00:00:00Z' --expiry '2018-08-20T00:00:00Z'
    ```
- 
+
 4. Save the changes to this PowerShell script.
 5. Run this script, using administrative privileges, to generate a *SAS connection string* for container level access.  You can use two basic approaches:
    - Run the script from the console.  For example, in Windows, write-click on the script and select **Run as administrator**.
-   - Run the script from a PowerShell script editor, such as the [Windows PowerShell ISE](https://docs.microsoft.com/powershell/scripting/core-powershell/ise/introducing-the-windows-powershell-ise), using administrative privileges. 
-     The following demonstrates a SAS connection string being generated within this editor. 
+   - Run the script from a PowerShell script editor, such as the [Windows PowerShell ISE](https://docs.microsoft.com/powershell/scripting/components/ise/introducing-the-windows-powershell-ise), using administrative privileges.
+     The following demonstrates a SAS connection string being generated within this editor.
 
      ![SAS URI generation in PowerShell ISE](./media/publishvm_032.png)
 
-6. Copy the resulting SAS connection string and save it to a text file in a secure location.  You will edit this string to add the associated VHD location information to it to create the final SAS URI. 
+6. Copy the resulting SAS connection string and save it to a text file in a secure location.  You will edit this string to add the associated VHD location information to it to create the final SAS URI.
 7. In the Azure portal, navigate to the blob storage that contains the VHD associated with the newly generated URI.
 8. Copy the URL value of the **Blob service endpoint**, as shown below.
 
@@ -86,19 +86,19 @@ Use the following steps to generate a SAS URI with the Microsoft Azure Storage E
 2. Open the explorer and, in the left-hand menubar, click on the **Add Account** icon.  The **Connect to Azure Storage** dialog box is displayed.
 3. Select **Add an Azure Account** and click **Sign in**.  Continue the required steps to sign into your Azure account.
 4. In the left-hand **Explorer** pane, navigate to your **Storage Accounts** and expand this node.
-5. Right-click on your VHD and select **Get Share Access Signature** from the context menu. 
+5. Right-click on your VHD and select **Get Share Access Signature** from the context menu.
 
     ![Get SAS item in Azure Explorer](./media/publishvm_034.png)
 
 6. The **Shared Access Signature** dialog is displayed. Enter values for the following fields:
    - **Start time** - Permission start date for VHD access. Provide a date that is one day before the current date.
    - **Expiry time** - Permission expiration date for VHD access.  Provide a date at least three weeks beyond the current date.
-   - **Permissions** - Select the `Read` and `List` permissions. 
+   - **Permissions** - Select the `Read` and `List` permissions.
 
      ![SAS dialog in Azure Explorer](./media/publishvm_035.png)
 
-7. Click **Create** to create the associated SAS URI for this VHD.  The dialog now displays details about this operation. 
-8. Copy the **URL** value and save it to a text file in a secure location. 
+7. Click **Create** to create the associated SAS URI for this VHD.  The dialog now displays details about this operation.
+8. Copy the **URL** value and save it to a text file in a secure location.
 
     ![SAS URI create in Azure Explorer](./media/publishvm_036.png)
 

articles/marketplace/cloud-partner-portal/virtual-machine/cpp-winrm-over-https.md

@@ -1,7 +1,7 @@
 ---
 title: Windows Remote Management over HTTPS for Azure | Azure Marketplace
 description: Explains how to configure an Azure-hosted, Windows-based VM so that it can be managed remotely with PowerShell.
-services: Azure, Marketplace, Cloud Partner Portal, 
+services: Azure, Marketplace, Cloud Partner Portal,
 author: v-miclar
 ms.service: marketplace
 ms.subservice: partnercenter-marketplace-publisher
@@ -12,9 +12,9 @@ ms.author: pabutler
 
 # Windows Remote Management over HTTPS
 
-This section explains how to configure an Azure-hosted, Windows-based VM so that it can be managed and deployed remotely with PowerShell.  To enable PowerShell remoting, the target VM must expose a Windows Remote Management (WinRM) HTTPS endpoint.  For more information about PowerShell remoting, see [Running Remote Commands](https://docs.microsoft.com/powershell/scripting/core-powershell/running-remote-commands?view=powershell-6).  For more information about WinRM, see [Windows Remote Management](https://docs.microsoft.com/windows/desktop/WinRM/portal).
+This section explains how to configure an Azure-hosted, Windows-based VM so that it can be managed and deployed remotely with PowerShell.  To enable PowerShell remoting, the target VM must expose a Windows Remote Management (WinRM) HTTPS endpoint.  For more information about PowerShell remoting, see [Running Remote Commands](https://docs.microsoft.com/powershell/scripting/learn/remoting/running-remote-commands).  For more information about WinRM, see [Windows Remote Management](https://docs.microsoft.com/windows/desktop/WinRM/portal).
 
-If you created a VM using one of the "classic" Azure approaches—either the Azure Service Manager Portal or the deprecated [Azure Service Management API](https://docs.microsoft.com/previous-versions/azure/ee460799(v=azure.100))—then it is automatically configured with a WinRM endpoint.  However, if you create a VM using any of the following "modern" Azure approaches, then your VM will *not* be configured for WinRM over HTTPS.  
+If you created a VM using one of the "classic" Azure approaches—either the Azure Service Manager Portal or the deprecated [Azure Service Management API](https://docs.microsoft.com/previous-versions/azure/ee460799(v=azure.100))—then it is automatically configured with a WinRM endpoint.  However, if you create a VM using any of the following "modern" Azure approaches, then your VM will *not* be configured for WinRM over HTTPS.
 
 - Using the [Azure portal](https://portal.azure.com/), typically from an approved base, as described in the section [Create an Azure-compatible VHD](https://docs.microsoft.com/azure/marketplace/cloud-partner-portal/virtual-machine/cpp-create-vhd)
 - [Using the Azure Resource Manager templates](https://docs.microsoft.com/azure/virtual-machines/windows/ps-template)
@@ -29,9 +29,9 @@ In contrast, typically Linux VMs are remotely managed using either [Azure CLI](h
 
 The WinRM endpoint for a windows-based VM can be configured during two different stages of its development:
 
-- During creation - during the deployment of a VM to an existing VHD.  This is the preferred approach for new offers.  This approach requires the creation of an Azure certificate, using supplied Azure Resource Manager templates, and running customized PowerShell scripts. 
-- After deployment - on an existing VM hosted on Azure.  Use this approach if you already have a VM solution deployed on Azure, and need to enable Window Remote Management for it.  This approach requires manual changes in the Azure portal and the execution of a script on the target VM. 
+- During creation - during the deployment of a VM to an existing VHD.  This is the preferred approach for new offers.  This approach requires the creation of an Azure certificate, using supplied Azure Resource Manager templates, and running customized PowerShell scripts.
+- After deployment - on an existing VM hosted on Azure.  Use this approach if you already have a VM solution deployed on Azure, and need to enable Window Remote Management for it.  This approach requires manual changes in the Azure portal and the execution of a script on the target VM.
 
 
 ## Next steps
-If you are creating a new VM, you can enable WinRM during [deployment of your VM from its VHDs](./cpp-deploy-vm-vhd.md).  Otherwise, WinRM can be enabled in an existing VM  
+If you are creating a new VM, you can enable WinRM during [deployment of your VM from its VHDs](./cpp-deploy-vm-vhd.md).  Otherwise, WinRM can be enabled in an existing VM

articles/service-fabric/service-fabric-cluster-standalone-deployment-preparation.md

@@ -1,6 +1,6 @@
 ---
 title: Azure Service Fabric Standalone Cluster Deployment Preparation | Microsoft Docs
-description: Documentation related to preparing the environment and creating the cluster configuration, to be considered prior to deploying a cluster intended for handling a production workload. 
+description: Documentation related to preparing the environment and creating the cluster configuration, to be considered prior to deploying a cluster intended for handling a production workload.
 services: service-fabric
 documentationcenter: .net
 author: dkkapur
@@ -63,7 +63,7 @@ Here are some recommended specs for each machine that you want to add to the clu
 * Connectivity to a secure network or networks for all machines
 * Windows Server OS installed (valid versions: 2012 R2, 2016, 1709, or 1803). Service Fabric version 6.4.654.9590 and later also supports Server 2019 and 1809.
 * [.NET Framework 4.5.1 or higher](https://www.microsoft.com/download/details.aspx?id=40773), full install
-* [Windows PowerShell 3.0](https://msdn.microsoft.com/powershell/scripting/setup/installing-windows-powershell)
+* [Windows PowerShell 3.0](https://msdn.microsoft.com/powershell/scripting/install/installing-windows-powershell)
 * The [RemoteRegistry service](https://technet.microsoft.com/library/cc754820) should be running on all the machines
 * Service Fabric installation drive must be NTFS File System
 
@@ -95,7 +95,7 @@ When a cluster administrator configures a Service Fabric standalone cluster, the
 1. The user creating the cluster should have administrator-level security privileges to all machines that are listed as nodes in the cluster configuration file.
 2. Machine from which the cluster is created, as well as each cluster node machine must:
    * Have Service Fabric SDK uninstalled
-   * Have Service Fabric runtime uninstalled 
+   * Have Service Fabric runtime uninstalled
    * Have the Windows Firewall service (mpssvc) enabled
    * Have the Remote Registry Service (remote registry) enabled
    * Have file sharing (SMB) enabled
@@ -139,7 +139,7 @@ When a cluster administrator configures a Service Fabric standalone cluster, the
 | FileStoreService.exe |
 
 ## Validate environment using TestConfiguration script
-The TestConfiguration.ps1 script can be found in the standalone package. It is used as a Best Practices Analyzer to validate some of the criteria above and should be used as a sanity check to validate whether a cluster can be deployed on a given environment. If there is any failure, refer to the list under [Environment Setup](service-fabric-cluster-standalone-deployment-preparation.md) for troubleshooting. 
+The TestConfiguration.ps1 script can be found in the standalone package. It is used as a Best Practices Analyzer to validate some of the criteria above and should be used as a sanity check to validate whether a cluster can be deployed on a given environment. If there is any failure, refer to the list under [Environment Setup](service-fabric-cluster-standalone-deployment-preparation.md) for troubleshooting.
 
 This script can be run on any machine that has administrator access to all the machines that are listed as nodes in the cluster configuration file. The machine that this script is run on does not have to be part of the cluster.
 
@@ -162,12 +162,12 @@ FabricInstallable          : True
 Passed                     : True
 ```
 
-Currently this configuration testing module does not validate the security configuration so this has to be done independently.  
+Currently this configuration testing module does not validate the security configuration so this has to be done independently.
 
 > [!NOTE]
-> We are continually making improvements to make this module more robust, so if there is a faulty or missing case which you believe isn't currently caught by TestConfiguration, please let us know through our [support channels](https://docs.microsoft.com/azure/service-fabric/service-fabric-support).   
-> 
-> 
+> We are continually making improvements to make this module more robust, so if there is a faulty or missing case which you believe isn't currently caught by TestConfiguration, please let us know through our [support channels](https://docs.microsoft.com/azure/service-fabric/service-fabric-support).
+>
+>
 
 ## Next steps
 * [Create a standalone cluster running on Windows Server](service-fabric-cluster-creation-for-windows-server.md)