Fix incorrect case/capitalization in ref docs (#11946)

This ensures the following components have the correct/consistent case
throughout the reference documentation:

Preference variable, PS environment variable, PS drive, PS provider,
PS command name, PS command argument, PS module, PS file extension,
PS host name/application, #Requires statement, parameter name,
about_* topic, member name, scope modifier, keyword, operator,
calculated property key/value, attribute, type accelerator,
type literal/name, WMI namespace/class, variable name,
special character, comment-based help keyword, product/company name,
Windows drive letter/directory, Windows/Unix environment variable

In addition, changes include fixes to incorrect terminology (e.g.,
referring to a keyword as a command) and formatting of PS syntax
elements (non-exhaustive).

Author: surfingoldelephant

reference/docs-conceptual/security/app-control/application-control.md

@@ -23,8 +23,8 @@ doesn't have way to query the policy enforcement status. To detect if a system w
 control policy is being enforced by AppLocker, PowerShell creates two temporary files and tests if
 they can be executed. The filenames use the following name format:
 
-- `$env:TEMP/__PSAppLockerTest__<random-8dot3-name>.ps1`
-- `$env:TEMP/__PSAppLockerTest__<random-8dot3-name>.psm1`
+- `$Env:TEMP/__PSAppLockerTest__<random-8dot3-name>.ps1`
+- `$Env:TEMP/__PSAppLockerTest__<random-8dot3-name>.psm1`
 
 App Control for Business is the preferred application control system for Windows. App Control
 provides APIs that allow you to discover the policy configuration. App Control is designed as a

reference/docs-conceptual/security/app-control/how-to-use-app-control.md

@@ -63,24 +63,24 @@ For testing, you just need to create a default policy and a self signed code sig
 
    ```powershell
    $newSelfSignedCertificateSplat = @{
-       DnsName = $env:COMPUTERNAME
+       DnsName = $Env:COMPUTERNAME
        CertStoreLocation = "Cert:\CurrentUser\My\"
        Type = 'CodeSigningCert'
    }
    $cert = New-SelfSignedCertificate @newSelfSignedCertificateSplat
-   Export-Certificate -Cert $cert -FilePath c:\certs\signing.cer
+   Export-Certificate -Cert $cert -FilePath C:\certs\signing.cer
    Import-Certificate -FilePath C:\certs\signing.cer -CertStoreLocation "Cert:\CurrentUser\Root\"
    $cert = Get-ChildItem Cert:\CurrentUser\My\ -CodeSigningCert
 
-   dir c:\bin\powershell\pwsh.exe | Set-AuthenticodeSignature -Certificate $cert
+   dir C:\bin\PowerShell\pwsh.exe | Set-AuthenticodeSignature -Certificate $cert
    ```
 
 1. Add the code signing certificate to the policy
 
    Use the following command to add the new code signing certificate to the policy.
 
    ```powershell
-   Add-SignerRule -FilePath .\SystemCIPolicy.xml -CertificatePath c:\certs\signing.cer -User
+   Add-SignerRule -FilePath .\SystemCIPolicy.xml -CertificatePath C:\certs\signing.cer -User
    ```
 
 1. Convert the XML policy file to a policy enforcement binary file
@@ -134,7 +134,7 @@ events.
 
 ```powershell
 Get-WinEvent -LogName PowerShellCore/Analytic -Oldest |
-    Where-Object Id -eq 16387 | Format-List
+    Where-Object Id -EQ 16387 | Format-List
 ```
 
 ```Output

reference/docs-conceptual/security/preventing-script-injection.md

@@ -202,7 +202,7 @@ You can use this to automate security analysis during builds, continuous integra
 deployments, and other scenarios.
 
 ```powershell
-$RulePath = (Get-Module -list InjectionHunter).Path
+$RulePath = (Get-Module -List InjectionHunter).Path
 Invoke-ScriptAnalyzer -CustomRulePath $RulePath -Path .\Invoke-Dangerous.ps1
 ```
 

reference/docs-conceptual/security/remoting/PS-remoting-second-hop.md

@@ -148,7 +148,7 @@ Now let's set up the variables we'll use to represent the servers:
 
 ```powershell
 # Set up variables for reuse
-$ServerA = $env:COMPUTERNAME
+$ServerA = $Env:COMPUTERNAME
 $ServerB = Get-ADComputer -Identity ServerB
 $ServerC = Get-ADComputer -Identity ServerC
 ```
@@ -202,14 +202,14 @@ $cred = Get-Credential Contoso\Alice
 
 # Test kerberos double hop
 Invoke-Command -ComputerName $ServerB.Name -Credential $cred -ScriptBlock {
-    Test-Path \\$($using:ServerC.Name)\C$
-    Get-Process lsass -ComputerName $($using:ServerC.Name)
-    Get-EventLog -LogName System -Newest 3 -ComputerName $($using:ServerC.Name)
+    Test-Path \\$($Using:ServerC.Name)\C$
+    Get-Process lsass -ComputerName $($Using:ServerC.Name)
+    Get-EventLog -LogName System -Newest 3 -ComputerName $($Using:ServerC.Name)
 }
 ```
 
-In this example, the `$using` variable is used to make the `$ServerC` variable visible to _ServerB_.
-For more information about the `$using` variable, see [about_Remote_Variables][06].
+In this example, the `Using:` scope modifier is used to make the `$ServerC` variable visible to
+_ServerB_. For more information about the `Using:` scope modifier, see [about_Remote_Variables][06].
 
 To allow multiple servers to delegate credentials to _ServerC_, set the value of the
 **PrincipalsAllowedToDelegateToAccount** parameter on _ServerC_ to an array:

reference/docs-conceptual/security/remoting/Running-Remote-Commands.md

@@ -109,7 +109,7 @@ For example, the following command runs the `DiskCollect.ps1` script on the remo
 Server01 and Server02.
 
 ```powershell
-Invoke-Command -ComputerName Server01, Server02 -FilePath c:\Scripts\DiskCollect.ps1
+Invoke-Command -ComputerName Server01, Server02 -FilePath C:\Scripts\DiskCollect.ps1
 ```
 
 ### Establish a Persistent Connection
@@ -149,11 +149,11 @@ PowerShell includes cmdlets that allow you to:
 - Import commands from a remote session that actually run implicitly on the remote session
 - Configure the security of a remote session
 
-PowerShell on Windows includes a WSMan provider. The provider creates a `WSMAN:` drive that lets you
+PowerShell on Windows includes a WSMan provider. The provider creates a `WSMan:` drive that lets you
 navigate through a hierarchy of configuration settings on the local computer and remote computers.
 
 For more information about the WSMan provider, see [WSMan Provider][07] and
-[About WS-Management Cmdlets][06], or in the Windows PowerShell console, type `Get-Help wsman`.
+[About WS-Management Cmdlets][06], or in the Windows PowerShell console, type `Get-Help WSMan`.
 
 For more information, see:
 

reference/docs-conceptual/security/remoting/SSH-Remoting-in-PowerShell.md

@@ -68,7 +68,7 @@ remote computer. And, you must enable **password** or **key-based** authenticati
    > If you want to set PowerShell as the default shell for OpenSSH, see
    > [Configuring Windows for OpenSSH][07].
 
-1. Edit the `sshd_config` file located at `$env:ProgramData\ssh`.
+1. Edit the `sshd_config` file located at `$Env:ProgramData\ssh`.
 
    Make sure password authentication is enabled:
 
@@ -79,15 +79,15 @@ remote computer. And, you must enable **password** or **key-based** authenticati
    Create the SSH subsystem that hosts a PowerShell process on the remote computer:
 
    ```
-   Subsystem powershell c:/progra~1/powershell/7/pwsh.exe -sshs -nologo
+   Subsystem powershell C:/progra~1/powershell/7/pwsh.exe -sshs -NoLogo
    ```
 
    > [!NOTE]
-   > Starting in PowerShell 7.4, you no longer need to use the `-nologo` parameter when running
+   > Starting in PowerShell 7.4, you no longer need to use the `-NoLogo` parameter when running
    > PowerShell in SSH server mode.
 
    > [!NOTE]
-   > The default location of the PowerShell executable is `c:/progra~1/powershell/7/pwsh.exe`. The
+   > The default location of the PowerShell executable is `C:/progra~1/powershell/7/pwsh.exe`. The
    > location can vary depending on how you installed PowerShell.
    >
    > You must use the 8.3 short name for any file paths that contain spaces. There's a bug in
@@ -105,7 +105,7 @@ remote computer. And, you must enable **password** or **key-based** authenticati
    > ```Output
    > EightDotThreeFileName
    > ---------------------
-   > c:\progra~1
+   > C:\progra~1
    > ```
 
    Optionally, enable key authentication:
@@ -122,7 +122,7 @@ remote computer. And, you must enable **password** or **key-based** authenticati
    Restart-Service sshd
    ```
 
-1. Add the path where OpenSSH is installed to your Path environment variable. For example,
+1. Add the path where OpenSSH is installed to your PATH environment variable. For example,
    `C:\Program Files\OpenSSH\`. This entry allows for the `ssh.exe` to be found.
 
 ## Install the SSH service on an Ubuntu Linux computer
@@ -155,15 +155,15 @@ remote computer. And, you must enable **password** or **key-based** authenticati
    Add a PowerShell subsystem entry:
 
    ```
-   Subsystem powershell /usr/bin/pwsh -sshs -nologo
+   Subsystem powershell /usr/bin/pwsh -sshs -NoLogo
    ```
 
    > [!NOTE]
    > The default location of the PowerShell executable is `/usr/bin/pwsh`. The location can vary
    > depending on how you installed PowerShell.
 
    > [!NOTE]
-   > Starting in PowerShell 7.4, you no longer need to use the `-nologo` parameter when running
+   > Starting in PowerShell 7.4, you no longer need to use the `-NoLogo` parameter when running
    > PowerShell in SSH server mode.
 
 1. Restart the **ssh** service.
@@ -202,15 +202,15 @@ remote computer. And, you must enable **password** or **key-based** authenticati
    Add a PowerShell subsystem entry:
 
    ```
-   Subsystem powershell /usr/local/bin/pwsh -sshs -nologo
+   Subsystem powershell /usr/local/bin/pwsh -sshs -NoLogo
    ```
 
    > [!NOTE]
    > The default location of the PowerShell executable is `/usr/local/bin/pwsh`. The location can
    > vary depending on how you installed PowerShell.
 
    > [!NOTE]
-   > Starting in PowerShell 7.4, you no longer need to use the `-nologo` parameter when running
+   > Starting in PowerShell 7.4, you no longer need to use the `-NoLogo` parameter when running
    > PowerShell in SSH server mode.
 
    Optionally, enable key authentication:

reference/docs-conceptual/security/remoting/jea/role-capabilities.md

@@ -1,6 +1,6 @@
 ---
 description: >-
-  A role capability is a PowerShell data file with the .psrc extension that lists all the cmdlets,
+  A role capability is a PowerShell data file with the `.psrc` extension that lists all the cmdlets,
   functions, providers, and external programs that are made available to connecting users.
 ms.date: 02/02/2023
 title: JEA Role Capabilities
@@ -300,21 +300,21 @@ module. You make those functions visible in the JEA session using the **VisibleF
 like you would with built-in and third-party modules.
 
 For tab completion to work properly in JEA sessions you must include the built-in function
-`tabexpansion2` in the **VisibleFunctions** list.
+`TabExpansion2` in the **VisibleFunctions** list.
 
 ## Make the role capabilities available to a configuration
 
 Prior to PowerShell 6, for PowerShell to find a role capability file it must be stored in a
 `RoleCapabilities` folder in a PowerShell module. The module can be stored in any folder included
-in the `$env:PSModulePath` environment variable, however you shouldn't place it in
-`$env:SystemRoot\System32` or a folder where untrusted users could modify the files.
+in the `$Env:PSModulePath` environment variable, however you shouldn't place it in
+`$Env:SystemRoot\System32` or a folder where untrusted users could modify the files.
 
 The following example creates a PowerShell script module called **ContosoJEA** in the
-`$env:ProgramFiles` path to host the role capabilities file.
+`$Env:ProgramFiles` path to host the role capabilities file.
 
 ```powershell
 # Create a folder for the module
-$modulePath = Join-Path $env:ProgramFiles "WindowsPowerShell\Modules\ContosoJEA"
+$modulePath = Join-Path $Env:ProgramFiles "WindowsPowerShell\Modules\ContosoJEA"
 New-Item -ItemType Directory -Path $modulePath
 
 # Create an empty script module and module manifest.

reference/docs-conceptual/security/remoting/jea/session-configurations.md

@@ -48,7 +48,7 @@ to the following default commands (and aliases):
 
 No PowerShell providers are available, nor are any external programs (executables or scripts).
 
-For more information about language modes, see [about_Language_modes][01].
+For more information about language modes, see [about_Language_Modes][01].
 
 ### Choose the JEA identity
 
@@ -191,7 +191,7 @@ to the user.
 
 When specifying local users or groups in the role definitions field, be sure to use the computer
 name, not **localhost** or wildcards. You can check the computer name by inspecting the
-`$env:COMPUTERNAME` variable.
+`$Env:COMPUTERNAME` variable.
 
 ```powershell
 RoleDefinitions = @{
@@ -207,7 +207,7 @@ capabilities are available on the system with the same name, PowerShell uses its
 order to select the effective role capability file. JEA does **not** give access to all role
 capability files with the same name.
 
-JEA uses the `$env:PSModulePath` environment variable to determine which paths to scan for role
+JEA uses the `$Env:PSModulePath` environment variable to determine which paths to scan for role
 capability files. Within each of those paths, JEA looks for valid PowerShell modules that contain a
 "RoleCapabilities" subfolder. As with importing modules, JEA prefers role capabilities that are
 shipped with Windows to custom role capabilities with the same name.

reference/docs-conceptual/security/remoting/powershell-remoting-faq.yml

@@ -88,7 +88,7 @@ sections:
 
           These cmdlets include the following:
 
-          - `Get-Hotfix`
+          - `Get-HotFix`
           - `Rename-Computer`
           - `Restart-Computer`
           - `Stop-Computer`
@@ -112,7 +112,7 @@ sections:
           For example:
 
           ```PowerShell
-          Get-Help Get-Hotfix -Parameter ComputerName
+          Get-Help Get-HotFix -Parameter ComputerName
           ```
 
           For all other commands, use the `Invoke-Command` cmdlet.
@@ -326,7 +326,7 @@ sections:
           [about_Remote_Jobs](/powershell/module/microsoft.powershell.core/about/about_remote_jobs).
 
       - question: |
-          Can I run windows programs on a remote computer?
+          Can I run Windows programs on a remote computer?
         answer: |
           You can use PowerShell remote commands to run Windows-based programs on remote computers.
           For example, you can run `Shutdown.exe` or `Ipconfig.exe` on a remote computer.

reference/docs-conceptual/whats-new/Migrating-from-Windows-PowerShell-51-to-PowerShell-7.md

@@ -76,9 +76,9 @@ PowerShell 7 installs to a new directory, enabling side-by-side execution with W
 
 Install locations by version:
 
-- Windows PowerShell 5.1: `$env:WINDIR\System32\WindowsPowerShell\v1.0`
-- PowerShell 6.x: `$env:ProgramFiles\PowerShell\6`
-- PowerShell 7: `$env:ProgramFiles\PowerShell\7`
+- Windows PowerShell 5.1: `$Env:windir\System32\WindowsPowerShell\v1.0`
+- PowerShell 6.x: `$Env:ProgramFiles\PowerShell\6`
+- PowerShell 7: `$Env:ProgramFiles\PowerShell\7`
 
 The new location is added to your PATH allowing you to run both Windows PowerShell 5.1 and
 PowerShell 7. If you're migrating from PowerShell 6.x to PowerShell 7, PowerShell 6 is removed and
@@ -97,8 +97,8 @@ load both Core and Desktop modules.
 
 |            Install Scope            |                Windows PowerShell 5.1                 |              PowerShell 7.0              |
 | ----------------------------------- | ----------------------------------------------------- | ---------------------------------------- |
-| PowerShell modules                  | `$env:WINDIR\system32\WindowsPowerShell\v1.0\Modules` | `$env:ProgramFiles\PowerShell\7\Modules` |
-| User installed<br>AllUsers scope    | `$env:ProgramFiles\WindowsPowerShell\Modules`         | `$env:ProgramFiles\PowerShell\Modules`   |
+| PowerShell modules                  | `$Env:windir\system32\WindowsPowerShell\v1.0\Modules` | `$Env:ProgramFiles\PowerShell\7\Modules` |
+| User installed<br>AllUsers scope    | `$Env:ProgramFiles\WindowsPowerShell\Modules`         | `$Env:ProgramFiles\PowerShell\Modules`   |
 | User installed<br>CurrentUser scope | `$HOME\Documents\WindowsPowerShell\Modules`           | `$HOME\Documents\PowerShell\Modules`     |
 
 The following examples show the default values of `$Env:PSModulePath` for each version.