Archive | PowerShell RSS feed for this section

Calling HTTPS on self-hosted C# service using PowerShell gives 404 error

1 Aug

 

A short post on something that was making me bold. So maybe I save you some hears 😉

 

Problem (no challenge this time)

 

You have a Self Hosted C# webservice. This web service is configured to listen to base address https://host.domain.com:8733

  1. You have created a selfsigned certificate as example below:

New-SelfSignedCertificate -DnsName host.domain.com -NotAfter “2020/01/01” -FriendlyName “Test Cert” -CertStoreLocation Cert:\LocalMachine\My

  1. You added the certificate also to the Trusted Root Certification Authorities on the server. So the cert chain will be valid !

     

  2. You have configured the binding and listener for example as below: (certhash should be replaced by the hash from the cert above)

netsh http add urlacl url=https://*:8733/Config_Service user=EVERYONE delegate=yes

netsh http add sslcert ipport=0.0.0.0:8733 certhash=‎aaaaaaaaaaaaaaaaaaaaaa appid={3a1d638b-1b51-482a-dddd-218a589c2e69}

  1. Now on the host it selfs you call the webservice from out your browser as :

     

    https://host.domain.com:8733/Config_Service/ConfigService/api/list/configuration

     

    You will get a 404

     

  2. Now you go to external workstation and open a web browser and go to:

    https://host.domain.com:8733/Config_Service/ConfigService/api/list/configuration

     

    And succeed! You get the expected results.

     

  3. Now you open a PowerShell on the server and execute:

     

    Invoke-RestMethod
    -Urihttps://host.domain.com:8733/Config_Service/ConfigService/api/list/configuration”
    -Method
    Get

     

    And you will get again the 404 as

    Invoke-RestMethod : The remote server returned an error: (401) Unauthorized.

     

    If you get this error below you didn’t setup the certificate correctly, see step 1 and 2

    Invoke-RestMethod : The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

     

  4. You try the same PowerShell on the external workstation. And it works …..

 

 

So local it looks not working …… Hmmmm

 

Solution

 

It’s very simple, but took me some time to find … Just disable the DisableLoopbackCheck on the server 😉

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\Lsa\DisableLoopbackCheck = 1 (as dword)

No restart needed.

 

Hope this helps you,

Michel Kamp

 

 

Advertisements

[BUG] VSAE with a PowerShell $Data parameter

27 May

Hi,

This time for a short post on a ‘possible’ bug i detected in VSAE

Problem:

You create a PowerShell script and want to include this script using the $includeFileContent/<script_name>$ tag.

For example

<ProbeAction
ID=Probe
TypeID=Windows!Microsoft.Windows.PowerShellProbe
RunAs=SystemCenter!Microsoft.SystemCenter.DatabaseWriteActionAccount>

<ScriptName>FixTopNQuery.ps1</ScriptName>

<ScriptBody>$IncludeFileContent/FixTopNQuery.ps1$</ScriptBody>

<TimeoutSeconds>300</TimeoutSeconds>

<StrictErrorHandling>true</StrictErrorHandling>

</ProbeAction>

(Added a screenshot below)

The FixTopNQuery.ps1 is a PS script added to the project as “Embedded Resource”.

Now you compile the project and you get a compile error:

Error    1176    The configuration specified for Module Probe is not valid.

: Incorrect expression specified: $DataSet=New-Object System.Data.DataSet

. Unable to resolve this expression. Check the expression for errors. (Hints: Check for correct character casing (upper case/lower case), mismatched “$” signs, double quotes(“), square brackets “[” or “]”). Here is a sample expression: $Data/EventNumber$

(Path = OpsLogix.IMP.Oracle.Dashboards.Task.FixTopNQuery/Probe)    C:\Program Files (x86)\MSBuild\Microsoft\VSAC\Microsoft.SystemCenter.OperationsManager.targets    255    6    Dashboards

(Added a screenshot below)


Hmmm.. Why ?

 

Analyze

After a lot of error and retry I found out that the problem is in the included powershell script. And exactly in this line below:

$DataSet=New-Object System.Data.DataSet

Hmm I hear you thinking, what’s wrong with this statement? That exactly what I was thinking…. But when I change the parameter name the compile was successful…

 

Solution

Do not start a parameter name with $Data in the powershell script. It looks like it’s a reserved word in VSAE.

 

I will share this issue also with the VSAA product team.

Happy Scomming

Michel Kamp

Reading out PS NoteProperty’s

6 Nov

 

Case:

How do i read out the IsManagementServer property on the example below ??

$X= Get-SCOMClass -Name “Microsoft.SystemCenter.ManagementServer” | Get-SCOMMonitoringObject

The output is:

[Microsoft.SystemCenter.HealthService].AuthenticationName : SRV.stateview.nl

[Microsoft.SystemCenter.HealthService].MaximumQueueSize : 104857600

[Microsoft.SystemCenter.HealthService].MaximumSizeOfAllTransferredFiles : (null)

[Microsoft.SystemCenter.HealthService].RequestCompression : True

[Microsoft.SystemCenter.HealthService].CreateListener : True

[Microsoft.SystemCenter.HealthService].Port : 5723

[Microsoft.SystemCenter.HealthService].IsRHS : True

[Microsoft.SystemCenter.HealthService].IsManagementServer : True

 

Now I want to get the IsManagementServer value

$.[Microsoft.SystemCenter.HealthService].IsManagementServer

But it Fails

$.IsManagementServer

But it Fails

How do I read it out ??

Solution:

Running the command below..

$x | GM

pointed out it was a noteproperty

image  

So since its using [] i have to use ” to make a string of it

So the correct syntax would be

$x.'[Microsoft.SystemCenter.HealthService].IsManagementServer’.value

Happy Scomming

Michel Kamp

Orchestrator and PowerShell Actions returned from a marriage therapy session…

11 May

 

Yes I know I blog a lot on SCOM related posts but this don’t imply that I don’t use the other system center products. As you know or not know that I work for a company that hosts SCOM as private clouds. So I use also a lot of Orchestrator runbooks to automate the boring and complex hand work and to glue all the components together.

The problem

As one of my best practice rules I try to use only the out of the box delivered actions (IPs). Some times I can’t find the correct action and have to use PowerShell to get it working. So I use the Run Dot Net Script PowerShell action. And now the bad marriage starts. You all know when you try to type the PowerShell code into the action window you get very strange line breaks and you completely miss the code IntelliSense and error/debug features that you will have in power shells ISE or other PowerShell editors. So what do you do ?

(1) Open the PowerShell editor lets say ISE and program your script.

(2) After testing you SAVE IT TO YOUR SOURCE SAFE solution. for example TFS

(3) Now you copy and paste your PowerShell code from the ISE editor to the orchestrator PowerShell action.

(4) you replace the the input parameters with the correct orchestrator subscriptions.

(5) you check-in the runbook.

So far so good… but .. Now you have detected a bug in your PowerShell action (and I think I am not the only one that has bugs in his work) . You will have to do the reverse actions and repeat the steps in forward order again. Pffff very time consuming…

The solution

After some thinking I came with a solution. I have made a PowerShell ISE plugin that does the following.

(1) connects to the Orchestrator database . You must supply the connection settings in the Config tab first.

(2) You Press on LOAD and it shows you a list of PowerShell actions you have in your workbook(s)

(3) You select the correct PS action by double click on it.

(4) the PowerShell code from that action will be opened in the ISE editor.

(5) the subscription parameters are collected also and a extra PowerShell code is created for you to fill in the parameters with values for off site testing. *Planned for next release.

(6) you bug fix and test the script.

(7) you press in the ISE orchestrator plugin on Save and the script will be saved to the orchestrator workbook action. (be sure that it is checked out , save will work but’s better to do so)

Now you will have the workbook action with the fixed script. You even don’t have to worry about the parameter subscriptions because the are all there… Press refresh in the Orchestrator designer and look at the properties again to check it out.

SNAGHTML5ea57926

Cool isn’t it !!

And that’s why I also share it with the community !

See download link below:

https://skydrive.live.com/redir?resid=2FFA0FC5B0B89EED!1391&authkey=!AGXGNQLdATUuMDg

1) unzip the file and read the readme.txt file for setup instructions.

2) go to the config tab and specify the correct SQL and DB. Remember its using integrated security.

Next release is coming soon. This version will also have a feature that replaces all the Orchestrator parameter subscriptions with real values from a runbook run history. So you can debug with real parameter values. I had some troubles making it stable so its coming later on…

Happy SCOMMING … Orchestrating.  

Michel Kamp