I'm trying to consume a SOAP web service at PowerShell 6. I used to do this task with the New-WebServiceProxy command on early versions but no longer exists on PowerShell 6. Is there any similar command?
I'm using currently PowerShell 7 and the lack of New-WebServiceProxy affect me in several Scripts that was running with this CmdLet as expected in PS 5.1.
As 'danno' answered before, Invoke-WebRequest is the natural option in Core editions.
Googling I found two sites with examples to implement a workaround for SOAP Web Services:
https://www.itprotoday.com/powershell/getting-started-soap-based-web-services-and-powershell
... and ...
https://www.powershellbros.com/send-soap-message-powershell/
Maybe someone says it that this is go back, but really works!
A combination of ConvertTo-XML with Invoke-WebRequest should be able to get you where you need to be, both of which are supported in PowerShell 6.
Related
I've inherited a lot of scripts that rely on Invoke-WebRequest and am aware that this commandlet requires IE to run.
Is there a way to configure Invoke-WebRequest so that it uses Edge instead?
Considering that Internet Explorer 11 desktop application will be retired and go out of support on June 15, 2022; I'd imagine that MS would have some drop-in replacement for the Invoke-WebRequest command that would allow PowerShell scripts using it to continue to function after IE11's retirement.
PowerShell 5.1 -UseBasicParsing
Indicates that the cmdlet uses the response object for HTML content without Document Object Model (DOM) parsing. This parameter is required when Internet Explorer is not installed on the computers, such as on a Server Core installation of a Windows Server operating system.
PowerShell 7.2 -UseBasicParsing
This parameter has been deprecated. Beginning with PowerShell 6.0.0, all Web requests use basic parsing only. This parameter is included for backwards compatibility only and any use of it has no effect on the operation of the cmdlet.
So I am at a big roadblock right now. I was working in PowerShell 5.1 and had the Get-WmiObject with the Win32_Service Class working perfectly fine to remotely stop/start/restart services remotely. However, I found out that the .StopService() method has been removed in PowerShell 6 (which I used this to bypass the dependencies issues I kept running in to). As well, I have found out that the -ComputerName variable has also been removed from a lot of the different commandlets.
Since the removed the -ComputerName from things like the Stop-Service commandlet, I am struggling to figure out how to properly handle the stopping of the service itself. I can retrieve the service or services I want without issue. I just can't seem to figure out how to handle stopping the service.
Tried being as detailed as I can. I know I am missing something stupidly small, but all of my Google searches appear to return everything with PowerShell 5, but so little on 6.
Thanks.
Ok, nevermind about this question. I decided to approach my Google searching another way and I stumbled upon the syntax I needed. For those of you wondering, you cannot run commands straight from the returned object. So for example, you could do "$service.StopService()" straight on the service previously. However, now you have to do an invoke of that StopService method by doing "Invoke-CimMethod -Name StopService" and that is only after you pipe the Get-CimInstance returned object to it. So the full syntax would look something like this.
get-ciminstance win32_service -filter "Name='spooler'" | Invoke-CimMethod -Name StartService
A really good website I found to explain and give really good examples of why and how the Cim Instances are they way they are.
https://4sysops.com/archives/managing-services-the-powershell-way-part-7
I have this large application that I am using Windows RM 3.0 to deploy Databases, SSIS packages, and other things to multiple different servers and it is working just fine. It was requested that branding changes to a Business Intelligence SharePoint site be added to this process as well. So I create a custom build script to do so, and set Win RM to run this command from PowerShell on Sharepoint server
Install-SPSolution –Identity Payload\SharepointDeploy.wsp –WebApplication http://localhost/ -GACDeployment
when I run that, I get the following error
Install-SPSolution : Microsoft SharePoint is not supported with version 4.0.30319.18444 of the Microsoft .Net Runtime.
Reading around, it seems its a PowerShell 3.0 issue and when running in 2.0 it works fine. However, my existing process requires PowerShell 3.0 to work properly. Is there anyway to get this working with 3.0? Or can I spin up a 2.0 instance using an Invoke-Command or something? I can provide more details if needed.
You can build a custom endpoint which will run the required version of PowerShell. That way you won't have to mess with the default endpoint which you probably want to keep with its defaults
This would require you to connect to the new endpoint with something like
new-pssession -computername "SharePoint01" -configurationName "psv2".
You build and endpoint with the following cmdlet:
New-PSSessionConfigurationFile -Path "psv2session.pssc"
And then register an endpoint using that config with this cmdlet:
Register-PSSessionConfiguration -Name psv2 -Path psv2session.pssc –ShowSecurityDescriptorUI
It's fairly easy to do, and this link provides a good introduction to the setup:
http://blogs.technet.com/b/heyscriptingguy/archive/2014/04/02/build-constrained-powershell-endpoint-using-configuration-file.aspx (although the blog deals with constrained endpoints, the teqnique is essentially the same for what you need to do)
I was facing the same issue with console application, I decreased the framework version from 4.5 to 3.5 from the project properties page and I works perfect!
I am looking for an automated way to start a virtual machine in Windows Powershell. Does anyone have any input on how I may accomplish this task?
I have looked around and have been unsuccessful so far with finding a way to do so.
I thought that this was a standard cmdlet form powershell, but I am beginning to think that I am wrong on that assumption.
I have looked into using (If i am understanding this correctly) PowerCLIs Start-VM and am having issues saying that I am currently not connected to the server, but I don't believe I have a server to connect to (unless I am thinking about this the wrong way). I am just trying to do this locally right now to check to see if it is a valid VM to use.
--- EDIT ---
I am looking to do this with VMware, but really I could use Windows if that means doing this without spending any money.
I am also using powershell 2.0 and it does not seem that Start-VM is an option for me to use unfortunately...
--- EDIT 2 ---
Can anybody further explain how WMI works? I am relatively new using powershell and I have never had to use WMI before.
Any help would be much appreciated. Thank you!
Extension of my comment above... this code snippet should do what you need:
$VM = gwmi MSVM_ComputerSystem -filter "ElementName='serverName'" -namespace "root\virtualization" -computername "."
$VM.requeststatechange(2)
WMI is pretty dated though (PowerShell 1.0), this works for me on Server 2008 R2. You should add what OS you're working with. If you're on Server 2012, it's a lot easier. Just use Start-VM (PowerShell 4.0):
Start-VM –Name VMName
Arguably a lot easier than using WMI.
After reading several other blog posts and articles (references found below) there appear to be several ways to run PowerShell on .NET 4.0 but few are sufficient for our purposes. Due to how we deploy our software we cannot update the registry or change add an application. This leaves us with two options, create our own shell by using ConsoleShell or override PSHost. We would like to be able to use the first option, ConsoleShell, due to it's simplicity but would like to know what issues we may encounter and whether doing so is recommended.
Reference
Based on other questions I have seen that you can use the following methods to run PowerShell as .NET 4.0. None of these methods appear to be officially sanction by Microsoft but the first shown below is included as a work around in this Microsoft connect issue.
The options to run PowerShell in .NET 4.0 appear to include:
Update the app.config to include .NET 4.0 as supported
Add a registry setting to switch the version
Use ConsoleShell to host your own PowerShell Console
Implement your own PowerShell host, PSHost , as done by PoshConsole or Nuget
As far as it is not officially approved (to my knowledge), then nobody can approve it but you. If your scenario works and passes reasonable tests, approve and use it.
I use PowerShell on .NET 4.0 but with the option 4, and used to use the option 1, too (I do not like the option 2, personally). Thus, I approved it, production or not, I use it a lot and it works. I still use PowerShell on .NET 2.0 for two reasons: 1) PowerShell.exe starts faster (especially x64); 2) to be sure that part of my PowerShell development is compatible with .NET 2.
Another thought. If something does not work properly in PowerShell on .NET 2.0 (there are some issues, indeed, see Connect) then the fact "it is approved for production" itself does not help much. One has to overcome existing issues, .NET 2 or .NET 4 does not matter.
P.S. I should have mentioned that I tried the option 3 as well. I did not find use cases suitable for using it in my scenarios. But I did not find any issues in using ConsoleShell either.
P.P.S Yet another option. Make a copy of PowerShell.exe, rename it into MyConsoleShell.exe, use it together with MyConsoleShell.exe.config configured for .NET 4. As far as you are going to use a separate application anyway, then why not to consider this?
I'm a bit of a powershell N00b, but I threw this together as a way of forcing an arbitrary script to use .NET 4.0 in my script:
# Place this at the top of your script, and it will run as a .NET 4 ps script.
# #############################################################################
if ($PSVersionTable.CLRVersion.Major -lt 4) { try {
$cfgPath = $Env:TEMP | Join-Path -ChildPath ([Guid]::NewGuid())
mkdir $cfgPath | Out-Null
"<configuration><startup useLegacyV2RuntimeActivationPolicy='true'><supportedRuntime version='v4.0'/></startup></configuration>" | Set-Content -Path $cfgPath\powershell.exe.activation_config -Encoding UTF8
$darkMagic = 'COMPLUS_ApplicationMigrationRuntimeActivationConfigPath'
$old = [Environment]::GetEnvironmentVariable($darkMagic)
[Environment]::SetEnvironmentVariable($darkMagic, $cfgPath)
& powershell.exe $MyInvocation.MyCommand.Definition $args
} finally {
[Environment]::SetEnvironmentVariable($darkMagic, $old)
$cfgPath | Remove-Item -Recurse
return
}}
# ##############################################################################
# My script starts here:
echo "Your arguments are: $args "
echo "The CLR Major Version is : $($PSVersionTable.CLRVersion.Major)"
It places a check in the beginning of the script, and if it's not .NET 4.0 it creates a configuration file, sets an environment variable and re-runs the powershell script so that it runs under .NET 4.0.
it does incur a bit of a startup time penalty of about a second or so on my pc, but at least it works :)