""Conversion to local time" means adjusting the time from, say, UCT to EST. It doesn't imply that there will be an addition of 1600 years!" - sorry, don't understand it :(
I'm trying to do exactly this: "adjusting the time from, say, UCT to EST" : the UCT time = 0422 3:09:43, my local time = 3 hours ahead of UTC - there shouldn't be any addition of 1600 years - only 3 hours!
What if today were 0422? Shouldn't I be able to get my local time in 422 (in any calendar)?
...maybe you mean that 0422 3:09:43 is not UCT time and that's the reason why Windows adds 4 hours instead of 3?
Oh, it's weird... my reply to your last comment is missing...
1) Thank you very much for the interesting articles!
2) All enabled user accounts that don't have PasswordLastSet have no metadata at all:
...so I think it's just the "remnants" of the migration process from old domain controllers to the new ones (it was ~in 2014). The main problem here is the LastLogonDate: for ALL accounts without PLS it is more recent then 2014... if those accounts have never been used since 2014 why their lastLogonDate is NOT ~2014 (later then 2014) ?
Regards,
Michael
As far as I understand the key point in this problem is that the "...next log generation" is NOT created:
According to the timing on the screenshot above the new log generation had to be created after ~11:56:39 AM (backup was started at 11:31 AM), but Exchange continued using the old log generation - am I getting it right?
Regards,
Michael
ErlandSommarskog, thank you so much for the explanation!!!
Regards,
Michael