Jump to content

Endpoint Configuration Manager integration


Recommended Posts

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

Link to post
Share on other sites

@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

 

Link to post
Share on other sites

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 

Link to post
Share on other sites

@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

 

Link to post
Share on other sites

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

Link to post
Share on other sites

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.

Link to post
Share on other sites

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

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

Link to post
Share on other sites

@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

 

Link to post
Share on other sites
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

Link to post
Share on other sites

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

Link to post
Share on other sites

@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.

image.png

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

Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
×
×
  • Create New...