I have my Windows 10 device locked down with UWF (Unified Write Filter) feature.
I noticed a strange behaviour when changing the system date and time while UWF is enabled and the volume C: is protected.
In particular I noticed that when i change the system date/time I can't go back in time more than 26 hours before the date/time that was set on the system when the UWF filter was enable.
To be more clear:
UWF filter is disabled
I set the system date/time to 25/10/2017 23:00
I enable UWF filter and restart
After the restart I set the system date/time to 22/10/2017 16:30
I restart the system
after the restart the date/time has been automatically restored to 25/10/2017 23:00
This behaviour doesn't seem to be bound to the Time Zone set on the system.I tested the behaviour from UTC-12 to UTC+14 and the result is always the same.
Has anyone experienced a similar problem or knows the reason that UWF doesn't allow to go back more than 26 hours?
Edit 1: After further tests we discovered that the 26 hours limit is granted by the registry key HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\TimeZoneInformation\RealTimeIsUniversal when it is set to 1.
If this key is not present or it's set to 0 then the hours limit varies depending on the Time Zone set on the system.
I can't comment or vote due to low rep but we have encountered this problem on both "Windows 8 Embedded Standard" and "Windows 10 v1607 LTSB Enterprise".
I don't have a solution, but this is our work-around...
We have a process in our factory which turns off the write filter, sets the time/date to somewhere in the year 2000 and then re-enables the write filter and flags the system such that when the customer receives it, the are forced to set the time/date for the first time. Note the flag and time/date UI upon first boot from factory is our own custom software.
This works because the time/date can be set forward (from time/date it was when the write filter was enabled) any amount, just not backwards.
I found out that you can in fact set the time backwards with the UWF enabled, but not further than the time last set without the UWF filter.
So if you have a system with the date September 2. 2018 adn then set UWF enabled, you can set the time forward a few years, and then back again at a later time, but if you try to set it further back than September 2. 2018 that will not work without disabling the UWF and adjusting the time there.
If this is by deisgn or a bug i do not know, but I guess it has some value to avoid users of a system with UWF to set the time further back then the time the system was set to when they received it.
Related
In my environment we are using Windows 10 Pro version for analytical applications. Sometimes unexplainedly time and date was going to back date.
We have changed the cmos battery, but after half a week of the analysis the date and time got changed again.
This type of issue may lead to data integrity issues.
Any suggestion on this is appreciated.
It may be, that Windows 10 updates the time and does not know where it is. It may then apply a different time zone.
I would turn off automatic date changes in the settings first and then see if this is the issue.
There is software that synchronizes the time with an atomic clock. This would probably be better if you rely on the time and have an internet connection available.
We have two domain controllers with windows server 2012 R2. My Timezone is set to +3:30 and I disabled the daylight savings. Daylight savings will add 1 hour to current time but I want it to be unchecked and add 1 hour manually to current time. After server reboot or a while my time goes back 1 hour!! NTP is disabled, Windows Time service is disabled. Why I can't set my clock manually?
I unplugged PDC from network and added 1 hour and reboot. the result was Ok. This shows that when PDC boots, it syncs clock with somewhere. How can I disable this?
Please help, My entire domain clock is in wrong time.
Thanks
you need to disable the external time source to stop updating system time.
you have two ways to fix this,
w32tm.exe /config /manualpeerlist:"127.0.0.1" /syncfromflags:manual /reliable:YES /update
or go to regedit
[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\W32Time\Parameters]
"NtpServer"="127.0.0.1"
this way you guarantee that your system have no external time source.
where (in the WMI?) is the timer located if the SCCM Client Agent 2007 is about to run a specific mandatory Advertisment?
I would like to shorten the 10 Minutes delay to some seconds with a Script or via a C# command. But not generally. Only if it has to be done urgent.
The message says "This program will begin running in xx minutes xx seconds"
I know that there exist a "ADV_RunNotificationCountdownDuration" in the CCM_SoftwareDistribution under the root\CCM\policy\machine\actualConfig, but this field is empty. And i dont know where the Actual Minutes left are stored.
Have you looked in the
System Center Configuration Manager 2007 Software Development Kit ?
You might want to look at IUIResourceMgr::ExecuteProgram Method
It should force the client to run the program immediately.
If you want to reduce the duration of the countdown, you can change the ADV_RunNotificationCountdownDuration value. Unfortunately it only takes effect after re-running the advertisments. Do take note, the value would revert back to your site settings once a policy refresh occurs.
On Windows XP, the OS will update file access times (if enabled, and it is on my system).
But...according to Microsoft:
"The NTFS file system delays updates to the last access time
for a file by up to 1 hour after the last access."
...and that doesn't just mean "delays updating disk-resident structures" ... no, for
some period after accessing a file then "last access time" will appear as it was before the access. Sometimes for seconds, sometimes for many minutes (haven't seen an hour yet).
Is there a way ("flush", "sync", or some utility or function) where I can tell Windows XP: hey, update all those unupdated file access times now?
I'm trying to determine how some old code works by tracking the files it accesses ... easy to do on most other OS's, but not Windows. (Yes, I'll also be using ProcMon.)
(I haven't researched this behaviour in newer versions of Windows yet.)
thanks,
Stan
I just found this answer on superuser.com that explains that fsutil can be used to disable the update delay on NTFS, at the cost of performance.
fsutil behavior set disablelastaccess 0
You have to reboot the system for the change to take effect (source).
I saw this question in a forum about how an application can be developed that can keep track of the installation date and show trial period expired after 30 days of usage. The only constraint is not to use the external storage of any kind.
Question: How to achieve this?
Thanks
Bala
--Edit
I think its easy to figure out the place to insert a question work. Anyway, I will write the question clearly. "external storage" means don't use any kind of storage like file, registry, network or anything. You only have your program.
Use the file-modified date of the file containing the program as the installation date.
I like Doug Currie's idea of the file-modification date. But if the application is downloaded from the web, every night at midnight it gets relinked with new initialized data containing the new expiration date. Then any binary downloaded that day expires on the date given.
If you like, sign the date with a private key so it can't be hacked. Include a public key in the app and decrypt the date. If not correctly signed, hasta la vista, baby.
I don't know if this is possible, as most work I've done has been with embedded systems in which I don't even need to touch the operating system. But would the following be possible?
When compiling your program, leave some extra space at the end (say, 8 bytes), all set to 0. When your application is run, it fetches those bytes and if they're all 0, replaces them with the current time (That's the part I'm not sure about. Does the OS let you do that? If not, there might be some work-arounds using multiple processes.), otherwise, if the time difference is greater than 30 days, it notifies the user that the trial period has ended.
Of course, that method would be vulnerable to resetting the system clock.
If you can't use any external storage at all (not even config files or anything like that), you would need to code it into the app itself so the app's main method (or some method) checks if the current date is less than some expiration date. Part of your installer could actually compile that code on the fly and then it would be set to the installation date. This could be easily defeated by reinstalling the app, but then again, it's not realistic to have no external storage either.
I think the only way to do this generally would be to have your application spawn something off in a separate process that would continue to run and keep track of the date/time even if the main application were closed. When it was restarted, it would then connect to the running process to see if the trial period had expired.
Of course, this would only work if the computer was never restarted and the user never hunted down your spawned process and killed it, which is pretty unlikely. If your application does not do anthing IO-related (file system, registry, something on the network etc.), then a simple restart will wipe away anything that you've done.
So, to summarize: it's not really possible.