AccountExpires attribute and UTC/Time issues.

Forums › IT Pro and developers › AccountExpires attribute and UTC/Time issues.

Aaroona

3130 posts

Uber Geek

#143804 28-Apr-2014 07:50

I'm busy building a Powershell script that will report on accounts that are soon to expire, where it collects the usernames and emails the managers.

All of the script is built, however I'm having a couple of issues where the dates are being converted to different values to what I'm expecting.

My understanding is that it gets converted from UTC/FileTime to local time, however, we are spread across NZ and AU, so a few different time zones. Therefore the time that my colleague in Sydney puts in, is 2 hours different to the one I entered, despite being the same value in AD.

Therefore, 28th February actually shows as the 1st March when pulled using powershell and converted.

Aside from using a query which will filter results such as "if 2 hours a head of time, move it back 2 hours", is there any way to fix/work around the issue?

Inphinity

2759 posts

Uber Geek

Subscriber

#1032337 28-Apr-2014 08:35

Well, the accountExpires property in AD is a numeric value giving the number of 100-nanosecond intervals after Jan 1st, 1601 UTC, that the account expires. So what method are you using to convert this back to a human-readable datestamp? This would be the step in which you convert it to the correct timezone.

Pluralsight

Learn cloud, mobile, security, data and web technologies with Pluralsight (affiliate link).

Aaroona

3130 posts

Uber Geek

#1032350 28-Apr-2014 08:56

That is a good question - I'm using Quest cmdlets and it looks like that does the converting itself. I tried using the -dontconverttofriendlyrepresentation flag, but it didn't seem to dump the raw data.

stefankrz

20 posts

Geek

#1037138 5-May-2014 16:36

you could grab accounts expiring over a particular day period which would simplify time zone issues

this would get you all the accounts that are expiring tomorrow
Get-QADUser -AccountExpiresafter (get-date).AddDays(1) -AccountExpiresBefore (get-date).AddDays(2)

Aaroona

3130 posts

Uber Geek

#1052834 25-May-2014 15:02

stefankrz: you could grab accounts expiring over a particular day period which would simplify time zone issues

this would get you all the accounts that are expiring tomorrow
Get-QADUser -AccountExpiresafter (get-date).AddDays(1) -AccountExpiresBefore (get-date).AddDays(2)

Thanks for the reply... unfortunately that's not going to work in the way I'm applying it.

Basically, I'm running a report for Managers, which will email them the details of their employees, i.e. the contract end date we have listed. Because of the time issue when my colleagues extend the accounts from Australia, the time gets messed up by a couple of hours, which in turn reports as the following day, which then results in the Manager logging a call saying "please change" despite the fact it's actually already set correctly.

hopefully that makes sense..?

Might just have to work around it by doing some If $date.time -eq 2am, then correct back one day and format to strong dd-mm-yyyy.

I only have to cater for two time zones, Perth and NSW, so might just bite the bullet and see if it works.