The issues were unpredictability. It would be relevant sometimes and not others due to the “self examination” problem. It was always supposed to be that way but there were issues with how the code was written so it could sneak through sometimes.
Ah… I get it… sort of a circular reference… Am I relevant based on the fact that I am relevant based on am I relevant, etc… That makes sense…
Before I go down the path of doing this in action script… is there any other way to get a list of computer group memberships (manual and automatic)? Using the relevant group fixlets was the only way I could find… I initially assumed this would be it’s own inspector…
It’s not ideal, but I would consider pushing a Policy Action to each group, changing a clients setting to match the group name. Then you could code all of your other relevance based on the value of that client setting.
It does require one new action per each computer group, but they shouldn’t change frequently.
In my case, I usually go the reverse direction - basing group memberships off of a client setting, and then changing the value of that setting to move clients among the groups.
In this case the relevance can be used in actionscript so it really wouldn’t require an action per group. You should be able to just set the client setting equal to the result of you relevance query!
Bill, that’s exactly what I did…and I went one step further.
I check for the number of groups matching the proper pattern for the MW.
- If I find 0, I assume no window and delete all MW settings (my original intent), and log that status to a custom setting.
- If I find > 1, it’s a bad scenario and I delete all MW settings and log a FAIL status to the custom setting with a message about more than one group.
- If I find 1 group, I parse all of the relevant data FROM the group name (this client only uses monthly windows so day ordinal, day of week, start time), and I set the MW settings based on those values.
This policy checks and re-applies once an hour, enforcing all systems to adhere to the groups.
So, now instead of 20+ MW tasks targeted at 20+ MW groups, they have one single master maintenance window task actioned as a policy whose latest status is available in a custom setting / property. Love it!!!
Now, to add, move, delete maintenance windows, it’s a simple group operation. Very clean and efficient.
This could easily be expanded / enhanced to accommodate ANY type of maintenance windows.
Turns out all of this was a good thing!