Today I pick up on my ramblings about the various things that challenge us in our daily routine in IT.  Whilst I am a GroupWise geek I’m going to do something a little different again.  Most environments that I work in push out policies in one form or another to the workstations.   A common complaint I hear from the more senior engineers in charge of managing and deploying these polices is that the support technicians sitting at the end user’s workstation troubleshooting issues often claim that it’s the policies that are causing something to not work or the policies are not applying correctly.

To make troubleshooting a little easier and the policy application at a workstation level more visible I’ve written a little script that collects the Resultant Set of Policies directly at the workstation, creates a report, and sends it to the relevant senior engineer via email.  Seeing is believing.  To look directly at what is and what is not happening at a workstation level can prove valuable in troubleshooting potential issues with deployed policies.

Now the disclaimer – I am by NO means adept at writing scripts or code in any form or variety.  Necessity is the mother of all inventions.  This short PowerShell script was born out of the necessity to alleviate a major pain point experienced by my colleagues.  Use this script entirely at your own risk.  I wrote this script in ISE on Windows 7.

What the script does:

1. 1. Sets the execution environment to unrestricted. I do that as my script is not digitally signed.  Don’t worry, we reverse this condition at the end of the script.

1. 1. Gives some information on the screen as to what is happening.

1. 1. Runs the Microsoft tools to collect the policy information and creates a .html file in the root of C: - I did that for simplicity sake.

1. 1. Prompts for the source email address – that would be the user experiencing the issue.

1. 1. Prompts for the destination email address – that would be the rather frustrated engineer.

1. 1. Compiles an email with the attachment and the information gathered above.

1. 1. Sends the email via SMTP

Here’s what you will need to do:

1. 1. Edit line 20 of the script to reflect the IP address of your SMTP server.

1. 1. Save the changes.

1. 1. Test and tweak to ensure that it’s working in your environment.

1. 1. Compile the script into an EXE file to prevent other misguided individuals from altering it. There are a number of tools available on the internet that will do this for you, just Google it.

1. 1. Make your EXE available to your support technicians and give them a little training on how to use it.

So here is what my script looks like:



I've also added the script in text format.

GW-RSOPv2

For my customers working in an Outlook/Exchange environment I have a different script that works directly with Outlook and Exchange without making use of a SMTP relay.  If you need this alternative script then please let me know and I’ll publish that one too.

If just one person finds this useful then I consider this “Mission Accomplished”