Test webservices with Powershell

I use this little thing to test webservices (by invoking SOAP/GET request etc) whenever I want to parse the output to, say, Windows Event Logs, or the nearest SoapUI installation is far far away.
The $request.SetRequestHeader parameters may vary from situation to situation, but in most cases this code should be sufficient for simple Webservices.
The only thing you need is the Webservice URL, and a set of XML parameters, depending on which test you want to do.

Originally written as a function for a bigger script, but the code should be easy to modify for other stuff.

 
#-- Global Parameters

$global:WebServiceURL = " -- URL to webservice here -- "
$global:XMLParameters = @"

-- Paste you XML request here --

"@

#-- The Actual Function

function CallWebservice {
echo "Sending webrequest to $WebServiceURL"

$request = New-Object -ComObject Msxml2.XMLHTTP
$request.open('POST', $WebServiceURL, $false)
$request.setRequestHeader("Content-type", "text/xml; charset=utf-8")
$request.setRequestHeader("Content-length", $XMLParameters.length)
$request.setRequestHeader("Connection", "close")
$request.send($XMLParameters)
$request.statusText
$request.status
$request.responseText
}

CallWebservice

– F

SCOM Agent install fails – Returncode 1603

My entire OpsMgr environment runs SCOM 2012 R2 UR1.
Occationally I come across Windows Servers that dont have any Agents installed – or so it seems.

A couple of days ago, this happened. I came across three servers without an agent, and started the Discorvery wizard.
All servers was discovered successfully, and I stared to push agents to them.
After a minute, they all failed, and the AgentInstall.log file on the Management Server returned with this funny little fucker.

————

MSI (s) (94:44) [11:41:02:856]: Product: Microsoft Monitoring Agent — Installation operation failed.

MSI (s) (94:44) [11:41:02:856]: Windows Installer installed the product. Product Name: Microsoft Monitoring Agent. Product Version: 7.1.10184.0. Product Language: 0. Manufacturer: Microsoft Corporation. Installation success or error status: 1603.

MSI (s) (94:44) [11:41:02:872]: Deferring clean up of packages/files, if any exist
MSI (s) (94:44) [11:41:02:872]: MainEngineThread is returning 1603
MSI (s) (94:64) [11:41:02:872]: No System Restore sequence number for this installation.
=== Logging stopped: 9/19/2014 11:41:02 ===
MSI (s) (94:64) [11:41:02:872]: User policy value ‘DisableRollback’ is 0
MSI (s) (94:64) [11:41:02:872]: Machine policy value ‘DisableRollback’ is 0
MSI (s) (94:64) [11:41:02:872]: Incrementing counter to disable shutdown. Counter after increment: 0
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerRollbackScripts 3: 2
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerRollbackScripts 3: 2
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerInProgress 3: 2
MSI (s) (94:64) [11:41:02:872]: Note: 1: 1402 2: HKEY_LOCAL_MACHINESoftwareMicrosoftWindowsCurrentVersionInstallerInProgress 3: 2
MSI (s) (94:64) [11:41:02:872]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (s) (94:64) [11:41:02:872]: Restoring environment variables
MSI (s) (94:64) [11:41:02:872]: Destroying RemoteAPI object.
MSI (s) (94:2C) [11:41:02:872]: Custom Action Manager thread ending.
MSI (c) (4C:68) [11:41:02:872]: Decrementing counter to disable shutdown. If counter >= 0, shutdown will be denied. Counter after decrement: -1
MSI (c) (4C:68) [11:41:02:872]: MainEngineThread is returning 1603
=== Verbose logging stopped: 9/19/2014 11:41:02 ===

————

Turns out there was an old SCOM 2007 agent installed on all of them.
Apparently, while upgrading our environment from 2007 R5 til 2012 SP1, we missed these servers.
As the SCOM DB server and management group was created from scratch, we did not receive any events on servers trying to connect to the management group with an old OpsMgr Agent.

After manually uninstalling the 2007 agents, the 2012 agents was pushed successfully from the SCOM console.

Lesson learned.

– F