As an organization we are aware we have been under utilizing our K1000 and are actively trying to improve on that.  Going in to any new settings/install/update task I am starting to think K1000 first.  Here is one example where the K1000 proved to be a better tool than the built in Group Policy Objects in our environment.  

I was troubleshooting Powershell Execution Policy settings after we noticed that certain powershell scripts were not being applied by Group Policy correctly across the domain.  This took me down a rabbit hole where I just decided to remove all existing settings in Group Policy for Powershell Execution Policy and build out fresh with the K1000.  

The first task was deciding which execution policy was going to meet our needs best.  Of the options, Restricted, AllSigned, RemoteSigned, and Unrestricted, RemoteSigned seemed the easiest.  But easiest isn't always the best.  After writing and deploying a script to update all machines to RemoteSigned I noticed that the servers would not run scripts off of a network share.  This was determined to be because of IE Enhanced security not trusting the "site" that was the remote share.  At this point we could decide to push setting to trust the "site" that the servers needed to run scripts from or move to the AllSigned execution policy and sign our scripts.  Based on the added security, low cost of a Comodo Code Signing Certificate, and a plethora of example powershell scripts to sign scripts we opted for that route.  

Now it is time to use the K1000 to implement a consistent application of the AllSigned execution policy.

Step 1:

I created a custom inventory rule to gather the current execution policy.  This brought its own challenges because the agent runs under the 32 bit shell and Powershell has execution policies set independently for 32 bit and 64 bit shells.  The following custom inventory rules gather the appropriate settings.  

32 bit: ShellCommandtextReturn(powershell.exe get-executionpolicy)

64 bit: ShellCommandtextReturn(%systemroot%\sysnative\windowspowershell\v1.0\powershell.exe get-executionpolicy)

Note the use of sysnative instead of system32 for the 64 bit command.  Thanks to this forum for helping me figure this out.

Step 2:

I then created a smart label that looks for either of these values not starting with "AllSigned".

Step 3:

After that a report was written to validate the current settings and functionality.  The following is the report query:

STR_FIELD_VALUE AS 'ExecutionPolicy'
WHERE SOFTWARE.DISPLAY_NAME = 'Powershell Execution Policy 32-bit'

Another report for the 64 bit Custom Inventory Rule was created.

Step 4:

Then a script was written and scheduled to run every 4 hours to update the execution policy that is restricted to the smart label created for the execution policies being incorrect.  

powershell.exe set-executionpolicy AllSigned -force
%systemroot%\sysnative\windowspowershell\v1.0\powershell.exe set-executionpolicy AllSigned -force

This is the batch file used to set both 32 bit and 64 bit.

Step 5:

Finally, I wanted to be notified if the settings were not being applied correctly.  I created an email alert that checks for either custom inventory rule having an incorrect value and run this daily.  


Utilizing the K1000 allows me to set, report, correct, and alert on a critical security setting within our domain.  Had I used Group Policy instead we would have had to write additional scripts to validate this setting and it would be very difficult to get a detailed report that isolated this setting.  In addition, you are not allowed to override the Group Policy powershell setting locally.  The configuration implemented allows me to override the setting for testing and development, if needed, and gives me the confidence to know that within 4 hours it will be reverted to its correct level.  

I hope this was helpful and illustrates the versatility the K1000 can give over standard Group Policy.