CONTINUAL INTEGRATION

Problem scenario:  You PowerShell or PowerCLI window keeps exiting automatically when you run a script.  You find that RAM and CPU are not constrained.  
Root cause: Human error.
Solution:  Look for the "exit" or the "Exit-Pssession" commands.  These can close PowerShell's ISE or PowerCLI.  You may need to eliminate these commands or use a different keyword.

-----------------------------------------------------------------------------------------------------------------------------------------------------------------------
Problem scenario:  You want to use a for-each loop in PowerShell, you do not want the script to cause the interactive PowerShell window to close, and you want the action portion (in braces {}) to run only once.  What do you do if you do not want to re-write the function to use an "if" or a "while" loop?

Solution:  Use the "break" or "return" key word as the last line in the action clause.

foreach ($cont in $integration) {
   write-host $cont
   return  # or break
}

Return will return the control of the PowerShell interpreter to the previous location before entering the foreach loop.  This is particularly significant when you have functions.  Break can be called with an accompanying label.  For example,
this code would not just interrupt the foreach clause but the PowerShell interpreter would start parsing the ":contInt" section of code:

:contInt if ($foo -eq 289) {
     while ($foo < 505) {
        foreach ($cont in $integration) {
           write-host $cont
           Break :contInt    
         }
      }
}

In the future we want to re-write these directions to use write-verbose instead of write-host. We want to warn people that write-verbose is recommended instead of write-host (according to this posting).

Problem Scenario 
You want to package a standalone .ps1 script as an .exe file.  How do you create an executable file that does what a PowerShell script does?

Solution 
Install PowerShell Community Extensions.  Then download this .ps1 file and use it according to the conventions in the comments, near the top, of the script itself,

The usage instructions are in the code.  We found that the -NET40 flag was needed.  Here is an example that assumes four things: 1) you saved the file as "Make-PS1ExeWrapper.ps1" (but this is optional and just an example) 2) the script you want to convert is named "good.ps1" 3) the directory the PowerShell prompt is in is the directory with the two files just mentioned 4) you want the new .exe file to be called good.exe.

>  .\Make-PS1ExeWrapper.ps1 .\good.ps1 .\good.exe -NET40

The actions of good.ps1 will run whenever you double click the good.exe file.  You may transfer good.exe to any Windows machine and run it.

Problem Scenario:  You want the rich features provided by PowerShell Community Extensions (also known as PSCX).

Solution:
1.  Download the .msi from this link. 
2,  Double click it. 
3.  Install it by accepting the License Agreement and the defaults. 
4.  Open PowerShell as Administrator. 
5. In PowerShell, Change directories to where it was installed (e.g., C:\Program Files (x86)\PowerShell Community Extensions\Pscx3\Pscx). 
6.  Run this command:  import-module .\Pscx.Core.dll

Problem scenario:  For no apparent reason, Scheduled Tasks are not kicking off PowerShell scripts.  You have configured Scheduled Tasks to launch .ps1 files.The task calls "%windir%\system32\WindowsPowerShell\v1.0\PowerShell_ISE.exe" (in the Action tab's "Program/Script" field) with an argument like this "C:\Program Files\good script.ps"

You manually run the scheduled task (by right clicking its name and choosing Run) and the Scheduled Task will seem to run.  In reality, the .ps1 file will not execute (despite having the correct Execution Policy).  You allow the time to pass when it is scheduled to run.  Still there is no evidence that the job runs.  When you look at the Scheduled Tasks you see a column for "Last Scan Result."  Underneath it you see things like this for the Scheduled Task that never really runs:  "The operation completed successfully" or "0x1".  There are no other hints in the history of whether or not previous runs were successful or not.

Root Cause:  The argument has spaces in it.  There is a space between "Program" and "Files".  There is a space between "good" and "script".

Solution:  Change the location of the .ps1 file to not be in a "Program Files" subdirectory.  The path must have no spaces in it.  Change the name of the .ps1 file to eliminate the space.  Reconfigure the Scheduled Task to have the Action tab's argument field point to the new name and location of the .ps1 file.

Miscellaneous:  Microsoft should have a special parsing feature in PowerShell when this command and flag are ran "schtasks /tr".  In the GUI for Task Scheduler, the argument field should detect spaces and not allow the administrator to leave a space in there.  Spaces can exist in the "Program/Script" field of the action of the Scheduled Task.  But the argument cannot have spaces.  If the argument is encapsulated in single quotes and there is a space in the file name, the "Last Scan Result" can speciously say "The operation completed successfully."  If the argument has double quotes or not quotes with a space in its name, the "Last Scan Result" will show "0x1" while the history will not clearly explain what is wrong.