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.
Related
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.
I am working on an application for our IT support team. For one of the requirement, I need to find out the manufacturing date of a laptop (and some desktops). I did some googling and found some solutions but none of them are feasible in my case:
Serial Number : get the serial number from the back of the machine and access the vendor's site with given serial number and get all the details.
-> This is not going to work because there are hundreds of machines and from many vendors like Dell, HP, Lenovo, etc.
Operating System : I can extract all the OS level info by using "systeminfo.exe". There is a field called "Original Install Date" which will give a date when OS was installed on the machine.
-> This is also not going to work for me because whenever a laptop is assigned to a new user, it is being formatted and fresh OS image is being deployed so everything this date will change.
BIOS : In one of the articles it is being stated that because BIOS is installed as soon as the assembly is finished so it can provide the most accurate date when the machine was ready to end user use after installing OS. So I have used "Win32_Bios" WMI class to extract this data.
-> The problem with this approach is whenever any BIOS version upgrade happens, this BIOS date is also getting modified, so I cannot get the real manufacturing date of the machine.
Last approach, I thought if I can get the processor manufacturing date then I might get some approximate date when the machine came into existence. I checked Device Manager --> Processors --> Properties.
-> Problem with this approach is, I am seeing the version and date of the processor driver and not the real processor and this date is showing way back from 2006
I would really appreciate if someone please share their views or experiences regarding the above situation.
I know this kind of the question has been asked before and it has been closed down because people thought it is not very interesting topic to discuss so I really request to all please do not close this question. Let's give a chance to everyone to share their views.
Thanks.
I have a script, which monitors some folder's subfolders, check their created date, and if DateDiff from created time and Now is more than 730(2 years) it deletes this folders. The problem is in that, if set current time on PC for 5/16/2015 - the script will delete folders, and it's not cool. I thought about getting time from some internet service, but there is no guarantee that PC will be connected to internet. So I tried to get BIOS time (I believe no users can change it to wrong), and compare folder's created time with this time. But, unfortunately I didn't find the way how to do that. Maybe you have any idea how to implement this task?
Having an incorrect date and time on a production-level machine is not an option nowadays. It will break a lot of things like HTTPS sites (they will fail to validate because of expired certificates), etc.
The system clock (BIOS time) is changed by the operating system whenever the time itself is changed in the OS, so you only have one clock in the computer. In other words the OS does not have a separate clock to track time with.
Nowadays most computers use the Network Time Protocol to keep their clocks in sync, so you should specify the correctly set time as a pre-requisite for your software. (Or you can just specify that the computer must be connected to an external atomic clock, but that's going to be expensive.)
I have a simulator application which writes some enrypted data into a text file. The information that it writes also has the timestamp (which the application picks from system time) along with it which I can not see. I have automated this whole task of sending random data from application to the text file but I want that the records must be written with some time interval in between.
For this I can either put delay in my automation script or I can change the system time every time a new record is inserted.
If I adopt the second approach i.e. I programatically change the system time very frequently (about once in every second) would it cause any harmful effect on the Windows system on which I am running this application ? Would any other critical system processes get affected by it ? Is this approach advisable ?
The best option here is just going to be putting in a delay in the automation script. I can't think of any problems that would arise from changing the system clock every second, but it's best just to let that be handled by the CMOS and any time syncing instead of setting it to change every second.
Changing the System Time might solve your problem, but at the same time it might have adverse affects on time dependent other applications sharing the same System. For example, the automatic antivirus signature updates are time dependent and might get impacted by explicitly changing the System Time or an automatic System Time adjustment for day light saving might get triggered at an inappropriate time. Keeping this issue in mind, the best bet would be to ensure that your application runs on an isolated environment i.e. ensure that other time dependent applications are not present in the same system and also to ensure that auto updates are kept off.
Changing the system time requires administrative privileges, so users of your application will be unable to run it as ordinary users.
I have node-locked licensing working, using the MAC address and system time. We're concerned that people will just edit their system date to extend a license, so I've tried getting the real date from an machine in the NTP pool. That works, but then obviously you can't use the product without being online, and it doesn't seem to be 100% reliable (I'm guessing the UDP packet never arrives/returns in some cases).
What's the standard approach here? Live with the changeable OS date? Run something on a web server that provides the time over TCP? I hear the BIOS date gets updated by the OS when you reboot, so perhaps there isn't any way to know for sure what the current date is without using the internet?
I know that licensing can never be completely secure, and I expect it to be cracked or torrented, but I don't want it to be as easy as changing the system date. Any ideas appreciated. Thanks
Using a hard disk drive serial number in addition to the date would be more difficult to bypass. You can also have it limited to the user login name. Other than having a hardware dongle, software licensing can always be circumvented.
Update:
If that's the case, can't you just monitor the time? Create an algorithm that validates the system clock follows a logical progression (always increasing.) If the date ever suddenly get shifted back more than a specified amount of time (you have to account for some drift and internet time server corrections), you disable the program until the user restores the clock?