(doc) powershell -> PowerShell

BoxStarter.Common/Enter-DotNet4.ps1

@@ -8,9 +8,9 @@ This function will ensure that the .net 4 runtime is installed on the
 machine. If it is not, it will be downloaded and installed. If running
 remotely, the .net 4 installation will run from a scheduled task.
 
-If the CLRVersion of the hosting powershell process is less than 4,
-such as is the case in powershell 2, the given script will be run
-from a new a new powershell process tht will be configured to host the
+If the CLRVersion of the hosting PowerShell process is less than 4,
+such as is the case in PowerShell 2, the given script will be run
+from a new a new PowerShell process tht will be configured to host the
 CLRVersion 4.0.30319.
 
 .Parameter ScriptBlock
@@ -29,12 +29,12 @@ https://boxstarter.org
     )
     Enable-Net40
     if($PSVersionTable.CLRVersion.Major -lt 4) {
-        Write-BoxstarterMessage "Relaunching powershell under .net fx v4" -verbose
+        Write-BoxstarterMessage "Relaunching PowerShell under .net fx v4" -verbose
         $env:COMPLUS_version="v4.0.30319"
         & powershell -OutputFormat Text -NoProfile -ExecutionPolicy bypass -command $ScriptBlock -args $ArgumentList
     }
     else {
-        Write-BoxstarterMessage "Using current powershell..." -verbose
+        Write-BoxstarterMessage "Using current PowerShell..." -verbose
         Invoke-Command -ScriptBlock $ScriptBlock -argumentlist $ArgumentList
     }
 }

Boxstarter.Bootstrapper/en-US/about_boxstarter_bootstrapper.help.txt

@@ -2,13 +2,13 @@ TOPIC
 	About_Boxstarter_Bootstrapper
 
 SYNOPSIS
-	Describes how to use Boxstarter to wrap powershell scripts.
+	Describes how to use Boxstarter to wrap PowerShell scripts.
 
 DESCRIPTION
 	The Boxstarter.Bootstrapper module provides an execution
 	environment for running scripts that may require one or more
 	reboots throughout its exeution process. This can be any
-	powershell script and is ideally suited for scripts that involve
+	PowerShell script and is ideally suited for scripts that involve
 	the installation of software and system configuration.
 
 ENABLING REBOOTS
@@ -87,7 +87,7 @@ LOGGING
 	ability to log both to the screen and the Boxstarter Log as well as
 	the ability to log to both simultaneously. Boxstarter also enables
 	you t ocapture the standard output and error streams of standard
-	command line executables and utilities and not just the powershell
+	command line executables and utilities and not just the PowerShell
 	pipeline. See About_Boxstarter_Logging for more details.
 
 WINDOWS CONFIGURATION UTILITIES

Boxstarter.Chocolatey/en-US/about_boxstarter_chocolatey.help.txt

@@ -49,11 +49,11 @@ Creating Packages
 Consuming Boxstarter Packages
 	The primary gateway to kicking off a Boxstarter.Chocolatey installation
 	session is Install-BoxstarterPackage. While you may use this
-	powershell function, you can also call Boxstarter.bat which takes the
+	PowerShell function, you can also call Boxstarter.bat which takes the
 	exact same parameters as Invoke-CocolateyBoxstarter. If you installed
 	Boxstarter.Chocolatey via Chocolatey or the setup.bat installer,
 	boxstarter.bat is placed in your path. Boxstarter.bat will import the
-	Boxstarter.Chocolatey module and create a powershell session bypassing
+	Boxstarter.Chocolatey module and create a PowerShell session bypassing
 	ExecutionPolicy. Boxstarter.bat is ideal for calling Boxstarter
 	remotely. Simply share the Boxstarter base directory and you can access
 	it via \\serverName\Boxstarter\Boxstarter.bat.
@@ -77,19 +77,19 @@ Running Boxstarter Remotely
 	When using the Computername, ConnectionURI or Session parameters of
 	Install-BoxstarterPackage, Boxstarter will attempt to install the package
 	the the remote maching it is directed at. Boxstarter will check to ensure
-	that all necessary client side Powershell Remoting settings are correctly
+	that all necessary client side PowerShell Remoting settings are correctly
 	configured. If they are not, Boxstarter will prompt to confirm whether it
 	should enable them unless the -Force parameter is used. The -Force
 	parameter will suppress prompts. As part of this configuration, Boxstarter
 	will enable CredSSP authentication to ensure that any network connection
 	that the package may try to establish will pass the users credentials.
 
-	Boxstarter will also attempt to enable Powershell remoting on the target
+	Boxstarter will also attempt to enable PowerShell remoting on the target
 	machine if it is not already installed. Boxstarter can only do this if the
 	WMI firewall ports are open on the target computer. If they are not and
-	powershell remoting is not enabled on the target machine, the installation
-	will fail. Users can easily enable powershell remoting manually on the
-	target machine by opening an administrative powershell console on the remote
+	PowerShell remoting is not enabled on the target machine, the installation
+	will fail. Users can easily enable PowerShell remoting manually on the
+	target machine by opening an administrative PowerShell console on the remote
 	computer and then issuing 'Enable-PSRemoting -Force'.
 
 Reboot detection
@@ -108,7 +108,7 @@ Reboot detection
 	invoke them.
 
 Package Authoring Considerations
-	Boxstarter can run any Chocolatey package and any valid powershell
+	Boxstarter can run any Chocolatey package and any valid PowerShell
 	inside that package. However, there are a few things to consider
 	that may make a Boxstarter Chocolatey package a better installation
 	experience.

Boxstarter.Chocolatey/invoke-chocolatey.ps1

@@ -261,7 +261,7 @@ namespace Boxstarter
         $cd = [System.IO.Directory]::GetCurrentDirectory()
         try {
             # Chocolatey.dll uses GetCurrentDirectory which is not quite right
-            # when calling via powershell. so we set it here
+            # when calling via PowerShell. so we set it here
             Write-BoxstarterMessage "setting current directory location to $((Get-Location).Path)" -Verbose
             [System.IO.Directory]::SetCurrentDirectory("$(Convert-Path (Get-Location).Path)")
             $choco.Run($chocoArgs)

Boxstarter.TestRunner/en-US/about_Boxstarter_TestRunner.help.txt

@@ -125,7 +125,7 @@ Configuring a Dedicated Build Server
     If you administer your own build server, there is some one time setup that
     you need to perform to integrate Boxstarter TestRunner tests and
     automatic package publishing. This must be performed on the build machine
-    that will run the builds (a remote powershell session is acceptable). In
+    that will run the builds (a remote PowerShell session is acceptable). In
     many build systems, this may be a different machine from the central server,
     in TFS it would be the build "controller" or in TeamCity the build "agent."
     Also, these steps must be performed using the credentials of the SAME USER

BuildScripts/bootstrapper.ps1

@@ -11,14 +11,14 @@ function Get-Boxstarter {
             Start-Process powershell -verb runas -argumentlist $command
         }
         else {
-            Write-Host "User is not running with administrative rights.`nPlease open a powershell console as administrator and try again."
+            Write-Host "User is not running with administrative rights.`nPlease open a PowerShell console as administrator and try again."
         }
         return
     }
 
     $badPolicy = $false
     @("Restricted", "AllSigned") | ? { $_ -eq (Get-ExecutionPolicy).ToString() } | % {
-        Write-Host "Your current Powershell Execution Policy is set to '$(Get-ExecutionPolicy)' and will prohibit boxstarter from operating propperly."
+        Write-Host "Your current PowerShell Execution Policy is set to '$(Get-ExecutionPolicy)' and will prohibit boxstarter from operating propperly."
         Write-Host "Please use Set-ExecutionPolicy to change the policy to RemoteSigned or Unrestricted."
         $badPolicy = $true
     }

BuildScripts/nuget/Boxstarter.Bootstrapper.nuspec

@@ -10,7 +10,7 @@
     <iconUrl>https://cdn.rawgit.com/chocolatey/boxstarter/master/Web/Images/boxLogo_sm.png</iconUrl>
     <projectUrl>https://Boxstarter.org</projectUrl>
     <licenseUrl>https://www.apache.org/licenses/LICENSE-2.0</licenseUrl>
-    <description>Boxstarter's Bootstrapper module provides a powershell wrapper that supports reboots and automatic logons and exposes commands that can detect pending reboots, perform logging and messaging, and several commands that can configure various windows settings.</description>
+    <description>Boxstarter's Bootstrapper module provides a PowerShell wrapper that supports reboots and automatic logons and exposes commands that can detect pending reboots, perform logging and messaging, and several commands that can configure various windows settings.</description>
     <tags>Boxstarter bootstrapper environment setup</tags>
     <dependencies>
       <dependency id="Boxstarter.Common" version="[$version$]" />

BuildScripts/nuget/Boxstarter.Chocolatey.nuspec

@@ -10,7 +10,7 @@
     <title>Boxstarter Chocolatey Module</title>
     <projectUrl>https://Boxstarter.org</projectUrl>
     <licenseUrl>https://www.apache.org/licenses/LICENSE-2.0</licenseUrl>
-    <description>Creates a fresh developer (or non developer) environment from a bare OS utilizing powershell and Chocolatey. Installs Chocolatey, cutomizes windows settings, installs windows updates, handles reboots, installs windows features and your favorite applications.</description>
+    <description>Creates a fresh developer (or non developer) environment from a bare OS utilizing PowerShell and Chocolatey. Installs Chocolatey, cutomizes windows settings, installs windows updates, handles reboots, installs windows features and your favorite applications.</description>
     <tags>Boxstarter environment setup</tags>
     <dependencies>
       <dependency id="Boxstarter.Common" version="[$version$]" />

Web/InstallBoxstarter.cshtml

@@ -31,13 +31,13 @@ CINST Boxstarter
 <p>After Boxstarter is installed, a new PowerShell console must be opened before you can load the modules and run its commands. For convenience you can use the <a href="/UsingBoxstarter">Boxstarter Shell</a> for running Boxstarter commands which is the easiest way to ensure that all Boxstarter modules are properly loaded regardless of the version of Windows and PowerShell you are running.</p>
 
 <h3>Installing from the web</h3>
-<p>If you are running powershell v3 or higher:</p>
+<p>If you are running PowerShell v3 or higher:</p>
 <pre>
 . { iwr -useb https://boxstarter.org/bootstrapper.ps1 } | iex; get-boxstarter -Force
 </pre>
 
 <p/><p/>
-<p>If you are running powershell v2:</p>
+<p>If you are running PowerShell v2:</p>
 <pre>
 iex ((New-Object System.Net.WebClient).DownloadString('https://boxstarter.org/bootstrapper.ps1')); get-boxstarter -Force
 </pre>

Web/Learn/WebLauncher.cshtml

@@ -50,15 +50,15 @@ cinst IIS-WebServerRole -source windowsfeatures
 
 <h3>Step 3</h3>
 <h4><span class="text-primary">Install the Boxstarter Modules</span></h4>
-<p>You can download the Boxstarter module installer from this web site or you can use Chocolatey to install the Boxstarter. Alternatively, you may invoke the module installer over the web using powershell.</p>
+<p>You can download the Boxstarter module installer from this web site or you can use Chocolatey to install the Boxstarter. Alternatively, you may invoke the module installer over the web using PowerShell.</p>
 
-<p>If you are running powershell v3 or higher:</p>
+<p>If you are running PowerShell v3 or higher:</p>
 <pre>
 . { iwr -useb https://boxstarter.org/bootstrapper.ps1 } | iex; get-boxstarter -Force
 </pre>
 
 <p/><p/>
-<p>If you are running powershell v2:</p>
+<p>If you are running PowerShell v2:</p>
 <pre>
 iex ((New-Object System.Net.WebClient).DownloadString('https://boxstarter.org/bootstrapper.ps1')); get-boxstarter -Force
 </pre>

Web/TestingPackages.cshtml

@@ -37,7 +37,7 @@
     boxstarter repository with <code>Set-BoxstarterConfig</code> all future
     interactions with the Boxstarter repository will act on this location.
     To temporarily change the repository location just for the current
-    powershell session, one can change the value of <code>$Boxstarter.LocalRepo</code>
+    PowerShell session, one can change the value of <code>$Boxstarter.LocalRepo</code>
     directly.
 </p>
 <pre>$Boxstarter.LocalRepo = "c:\dev\Chocolatey-Packages"</pre>
@@ -197,7 +197,7 @@ Mode                LastWriteTime     Length Name
         If you administer your own build server, there is some one time setup that
         you need to perform to integrate Boxstarter TestRunner tests and
         automatic package publishing. This must be performed on the build machine
-        that will run the builds (a remote powershell session is acceptable). In
+        that will run the builds (a remote PowerShell session is acceptable). In
         many build systems, this may be a different machine from the central server,
         in TFS it would be the build "controller" or in TeamCity the build "agent."
         Also, these steps must be performed using the credentials of the SAME USER

tests/Common/Invoke-FromTask.tests.ps1

@@ -90,7 +90,7 @@ Describe "Invoke-FromTask" {
             schtasks /query /TN 'Ad-Hoc Task' 2>&1 | out-null
             $LastExitCode | should be 1
         }
-        It "Should kill the original powershell task"{
+        It "Should kill the original PowerShell task"{
             ($proc -eq $null -or $proc.HasExited) | should be $true
         }
     }
@@ -107,7 +107,7 @@ Describe "Invoke-FromTask" {
             schtasks /query /TN 'Ad-Hoc Task' 2>&1 | out-null
             $LastExitCode | should be 1
         }
-        It "Should kill the original powershell task"{
+        It "Should kill the original PowerShell task"{
             ($proc -eq $null -or $proc.HasExited) | should be $true
         }
     }

vNext.md

@@ -43,7 +43,7 @@ I'm considering rewriting the core of boxstarter in GO for these reasons.
 * Is not c++
 * I want to learn it. Yeah I said it.
 
-Once some design decisions have been ironed out, it may make more sense to remain in pure powershell and then port to GO later after the basic structure is stable or maybe not. Regardless, there will be a powershell module to wrap the core so users can still call boxstarter via powershell commands.
+Once some design decisions have been ironed out, it may make more sense to remain in pure PowerShell and then port to GO later after the basic structure is stable or maybe not. Regardless, there will be a PowerShell module to wrap the core so users can still call boxstarter via PowerShell commands.
 
 ## Thoughts on revised execution flow
 ### Boxstarter core as entry point