PowerShell 5 and 7 are different still when it comes to PackageManagers.
Chocolatey seems not to be 'integrated' yet and I cannot use Chocolatey in PowerShell 7 as I do in PowerShell 5.
I have installed chocolatey the way their site says but this lets me use chocolatey with starting my command with choco.
How can I configure Chocolatey in PowerShell 7 so that I can use it like I do in PowerShell 5.
Find-Package -ProviderName Chocolatey -Name <packagename>
As of PowerShell [Core] 7, it looks like you cannot use Chocolatey as a provider for PowerShell's PackageManagement module, which means that you cannot discover or install Chocolatey packages with Find-Package and Install-Package.
However, direct use of Chocolatey via its CLI, choco.exe, works just fine in PowerShell [Core] (an *.exe file runs as long as its runtime is present on the system, which needn't be the same runtime as PowerShell's).
Read on for background information:
It looks like implementing a PackageManagement provider would require access to Chocolatey APIs in a manner that supports only .NET Framework (FullCLR), not also .NET Core (on which PowerShell [Core] is built)[1]; a quote from the read-me of Chocolatier, a community-provided alternative to the never-released prototype of the official provider:
Currently, Chocolatier works on Full CLR. It is not supported on CoreClr (...). The primary reason is that the current version of choco.exe does not seem to support CoreClr yet.
As for use on Windows PowerShell:
The official - Windows PowerShell-only - prototype for the Chocolatey PackageManagement provider has to date, many years later, not been implemented; here's what the docs say, retrieved on 13 Apr 2020 (emphasis added):
Chocolatey has a prototype provider for the built-in package manager on Windows 10/Windows Server 2016 that was created by Microsoft awhile back. It is not fully functional and it may have security issues. If you want to use Chocolatey with PackageManagement, we recommend using ChocolateyGet, which is a nice bridge until an official one is implemented. No ETA has been defined.
Note:
The aforementioned Chocolatier, which builds on ChocolateyGet, seems to be the more actively maintained project as of this writing.
There is a fairly recent pending PR by a community member for the official prototype, but it hasn't received any attention; also, it isn't complete yet either; for the full backstory, see this GitHub issue.
[1] If you know details, do let us know.
I manage the Chocolatier community project that mklement0 mentions in their (excellent) answer.
You're correct that PackageManagement works a bit differently under PowerShell 7, and on its initial release, many PackageManagement providers didn't work at all. The defect in PowerShell 7 was fixed in their 7.0.1 release, though there is still some work for PackageManagement provider maintainers to integrate with PowerShell 7.
As of May 2020, the Chocolatier provider will work with both PowerShell 5.1 and PowerShell 7, even though Chocolatey is written in the older .NET Framework that isn't compatible with PowerShell 7. When the provider runs under PowerShell 7, it will construct and run the Chocolatey CLI commands for you (ex: choco install firefox), bypassing the .NET compatibility problem.
If you're still interested in using PackageManagement to interact with Chocolatey, I'd recommend giving Chocolatier a try. I've iterated on it through both personal and professional use (works with private repositories and Desired State Configuration), and though I'm a bit biased, am pretty happy with it.
Related
I'm currently trying to remote to multiple servers that are on PowerShell 4.0 whereas the local computer currently runs on 5.0+. I am attempting to query servers that are Server 2016 for the Local Administrator group, but will fail for servers that are on 2012. Which upon researching the error messages for cmdlets from Microsoft.Powershell.LocalAccounts indicates that the modules don't exist for 2012.
Rather than updating the PowerShell version, or installing the modules to each server, I wondering if it's possible to execute cmdlets from the local 2016 into remote sessions of the 2012 servers.
Technically, yes, you could copy modules from the local server to one of the module directories on the remote server's $env:PSModulePath and import them in the remote session, but as #mklement0 stated there is no guarantee current modules will work with PowerShell 4.0, let alone Server 2012.
That said, Microsoft.PowerShell.LocalAccounts is a module provided by PowerShell 5.1, not the OS, and the features should still work on 2012. However, I don't have a 2012 instance I can test with. But you may be able to get your task done by upgrading your servers' PowerShell version to PowerShell 5.1 (Windows Management Framework 5.1) to leverage the additional features and built-in modules this version brings. But any modules that are shipped with later Windows versions and not PowerShell itself will remain unavailable.
$localAdminUsers = net localgroup administrators
After some talking with a colleague, I realized I had overcomplicated my script, when I could have used the command prompt. From there, I parse the string for the users I was looking for.
Thank you for your responses.
So I've just read a lengthy explanation of the difference between PowerShell and PowerShell Core. Basically, the latter is the new name for all future versions of PowerShell, and it's now open source and cross-platform.
Alright. Good. But why does it have to be installed on Windows? Wouldn't the point be that it's already on Windows, but then you can also install it on Linux/macOS and use it the same way as on Windows?
Why is it an "installation" even on Windows? That part makes no sense to me. And it can't be explained by "it's just released", because it's apparently been several years already...
Powershell Core is the new Universal Powershell.
Windows Comes with "Windows Powershell" which was the predecessor to Powershell core and only runs on windows, and uses methods that are windows .net specific, instead of using the portable.net methods.
Powershell Core is being actively developed and enhanced, and is able to be run on Windows and Linux systems, but does not contain the Windows-specific methods as it is intended to be cross-platform, which leads to some incompatibilities.
Rather than continue to build and maintain separate flavors of Powershell in perpetuity, the Windows Powershell 5.1 functions will eventually fold into PowerShell core at some point in the future (possibly as early as version 7.0), and deprecated methods will need to be re-written to use the universal functions.
Last I read on this Redmond had predicted that Powershell Core 7.0 will essentially usurp the needs for Powershell 5.1 on Windows and will start being the pre-installed version of Powershell in Windows at some point thereafter. (So Probably Windows 2022 for Server folks)
I'm having trouble with installing PowerShell 5 on Windows Server 2012 R2 using Packer.
To install PowerShell 5.1, I'm using chocolatey
powershell
iwr https://chocolatey.org/install.ps1 -UseBasicParsing | iex
choco install PowerShell -y
I need to to do this for two packer builder:
Amazon Web Services EC2 AMI.
Hyper-V Vagrant.
With the Amazon Web Services EC2 AMI I've tried executing the above from the following locations
As part of the user_data_file script.
As an inline provision script.
I've added the windows-restart provision in the flow after the execution of the fragment.
Similarly I've tried the same with the Hyper-V Vagrant both as part of the Autounattend flow and as an inline provision.
In both cases the installation fails because the user profile is not created. At least I think that is the problem. As a reference, I've faced the exact same problem when installing sql server express.
Has anyone managed to accomplish this flow and what is your recommendation?
PowerShell package uses MSU (Windows Update file). There are a couple of considerations here:
Ensure Windows Updates Service is turned on. Chocolatey doesn't do that yet, although there is an issue filed.
MSUs must be run locally from the machine. So if you are running over WinRM, you instead need to have it set up a scheduled task to call choco install and then run it that way.
Yes, that second point is accurate. No, it is not Chocolatey's fault. That's a Microsoft design decision with MSU files. It's a real PITA.
FYI - BoxStarter handles it appropriately, and it can be used with Packer. You will find less pain if you look there.
HTH
The OS that I am using is Windows 7, and the PowerShell version that is installed here is 2.0. Is it possible for me to upgrade it to version 3.0 or 4.0?
Because there are cmdlets that version 2.0 can't recognize.
Download and install from http://www.microsoft.com/en-us/download/details.aspx?id=34595. You need Windows 7 SP1 though.
It's worth keeping in mind that PowerShell 3 on Windows 7 does not have all the cmdlets as PowerShell 3 on Windows 8. So you may still encounter cmdlets that are not present on your system.
The latest PowerShell version as of Sept 2015 is PowerShell 4.0. It's bundled with Windows Management Framework 4.0.
Here's the download page for PowerShelll 4.0 for all versions of Windows.
For Windows 7, there are 2 links on that page, 1 for x64 and 1 for x86.
Just run this in a console.
#powershell -NoProfile -ExecutionPolicy unrestricted -Command "iex ((new-object net.webclient).DownloadString('https://chocolatey.org/install.ps1'))" && SET PATH=%PATH%;%systemdrive%\chocolatey\bin
cinst powershell
It installs the latest version using a Chocolatey repository.
Originally I was using command cinst powershell 3.0.20121027, but it looks like it later stopped working. Since this question is related to PowerShell 3.0 this was the right way. At this moment (June 26, 2014) cinst powershell refers to version 3.0 of PowerShell, and that may change in future.
See the Chocolatey PowerShell package page for details on what version will be installed.
Install Chocolatey
Run the following commands in CMD
choco install powershell
choco upgrade powershell
As of today, Windows PowerShell 5.1 is the latest version. It can be installed as part of Windows Management Framework 5.1. It was released in January 2017.
Quoting from the official Microsoft download page here.
Some of the new and updated features in this release include:
Constrained file copying to/from JEA endpoints
JEA support for Group Managed Service Accounts and Conditional Access Policies
PowerShell console support for VT100 and redirecting stdin with interactive input
Support for catalog signed modules in PowerShell Get
Specifying which module version to load in a script
Package Management cmdlet support for proxy servers
PowerShellGet cmdlet support for proxy servers
Improvements in PowerShell Script Debugging
Improvements in Desired State Configuration (DSC)
Improved PowerShell usage auditing using Transcription and Logging
New and updated cmdlets based on community feedback
The latest PowerShell version as of Aug 2016 is PowerShell 5.1. It's bundled with Windows Management Framework 5.1.
Here's the download page for PowerShell 5.1 for all versions of Windows, including Windows 7 x64 and x86.
It is worth noting that PowerShell 5.1 is the first version available in two editions of "Desktop" and "Core". Powershell Core 6.x is cross-platform, its latest version for Jan 2019 is 6.1.2. It also works on Windows 7 SP1.
do use the links above. If you run into error "This update is not applicable to your computer. " then make sure you are in fact using the right file for your os. for example i tried running windows 2012 server from that link on windows 7 service pack 1 and I got the above error so be sure to use the right zip. If you don't know which os you have then go to start and system and it should pop right up This should be self explanatory but
Looking to use Powershell for writing some scripts. The concern is, do all users of the script need Powershell installed on their computer in order to have the script execute properly? Is the behavior different for Windows 7 vs. XP vs. 2k etc? I understand powershell is included in 8, so that's not a concern.
PowerShell is also included in Windows 7. PowerShell might be included in XP not sure on that. I'm pretty sure 2k does not have PowerShell. Yes, if you want to run a PowerShell script you will need to have PowerShell installed. Just like you would need Python installed if you want to run a Python script.
I know that Win 7 comes with PS version 2.0 by default. Not sure on XP. The current version is PS is 3.0 it comes with the Windows Management Framework (WMF) 3.0.
During December 2012 Microsoft had the WMF 3.0 deployed as an update but recalled it a couple of weeks later because there was some compatibly errors with other stuff.
I'm using PS 3.0 and updating all my computers to PS 3.0. PS add new stuff that I want to learn.