I have two different revision of PowerShell in different machines. The local one have the following one:
Major
Minor
Build
Revision
5
1
17763
1007
And the virtual machine has the following one:
Major
Minor
Build
Revision
5
1
17763
771
As you can see that it has the same: Major, Minor, and Build values except the Revision values. I am not sure if it is behind the failure of the command:
Register-PSRepository -Name $RepoKeyName -SourceLocation $RepoKeyValue
-PublishLocation $RepoKeyValue -InstallationPolicy Trusted -Verbose
The above snippet works fine on the local machine but not on the virtual machine and it fails in the virtual machine with the following error:
parameter 'SourceLocation' is an invalid Web Uri. Please ensure that it meets the Web Uri requirements.
And this is why I want to update the PowerShell in the virtual machine to the latest revision value. How to do it?
If you have Microsoft's winget app (Windows package manager), you can run the following command to update to the most recent version of PowerShell:
winget install Microsoft.PowerShell
If you're running Windows 11 or have updated App Installer in Windows 10.
Update PowerShell using Windows Package Manager (winget)
winget upgrade Microsoft.PowerShell
You also can install PowerShell by using below command via winget
winget install Microsoft.PowerShell
Learn more:
winget in Microsoft Docs
winget in GitHub repository
Run the following command from command prompt wait till gets downloaded, and it will prompt to installation wizard follow the instructions to install it.
Invoke-Expression "& { $(irm https://aka.ms/install-powershell.ps1) } -UseMSI"
You can never update Windows PowerShell installations on demand - except, in the past, if you upgraded to a new major version, but v5.1 is the last version that will ever be released, given that Windows PowerShell is in maintenance-only will see no new development, unlike its successor, the cross-platform PowerShell (Core) 7+ edition.[1]
Note:
While switching to the PowerShell (Core) edition[1] - where all future development effort will go - is advisable in general, doing so is not something to be done casually and requires a deliberate decision:
PowerShell (Core) is mostly, but not fully backward-compatible with Windows PowerShell, and certain cmdlets are unavailable, except via a compatibility feature that has its limitations both in terms of performance and type fidelity.
PowerShell (Core) is installed alongside Windows PowerShell and has different CLI (pwsh.exe rather than powershell.exe) and different SDKs (see this answer); also, targeting PowerShell (Core) via PowerShell remoting requires explicit configuration - see this answer.
Windows PowerShell-specific considerations:
Revisions of v5.1 are delivered as part of Windows updates.
However, you can selectively update the PowerShellGet module, in which the problem-causing Register-PSRepository command is defined:
While you normally would just run Update-Module PowerShellGet, a different approach is required the first time, when switching from the bundled PowerShellGet module to the latest version from the PowerShell Gallery:
Open an elevated session (Run as Administrator).
Execute the following (add -Verbose to get detailed information):
Install-Module PowerShellGet -Force
The -Force is to enable installation even though a module by that name is already installed; you may still see a prompt about downloading the NuGet package provider.
Note that the old PowerShellGet version will linger in a different location, but the new one will take precedence over it.
After this initial switch to the gallery-installed version, you'll be able to use
Update-Module PowerShellGet for future versions.
You can use the Get-Command cmdlet to discover a given command's module of origin; e.g.:
PS> (Get-Command Register-PSRepository).Module
ModuleType Version PreRelease Name ExportedCommands
---------- ------- ---------- ---- ----------------
Script 2.1.4 PowerShellGet {Find-Command, Find-DscResource, Find-Module, Find-RoleCapability…}
[1] PowerShell (Core) 7+ versions can be updated on demand - however, as of v7.2.x, PowerShell (Core) doesn't come with Windows and initially requires manual installation. However, you can now install and update it via the Microsoft Store application or, programmatically, using winget.exe (which comes with the App Installer Microsoft Store application, which recent versions of Windows ship with):
Initial installation:
winget install Microsoft.PowerShell
Later upgrade:
winget upgrade Microsoft.PowerShell
Note: Use Microsoft.PowerShell.Preview to install / upgrade the latest preview version instead.
Solution1:
Go to this link:
https://github.com/PowerShell/PowerShell/releases/
Find Assets and click on Assets word.
Download and install .msi link.
Solution2:
Go to this link for download Windows Package Manager:
https://github.com/microsoft/winget-cli/releases
Find Assets and click on Assets word.
Download : Microsoft.DesktopAppInstaller_8wekyb3d8bbwe.msixbundle
Execute the downloaded file and click on update.
Open your command prompt or powershell and execute this command on it:
winget install Microsoft.PowerShell
If you have Mircrosoft.PowerShell execute this command:
winget upgrade Microsoft.PowerShell
For figure out your powershell version: execute host command in your powershell.
Related
When I run a powershell script, I get the following warning:
WARNING: Multiple variants of AWS Tools for PowerShell (AWSPowerShell,
AWSPowerShell.NetCore or AWS.Tools) are currently installed. Please
run 'Get-Module -Name
AWSPowerShell,AWSPowerShell.NetCore,AWS.Tools.Common -ListAvailable'
for details. To avoid problems with cmdlet auto-importing, it is
suggested to only install one variant. AWS.Tools is the new
modularized version of AWS Tools for PowerShell, compatible with
PowerShell Core 6+ and Windows Powershell 5.1+ (when .NET Framework
4.7.2+ is installed). AWSPowerShell.NetCore is the monolithic variant that supports all AWS services in a single large module, it is
compatible with PowerShell Core 6+ and Windows Powershell 3+ (when
.NET Framework 4.7.2+ is installed). AWSPowerShell is the legacy
module for older systems which are either running Windows PowerShell 2
or cannot be updated to .NET Framework 4.7.2 (or newer).
Screenshot:
How do I fix the warning? Do I uninstall one or 2 of these modules? Which ones?
Going purely by the error message:
How do I fix the warning?
You ensure that only one of the three listed module (groups) is installed:
Modern, modular group of related modules:
AWS.Tools.*, core module is AWS.Tools.Common, installation-helper module is AWS.Tools.Installer
Legacy modules (monolithic):
AWSPowerShell
AWSPowerShell.NetCore
Do I uninstall one or 2 of these modules? Which ones?
Yes. Which ones to uninstall and thereby implicitly which one to keep depends on your needs and which powershell version you have:
(a) If you're running Windows PowerShell 5.1 and have .NET Framework 4.7.2+ installed, or you're running PowerShell (Core), keep the AWS.Tools.* modules.
(b) If you're still running Windows PowerShell 3 or 4, and have .NET Framework 4.7.2+ or higher installed, keep the AWSPowerShell.NetCore module.
(c) If you're still running Windows PowerShell 2 or a higher version, but cannot install .NET Framework 4.7.2+, keep the legacy AWSPowerShell module.
For instance, to go with (a):
Note
To be safe, run with elevation (as admin), so that removal of modules that were installed in the AllUser scope can be removed.
Any non-installed modules among the specified ones are quietly ignored.
Start a new PowerShell session afterwards (modules already imported in the current session remain in memory, even after uninstallation; however, you can also remove them individually from memory with Remove-Module).
Get-Module -ListAvailable AWSPowerShell, AWSPowerShell.NetCore |
Uninstall-Module -Force
I'm trying to take advantage of the PowerShell Gallery which requires Install-Module. For some reason I cannot get this to work on any computer I have access to:
Install-Module: The term 'Install-Module' is not recognized as a name of a cmdlet, function, script file, or executable program.
I tried this on a Windows 8.1, Windows 10 and even installed PowerShell 7.1 on the Windows 10 computer. I see that a lot of people have this issue, but other than installing WMF (which seems to already be included with Win10) I don't see any useful suggestions.
I don't have a lot of experience with PowerShell, and definitely not managing it, so I'm curious if anybody has an idea as to why this is not working.
Edit 1:
I seem to have the PowerShellGet module in the following directories:
C:\Program Files\WindowsPowerShell\Modules
C:\Program Files\PowerShell\7\Modules
and the $env:PSModulePath variables contains C:\Program Files\PowerShell\Modules;c:\program files\powershell\7\Modules;C:\Program Files\WindowsPowerShell\Modules;C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules
Edit 2:
This may be related to the __PSLockDownPolicy environment variable, that was set to 4 on all of the affected computers. I was able to figure this out by attempting to manually load the PowerShellGet module, which yielded an error that hinted at this.
After removing that environment variable, it seems to work.
As you've discovered yourself, it was the presence of machine-level environment variable __PSLockDownPolicy that prevented Install-Module from running (see below for general prerequisites).
This undocumented environment variable, effective on Windows only, is for security reasons only respected if defined at the machine level via the registry (rather than as a per-user or process-specific variable) and can be used to restrict what is allowed in a PowerShell session.
Values 4 through 7 result in PowerShell operating in constrained language mode, where only a handful of pre-approved .NET types may be used, which as a result prevents the PowerShellGet module that contains the Install-Module from loading - see the conceptual about_Language Modes help topic.
You can check what language mode is in effect in a given session by executing $ExecutionContext.SessionState.LanguageMode; in constrained mode, the result is ConstrainedLanguage; FullLanguage indicates that no language restrictions are in place.
Looking at PowerShell's source code, the fact that this variable is checked inside a method named GetDebugLockdownPolicy() suggests that it isn't officially supported.
For more information, see this archived blog post.
The simplest way to remove this restriction is to delete the environment variable, by running the following from an elevated PowerShell prompt:
Remove-ItemProperty 'HKLM:\SYSTEM\CurrentControlSet\Control\Session Manager\Environment' __PSLockdownPolicy
One mystery remains:
As you state, importing the PowerShellGet module explicitly, with Import-Module PowerShellGet showed you that the real problem was not that the Install-Module command didn't exist, but that its enclosing module failed to load.
Doing so revealed that yet another module was the problem, namely the PackageManagement module that PowerShellGet depends on; Import-Module PackageManagement finally reveals: Cannot set property. Property setting is supported only on core types in this language mode, which implies that the (constrained) language mode was the problem.
The mystery is the error message reported in your question: Install-Module: The term 'Install-Module' is not recognized as a name of a cmdlet, function, script file, or executable program.
I see a different error message, both in Windows PowerShell 5.1 and PowerShell (Core) 7.1.2, when the constrained language mode is in effect, i.e. when $ExecutionContext.SessionState.LanguageMode reports ConstrainedLanguage:
Install-Module: The 'Install-Module' command was found in the module 'PowerShellGet', but the module could not be loaded. For more information, run 'Import-Module PowerShellGet'.
This error message makes it more obvious what the problem is, and would probably have led to a faster diagnosis.
The following contains general information that is unrelated to the above:
Installing / troubleshooting of the PowerShellGet module that provides the Install-Module command:
Install-Module is a (function-based) cmdlet that comes with Windows PowerShell 5.0 and 5.1 as well as all versions of PowerShell (Core) (v6+), as part of the PowerShellGet module.
If your computers do meet these criteria, the implication is that your PowerShell installation has been corrupted in one or both of the following ways:
The PowerShell get module was removed (or renamed) from its default location
(C:\Program Files\WindowsPowerShell\Modules\PowerShellGet in Windows PowerShell,
C:\Program Files\Powershell\7\Modules\PowerShellGet in PowerShell (Core) 7.x, on Windows).
Either reinstall PowerShell or try the manual installation instructions linked to below.
The $env:PSModulePath environment variable is missing an entry for the parent directory of the respective default location (that is,
C:\Program Files\WindowsPowerShell\Modules /
C:\Program Files\PowerShell\7\Modules). Without this entry, PowerShell cannot find the PowerShellGet module (by name only).
Manually update the machine-level definition of environment variable PSModulePath via sysdm.cpl, tab Advanced, button Environment Variables... to include the applicable directory.
If your computers do not meet these criteria, you have two choices:
If you can, upgrade the Windows PowerShell version to v5.1 or switch to PowerShell (Core).
Alternatively - if your Windows PowerShell version is 3 or 4 - install PowerShellGet manually, as per the official instructions.
Note: You may have to have access to at least one computer that already has a functioning copy of PowerShellGet to source the manual installation from.
I just started writing scripts in PowerShell.
The desired script is supposed to create a local GroupPolicyObject (GPO) which will be specified afterwards. Research showed that it could be done with the New-GPO command within the GroupPolicy module for PowerShell. I tried to install the mentioned module but unfortunately nothing I found worked. May I ask for help?
I am using Windows 7 and Powershell 5.1.14409.1005
Error I receive when running example from Microsoft page (New-GPO -Name TestGPO -Comment "This is a test GPO."):
It is actually extremely simple, but the organization of the modules and features has changed many times in the past ten years, Microsoft Docs don't document the up-to-date way anywhere and all articles found online are very old.
Anyway, to install the Powershell Module called GroupPolicy, you need to install the Windows Feature called GPMC (Group Policy Management Console) which includes the mentioned module.
Install-WindowsFeature GPMC
This feature was once a subfeature of the RSAT feature, which is the cause of confusion.
Step 1. Install RSAT from Microsoft site:
https://www.microsoft.com/en-in/download/details.aspx?id=7887
Step 2. Enable Group Policy from Windows Features.
Following link describes the steps in details:
https://www.powershellmagazine.com/2012/05/14/managing-group-policy-with-powershell
Have you installed the RSAT (Remote Server Administration Tools) Group Policy component?
Trying to set up my VSTS windows build agent to accommodate for powershell steps within VSTS but having some problems. Initially it reported that the AzurePS system capability was not present, so I made sure to install the latest Azure modules via the powershell gallery. Now, the AzurePS capability is present but certain powershell commands do not seem to work.
This may not be related to VSTS at all but rather just a configuration issue with my specific powershell installation / configuration. The full error is as follows:
The term 'Select-AzureRMSubscription' is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the path is correct and try again.
This error can be seen both in the VSTS release logs of the particular definition I am trying to execute, as well as when attempting to run the Select-AzureRMSubscription command directly on the box itself.
According to This MS Docs for Get-AzSubscription it's located in the module Az.Accounts.
So I had to run:
Install-module Az -AllowClobber -Force
Import-module Az
to make the command avaliable to me.
For me, updating the AzureRM module did the trick:
Update-Module -Name AzureRM
Depending on your system, you may get some messages while installing
Powershell requires NuGet provider version '2.8.5.201' or newer to
interact with NuGet-based repositories. The NuGet provider must be
available in 'C:\Program Files\PackageManagement\ProviderAssemblies'
or
'C:\Users\<...>\AppData\Local\PackageManagement\ProviderAssemblies'.
You can also install the NuGet provider by running
Install-PackagePovider -Name NuGet -MinimumVersion 2.8.5.201 -Force'.
Do you want PowerShellGet to install and import the NuGet provider
now?
[Yes] {No] [Suspend]
Choose "Yes"
You are installling the modules form an untrusted repository. If you
trust this repository, change its installationPolicy value by running
the Set-PSRepository cmdlet. Are you sure you want to install the
modules from 'PSGallery'?
[Yes] [Yes to All] [No] [No to All] [Suspend]
Choose "Yes to all"
Up to three modules will be installed/updated and directly after that, the Select-AzureRmSubscription should work immediately.
Select-AzureRmSubscription b0cabaca-1234-1337-abcd-bebedada1337
# note: this subscription GUID is completely fictional.
# To get the correct one, query your subscriptions with
# Get-AzureRmSubscription
You have to make sure that certain Azure Powershell modules are installed for certain cmdlets to work. You can check which modules are available by running Get-Module -ListAvailable. Select-AzureRMSubscription requires AzureRM module.
You could just install Azure Powershell with its modules using webPI - I've never had problems using it and I've heard that installing PS modules using gallery could cause problems (see here).
You can run azure PowerShell with Azure PowerShell step/task.
Edit your build definition
Click Add build step
Select Deploy catalog > Add Azure PowerShell step/task
the OS in question is server 2012
To install PowerShell on windows server 2012, we should add the .NET Framework 3.5 feature and add the windows PowerShell 2.0 Engine feature.
About how to add features, refer to the link.
Then we can download PowerShell installation package, and install it.
Then we can use windows server 2012 PowerShell to login azure.
You need to use the Set-AzContext,
Select-AzSubscription -SubscriptionName 'SubName' | Set-AzContext
I want to write a script which cleans up all existing versions of Python on a machine, and a separate script to re-install both versions 2.7 and 3.5 in standardized locations. I'm currently trying to do this using the Package Management cmdlets in PowerShell 5.1.14393.187.
For the cleanup script, I started with PowerShell's package commands:
Get-Package "*python*" | Uninstall-Package
Which, when run from an admin console, seems to work nicely, but on further investigation leaves some packages remaining...
PS C:\WINDOWS\system32> Get-Package "*python*"
Name Version Source ProviderName
---- ------- ------ ------------
Python 3.5.1 (64-bit) 3.5.1150.0 Programs
Python 3.5.1 pip Bootstrap ... 3.5.1150.0 msi
Python 3.5.1 Tcl/Tk Support... 3.5.1150.0 msi
Python 2.7.11 2.7.11150 msi
Python 3.5.2 pip Bootstrap ... 3.5.2150.0 msi
Python 3.5.2 (32-bit) 3.5.2150.0 Programs
Why are these packages still present after Uninstall-Package? Is there a best-practice way to do this? Is there a best-practice way to script Python's re-installation so this won't happen again?
Update
I've had some success in cleaning up the majority of this by using the control panel GUI to first repair and then uninstall the Python 3 installations. I'm surprised there is no Repair-Package command to go with Get-Package.
Once the other parts of Python 3 were repaired, there was one MSI package called "Python Launcher", and the Python 2.7 MSI package remaining reported by Get-Package, but nothing in the GUI. At this point Uninstall-Package on the "Python Launcher" succeeded with a warning that a reboot was required. No such luck with msi:Python 2.7.11/2.7.11150.
Additional information:
I think Chocolatey v0.10.1 may have contributed to the current situation. At least some of the machines may have had python installed using chocolaty from the public repository. On the same machine above, I've also tried this:
PS C:\WINDOWS\system32> choco uninstall python
Chocolatey v0.10.1
Uninstalling the following packages:
python
python is not installed. Cannot uninstall a non-existent package.
Chocolatey uninstalled 0/1 packages. 1 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
Failures
- python - python is not installed. Cannot uninstall a non-existent package.
Did you know the proceeds of Pro (and some proceeds from other
licensed editions) go into bettering the community infrastructure?
Your support ensures an active community, it makes you look smarter,
plus it nets you some awesome features!
https://chocolatey.org/compare
PS C:\WINDOWS\system32> choco uninstall python3
Chocolatey v0.10.1
Uninstalling the following packages:
python3
python3 v3.5.1
Skipping auto uninstaller - No registry snapshot.
python3 has been successfully uninstalled.
Chocolatey uninstalled 1/1 packages. 0 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
PS C:\WINDOWS\system32> choco uninstall python2
Chocolatey v0.10.1
Uninstalling the following packages:
python2
python2 v2.7.11
Running auto uninstaller...
Skipping auto uninstaller - The application appears to have been uninstalled already by other means.
python2 has been successfully uninstalled.
Chocolatey uninstalled 1/1 packages. 0 packages failed.
See the log for details (C:\ProgramData\chocolatey\logs\chocolatey.log).
PS C:\WINDOWS\system32> get-package "*python*"
Name Version Source ProviderName
---- ------- ------ ------------
Python 3.5.1 (64-bit) 3.5.1150.0 Programs
Python 3.5.1 pip Bootstrap ... 3.5.1150.0 msi
Python 3.5.1 Tcl/Tk Support... 3.5.1150.0 msi
Python 2.7.11 2.7.11150 msi
Python 3.5.2 pip Bootstrap ... 3.5.2150.0 msi
To answer this question I'm going to highlight a couple of points for you to consider.
Until official support has been announced, don't use the non-official PowerShell PackageManagement provider for Chocolatey. It is an unsupported preview subject to bugs and security flaws (it was also not created by the Chocolatey team). Instead use choco.exe, or another official provider.
AutoUninstaller is the resource in official Chocolatey clients that can remove natively installed software from packages that do not contain an uninstall script. It's important to note that you also need to install from those official clients. More information at https://chocolatey.org/docs/commands-uninstall
Why are these packages still present after uninstall-package?
It really depends on what you used to install the packages and whether Chocolatey was able to capture a snapshot for auto uninstaller.
Many packages do not require an uninstall script. Some do. When they are an MSI and are upgraded outside of Chocolatey (like Chrome does automatically), you either need Package Synchronizer or an uninstall script to uninstall the software.
Is there a best-practice way to do this?
If this is for organizational use, and you have a low tolerance for breakages, we recommend you build your own internal packages. Then you can completely control the process and have a repeatable, reliable process. This is how hundreds of organizations that use Chocolatey currently have enhanced their installation processes. They typically already have software installers already present on some internal file share and build packages around them to take advantage of better automation processes (versus old batch files they may have been using, or worse, manually installing from).
If you are curious on why you should build your own, see https://chocolatey.org/docs/community-packages-disclaimer (it attempts to highlight the issues with a public repository and it being subjected to distribution rights, something an internal repository is not subject to).
Is there a best-practice way to script python's re-installation so this won't happen again?
Use a configuration management tool like Puppet, Chef, Ansible, or DSC with the Chocolatey provider. https://chocolatey.org/docs/features-infrastructure-automation
This is how you create automation across all of your machines and take advantage of package management.