Combining scripts in provisioning policies

Hi jody gilbert 

To some extent this is personal choice, there are advantages and disadvantages to both approaches. IE:

• Multiple executions of shorter quicker scripts, vs single execution of longer slightly more complex scripts. (Plus any overhead from executing a script, especially if loading modules without checking, or using Exit accidentally in PowerShell scripts)
• Smaller more readable scripts, vs larger most difficult to read scripts.

My usual approach is (where possible is) to combine as many of the tasks into a single script module (granted using Library Script where I can locate re-useable code), and ensure I have appropriate checks in my logic to prevent doing tasks that are not required. Only splitting into different scripts for different use cases.

However it does depend on what your doing, as their might be other methods to deliver the same results (or not as the case may be).

Hi jody gilbert 

To some extent this is personal choice, there are advantages and disadvantages to both approaches. IE:

• Multiple executions of shorter quicker scripts, vs single execution of longer slightly more complex scripts. (Plus any overhead from executing a script, especially if loading modules without checking, or using Exit accidentally in PowerShell scripts)
• Smaller more readable scripts, vs larger most difficult to read scripts.

My usual approach is (where possible is) to combine as many of the tasks into a single script module (granted using Library Script where I can locate re-useable code), and ensure I have appropriate checks in my logic to prevent doing tasks that are not required. Only splitting into different scripts for different use cases.

However it does depend on what your doing, as their might be other methods to deliver the same results (or not as the case may be).

Many thanks Stu.Pollock , I did wonder if that's the case.

I've been busily moving any reusable code to libraries and I think we'll go with a combined script, to me it feels like it should be more performance and I'm not so keen on multiple scripts firing for the same event handlers (could cause issues with troubleshooting, for example). 

No problem

You need to remember Policy Scripts fire against any object class, for you need to ensure in your script you check if the object being (in your case) modified is of the correct type. Also remember that it will execute for any (again in your case) modify of that object class, regardless of if you only want it to do something when a certain attribute is changed, so its important to ensure you check what's being changed.

thanks for the reminder, can I just confirm that you mean we check the $Request.Class at the start of every function/event handler and we use something like IsAttributeModified for the relevant properties?

Hi Jody

Yes, always ensure that your code only executes for the objects you want it to execute against, than could be a mixture of the objects class, plus other factors, like which attribute has changed, or an attributes value etc.

The (+) PowerShell Library Source Code - Wiki - Active Roles Community - One Identity Community has some good helper functions you can use.

Script execution when done via an Administration Policy will occur for ANY operation that occurs against any object in-scope of that policy.