Has anyone managed to use this module with success, i'm running 32bit Windows 7, where i have opened an administrator shell using run as administrator, i have imported the WebAdministration module and then attempted to use the commands with some issues, have provided two examples here
Websites
I created a web site with the following command
new-website -name testsite -port 80 -hostheader testsite -physicalpath c:\temp
Then i attempted to get the sites details using the command
get-website -name testsite
but it always returns all sites, seems to ignore the -name parameter. Only way i can get the site is using a filter
get-website | ? { $_.name -eq 'testsite' } | get-member
When i use appcmd it works as expected using the following command
C:\> C:\Windows\System32\inetsrv\appcmd.exe list site testsite
AppPools
When i try to list the apppools using the following command
dir iis:\apppools
i get the following error
Get-ChildItem : Access is denied. (Exception from HRESULT: 0x80070005 (E_ACCESSDENIED))
Yet when i use appcmd as follows i get all the apppools as expected without any error
C:\Windows\System32\inetsrv\appcmd.exe list apppool
Has anyone successfully managed to use the WebAdministration module ?
Thanks in advance
Pat
If you are already running PowerShell as an administrator and have Windows UAC disabled and you are still seeing this error, make sure WAS (Windows Process Activation Service) is running. You can stop W3SVC but PowerShell will definitely give the same head-scratching "access denied" error if WAS is stopped.
You need to make sure that the PowerShell window is running elevated, try right-clicking in the Start Menu and using the "Run as administrator" option to ensure it runs elevated.
Regarding Get-Website ignoring the -Name parameter, this appears to be a bug according to this forum post. The workaround is to use Get-Item
$website = "Default Web Site"
Get-Item "IIS:\sites\$website"
Be sure to use double quotes, variables are not expanded when single quotes are used.
Regarding browsing the application pools I suspect this is a permissions issue as CarlosAg mentioned. Make sure that you are running PowerShell with elevated privileges. I typically launch PowerShell by right-clicking on it and selecting "Run as administrator".
Related
Looking online, I have not seen any information on how to capture the status of the logging function on the IIS console and I was hoping to see if anyone knew how to do this via cmd/PowerShell? I am trying to see if the logging component is enabled/disabled via the command-line interface.
you could use the below PowerShell command to check the iis logging is enabled or not and other details:
Import-Module -Name WebAdministration
Get-ItemProperty -Path 'IIS:\Sites\Default Web Site' -Name logfile
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")
I'm trying to follow this article about deploying a service fabric app through powershell, but I have an issue with running the Connect-ServiceFabricCluster cmdlet. I get the following:
Connect-ServiceFabricCluster : The term 'Connect-ServiceFabricCluster' 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.
At line:1 char:2
+ Connect-ServiceFabricCluster
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Connect-ServiceFabricCluster:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Following other articles on the internet, I've tried importing the following things:
Import-Module "$ENV:ProgramW6432\Microsoft SDKs\Service Fabric\Tools\PSModule\ServiceFabricSDK\ServiceFabricSDK.psm1"
Import-Module "C:\Windows\System32\WindowsPowerShell\v1.0\Modules\ServiceFabric"
I also saw somewhere to try and set execution policy before importing modules, so I tried this:
Set-ExecutionPolicy -ExecutionPolicy Unrestricted -Force -Scope CurrentUser
In the Modules section of the Powershell ISE I see the ServiceFabricSDK module, but I don't see this cmdlet.
How do I get access to these cmdlets?
Thank you for any help.
Current versions:
Running $PSVersionTable.PSVersion, I get
Major Minor Build Revision
----- ----- ----- --------
4 0 -1 -1
Service Fabric SDK is version 2.5.216
You should make sure you are running the Windows Powershell as opposed to just Powershell. This made a difference for me.
Are you running x86 version of Powershell ISE? I got this error as well but when I switched to the other ISE the cmdlet was available again.
First, I would set your policy to bypass. This can't be done from the script itself, because, well, that's what needs to run with this policy. You could look into setting your powershell ise profile to do this for you.
Set-ExecutionPolicy Bypass
To your question. Not all modules can use the Import-Module feature. For instance, modules from the technet.microsoft.com site must sometimes be manually installed and unzipped. I'm including a script I use below to do this automatically.
#https://www.petri.com/manage-windows-updates-with-powershell-module\
$url = "https://gallery.technet.microsoft.com/scriptcenter/2d191bcd-3308-4edd-9de2-88dff796b0bc/file/41459/47/PSWindowsUpdate.zip"
$module = "PSWindowsUpdate"
$zipped = "$($PSScriptRoot)\$($module).zip"
$unzipped = "C:\Windows\System32\WindowsPowerShell\v1.0\Modules"
#$unzipped = "$PSScriptRoot\$($module)"
if (Get-Module -Name $($module)) {
Write-Host "Module exists $($module)"
} else {
Write-Host "Getting Module $($module)"
if(!(Test-Path $zipped)){
(New-Object System.Net.WebClient).DownloadFile($url, $zipped)
if($?){Write-Output "Downloaded zip $($zipped)"}
}else{
Write-Output "Zip found $($zipped)"
}
if(!(test-path "$($unzipped)\$($module)")){
Add-Type -assembly “system.io.compression.filesystem”
[io.compression.zipfile]::ExtractToDirectory($zipped, $unzipped)
if($?){Write-Output "Unzipped to $($unzipped)"}
}
Unblock-File -Path "$($unzipped)\$($module)" -Confirm
if($?){Write-Output "Unblocked file $($unzipped)"}
Import-Module $unzipped\*\$($module).psd1 -Verbose
if($?){Write-Output "Imported module $($unzipped)"}
}
I was too hasty in my first answer. (which is weird, cuz it took awhile to type...) anyhow. It looks like the install process actually unpacks the psm1 for you.
Be sure you are running as admin, use this to check.
([Security.Principal.WindowsPrincipal] [Security.Principal.WindowsIdentity]::GetCurrent()).IsInRole(`
[Security.Principal.WindowsBuiltInRole] “Administrator”)
Make sure the file name you made in step 3 matches the path in step 6.
When you run the import module command, follow that up with $?. This will tell you if it imported correctly. You can also use these commands to see if it worked.
get-command -name "Cluster"; get-module
I have just experienced the same problem on my Win10 box,
when cmdlets were not recognized as valid and downloading/installing relevant modules that contained those cmdlets didn't work.
The only solution that worked for me was as follows:
Go to the Control Panel -> "Programs and Features"
Uninstall Service Fabric SDK
click "Turn Windows features on or off" link and uninstall PowerShell
Next, reboot the Windows
Go back to the Control Panel -> "Programs and Features" -> "Turn Windows features on or off"
And install PowerShell
After which download/install Service Fabric SDK
Once again, restart your PC, start the Service Fabric Cluster Manager (if it doesn't auto-start), then right-click its icon on the task-bar and try creating 1-node or 5-node cluster again. In my case, it took less than a minute.
I was going to write up a simple alias 'iis' to invoke the IIS Manager, which is 'C:\Windows\System32\inetsrv\InetMgr.exe'
set-alias iis "OpenIIS.ps1"
and in the OpenIIS.ps1 I have
$item = "C:\Windows\system32\inetsrv\InetMgr.exe"
invoke-item -path $item
This doesn't work. The error I get is "The system cannot find the file specified"
In fact, just doing a Get-ChildItem on the inetsrv won't show the InetMgr.exe (no difference with -Force switch)
Get-ChildItem C:\Windows\system32\inetsrv\*.exe -force
Obviously I can see it in Explorer and I can launch it using cmd, but not with Powershell it seems. Also, Powershell is running as Administrator.
What is going on?
As a workaround I tried creating a link to the file and then invoking that link from Powershell. I now get a 'NotSpecified' Win32Exception.
I have originally used 64 bit Powershell, but get the same result on the x86 Powershell (both run as Administrator)
Are you at the elevated PowerShell prompt? Some system files may not show up unless you use -Force parameter with Get-ChildItem.
I think evidently the file InetMgr.exe is not there as when I do a get-childitem in the mentioned directory,it lists the "InetMgr.exe" there.
This may not be the problem with Get-ChildItem or the Alias you created but instead with ur IIS Server.
I am trying to use the Invoke-Command powershell cmdlet to install a MSI installer. From within powershell on the local machine and from the proper directory, the following works:
./setup /quiet
The following does not seem to work:
$script =
{
param($path)
cd "$path"
& ./setup /quiet
return pwd
}
return Invoke-Command -ComputerName $product.IPs -ScriptBlock $script -Args $sourcePath
For test purposes I am working on the local machine passing in "." for the -ComputerName argument. The paths have been verified correct before passing in to Invoke-Command, and errors generated on different versions of this code indicate the paths are correct. I have also tried with and without the "& " on the remote call to setup. Other Invoke-Command calls are working, so I doubt it is a permissions issue. I have verified that the return from the pwd call is the expected directory.
How do I get the install to work?
What error (if any) are you receiving? Unfortunately, you must run the shell as admin on your local machine to be able to connect to your local machine with invoke-command or any WINRM based command that requires administrative privilege (this is not a requirement when connecting remotely).
When connecting to loopback, I believe it is unable (for some security reason) to enumerate groups and determine if you are in an admin enabled AD or local group, which is how it auto elevates when invoking on a remote machine. The only solution may be to have a conditional which checks for localhost and if so, don't use the -ComputerName parameter.
This GitHub Issue covers it
You might try using Start-Process in your script block:
cd $path
start-process setup.exe -arg "/quiet"
Not sure if you will want or need to wait. Look at help for Start-Process.
I have had weird issues when trying to remotely execute a script on a local machine. In other words, remote powershell to the local machine. It comes back with an error that seems to say that PowerShell remoting is not enabled on the machine, but it was. I can run the script remotely from another machine to the target, but when using remoting to the same box, the issue crops up.
Verify that the WinRM service is running.
Verify powershell remoting has been enabled as in Enable-PSRemoting -force.
Verify your powershell execution policy is loose enough as in Set-ExecutionPolicy Unrestricted, for example. If the policy was set to RemoteSigned, this might be the problem.
You might also want to verify the user you are running the script as (locally, but using remoting) has privileges to "log on as a service" or as a batch job. Just guessing there, if the above list doesn't solve anything.