• State Suggested Answer
  • Locked Locked
  • Replies 4 replies
  • Answers 1 answer
  • Subscribers 61 subscribers
  • Views 5344 views
  • Users 0 members are here
Options
Related
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Question - ARS 6.9 Workflow How to Filter out a specific sub OU

dyannic
over 6 years ago

I have a compliance requirement.  All new server objects must be added to X policy filtering group in 3 of our AD's

I have workflow setup - to detect a computer created under domain\Xservers  (for which there are sub OU's for IIS/SQL/FILE/SharePoint ... etc

I want to filter out further processing on any new computer creation executed in the SharePoint OU.

Everything fires off fine - except the filter.    Unless I'm misunderstanding filters ... the workflow checks for new creation under the XServers OU and only begins the if/then policy blocks defined in the GUI - if it's under XServers AND not in a sub OU named SharePoint ...

Regardless of which path property of the target object I evaluate, SharePoint servers end up in the group like the other WinServers do.

Ideas on how to prevent the workflow from continuing past the initiate 'create' trigger - based on a word in the directory path to the object?

Parents
  • 0 over 6 years ago

    What was mentioned here - should have worked for me ...  The Computer object continued to be added to the policy filtering group  despite being filtered for an OU named W2K3 or SharePoint...  If I had a longer attention span -or more time to play before I had to implement. - I'd stay with it.    I fell back to script policy.   I had 3 domains to link this to - so I linked the policy to the windows server OU in each domain.   This is the last change I have to make in ARS 6.9 - as we are working to deploy ARS 7 in the coming weeks.

    ... and this is working.   Which - is like a plus, or something.

    function onPostCreate($Request)
{
    $strObjClass = $Request.Class
    if ($strObjClass -eq "computer")
{
[string]$strPath = $request.DN

if($strPath -notmatch "(SHAREPOINT|W2K3)"){
    $strGroup = "POLICYX Group"
    $strDOM = (($strPath -split "DC=",0)[1].split(",")).split()[0]
    add-qadgroupmember -identity "$strDOM\$strGroup" -Member $strPath -erroraction silentlycontinue -proxy
            }
        }
    }

    Edited to reduce footprint of the PS script

Reply
  • 0 over 6 years ago

    What was mentioned here - should have worked for me ...  The Computer object continued to be added to the policy filtering group  despite being filtered for an OU named W2K3 or SharePoint...  If I had a longer attention span -or more time to play before I had to implement. - I'd stay with it.    I fell back to script policy.   I had 3 domains to link this to - so I linked the policy to the windows server OU in each domain.   This is the last change I have to make in ARS 6.9 - as we are working to deploy ARS 7 in the coming weeks.

    ... and this is working.   Which - is like a plus, or something.

    function onPostCreate($Request)
{
    $strObjClass = $Request.Class
    if ($strObjClass -eq "computer")
{
[string]$strPath = $request.DN

if($strPath -notmatch "(SHAREPOINT|W2K3)"){
    $strGroup = "POLICYX Group"
    $strDOM = (($strPath -split "DC=",0)[1].split(",")).split()[0]
    add-qadgroupmember -identity "$strDOM\$strGroup" -Member $strPath -erroraction silentlycontinue -proxy
            }
        }
    }

    Edited to reduce footprint of the PS script

Children
No Data