diff --git a/dsc/metaConfig.md b/dsc/metaConfig.md index c64c2462b9d2..e2dcfcee1a95 100644 --- a/dsc/metaConfig.md +++ b/dsc/metaConfig.md @@ -4,7 +4,6 @@ ms.topic: conceptual keywords: dsc,powershell,configuration,setup title: Configuring the Local Configuration Manager --- - # Configuring the Local Configuration Manager > Applies To: Windows PowerShell 5.0 @@ -22,9 +21,10 @@ It is also responsible for a number of other aspects of DSC, including the follo You use a special type of configuration to configure the LCM to specify each of these behaviors. The following sections describe how to configure the LCM. -> **Note**: This topic applies to the LCM introduced in Windows PowerShell 5.0. +Windows PowerShell 5.0 introduced new settings +for managing Local Configuration Manager. For information about configuring the LCM in Windows PowerShell 4.0, -see [Windows PowerShell 4.0 Desired State Configuration Local Configuration Manager](metaconfig4.md). +see [Configuring the Local Configuration Manager in Previous Versions of Windows PowerShell](metaconfig4.md). ## Writing and enacting an LCM configuration @@ -94,47 +94,14 @@ The following properties are available in a **Settings** block. ## Pull service -DSC settings allow a node to be managed by pulling configurations and modules, -and publishing reporting data, to a remote location. -The current options for pull service include: - -- Azure Automation Desired State Configuration service -- A pull service instance running on Windows Server -- An SMB share (does not support publishing reporting data) - LCM configuration supports defining the following types of pull service endpoints: - **Configuration server**: A repository for DSC configurations. Define configuration servers by using **ConfigurationRepositoryWeb** (for web-based servers) and **ConfigurationRepositoryShare** (for SMB-based servers) blocks. - **Resource server**: A repository for DSC resources, packaged as PowerShell modules. Define resource servers by using **ResourceRepositoryWeb** (for web-based servers) and **ResourceRepositoryShare** (for SMB-based servers) blocks. - **Report server**: A service that DSC sends report data to. Define report servers by using **ReportServerWeb** blocks. A report server must be a web service. -**The recommended solution**, and the option with the most features available, -is [Azure Automation DSC](https://docs.microsoft.com/en-us/azure/automation/automation-dsc-getting-started). - -The Azure service can manage nodes on-premises in private datacenters, -or in public clouds such as Azure and AWS. -For private environments where servers cannot directly connect to the Internet, -consider limiting outbound traffic to only the published Azure IP range -(see [Azure Datacenter IP Ranges](https://www.microsoft.com/en-us/download/details.aspx?id=41653)). - -Features of the online service that are not currently available in the pull service on Windows Server include: -- All data is encrypted in transit and at rest -- Client certificates are created and managed automatically -- Secrets store for centrally managing [passwords/credentials](https://docs.microsoft.com/en-us/azure/automation/automation-credentials), or [variables](https://docs.microsoft.com/en-us/azure/automation/automation-variables) such as server names or connection strings -- Centrally manage node [LCM configuration](metaConfig.md#basic-settings) -- Centrally assign configurations to client nodes -- Release configuration changes to "canary groups" for testing before reaching production -- Graphical reporting - - Status detail at the DSC resource level of granularity - - Verbose error messages from client machines for troubleshooting -- [Integration with Azure Log Analytics](https://docs.microsoft.com/en-us/azure/automation/automation-dsc-diagnostics) for alerting, automated tasks, Android/iOS app for reporting and alerting - -Alternatively, for information about -setting up and using HTTP pull service on Windows Server, -see [Setting up a DSC pull server](pullServer.md). -Please be advised that it is a limited implementation with only basic -capabilities of storing configurations/modules and capturing report data -in to a local database. +For more details on pull service see, +[Desired State Configuration Pull Service](pullServer.md). ## Configuration server blocks diff --git a/dsc/metaConfig4.md b/dsc/metaConfig4.md index 467225674575..6adfa4b85b35 100644 --- a/dsc/metaConfig4.md +++ b/dsc/metaConfig4.md @@ -2,13 +2,14 @@ ms.date: 2017-10-12 ms.topic: conceptual keywords: dsc,powershell,configuration,setup -title: Windows PowerShell 4.0 Desired State Configuration Local Configuration Manager (LCM) +title: Configuring the Local Configuration Manager in Previous Versions of Windows PowerShell --- - -# Windows PowerShell 4.0 Desired State Configuration Local Configuration Manager (LCM) +# Configuring the Local Configuration Manager in Previous Versions of Windows PowerShell >Applies To: Windows PowerShell 4.0 +**For information related to Windows PowerShell 5.0 and later, see [Configuring the Local Configuration Manager](metaConfig.md).** + Local Configuration Manager is the Windows PowerShell Desired State Configuration (DSC) engine. It runs on all target nodes, and it is responsible for calling the configuration resources diff --git a/dsc/pullServer.md b/dsc/pullServer.md index 8d6be97ab283..114fe4acabc0 100644 --- a/dsc/pullServer.md +++ b/dsc/pullServer.md @@ -1,74 +1,129 @@ --- -ms.date: 2017-06-12 +ms.date: 2018-02-02 ms.topic: conceptual keywords: dsc,powershell,configuration,setup -title: Setting up a DSC web pull server +title: DSC Pull Service --- - -# Setting up a DSC web pull server +# Desired State Configuration Pull Service > Applies To: Windows PowerShell 5.0 -A DSC web pull server is a web service in IIS that uses an OData interface to make DSC configuration files available to target nodes when those nodes ask for them. +Local Configuration Manager can be centrally managed by a Pull Service solution. +When using this approach, the node that is being managed is registered with a +service and assigned a configuration in LCM settings. +The configuration and all DSC resources needed as dependencies +for the configuration are downloaded to the machine and used by LCM +to manage the configuration. +Information about the state of the machine being managed is uploaded +to the service for reporting. +This concept is referred to as "pull service". + +The current options for pull service include: + +- Azure Automation Desired State Configuration service +- A pull service running on Windows Server +- Community maintained open source solutions +- An SMB share + +**The recommended solution**, and the option with the most features available, +is [Azure Automation DSC](https://docs.microsoft.com/en-us/azure/automation/automation-dsc-getting-started). + +The Azure service can manage nodes on-premises in private datacenters, +or in public clouds such as Azure and AWS. +For private environments where servers cannot directly connect to the Internet, +consider limiting outbound traffic to only the published Azure IP range +(see [Azure Datacenter IP Ranges](https://www.microsoft.com/en-us/download/details.aspx?id=41653)). + +Features of the online service that are not currently available in the pull service on Windows Server include: +- All data is encrypted in transit and at rest +- Client certificates are created and managed automatically +- Secrets store for centrally managing [passwords/credentials](https://docs.microsoft.com/en-us/azure/automation/automation-credentials), or [variables](https://docs.microsoft.com/en-us/azure/automation/automation-variables) such as server names or connection strings +- Centrally manage node [LCM configuration](metaConfig.md#basic-settings) +- Centrally assign configurations to client nodes +- Release configuration changes to "canary groups" for testing before reaching production +- Graphical reporting + - Status detail at the DSC resource level of granularity + - Verbose error messages from client machines for troubleshooting +- [Integration with Azure Log Analytics](https://docs.microsoft.com/en-us/azure/automation/automation-dsc-diagnostics) for alerting, automated tasks, Android/iOS app for reporting and alerting + +## DSC pull service in Windows Server + +It is possible to configuring a pull service +to run on Windows Server. +Please be advised that the pull service solution included in Windows Server +includes only capabilities of storing configurations/modules for download +and capturing report data in to database. +It does not include many of the capabilities offered by the service in Azure +and so is not a good tool for evaluating how the service would be used. + +The pull service offered in Windows Server +is a web service in IIS that uses an OData interface +to make DSC configuration files available +to target nodes when those nodes ask for them. Requirements for using a pull server: -* A server running: +- A server running: - WMF/PowerShell 5.0 or greater - IIS server role - DSC Service -* Ideally, some means of generating a certificate, to secure credentials passed to the Local Configuration Manager (LCM) on target nodes +- Ideally, some means of generating a certificate, to secure credentials passed to the Local Configuration Manager (LCM) on target nodes + +The best way to configure Windows Server to host pull service +is to use a DSC configuration. +An example script is provided below. -You can add the IIS server role and DSC Service with the Add Roles and Features wizard in Server Manager, or by using PowerShell. The sample scripts included in this topic will handle both of these steps -for you as well. +### Using the xDSCWebService resource -## Using the xDSCWebService resource -The easiest way to set up a web pull server is to use the xWebService resource, included in the xPSDesiredStateConfiguration module. The following steps explain how to use the resource in a configuration that sets up the web service. +The easiest way to set up a web pull server is to use the xWebService resource, +included in the xPSDesiredStateConfiguration module. +The following steps explain how to use the resource +in a configuration that sets up the web service. 1. Call the [Install-Module](https://technet.microsoft.com/en-us/library/dn807162.aspx) cmdlet to install the **xPSDesiredStateConfiguration** module. **Note**: **Install-Module** is included in the **PowerShellGet** module, which is included in PowerShell 5.0. You can download the **PowerShellGet** module for PowerShell 3.0 and 4.0 at [PackageManagement PowerShell Modules Preview](https://www.microsoft.com/en-us/download/details.aspx?id=49186). 1. Get an SSL certificate for the DSC Pull server from a trusted Certificate Authority, either within your organization or a public authority. The certificate received from the authority is usually in the PFX format. Install the certificate on the node that will become the DSC Pull server in the default location which should be CERT:\LocalMachine\My. Make a note of the certificate thumbprint. 1. Select a GUID to be used as the Registration Key. To generate one using PowerShell enter the following at the PS prompt and press enter: '``` [guid]::newGuid()```' or '```New-Guid```'. This key will be used by client nodes as a shared key to authenticate during registration. For more information see the Registration Key section below. 1. In the PowerShell ISE, start (F5) the following configuration script (included in the Example folder of the **xPSDesiredStateConfiguration** module as Sample_xDscWebService.ps1). This script sets up the pull server. - - ```powershell + +```powershell configuration Sample_xDscPullServer - { - param - ( - [string[]]$NodeName = 'localhost', + { + param + ( + [string[]]$NodeName = 'localhost', - [ValidateNotNullOrEmpty()] + [ValidateNotNullOrEmpty()] [string] $certificateThumbPrint, [Parameter(Mandatory)] [ValidateNotNullOrEmpty()] - [string] $RegistrationKey - ) - + [string] $RegistrationKey + ) + Import-DSCResource -ModuleName xPSDesiredStateConfiguration Import-DSCResource –ModuleName PSDesiredStateConfiguration - Node $NodeName - { - WindowsFeature DSCServiceFeature - { + Node $NodeName + { + WindowsFeature DSCServiceFeature + { Ensure = 'Present' - Name = 'DSC-Service' - } - - xDscWebService PSDSCPullServer - { - Ensure = 'Present' - EndpointName = 'PSDSCPullServer' - Port = 8080 - PhysicalPath = "$env:SystemDrive\inetpub\PSDSCPullServer" - CertificateThumbPrint = $certificateThumbPrint - ModulePath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules" - ConfigurationPath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration" + Name = 'DSC-Service' + } + + xDscWebService PSDSCPullServer + { + Ensure = 'Present' + EndpointName = 'PSDSCPullServer' + Port = 8080 + PhysicalPath = "$env:SystemDrive\inetpub\PSDSCPullServer" + CertificateThumbPrint = $certificateThumbPrint + ModulePath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Modules" + ConfigurationPath = "$env:PROGRAMFILES\WindowsPowerShell\DscService\Configuration" State = 'Started' - DependsOn = '[WindowsFeature]DSCServiceFeature' + DependsOn = '[WindowsFeature]DSCServiceFeature' UseSecurityBestPractices = $false - } + } File RegistrationKeyFile { @@ -80,11 +135,11 @@ The easiest way to set up a web pull server is to use the xWebService resource, } } - ``` +``` 1. Run the configuration, passing the thumbprint of the SSL certificate as the **certificateThumbPrint** parameter and a GUID registration key as the **RegistrationKey** parameter: - ```powershell +```powershell # To find the Thumbprint for an installed SSL certificate for use with the pull server list all certificates in your local store # and then copy the thumbprint for the appropriate certificate by reviewing the certificate subjects dir Cert:\LocalMachine\my @@ -94,9 +149,11 @@ The easiest way to set up a web pull server is to use the xWebService resource, # Run the compiled configuration to make the target node a DSC Pull Server Start-DscConfiguration -Path c:\Configs\PullServer -Wait -Verbose - ``` -## Registration Key +``` + +#### Registration Key + To allow client nodes to register with the server so that they can use configuration names instead of a configuration ID, a registration key which was created by the above configuration is saved in a file named `RegistrationKeys.txt` in `C:\Program Files\WindowsPowerShell\DscService`. The registration key functions as a shared secret used during the initial registration by the client with the pull server. The client will generate a self-signed certificate which is used to uniquely authenticate to the pull server once registration is successfully completed. The thumbprint of this certificate is stored locally and associated with the URL of the pull server. > **Note**: Registration keys are not supported in PowerShell 4.0. @@ -114,14 +171,14 @@ configuration PullClientConfigID RefreshFrequencyMins = 30 RebootNodeIfNeeded = $true } - + ConfigurationRepositoryWeb CONTOSO-PullSrv { ServerURL = 'https://CONTOSO-PullSrv:8080/PSDSCPullServer.svc' RegistrationKey = '140a952b-b9d6-406b-b416-e0f759c9c0e4' ConfigurationNames = @('ClientConfig') - } - + } + ReportServerWeb CONTOSO-PullSrv { ServerURL = 'https://CONTOSO-PullSrv:8080/PSDSCPullServer.svc' @@ -131,42 +188,75 @@ configuration PullClientConfigID } PullClientConfigID -OutputPath c:\Configs\TargetNodes + + ``` -> **Note**: The **ReportServerWeb** section allows reporting data to be sent to the pull server. -The lack of the **ConfigurationID** property in the metaconfiguration file implicitly means that pull server is supporting the V2 version of the pull server protocol so an initial registration -is required. Conversely, the presence of a **ConfigurationID** means that the V1 version of the pull server protocol is used and there is no registration processing. +> **Note**: The **ReportServerWeb** section allows reporting data to be sent to the pull server. ->**Note**: In a PUSH scenario, a bug exists in the current relase that makes it necessary to define a ConfigurationID property in the metaconfiguration file for nodes that have never -registered with a pull server. This will force the V1 Pull Server protocol and avoid registration failure messages. +The lack of the **ConfigurationID** property in the metaconfiguration file +implicitly means that pull server is supporting the V2 version +of the pull server protocol so an initial registration is required. +Conversely, the presence of a **ConfigurationID** means that the V1 version +of the pull server protocol is used and there is no registration processing. + +>**Note**: In a PUSH scenario, a bug exists in the current relase that makes it necessary to define a ConfigurationID property in the metaconfiguration file for nodes that have never registered with a pull server. This will force the V1 Pull Server protocol and avoid registration failure messages. ## Placing configurations and resources -After the pull server setup completes, the folders defined by the **ConfigurationPath** and **ModulePath** properties in the pull server configuration are where you will place modules and -configurations that will be available for target nodes to pull. These files need to be in a specific format in order for the pull server to correctly process them. +After the pull server setup completes, +the folders defined by the **ConfigurationPath** and **ModulePath** properties +in the pull server configuration are where you will place modules +and configurations that will be available for target nodes to pull. +These files need to be in a specific format in order for the pull server +to correctly process them. ### DSC resource module package format -Each resource module needs to be zipped and named according the following pattern `{Module Name}_{Module Version}.zip`. For example, a module named xWebAdminstration with a module version -of 3.1.2.0 would be named 'xWebAdministration_3.2.1.0.zip'. Each version of a module must be contained in a single zip file. Since there is only a single version of a resource in each zip -file the module format added in WMF 5.0 with support for multiple module versions in a single directory is not supported. This means that before packaging up DSC resource modules for use with -pull server you will need to make a small change to the directory structure. The default format of modules containing DSC resource in WMF 5.0 is -'{Module Folder}\{Module Version}\DscResources\{DSC Resource Folder}\'. Before packaging up for the pull server simply remove the **{Module version}** folder so the path becomes -'{Module Folder}\DscResources\{DSC Resource Folder}\'. With this change, zip the folder as described above and place these zip files in the **ModulePath** folder. +Each resource module needs to be zipped and named +according the following pattern `{Module Name}_{Module Version}.zip`. +For example, a module named xWebAdminstration with a module version +of 3.1.2.0 would be named 'xWebAdministration_3.2.1.0.zip'. +Each version of a module must be contained in a single zip file. +Since there is only a single version of a resource in each zip file +the module format added in WMF 5.0 with support for multiple module versions +in a single directory is not supported. +This means that before packaging up DSC resource modules for use with +pull server you will need to make a small change to the directory structure. +The default format of modules containing DSC resource in WMF 5.0 is +'{Module Folder}\{Module Version}\DscResources\{DSC Resource Folder}\'. +Before packaging up for the pull server simply +remove the **{Module version}** folder so the path becomes +'{Module Folder}\DscResources\{DSC Resource Folder}\'. +With this change, zip the folder as described above and place these zip files +in the **ModulePath** folder. + +Use `new-dscchecksum {module zip file}` to create a checksum file +for the newly-added module. + +### Configuration MOF format + +A configuration MOF file needs to be paired with a checksum file +so that an LCM on a target node can validate the configuration. +To create a checksum, call the +[New-DSCCheckSum](https://technet.microsoft.com/en-us/library/dn521622.aspx) cmdlet. +The cmdlet takes a **Path** parameter that specifies the folder +where the configuration MOF is located. +The cmdlet creates a checksum file named `ConfigurationMOFName.mof.checksum`, +where `ConfigurationMOFName` is the name of the configuration mof file. +If there are more than one configuration MOF files in the specified folder, +a checksum is created for each configuration in the folder. +Place the MOF files and their associated checksum files +in the **ConfigurationPath** folder. -Use `new-dscchecksum {module zip file}` to create a checksum file for the newly-added module. +>**Note**: If you change the configuration MOF file in any way, you must also recreate the checksum file. -### Configuration MOF format -A configuration MOF file needs to be paired with a checksum file so that an LCM on a target node can validate the configuration. To create a checksum, call the -[New-DSCCheckSum](https://technet.microsoft.com/en-us/library/dn521622.aspx) cmdlet. The cmdlet takes a **Path** parameter that specifies the folder where the configuration MOF is -located. The cmdlet creates a checksum file named `ConfigurationMOFName.mof.checksum`, where `ConfigurationMOFName` is the name of the configuration mof file. If there are more than -one configuration MOF files in the specified folder, a checksum is created for each configuration in the folder. Place the MOF files and their associated checksum files in the -the **ConfigurationPath** folder. +### Tooling ->**Note**: If you change the configuration MOF file in any way, you must also recreate the checksum file. +In order to make setting up, validating and managing the pull server easier, +the following tools are included as examples +in the latest version of the xPSDesiredStateConfiguration module: -## Tooling -In order to make setting up, validating and managing the pull server easier, the following tools are included as examples in the latest version of the xPSDesiredStateConfiguration module: 1. A module that will help with packaging DSC resource modules and configuration files for use on the pull server. [PublishModulesAndMofsToPullServer.psm1](https://github.com/PowerShell/xPSDesiredStateConfiguration/blob/dev/DSCPullServerSetup/PublishModulesAndMofsToPullServer.psm1). Examples below: ```powershell @@ -180,17 +270,27 @@ In order to make setting up, validating and managing the pull server easier, the 1. A script that validates the pull server is configured correctly. [PullServerSetupTests.ps1](https://github.com/PowerShell/xPSDesiredStateConfiguration/blob/dev/DSCPullServerSetup/PullServerDeploymentVerificationTest/PullServerSetupTests.ps1). +## Community Solutions for Pull Service -## Pull client configuration -The following topics describe setting up pull clients in detail: +The DSC community has authored multiple solutions to implement +the pull service protocol. +For on-premises environments these offer pull service capabilities +and an opportunity to contribute back to the community +with incremental enhancements. -* [Setting up a DSC pull client using a configuration ID](pullClientConfigID.md) -* [Setting up a DSC pull client using configuration names](pullClientConfigNames.md) -* [Partial configurations](partialConfigs.md) +- [Tug](https://github.com/powershellorg/tug) +- [DSC-TRÆK](https://github.com/powershellorg/dsc-traek) + +## Pull client configuration + +The following topics describe setting up pull clients in detail: +- [Setting up a DSC pull client using a configuration ID](pullClientConfigID.md) +- [Setting up a DSC pull client using configuration names](pullClientConfigNames.md) +- [Partial configurations](partialConfigs.md) ## See also -* [Windows PowerShell Desired State Configuration Overview](overview.md) -* [Enacting configurations](enactingConfigurations.md) -* [Using a DSC report server](reportServer.md) +- [Windows PowerShell Desired State Configuration Overview](overview.md) +- [Enacting configurations](enactingConfigurations.md) +- [Using a DSC report server](reportServer.md) diff --git a/reference/5.1/Microsoft.PowerShell.Management/Join-Path.md b/reference/5.1/Microsoft.PowerShell.Management/Join-Path.md index f13fac95f272..b0a5a281f5ef 100644 --- a/reference/5.1/Microsoft.PowerShell.Management/Join-Path.md +++ b/reference/5.1/Microsoft.PowerShell.Management/Join-Path.md @@ -32,7 +32,7 @@ PS C:\> Join-Path -Path "C:\win*" -ChildPath "System*" ``` This command uses **Join-Path** to combine the C:\Win* path with the System* child path. -The Windows PowerShell file system provider, FileSystem joins the path and adds the "\" delimiter. +The Windows PowerShell file system provider, FileSystem joins the path and adds the "\\" delimiter. ### Example 2: Display files and folders by joining a path with a child path ``` diff --git a/reference/5.1/Microsoft.PowerShell.Management/New-PSDrive.md b/reference/5.1/Microsoft.PowerShell.Management/New-PSDrive.md index c4a1cf5882e9..5923e28ff4f0 100644 --- a/reference/5.1/Microsoft.PowerShell.Management/New-PSDrive.md +++ b/reference/5.1/Microsoft.PowerShell.Management/New-PSDrive.md @@ -41,10 +41,6 @@ When your command is scoped locally (no dot-sourcing), the *Persist* parameter d If you are running **New-PSDrive** inside a script, and you want the drive to persist indefinitely, you must dot-source the script. For best results, to force a new drive to persist indefinitely, add the *Scope* parameter to your command, and set its value to Global. - External drives. -When an external drive is connected to the computer, Windows PowerShell automatically adds a PSDrive to the file system that represents the new drive. -You do not have to restart Windows PowerShell. -Similarly, when an external drive is disconnected from the computer, Windows PowerShell automatically deletes the **PSDrive** that represents the removed drive. -- External drives. When an external drive is connected to the computer, Windows PowerShell automatically adds a **PSDrive** to the file system that represents the new drive. You do not have to restart Windows PowerShell. Similarly, when an external drive is disconnected from the computer, Windows PowerShell automatically deletes the **PSDrive** that represents the removed drive. diff --git a/reference/5.1/Microsoft.PowerShell.Security/Get-PfxCertificate.md b/reference/5.1/Microsoft.PowerShell.Security/Get-PfxCertificate.md index 348801e04a8f..ef00ea24ab18 100644 --- a/reference/5.1/Microsoft.PowerShell.Security/Get-PfxCertificate.md +++ b/reference/5.1/Microsoft.PowerShell.Security/Get-PfxCertificate.md @@ -45,7 +45,7 @@ This command gets information about the Test.pfx certificate on the system. ### Example 2: Get a .pfx certificate from a remote computer ``` -PS C:\> Invoke-Command -ComputerName "Server01" -ScriptBlock {Get-PfxCertificate -FilePath "C:\Text\TestNoPassword.pfx}" -authentication CredSSP +PS C:\> Invoke-Command -ComputerName "Server01" -ScriptBlock {Get-PfxCertificate -FilePath "C:\Text\TestNoPassword.pfx"} -authentication CredSSP ``` This command gets a .pfx certificate file from the Server01 remote computer. diff --git a/reference/6/Microsoft.PowerShell.Core/mkdir.md b/reference/6/Microsoft.PowerShell.Core/mkdir.md index adde97ad1e2b..6c81c8b7b6fb 100644 --- a/reference/6/Microsoft.PowerShell.Core/mkdir.md +++ b/reference/6/Microsoft.PowerShell.Core/mkdir.md @@ -249,7 +249,6 @@ Accept wildcard characters: False ### -WhatIf Shows what would happen if the cmdlet runs. -The cmdlet is not run.Shows what would happen if the cmdlet runs. The cmdlet is not run. ```yaml diff --git a/reference/6/Microsoft.PowerShell.Utility/Invoke-WebRequest.md b/reference/6/Microsoft.PowerShell.Utility/Invoke-WebRequest.md index 626fb2652023..e0fccf97c43c 100644 --- a/reference/6/Microsoft.PowerShell.Utility/Invoke-WebRequest.md +++ b/reference/6/Microsoft.PowerShell.Utility/Invoke-WebRequest.md @@ -84,7 +84,7 @@ $ProfileResponse = Invoke-WebRequest 'http://www.contoso.com/profile/' -WebSessi $ProfileResponse ``` -This example shows how to use the `Invoke-WebRequest` cmdlet with a stateful web service. T +This example shows how to use the `Invoke-WebRequest` cmdlet with a stateful web service. The first call to `Invoke-WebRequest` sends a sign-in request. The command specifies a value of "Session" for the value of the **-SessionVariable** parameter, and saves the result in the `$LoginResponse` variable. When the command completes, the `$LoginResponse` variable contains an `BasicHtmlWebResponseObject` and the `$Session` variable contains a `WebRequestSession` object. This logs the user into the site. @@ -126,7 +126,8 @@ The final few commands write the **Content** property to the file then disposes Note that the **Encoding** property will be null if the web request does not return text content. -### Example 3: Submit a multipart/form-data file +### Example 4: Submit a multipart/form-data file + ```powershell $FilePath = 'c:\document.txt' $FieldName = 'document' diff --git a/reference/docs-conceptual/setup/Installing-Windows-PowerShell.md b/reference/docs-conceptual/setup/Installing-Windows-PowerShell.md index 0fc9d11fadb6..7b6efd6d49bd 100644 --- a/reference/docs-conceptual/setup/Installing-Windows-PowerShell.md +++ b/reference/docs-conceptual/setup/Installing-Windows-PowerShell.md @@ -15,7 +15,7 @@ in their machines, need to: 1. Get PowerShell for the specific OS and version, from [GitHub](https://github.com/powershell/powershell#get-powershell) 1. Follow the installation instructions - [Linux](https://github.com/PowerShell/PowerShell/blob/master/docs/installation/linux.md) - - [macOS](https://github.com/PowerShell/PowerShell/blob/master/docs/installation/linux.md#macos-1012) + - [macOS](https://github.com/PowerShell/PowerShell/blob/master/docs/installation/macos.md) - [Windows](https://github.com/PowerShell/PowerShell/blob/master/docs/installation/windows.md#msi) PowerShell 6 is also available for Docker;