Endpoint Configuration Manager integration

[AndyGilly]

Without any known change in config of the SIS server where the 'add device to collection' process runs we have suddenly started to receive the following error when a service manager BPM asks for the add to device collection automation

{{SISJobOutputParameterStart:outcome}}FAIL{{SISJobOutputParameterEnd}}
{{SISJobOutputParameterStart:errors}}Error trying to add Device to Collection: This command cannot be run from the current drive. To run this command you must first connect to a Configuration Manager drive.{{SISJobOutputParameterEnd}} 

We have seen this before and it was fixed by using the edit execution policy to 'bypass' automation in front of the request to add the device to the collection

We are struggling to find why this has happened

any guidance would be much appreciated

thanks

Andy

[Ricky]

@AndyGillyCan you check if the SiteId is correct as it is case sensitive?

Regards

Ricky

 

[AndyGilly]

Hi @Ricky, i have checked the siteID and is in capitals in all places

thanks

Andy

[Ricky]

@AndyGillyCan you also confirm that you are able to manually change to the the drive on the target device using:

Set-Location <dirve-name>:

This will confirm the package is being executed on the correct device, and I will also get back to the dev team who are currently investigating the error message with your update.

Thanks

Ricky

 

[AndyGilly]

Hi @Ricky

after some more digging i have found that the pre-req automation of setting the execution policy to ByPass to allow the configuration manager automation to work is not working

although the automation returns a success the policy on the SIS server has not changed

when I manually amend the execution policy the configuration manager process starts to work again

Any thoughts on best way off troubleshooting the execution policy job??

thanks
Andy 

[Ricky]

@AndyGilly Thanks for the update, I will take a look and see what I can come up with, and get back to you.

Thanks 

Ricky

 

[Ricky]

@AndyGilly We have updated the ECM package to provide enhanced error messaging (https://community.hornbill.com/topic/20615-new-update-hornbill-itom-content-pack-32/)  this should help with any issues going forward.

With regards to the Execution policy can you supply the the full debug log and Monitor for the Set-Execution Policy operation?  Would also be useful to get the output of following command on the target device

Quote

Get-ExecutionPolicy -List

Thanks

Ricky

 

[AndyGilly]

Debug Log - post library update applied

Standard
--------
2021-04-07 13:50:50Z Package filename: C:\Users\SVC-HB~1.WWC\AppData\Local\Temp\Hornbill\SIS Package Processor\2416f7c9-5bc8-40c7-abff-9e9db0132671\Alternate\Package.pkg
2021-04-07 13:50:50Z Operation: Set Execution Policy
2021-04-07 13:50:50Z Analysing input parameters
2021-04-07 13:50:50Z Parameter: Name: ExecPolicy Value: Bypass
2021-04-07 13:50:50Z Parameter: Name: Scope Value: LocalMachine
2021-04-07 13:50:50Z Target platform: win3264
2021-04-07 13:50:50Z Command Type: ps1
2021-04-07 13:50:50Z Timeout: 300
2021-04-07 13:50:50Z Using executable C:\Windows\system32/WindowsPowerShell\v1.0\PowerShell.exe
2021-04-07 13:50:50Z Plain text arguments: .\"SetExecutionPolicy.ps1" -ExecPolicy "Bypass" -Scope "LocalMachine"
2021-04-07 13:50:50Z Base64 arguments: LgBcACIAUwBlAHQARQB4AGUAYwB1AHQAaQBvAG4AUABvAGwAaQBjAHkALgBwAHMAMQAiACAAIAAgAC0ARQB4AGUAYwBQAG8AbABpAGMAeQAgACIAQgB5AHAAYQBzAHMAIgAgAC0AUwBjAG8AcABlACAAIgBMAG8AYwBhAGwATQBhAGMAaABpAG4AZQAiAA==
2021-04-07 13:50:53Z Processing result: Exit Success


Full
----
2021-04-07 13:50:50Z Log filename: C:\Users\SVC-HB~1.WWC\AppData\Local\Temp\Hornbill\SIS Package Processor\2416f7c9-5bc8-40c7-abff-9e9db0132671\Alternate\Processing.log
2021-04-07 13:50:50Z Local computer name: WXAPSHRNBP01-01
2021-04-07 13:50:50Z Package filename: C:\Users\SVC-HB~1.WWC\AppData\Local\Temp\Hornbill\SIS Package Processor\2416f7c9-5bc8-40c7-abff-9e9db0132671\Alternate\Package.pkg
2021-04-07 13:50:50Z Operation: Set Execution Policy
2021-04-07 13:50:50Z XML result filename: C:\Users\SVC-HB~1.WWC\AppData\Local\Temp\Hornbill\SIS Package Processor\2416f7c9-5bc8-40c7-abff-9e9db0132671\Alternate\Result.xml
2021-04-07 13:50:50Z Timeout: 300
2021-04-07 13:50:50Z Encoded parameters: okpfR9fnZEwMovC0_-G_42TYE2Mo5b75u0qQUTTgsa6mx5GSj7HFkit8--pAYT5phA0eaL4rLSF7-3SCmrveB88s8xKb5-G-lMfC9j6TxgZXoUwhTMf_mdvM_z73Sjb42106Z5uqOk84806NBTr5CB_Oe8XkOYuiEvh8NJT522TiVA31MFvyLciT5kFnhyQ0RcMGoZEp348pQkaqxhwATscYYxVbmFkrHtihtTIN0vw1Cdxpho0h83HgbQ2rJx6Y8s689i9nBA3Hhb_ORRrN2JLAgCXKjukUDc8PNsabogxHOD24nH0md1ABPJOwYN0BB_opryI5gp1xd_3cPn6yQOV5ZZOezxgqBZispQeazTc1zcE8BXhRqxd6LuXGvYyzO17F
2021-04-07 13:50:50Z Encoded credentials: RMFrQFMVdXvfl5MRvBNLUrH8QwNHF3CeioK1TGCfUO-TsWEwS2TMFuHY3OOAs3M7Mgq8vdFJC199A6O_Uo8PwbVVTFdj1yJ7nuuxlW9NJptUGcD6rMj31AMw5pL6eDSMR_WfyFOSzKIVriMBRsWjsj-88gOAdA8oQUBgY59jRNNYzgQD3gJmt5PWxrxc7ieL-M9mQpzz4QGVc4qMymp2qFPUIHDqdWv4UeTtNZolE11GmemlrtxlP4KPuH-e_NPal14pyn3AUsk-Y-ZMmlgV3Ohzjy8obbToDuemCoztyU5G2-0xArYCRfhQ-J6V08tSEfRH5l8fNUbJNHJ3lC3ZT11eCfiFRbGWhToIHtH9gL0Nad-mCq3p8CKEDuSySg
2021-04-07 13:50:50Z Callback context: zEmgs7Gp31vYr23mB4kYjIXvYis_uEMG51ke4_KbXAx8MWKJORKBIh9faqQ8-6QZ9gAStYQpeveDemPQAVNc43aDJVxhZ58fzWR3xjTTIlsxBLxMfsmH4lcUKqIZgqi0hpYAvH18106iU5pLA3R3e26PxlK1ZEE18mlo_EBV3as0nS67I-bYNKva_CFZvR8ZGIRIiZdui5T5sPpG6EVywAyc6LkiiXxAUv0q7ZR9AASyBUu483CLFc1Cn006jbKvYfOAu8ZXl9kqRa4I8Q48Y47kuT38ikTVAxj-5G6WzfRHYZxM3j0kjQ9TTLYQAJgfEPvdXsFaeAYJD4zgjNtWGc32aO9q0u1bMH3SuFqWUcFcyhbTDW8
2021-04-07 13:50:50Z Log line prefix: P
2021-04-07 13:50:50Z Package processing started as WWCORP\SVC-HBEPCON-MGRAUTO. PID: 9068
2021-04-07 13:50:50Z Analysing input parameters
2021-04-07 13:50:50Z Parameter: Name: ExecPolicy Value: Bypass
2021-04-07 13:50:50Z Parameter: Name: Scope Value: LocalMachine
2021-04-07 13:50:50Z Target platform: win3264
2021-04-07 13:50:50Z Command Type: ps1
2021-04-07 13:50:50Z Timeout: 300
2021-04-07 13:50:50Z Using the native variant of PowerShell
2021-04-07 13:50:50Z Using executable C:\Windows\system32/WindowsPowerShell\v1.0\PowerShell.exe
2021-04-07 13:50:50Z Plain text arguments: .\"SetExecutionPolicy.ps1" -ExecPolicy "Bypass" -Scope "LocalMachine"
2021-04-07 13:50:50Z Base64 arguments: LgBcACIAUwBlAHQARQB4AGUAYwB1AHQAaQBvAG4AUABvAGwAaQBjAHkALgBwAHMAMQAiACAAIAAgAC0ARQB4AGUAYwBQAG8AbABpAGMAeQAgACIAQgB5AHAAYQBzAHMAIgAgAC0AUwBjAG8AcABlACAAIgBMAG8AYwBhAGwATQBhAGMAaABpAG4AZQAiAA==
2021-04-07 13:50:50Z Console Output: C:\Users\SVC-HB~1.WWC\AppData\Local\Temp\Hornbill\SIS Package Processor\b29ba7c8-38de-473d-8a45-a35d7b19d2c7\Output/Output.txt
2021-04-07 13:50:53Z Processing result: Exit Success

[AndyGilly]

Monitor

Supervisory processing for RunAs processing started as WWCORP\svc-hbadauto. PID: 9276
Package processing started as WWCORP\SVC-HBEPCON-MGRAUTO. PID: 9068
Payload processing started as WWCORP\SVC-HBEPCON-MGRAUTO. PID: 3132
#< CLIXML
Bypass : Bypass
{{SISJobOutputParameterStart:outcome}}OK{{SISJobOutputParameterEnd}}
<Objs Version="1.1.0.1" xmlns="http://schemas.microsoft.com/powershell/2004/04"><Obj S="progress" RefId="0"><TN RefId="0"><T>System.Management.Automation.PSCustomObject</T><T>System.Object</T></TN><MS><I64 N="SourceId">1</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj><Obj S="progress" RefId="1"><TNRef RefId="0" /><MS><I64 N="SourceId">2</I64><PR N="Record"><AV>Preparing modules for first use.</AV><AI>0</AI><Nil /><PI>-1</PI><PC>-1</PC><T>Completed</T><SR>-1</SR><SD> </SD></PR></MS></Obj></Objs>
The job was executed successfully.

[AndyGilly]

PS C:\Users\svc-hbepcon-mgrauto> get-executionpolicy -list

        Scope ExecutionPolicy
        ----- ---------------
MachinePolicy       Undefined
   UserPolicy       Undefined
      Process       Undefined
  CurrentUser       Undefined
 LocalMachine    RemoteSigned

[Ricky]

@AndyGilly There looks to be no issue with the execution, the only issue maybe where you are entering the Get-ExecutionPolicy to check the change.  The package is built to use the 32 bit (x86) version of PowerShell and thus the change would not be seen in the 64bit console.  This can be identified in the logs by the entry "2021-04-07 13:50:50Z Target platform: win3264".

I am unable to get it to fail at my end and the output you have provided in the logs looks as if all was working as expected.

When you set the Policy which version of PowerShell console are you setting it in PowerShell or Powershell (x86)?

Ricky

 

[Ricky]

17 minutes ago, Ricky said:

@AndyGilly There looks to be no issue with the execution, the only issue maybe where you are entering the Get-ExecutionPolicy to check the change.  The package is built to use the 32 bit (x86) version of PowerShell and thus the change would not be seen in the 64bit console.  This can be identified in the logs by the entry "2021-04-07 13:50:50Z Target platform: win3264".

I am unable to get it to fail at my end and the output you have provided in the logs looks as if all was working as expected.

When you set the Policy which version of PowerShell console are you setting it in PowerShell or Powershell (x86)?

Ricky

 

@AndyGilly  Ignore the above comment as it is mis-leading, i should of written it as follows:

There looks to be no issue with the execution, the only issue maybe where you are entering the Get-ExecutionPolicy to check the change.  The package is built to use the native version of PowerShell and thus the change should be seen in the native console.   This can be identified in the logs by the entry:
 

2021-04-07 13:50:50Z Target platform: win3264
2021-04-07 13:50:50Z Using the native variant of PowerShell
2021-04-07 13:50:50Z Using executable C:\Windows\system32/WindowsPowerShell\v1.0\PowerShell.exe

I have notice that when we apply the setting and open the native console that the change is not registered, however the change is registered in the  PowerShell (x86) console.

When you set the Policy, which version of PowerShell console are you setting it in PowerShell or PowerShell (x86)?

Ricky

[AndyGilly]

thanks @Ricky

I have checked the native PowerShell. I manually set policy etc. Once i had done this on the box the automated job seemed to start working again

I am not sure if it is a sequencing thing or what quite stopped it working but an end to end process was tested last night and seems to be working fine

i am a little confused to why but we are back

thanks

Andy

[Ricky]

@AndyGillyThanks for the update, the only thing i can see that may cause this the process not to set it, may be to do with IT Automation node setting the Policy not waiting for a response before the  next node is executed.

The execution policy can only be modified by ITOM via an IT Automation, so would  not have been modified unless specifically called, and therefore may have been changed by some other mechanism such as a Group Policy setting.

Ricky

[AndyGilly]

Hi @Ricky

as an update:

we are finding that in order for the Set-Execution policy job to work (it always states job successful but the policy has not changed) the server needs to be logged in as the Run As account and PowerShell open

any other scenario - logged in but PowerShell closed, not logged in etc, the outcome is no change in the policy

would appreciate any other thoughts you have

thanks

Andy

 

 

 

[Ricky]

Hi @AndyGilly, have not come across that as yet, but will take a look at it and get back to you.

Regards

Ricky

 

[AndyGilly]

Hi @Ricky

any news on this one?

its happened again post a SIS server reboot, we have had to log back in

thanks

Andy

[Ricky]

Hi @AndyGilly, I have not been able to replicate the issue in-house as yet and will have another look at it today and discuss with the development team to see how to best progress this issue. If we are unable to make any further progress, I will raise a support request and organise a remote session to get this sorted asap.
 

Regards,
 

Ricky

 

[Ricky]

@AndyGillyI have raised a support request for this issue and will organise an email request to schedule a remote session to be sent out to get this issue resolved asap.

Regards,

Ricky