I am learning SharePoint and more specifically provisioning with PowerShell. I can't use cmdlets as Get-PnPProvisioningTemplate or Apply-PnPProvisioningTemplate, when execute them PS return that are not cmdlets. I don't know if I need to install something.
#Felipe,
These cmdlets are existed in legacy PnP but replaced by a new cmdlet in the current PnP.
Upgrading from the Legacy version of PnP PowerShell | PnP PowerShell
PnP PowerShell | PnP PowerShell
And the new corresponding cmdlet is:
Invoke-PnPSiteTemplate
More reference:
https://github.com/pnp/powershell/issues/285
BR
You need to follow the PnP.Powershell Documentation (https://github.com/pnp/powershell) that links you to the installation guide (https://pnp.github.io/powershell/articles/installation.html)
Basically you need to run Install-Module -Name "PnP.PowerShell" from a powershell console
Related
Im developing a script that connects to Exchange Online Microsoft 365, but when the script executes the cmdlet "Connect-ExchangeOnline", it ends with errors.
The specific instruction is:
Connect-ExchangeOnline -Organization $myTenant -AppId $AppId -Certificate $myCert
The variables in the parameters are correct, the error says:
New-ExoPSSession: Index was out of range. Must be non-negative and less than the size of the collection. Parameter name: index
I can load the module succesfully. The script connects to Exchange Online trough a cert installed in my machine, my script can read it without issues.
I'm running this script in Powershell V4 and .Net Framework 4.7.1. If i execute the same script in another machine with PowerShell V5.1 I can connect to Microsoft 365 Exchange Online succesfully. I tried with a lower version (ExchangeOnlineManagement 1.0.1) but this version hasn't got those parameters (Organization, AppId, etc...), I'm now using 2.0.3 version. I not sure if you can upgrade Powershell to 5.1.
Does anyone know why i can't connect to Exchange Online?
I've been struggling with this issue, and I finally found a solution.
Turns out running Import-Module ExchangeOnlineManagement before Connect-ExchangeOnline causes this error.
Removing Import-Module ExchangeOnlineManagement was enough to allow Connect-ExchangeOnline to connect without the New-ExoPSSession: Index was out of range error
EXO V2 is only supported on PowerShell 5.1 and later. If you want to use PowerShell 4.0 you will have to use EXO V1.
I'm not familiar enough with the EXO module to how or whether you can use EXO V1 in your current environment. If V2 is required for modern Exchange Online management then you will need to upgrade your nodes to use WMF 5.1 or install PowerShell Core (7+) and use EXO V2 from there.
PowerShell Core installs in parallel to Windows PowerShell so there is less of a risk of impacting other code which requires PowerShell 4.0 if you go this route.
I am using Windows PowerShell 5.1 and this seems to be an issue that's introduced in ExchangeOnlineManagement version 2.0.4.
Downgrading to 2.0.3 worked for me.
PowerShell needs to be started in elevated mode. However, my error was caused by RunAs with a domain admin account. Using RunAs with a local admin account works. YMMV.
I'm trying to update a PS5 script to PS7, mainly because the script does work that requires a PS Core module.
Part of the script involved updating IIS bindings to use a different SSL Certificate. The cert is in the store and ready to be used - I just need to change the thumbprint on the binding.
My PS5 script used Get-WebConfiguration to get the bindings and then just looped through, calling RebindSslCertificate on relevant bindings.
I've tried using Set-WebConfigurationProperty and Set-WebBinding; neither errors but neither actually updates the binding with IIS - example:
Set-WebConfigurationProperty -Name 'certificateHash' -Value $newCert.Thumbprint -PSPath "IIS:\\" `
-Filter "/system.applicationHost/sites/site/bindings/binding[#protocol='https'][#bindingInformation='*:443:hostname']" `
Could anyone help point me in the right direction for what I'm missing?
Thanks,
Mark.
P.S., Apologies if this is a repeat question but all I can find is old stuff that doesn't work or relates to "-Set-Item IIS:\SslBindings" Maybe there is someway to get the IIS drive working with remoting?
Ran into this on 9/10/2021 using Powershell 7.1.4.
As of date of writing, this is an open issue on github for PowerShell.
Link for reference: https://github.com/PowerShell/PowerShellModuleCoverage/issues/14
Issue is that PowerShell 7 is based on .NET Core and the PS module WebAdministrator is based on .NET Framework.
When you run
Import-Module WebAdministration
WARNING: Module WebAdministration is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell please use 'Import-Module -SkipEditionCheck' syntax.
Notice the mention of 'WinPSCompatSession' in the warning. If the module manifest doesn't indicate that the module is compatible with PowerShell Core, then it gets loaded via the Windows PowerShell Compatibility Feature.
It seems this module partially works in compatibility mode, however if you try to work with IIS:\ then you start getting errors.
Alternatively, if you run the parameter in the warning you get this.
Import-Module -SkipEditionCheck WebAdministration
Import-Module: Could not load type 'System.Management.Automation.PSSnapIn' from assembly 'System.Management.Automation, Version=7.1.4.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35'.
A quick test in PowerShell 7.1.4 will show you that you can't access the IIS connector.
PS C:\Windows\System32> Import-Module WebAdministration
WARNING: Module WebAdministration is loaded in Windows PowerShell using WinPSCompatSession remoting session; please note that all input and output of commands from this module will be deserialized objects. If you want to load this module into PowerShell please use 'Import-Module -SkipEditionCheck' syntax.
PS C:\Windows\System32> cd IIS:\
Set-Location: Cannot find drive. A drive with the name 'IIS' does not exist.
However, if you open up PowerShell 6 you can do this no problem.
PS C:\WINDOWS\system32> Import-Module WebAdministration
PS C:\WINDOWS\system32> cd IIS:\
PS IIS:\> dir
Name
----
AppPools
Sites
SslBindings
My next step is trying to get this to work by loading the .NET assembly directly. Will update with the solution
[System.Reflection.Assembly]::LoadFrom("$env:systemroot\system32\inetsrv\Microsoft.Web.Administration.dll")
So, I'm looking to do some powershell automation now that my company is clamoring for Microsoft Teams. I installed the module version 1.0.5 (currently the latest) and I'm seeing documentation on how to add users to team channels.
I get cmdlet not found errors when using those commandlets
Get-TeamChannelUser : The term 'get-teamchanneluser' is not recognized as the name of a cmdlet, function, script file...
Low and behold, get-command -module MicrosoftTeams returns no cmdlets with TeamChannelUser (Get, Remove or Set).
I've tried older versions of the module but I'm still seeing the same symptom. Is anyone else able to reproduce this? Any workarounds?
I haven't tested this specifically, but have you looked into the new (pre-release) Microsoft Graph PowerShell module? It includes a lot of "Teams" functions, but also of course more broad "Graph" capabilities, which is important (recall that Teams relies on SharePoint, Groups, etc.).
I had to manually install a test version 1.0.21, but now when I run the Get-Command, I see the ChannelUser cmdlets.
Thanks to Hilton Giesenow, I'm going to try his suggestion as well and will mark it as the answer if it works better and post an update.
I struggled to get this working. I ended up installing 1.1.3.
This is what worked for me:
PS C:\WINDOWS\system32> Install-Module -Name MicrosoftTeams -RequiredVersion 1.1.3-preview -AllowPrerelease -force -AllowClobber
PS C:\WINDOWS\system32> Import-Module microsoftteams
PS C:\WINDOWS\system32> get-command -Module microsoftteams
PSCommand commandToRun = new PSCommand();
commandToRun.AddCommand("Connect-MsolService");
commandToRun.AddParameter("Credential", new PSCredential(msolUsername, msolPassword));
powershell.Streams.ClearStreams();
powershell.Commands = commandToRun;
powershell.Invoke();
I am trying to run above code in visual studio and getting the following error :
The term 'Connect-MsolService' 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.
But I am able to Connect to Msol service from Microsoft Azure Active Directory Module for Windows PowerShell. Please help.
I had to do this in that order:
Install-Module MSOnline
Install-Module AzureAD
Import-Module AzureAD
All links to the Azure Active Directory Connection page now seem to be invalid.
I had an older version of Azure AD installed too, this is what worked for me.
Install this.
Run these in an elevated PS session:
uninstall-module AzureAD # this may or may not be needed
install-module AzureAD
install-module AzureADPreview
install-module MSOnline
I was then able to log in and run what I needed.
This issue can occur if the Azure Active Directory Module for Windows PowerShell isn't loaded correctly.
To resolve this issue, follow these steps.
1.Install the Azure Active Directory Module for Windows PowerShell on the computer (if it isn't already installed). To install the Azure Active Directory Module for Windows PowerShell, go to the following Microsoft website:
Manage Azure AD using Windows PowerShell
2.If the MSOnline module isn't present, use Windows PowerShell to import the MSOnline module.
Import-Module MSOnline
After it complete, we can use this command to check it.
PS C:\Users> Get-Module -ListAvailable -Name MSOnline*
Directory: C:\windows\system32\WindowsPowerShell\v1.0\Modules
ModuleType Version Name ExportedCommands
---------- ------- ---- ----------------
Manifest 1.1.166.0 MSOnline {Get-MsolDevice, Remove-MsolDevice, Enable-MsolDevice, Disable-MsolDevice...}
Manifest 1.1.166.0 MSOnlineExtended {Get-MsolDevice, Remove-MsolDevice, Enable-MsolDevice, Disable-MsolDevice...}
More information about this issue, please refer to it.
Update:
We should import azure AD powershell to VS 2015, we can add tool and select Azure AD powershell.
Following worked for me:
Uninstall the previously installed ‘Microsoft Online Service Sign-in Assistant’ and ‘Windows Azure Active Directory Module for Windows PowerShell’.
Install 64-bit versions of ‘Microsoft Online Service Sign-in Assistant’ and ‘Windows Azure Active Directory Module for Windows PowerShell’.
https://littletalk.wordpress.com/2013/09/23/install-and-configure-the-office-365-powershell-cmdlets/
If you get the following error In order to install Windows Azure Active Directory Module for Windows PowerShell, you must have Microsoft Online Services Sign-In Assistant version 7.0 or greater installed on this computer, then install the Microsoft Online Services Sign-In Assistant for IT Professionals BETA:
http://www.microsoft.com/en-us/download/details.aspx?id=39267
Copy the folders called MSOnline and MSOnline Extended from the source
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\
to the folder
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\Modules\
https://stackoverflow.com/a/16018733/5810078.
(But I have actually copied all the possible files from
C:\Windows\System32\WindowsPowerShell\v1.0\
to
C:\Windows\SysWOW64\WindowsPowerShell\v1.0\
(For copying you need to alter the security permissions of that folder))
Currently I'm working on Windows Server 2012 R2 with Powershell 4.0 and can execute Get-Process -IncludeUserName while using elevated user rights as an admin. But when I try running the same command on a Windows Server 2008 R2 with Powershell 3.0 while using the same elevated user rights, the parameter -IncludeUserName isn't found. What's missing on the 2nd system for executing the command?
According to the Technet Article for get-process the -IncludeUserName parameter was not available in the get-process cmdlet until Powershell 4. You'll need to install the updated version in order to gain access to that feature.
It seems the difference between V3 and V4 is that V4 brings the additional ability to include the username of the process.
I don't have V3 to test with, but I do have V2, and it's not available there.