I am relying on the Powershell cmdlet Apply-PnPProvisioningTemplate to automate deployment of Sharepoint-Templates to new sites.
Have always used the "SharePointPnPPowerShellOnline" Powershell module where it exists, but when importing it, it said that it's about to be retired.
WARNING: You are running the legacy version of PnP PowerShell. This
version will be archived soon which means that while staying
available, no updates or fixes will be released. Consider installing
the newer prereleased cross-platform version of PnP PowerShell:
Uninstall-Module -Name SharePointPnPPowerShellOnline -AllVersions
-Force Install-Module -Name PnP.PowerShell -AllowPrerelease
Read more about the new cross-platform version of PnP PowerShell at
https://pnp.github.io/powershell
The new version of PnP PowerShell will be released as 1.0 in January
2021.
*The problem is that the new module doesn't seem to include any of the -PNPProvisioningTemplate cmdlets.
Anyone know how to apply a pnpprovisioning template now or has the cmdlets been renamed?
There is also a bug with the Apply-PnPProvisioningTemplate cmdlet in the SharePointPnPPowerShellOnline module, that forces me to use a very old version 3.23.2007.1... But now I know that that bug will never be fixed.
Take a look
https://github.com/pnp/powershell/issues/179#issuecomment-767683904
It states that you should use
Invoke-PnPSiteTemplate
Related
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.
I am using PowerShell 6.2 preview at the moment. In my script I am trying to do stuff with Windows 10 apps. To be able to use commands like Get-AppxPackage, I need to import Windows modules from previous PowerShell like so:
Import-Module C:\Windows\system32\WindowsPowerShell\v1.0\Modules\Appx\Appx.psd1 -SkipEditionCheck
Import-Module C:\Windows\system32\WindowsPowerShell\v1.0\Modules\dism\dism.psd1 -SkipEditionCheck
Does PowerShell core has its own modules to work with this? I found Get-Package for example, but that does not give me anything.
Since this is one of the top search results for PowerShell Core Get-AppxPackage, I'm going to take the information from the link provided in the comments and provide an answer, with example.
As LangsGalgEnRad pointed out in the comments, it's easiest just to do this from Windows PowerShell, but ultimately that's just-shy-of-deprecated at this point, with Microsoft stating that there are to be no more fixes or changes other than critical security issues. That said, it's still (afaik) universally available in Windows installations.
But for those of us who want to follow Microsoft's advice to use PowerShell Core, LangsGalgEnRad also points out in the comments the WindowsCompatibility module from Microsoft. Reading the blog post, this seems a bit safer than importing a Windows module (e.g. AppX) from PowerShell Core, since among other things ...
WindowsCompatibility is very careful to not overwrite native PowerShell core commands.
To install from PowerShell Gallery:
Install-Module WindowsCompatibility
Example usage for AppX:
Import-Module WindowsCompatibility
Import-WinModule AppX
Get-AppxPackage
I see in powershell gallery that there is a newer version of the iisadministration module than the one that shipped with Server 2016.
I got it installed using:
install-module -name IISadministration -scope currentuser -verbose -force -SkipPublisherCheck
I now have two versions, the newer one installed for the currentuser and the original that shipped with the OS.
Import-Module IISAdministration was successful and so was explicitly specifying the psd1 path. However, when I try to use New-IISSiteBinding (included in the newer version), it complains that the cmdlet is not recognized.
Article referencing the new cmdlt
https://blogs.iis.net/iisteam/introducing-iisadministration-in-the-powershell-gallery
Can anyone please help? Thanks
I have created virtual machine in Azure and selected Windows Server 2012 R2.
I have installed windows PowerShell using the Web platform installer. When I try to run the following command:
Save-AzureRmProfile -Path C:\MyPath\myfile.json
It throws the error:
The term 'Save-AzureRmProfile' 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.
I have tried to follow this link here by adding environments variables but no help. Has anyone solved this issue?
Save-AzureRmProfile works on version 3.7. You could use the following cmdlet to check Azure PowerShell version.
Get-Module -ListAvailable -Name Azure -Refresh
You could download 3.7 version msi installer from this link.
You have to Install the Azure PowerShell cmdlets. I suggest you to install it using the latest MSI from this site.
It looks like the Save-AzureRmProfile cmdlet has been replaced by Save-AzureRmContext. I found that information here.
The name of the cmdlet was changed in 4.0, you can see all the changes in 4.0 here: https://github.com/Azure/azure-powershell/blob/preview/documentation/release-notes/migration-guide.4.0.0.md
Unfortunately, the name of the cmdlet was changed without an alias for backward compatibility in version 3.8, per this issue: . This is actually a bug we will be pushing out a version 3.9 which is identical to 3.8, except that the two profile cmdlets (Save-AzureRmProfile, Select-AzureRmProfile) remove this breaking change
Save-AzureRmContext and Import-AzureRmContext can be used for same purpose on Version 4.0
Usage is same!
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