Deprov - Sleep

Looks to be down to the syntax type, the attributes I tried this on were GeneralizedTime

I tried both just setting the date using the OOTB calculation and with script, both were populated with a UTC value in there:

Script

OOTB

The script I used was super basic

 function Return-Date()
 {
     [string]$Time = Get-Date -format HH:mm:ss
     
     return $Time
 }

Huuuuum might need to rethink some of this. It might not be an issue, but So UserA has a time stamp and then say 10 mins later UserB runs it then stamps both accounts with the same time as UserB. Might need to look at this a different way. 

Hi Craig

Depending on how the Automation Workflow is configured, you're correct. If you had no control/criteria for a set of users to be included in the setting of the date/time value, yes run 1 of the workflow might set "UserA" to 16:55, but Run  2 ten minutes later which now included "UserA" and "UserB" would set the time to 17:05

SO you might consider modifying the filter condition in your "Search" activity, to filter the objects returned by the search so that if AttributeA = "Deprovison" and "Azure-Deprovision-DateTime" is empty. Naturally your filter could be whatever condition you need.

Top man that works. On the filter i set the Azure-Deprovision-Date-Time attribute and set it to is empty. It now stamps only new accounts and leaves the originals as is. I am learning so much about ARS again today. 100% loving it. 

So now i have UserA and UserB and UserC all in the managed unit all with different times they were run. This is fantastic. I have another workflow that is searching for users in the same managed unit  and is running the deprovision step. I just need this to only run on accounts that have a time stamp 45 mins or more from the time the deprov runs. Anything that has been in there say 30 mins will get picked up on the next cycles. This is the bit i am 100% not sure on how to achieve.  Can you call the deprov process from a powershell script? 

Save yourself the headache of doing the time calculation and just drop the user from the Managed Unit once you have processed them by clearing the original VA?  Unless you need them to hang around?

Yes you can - Deprovision-QADUser cmdlet.

In your script activity, you would initially need to do the math on your timestamp attribute to determine whether the above command should be fired.

Just be sure you to structure script in such a way that it's intended to be run on each object returned by the search.

The way you get the object name for each iteration is like this:

$CurrentObjectFromSearch = $workflow.FoundObject("My Search Name").get("distinguishedName")

Hi mate. Yeah i need them to hang around long enough in that managed unit for the Azure AD connect sync to run which I think is every 30 mins. Thats why I just need that second workflow to only action accounts that have been in there for 45 mins or more. 

I guess another way I might be able to tackle this Is have a scheduled task script that checks Azure AD for the user accounts in the managed unit. when it returns that the account has been removed from all groups that it sets another virtual attribute to TRUE which in turns adds the account another managed unit. Then I just have the scheduled task deprovision work flow run every 20 mins as technically if your in that managed unit then you have done the Azure parts. 

sound better / easier than dealing with dates and times? 

Hi Stu.Pollock I am actually going to look at this. Part 1 we have working now. 

So part 1

Custom command which sets a VA to TRUE. This put the account in the Managed Unit and removes the account from all the Azure groups. Within 30 mins Azure AD connect will run and do the Azure parts. 

Now I think what you have suggested is the best way to look at running Part 2 which is the deprovision step. What i would like to do and i think its similar to your suggestion. I don't want to disable anything just yet. 

However as a step of Part 1 I can have another attribute AD attribute and synchronise this to Azure AD via the AD Connect. That part is not a problem. The bit i am unsure about is your step 4. Are you saying i need an AD attribute and also AR VA? or is this custom VA already created? 

If we can clarify step 4

What i am thinking is that this VA that comes back as part of the back Sync is that i can link that to Managed Unit and then have the deprov work flow run every 20 mins or so. As if i am following right the account wont have the VA set until it comes back as part of the back sync. If this is correct then i am on to a winner with this. 

Thanks for your help so and your suggestion. I think this is the best step

Edit / Update 1: So I have the AD attribute from onPrem AD that I am now synchronising up to Azure AD via the AD Connect.

Edit / Update 2: When i look in Sync Service I can see that i now have extension_GUID-HERE_Name-Of-My-onPrem-Attribute. I have Forward Sync rule from that attribute in to another AR VA. However when the Sync run the attribute does not get updated? Am i supposed to to the extension_ attribute in Azure AD as an attribute i can select? 

Edit / update 3. I’ve got this working now. When I setup sync service I must had set it up in a manual way. Went back and used the back sync wizard and everything made sense to me. Thanks for your help. I now have a solution that is based on sync times rather than me trying to second guess with sleep scripts.