![\"\"](\"https:\/\/www.aladan.net\/MIMicry\/wp-content\/uploads\/2018\/09\/set-madness.jpg\")
<\/p>\nSo… maybe you have a set like this:<\/p>\n
<\/p>\n
You might wonder exactly what “prior to today” actually means.\u00a0 Especially when it comes to timezone handling.\u00a0 And if you’re not wondering that, well you probably should be \ud83d\ude42<\/p>\n
First of all, remember that all your time DateTimes are (or at least should be) stored in UTC inside the MIM Service database.\u00a0 That’s the sensible approach, and the Portal will format your DateTimes correctly based on the configured timezone if you do.<\/p>\n
Anyway, back in the Portal and you’re clicking the “View Member” button.\u00a0 It’s not hard to work out that “prior to today” seems to actually mean “prior to now” there.\u00a0 Specifically, the UTC time in your attribute needs to be before the current UTC time.\u00a0 I’m not specifically<\/em> sure if that’s the web browser’s UTC time or the server’s UTC time, but in any sensible environment they’ll be the same anyway.<\/p>\n Here’s a quick look at the underlying Filter attribute to get a better understanding of that:<\/p>\n So it’s all about fn:current-dateTime().\u00a0 Cool.<\/p>\n So far so sensible.\u00a0 Now we know that temporal sets<\/strong> like this only get re-evaluated when the FIM_MaintainSetsJob runs on the SQL server.\u00a0 And here’s where the pain sets in – a user with accessExtensionExpiryDate prior to the current time appeared as a member just fine in the Portal, but when I ran the SQL agent job to recalculate my set membership the user object didn’t get added to the set.<\/p>\n After quite a bit of trial and error it appears that the SQL Agent job’s definition of “prior to now” is “before 1AM today in the local server time”.\u00a0 I can sort-of understand a decision to do the evaluation in local time – at some time someone decided that the job should just do the sensible thing, since “prior to today” inherently needs to know what “today” means, and using local server time is probably what MIM developers want, rather than “today” in the UTC sense.\u00a0 But the 1am threshold?\u00a0 That makes basically no sense to me.\u00a0 I can only guess it’s because FIM_MaintainSetsJob is configured to run at 1am by default.\u00a0 If that’s the case then hard-coding the definition of “today” to the time when a SQL job runs by default<\/em> isn’t my idea of sensible programming \ud83d\ude41<\/p>\n No wonder temporal sets cause headaches!<\/p>\n Addendum: if you really want to see what’s in your Set, LithnetRMA is your friend:<\/p>\n So… maybe you have a set like this: You might wonder exactly what “prior to today” actually means.\u00a0 Especially when it comes to timezone handling.\u00a0 And if you’re not wondering that, well you probably should be \ud83d\ude42 First of all, remember that all your time DateTimes are (or at least should be) stored in UTC…<\/span><\/p>\n![\"\"](\"https:\/\/www.aladan.net\/MIMicry\/wp-content\/uploads\/2018\/09\/set-filter.jpg\")
<\/p>\n(Search-Resources -XPath \"\/Set[DisplayName='My Lovely Set']\" -AttributesToGet @(\"ComputedMember\")).ComputedMember<\/pre>\n","protected":false},"excerpt":{"rendered":"