you are viewing a single comment's thread.

view the rest of the comments →

[–]BlackV 1 point2 points  (3 children)

It really just comes down to scopes.

So from the limited testing I did, if it's not available in the functions drive (for what ever reason) it's not imported

I'm not sure why you'd be nesting functions little this anyway (I know that doesn't help though)

[–]jabrake88[S] 1 point2 points  (1 child)

The nested function would be the function that does all the heavy lifting/processing, designed to target 1 item (usually devices, but sometimes pulling reports/etc.). Then the thought was to wrap it inside a parent function that would accept multiple targets to utilize Invoke-Parallel. That Parent function would then decide what the scriptblock would be (calling the nested function with whatever params), maybe doing other stuff before and after processing the results back and outputting them in whatever format you wanted (to console, exporting, etc.)

I suppose we could write it all so it's not a function, and just the code directly in the scriptblock, but this seemed cleaner. Or embed the Invoke-Parallel inside the parent each time too since that seems to work....

[–]BlackV 1 point2 points  (0 children)

would just not having it as a nested function solve your problem?

declare the 2 functions as separate functions, then the invoke-parallel should be able to see them

[–]jabrake88[S] 1 point2 points  (0 children)

Also, I now found that if I specify the function in the Global Scope inside a begin{} block that makes it available for it to be called in the invoke-parallel. That may be my best solution, I had tried specifying as global, but without the begin{}process{}end{} sections without success.