Jump to content

SCCM add to device collection error


AndyGilly

Recommended Posts

Afternoon

we have our first attempt to use the device collection process this morning. The ITOM job was a success but the output was a failure msg

Failure to import SCCM/ConfMan/ECM Cmdlets:Cannot bind argument to parameter 'Path' because it is null.

the debug log looks to be happy that it has all the items it needs.

I cannot find what this msg means

please can someone have a look??

thanks

Andy

Link to comment
Share on other sites

Hi @AndyGilly,

This error would suggest that the value provided to the SiteID input parameter isn't a valid, or accessible, ECM site. The operation basically uses the Set-Location cmdlet to set the execution location to the ECM site drive using the provided site ID, then uses the Add-CMDeviceCollectionDirectMembershipRule cmdlet (alongside a couple of other bits) to add the supplied device to the collection. The SiteID will be case-sensitive too, so it may be worth checking this first.

Cheers,

Steve

  • Like 1
Link to comment
Share on other sites

Hi @Ricky @Steve G

 

for some reason the PowerShell cmdlet did not enable local execution globally, just for the local user context
The answer was to go into the Local Group Policy Editor -> Local Computer Policy -> Administrative Templates -> Windows Components -> Windows PowerShell and double-click on 'Turn on Script Execution'. This then let me change it to 'Enabled' and then execution policy of "Allow all scripts"
 
I would need to check with our security team to see if i can enable this policy on that machine fulltime
 
Is this something you have seen in any testing??? Would you say this is WW environment specific? 
 
the Active Directory Package library scripts run fine, so it must be something about this specific ECM requirements i guess
 
thanks
Andy
Link to comment
Share on other sites

Hi @AndyGilly,

This is not WW environment specific, Windows servers restrict script execution by default. We've provided a Set Execution Policy operation in the Windows Management package that can be executed either side of the operation you wish to run so that the local machine or current user policy doesn't need to be left in a  permanently relaxed state. So in a runbook for example, you could use the Set Execution Policy operation to relax the script execution policy for the current user, then execute your actual operation, then use Set Execution Policy to restrict it again.

I expect the AD package operations are ok as the target machine must already have a less-restrictive script execution policy in place, either in the local machine or current user policies.

Cheers,

Steve

Link to comment
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...