Powershell Version: 5.0.10586.494
I just began working with powershell this weekend and I discovered that I cannot find any help files when using the shell, for example, I was looking to read the about_Comparison_Operators help file but it seems as though the console cannot find it.
When doing: Get-Help About_* the only result I get is About_CimSession... it seems like there are no other help files?
This TechNet article suggests that in Powershell v3 the module must be imported,
To download or update the help files for a module in Windows PowerShell 3.0, use the Update-Help cmdlet.
I don't know if it's the same deal in my case? I've used the update-help cmdlet (as admin) and it does not seem to effect the help files.
Thanks!
EDIT: Forgot to mention, I've been running PS as admin while trying to update help. This runs without error, but the help files remain untouched.
UPDATE: Still no luck, tried updating help by specifying language using the UICulture parameter but this didn't make a difference. Will keep this post updated if I find a fix.
Update: PowerShell updatable help is no longer broken. About_ helpfiles are now downloaded with the correct extension. The formatting of these plaintext files still doesn't equal the old versions, however.
PowerShell updatable help is currently broken. PS5 doesn't ship with those about_* helpfiles, and if you update-help to download them, they aren't stored with the appropriate file extension, so get-help doesn't read them.
Only recently were these files being downloaded at all, so if you haven't tried in a while you should still do update-help -force in an elevated session. Then, see this answer for a one-liner that will rename the files correctly: https://superuser.com/a/1134681/4782
However, due to a (probably) unrelated issue, these new help files have some mangled text formatting that makes them very difficult to read any time a table-like layout is being used. If you'd like instead to grab the PS4-era about_* files with proper formatting and use those instead, an alternative solution can be found here: https://github.com/kilasuit/Install-AboutHelp. Note that this solution will unzip an archive of about_* files to the en\ locale folder, which may not be your default locale (mine is en-US\, for example). This will work fine since the en\ location will be used as a fallback as long as the desired document doesn't exist in your default locale's folder.
Further reference:
https://github.com/PowerShell/PowerShell/issues/2028
https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/15832144-powershell-5-on-windows-10-server-2012-helpfiles-a
https://windowsserver.uservoice.com/forums/301869-powershell/suggestions/17014843-core-help-files-as-of-2016-11-08-have-broken-tex
FOR non-English OS only
If you are using PowerShell v5 on an operating system that has not the "en-US" language settings then update-help tries to download the help files for your language which might not be available. Use:
Update-Help -UICulture "en-US"
in an elevated (admin) console.
Background
You can check your language setting with the cmdlet get-culture. In my case I get:
PS C:\> Get-Culture
LCID Name DisplayName
---- ---- -----------
1031 de-DE Deutsch (Deutschland)
and at least today (20.7.2017) there are help-files missing (for example get-services). Note that the get-help applet will still first look for help files in your language before it will resort to "en-US" Quelle (in Deutsch).
Related
While debugging a script in VS code's Powershell Integrated Console if I test for a registry path it's printing False even though the path exists.
If I execute the same instruction in PowerShell window or VS Code's Powershell Console it prints True.
I am running all instances with Admin privileges.
Check if Get-PSProvider shows Registry providers in both Integrated Console and Powershell Console. If it does not exist for some reason, test path simply won't understand Registry:: root. Environments may be different as explained here: https://powershell.org/2013/10/19/the-shell-vs-the-host/
You're using the wrong syntax argument (I'd suggest testing in the DBG console or the powershell.exe process as an FYI)... Also, don't post code as images, it's a bad practice that will not get your question answered.
The PowerShell way:
Test-Path -Path 'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\GMS Software'
The issue was with VS code installation. A complete uninstall of VS code and reinstalling it resolved the problem.
I'm working with DNS resource records in Powershell 5 using code that I inherited from the guy who was trying to do this before me. The cmdlet I am trying to use is Add-DnsServerResourceRecordA.
Part of his code has import-module certain folder\PowerShell\Modules\DnsServer. The weird thing is, it seems like as I was trying bits and pieces of the code earlier, I was able to use the add-DNSblah cmdlet. Now, after It ried running the whole script including the import-module, Powershell is saying that the cmdlet does not exist natively, and when I import the module and run it it is giving me Add-DnsServerResourceRecordA: Invalid Class.
It is my understanding that Add-DnsServerResourceRecordA should be included in my normal Powershell 5.0. Could that Import-Module have permanently damaged PS somehow? Why else would the cmdlet not show up, even in a Get-Command "dns"?
I'm pretty sure you will need the Remote Server Administration Tools (RSAT) installed to have these cmdlets available on a non-server Windows OS.
You can download them from this page: https://www.microsoft.com/en-gb/download/details.aspx?id=45520.
Not really sure why the Import-Module does not fail if the DNSServer module is not present on the system.
If RSAT are already installed, you can try to reinstall them.
I am not a scripter at all. Someone else had created this script for me and it has previously worked. The only thing that has changed is the drive letter (which I did change in the script - it is currently drive E). But it is not working now. All it is supposed to do is pull back a list of files in a specified folder and save it as a text file in that directory; in this case, it's my karaoke song collection.
When I run the script now, I get:
Get-Process : A positional parameter cannot be found that accepts argument Get-ChildItem.
Here is the original script:
PS C:\Users\Tina> Get-ChildItem "F:\My Music\Karaoke\*.*" | Set-Content "F:\My Music\Karaoke\test.txt"
I'd like to make it so that it just pulls back all .mp3's, if that's possible, too. Thanks in advance for your help!
Since you appear to be copying and pasting this to the command line I will assume there was a typo that caused this issue. After a couple of quick tests to try and guess what the accident was I was unable to replicate exactly. Not being a scripter might make this harder but I recommend saving this code to a ps1 file so that you can just double click on it.
Get-ChildItem "F:\My Music\Karaoke\*.mp3" | Set-Content "F:\My Music\Karaoke\test.txt"
Warning
In order for the this file to work for you you have to allow PowerShell to execute it. If you run the shell as administrator once and run this code
Set-ExecutionPolicy remotesigned
It will allow your script to run. Keep in mind this is a site for scripters to get help. You should expect answers like this.
I'm using InstallShield 2013 to make a Basic MSI installer for an application that requires Windows Platform Update KB2670838.
For .NET frameworks and other requirements, I select them in InstallShield in the Redistributables section. KB2670838 is not available.
If I download KB2670838 from Microsoft I get a .msu file. Can that be included in the installer somehow so that it automatically installs if needed? If not, is there a way to stop the install and tell the user that "KB2670838 is required but not installed. Get it here..."?
In InstallShield, you should typically deliver this sort of update as a prerequisite (Tools > Prerequisite Editor), or as a package included in a Suite (reference [SystemFolder]wusa.exe to install an .msu file). In both cases this keeps the redistributable installation logically separate from your package's installation, while providing your users a single installer experience.
Glytzhkof mentions several really good points about how to determine whether the update has been installed. You will want to incorporate these into your conditions (on the prerequisite or suite package), and also into detecting the update or lack thereof in your .msi package so it can abort if the required update has not been installed by the time the .msi is launched.
The Add/Remove programs list in the registry could help you get a rough idea of what's installed:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
It seems this doesn't provide a full list of what is installed though: http://social.technet.microsoft.com/Forums/windows/en-US/d913471a-d7fb-448d-869b-da9025dcc943/where-does-addremove-programs-get-its-information-from-in-the-registry?forum=w7itprogeneral
Another way may be to use the file information from the knowledge base article:
http://support.microsoft.com/kb/2670838/en (For More Information : File Information) and use WIX / MSI's AppSearch / LaunchCondition feature. That should do the trick, though I find the syntax a bit counterintuitive.
Another approach is to write a custom action and combine these two sources (add /remove entry and file info). Such a custom action will make no changes to the system, and is hence less problematic than other custom actions that cause rollback-problems. I find it easier to test and maintain a custom action in case there are further prerequisites that are needed at some point. This is a matter of taste though. I just find it easier to run a prerequisite script against a selection of files to test that it identifies them correctly and run through as expected than to keep running the MSI file for every test.
Here is a similar question with some pointers from superuser.com:
https://superuser.com/questions/521175/determine-if-windows-hotfix-has-been-applied
And another link to serverfault.com (system administration site). Nice approach using PowerShell which can certainly be migrated to a custom action:
https://serverfault.com/questions/312778/determine-if-user-has-hotfix-981889-installed
Even more serverfault.com stuff involving update.exe, WMI and a Powershell script to view all installed hotfixes:
https://serverfault.com/questions/263847/how-can-i-query-my-system-via-command-line-to-see-if-a-kb-patch-is-installed . Recommended read. Microsoft: http://technet.microsoft.com/en-us/library/hh849836.aspx
PSInfo appears to be able to show installed hotfixes: http://technet.microsoft.com/en-us/sysinternals/bb897550
#Glytzhkof Good point. So how do I get InstallShield to abort and give the user a nice message so they know what to do? – shoelzer 1 hour ago
I will just add a new answer then - too long to write in a comment.
Locate the file details you need to scan for under "For More
Information : File Information" in this kdb article:
http://support.microsoft.com/kb/2670838/en
Select a few files to scan for and add as file searches in Installshield (see below screenshot). You specify a property for each file (FILE1FOUND, FILE2FOUND, FILE3FOUND, etc...), and if the search matches the file details (version, size, date, etc...) the property is set to the full path of the file. Otherwise the property is undefined or set to a default value (screenshot shows predefined search, and not file search, but you get the idea).
Finally you add LaunchCondition entries for each file to ensure that all files you have selected to check are the correct version or higher. I guess this is in Prerequisites or similar - I can't recall. Open the compiled MSI and check that it looks like the LaunchConditon table.
For the record: (not part of above suggestion)
Personally I am in favor of coding a single script for complex logic like this to ensure the logic can be inspected as a whole and crucially tested as a whole outside the MSI file. It is also good to add comments to such code to explain what the script is checking, and why (helps corporate deployment). A script can be run through dozens of tests against the machine directly without recompiling the MSI. This can save a lot of time if the logic is complex. If you write a compiled dll you can show a message box and attach the visual studio debugger to the msiexec.exe process (client or server depending on what context your custom action is running in) and step-through the code whilst embedded in the MSI, but this seems out of scope for your scenario. Just want to mention it for other people who might read this. Also check Stefan Kruger's installsite.com for more information on complex setup debugging like this.
It is important to note that scripting is never generally recommended for scenarios where the script makes changes to the system - if there is a built-in MSI way to achieve the same result. The reason for this is that a script that makes changes to a machine will need a separate rollback-operation to be specified for it for the MSI to follow best practice. This can be a spectacular amount of work and complexity to get right. The above script would only check system conditions, so there is no need for rollback support.
Let me try and add a reference style answer since my other answer is a bit organic to say the least at this point - I will leave it in since it contains an MSI discussion. See MSI recommendation in the middle section below:
WMI:
wmic qfe where "HotfixID = 'KB973687'"
PowerShell: (just get-hotfix for full list)
get-hotfix | findstr "981889"
SystemInfo (remove arguments for list format):
systeminfo /fo csv
PSInfo (seems to not list everything on all machines, and may not run silently properly):
PSinfo -h
Registry (apparently not complete list of hotfixes):
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall
For MSI custom action use, I would actually use a custom action that inspects file versions as explained in my other answer. Very reliable, and takes into account that the hotfix may be deprecated whilst the files are still up to date.
References:
Recommended: https://serverfault.com/questions/263847/how-can-i-query-my-system-via-command-line-to-see-if-a-kb-patch-is-installed
How do I get a list of installed updates and hotfixes?
SystemInfo: https://serverfault.com/questions/334552/how-to-check-that-a-known-windows-vulnerability-has-been-patched
http://windowsitpro.com/scripting/get-hotfix-information-quickly-wmic
https://serverfault.com/questions/69467/list-all-hotfixes-applied-to-windows-server
wmic in general: http://technet.microsoft.com/en-us/library/bb742610.aspx
Recommended: http://www.dedoimedo.com/computers/windows-wmic.html
http://www.techsupportalert.com/content/quick-and-easy-way-list-all-windows-updates-installed-your-system.htm
http://pario.no/2011/06/19/list-installed-windows-updates-using-wmic/
Had the same issue and solved it by adding a prerequisite of a PowerShell script and a batch file to execute it.
The pre.ps1 file looks something like this:
function TestConnection
{
Test-Connection -ComputerName "8.8.8.8" -Quiet
}
get-hotfix -id KB2670838
if(!$?){
#SourceURI = "https://download.microsoft.com/download/1/4/9/14936FE9-4D16-4019-A093-5E00182609EB/Windows6.1-KB2670838-x64.msu";
#$FileName = $SourceURI .Split('/')[-1]
#$BinPath = Join-Path $DownloadPath -ChildPath $FileName
Invoke-Webrequest -Uri $SourceURI -OutFile $BinPath
#Start-Process -FilePath $BinPath -ArgumentList "/q /norestart" -Wait -NoNewWindow
}
the pre.cmd file looks something like this:
#echo off
::set PS_FILE=%~dp0Prerequisite.ps1
set PS_FILE=%~dpn0.ps1
set PS_EXEC_PATH=%SystemRoot%\sysnative\WindowsPowerShell\v1.0\
set PS_EXEC_PATH=%SystemRoot%\System32\WindowsPowerShell\v1.0\
::set PS_EXEC_PATH=%SystemRoot%\SysWOW64\WindowsPowerShell\v1.0\
set PS_EXEC_PATH=
set PS_EXEC=%PS_EXEC_PATH%powershell.exe
echo %PS_EXEC%
echo %PS_FILE%
::%PS_EXEC% -file %PS_FILE% set-executionpolicy remotesigned
::%PS_EXEC% -NoProfile -ExecutionPolicy Bypass -Command "& '%PS_FILE%'"
::This is with admin rights
%PS_EXEC% -NoProfile -Command "& {Start-Process PowerShell.exe -ArgumentList '-NoProfile -ExecutionPolicy Bypass -File ""%PS_FILE%""' -Verb RunAs}"
::pause
Is it possible to create an executable file.exe file from a PowerShell Script?
No. At least, not yet, and after 5 versions of PowerShell, it seems unlikely ever.
I wish I could just leave it at that, but other people have provided a bunch of "workaround" type answers I feel compelled to address:
You can wrap your .ps1 script in another script type to make it double-clickable, and you can even generate an executable with the script embedded (see the other answers on this thread) ... but those "executables" require the right version of PowerShell to be already present on the system, so you're not gaining anything by doing that, and you loose a lot of the features of PowerShell (like streaming object output, help documentation, and automatic parameter handling with tab completion for users).
Here is a simple .cmd batch file wrapper (you could extend this to allow parameters):
REM <#
copy %0 %0.ps1
PowerShell.exe -ExecutionPolicy Unrestricted -NoProfile -Command "&{Set-Alias REM Write-Host; .\%0.ps1}"
del %0.ps1
exit
REM #>
### Your PowerShell script goes below here.
### I've put a couple of lines as an example ...
ls | sort length -desc | select -first 5 | ft
ps | sort ws -desc | select -first 10 | ft
I know ...
With Portable PowerShell, it would probably be possible to package up a sort of self-extracting zip that would contain the right version of PowerShell and a script and would work. That's not an executable in any normal sense of the word -- it's a bit like if Valve had decided to just ship a vmware image on a thumbdrive as their solution to letting Linux users play Half Life. However, the product seems abandoned.
With PrimalScript (or PowerShell Studio) or PowerGui or pShellExec, your script can be encrypted, so it's slightly secured against prying eyes ... but this is basically just obfuscation, and essentially no different than the batch file, and in some ways worse.
Out of the box - no. However I have built a PowerShell script that can take a script and create an EXE wrapper around it. I created this script a while ago but decided to blog it here for folks to check out.
Use PowerGUI's Script Editor (it is free and works). Open your script in the PowerGUI Script Editor > Tools > Compile script > Choose whatever options you would like for your .exe (password protect source code, automatically close console after .exe runs, etc.).
Yes, there is a option with PS2EXE to create such *.exe Files.
Usage
The whole thing is really simple and well explained nevertheless
here is a snippet of it:
C:\Scripts\PS2EXE\PS2EXE_0.5.0.0.0\ps2exe.ps1
-inputFile C:\Scripts\ExampleEXE\example.ps1
-outputFile C:\Scripts\ExampleEXE\example.exe -sta -noConsole -runtime40 -verbose -x64
The only bad thing is that the project is depreciated. No Updates or new Versions since 2015.
EDIT:
This projected has been picked up and is being maintained by a new person now. You can find the updated code here, last updated 01/04/2018 as of this edit.
https://gallery.technet.microsoft.com/scriptcenter/PS2EXE-GUI-Convert-e7cb69d5
Version Information
For adding and editing the version information use something like VERPATCH.
UPDATE 2019
Shout out to a git-repo which is called PythonEXE.
It demonstrates how to create an executable from a Python project and also provides a YouTube Step-By-Step Guide.
I understood your question as "Can my PowerShell script generate an executable?" That is what I was trying to do when I found this post. That is possible using the Add-Type command.
Add-Type -TypeDefinition #"
using System;
class Program {
public static void Main(string[] args) {
Console.WriteLine("Hello World!");
}
}
"# -CompilerParameters #{
"GenerateExecutable" = $true
"OutputAssembly" = "test2.exe"
}
PrimalScript from Sapien will generate an exe from a PowerShell script. The machine one which the executable is run must have PowerShell installed.
The solution I found best to distribute a PowerShell script as exe was to wrap it in a NSIS executable.
I write a .nsi script like this:
Name "Maintenance task"
OutFile "maintenance.exe"
ShowInstDetails show
Section "Main"
;Executes the "script-to-run.ps1" PowerShell script
InitPluginsDir
SetOutPath "$pluginsdir\MyOrg" ;It is better to put stuff in $pluginsdir, $temp is shared
;extract the .ps1 and run it, collecting output into details.
File script-to-run.ps1
nsExec::ExecToLog 'powershell -inputformat none -ExecutionPolicy RemoteSigned -File "$pluginsdir\MyOrg\script-to-run.ps1" '
SetOutPath $exedir
SectionEnd
I just have to compile the script to an exe with the NSIS toolchain, and it will run on any OS that has PowerShell, no matter what is the execution policy.
This was inspired by this question How to call PowerShell in NSIS.
There's a project called Portable PowerShell that is still in beta after a couple of years ... might be worth looking at for your needs.
http://shelltools.wik.is/Portable_PowerShell