Ever since virtualizing several physical servers into GCP, I have had an issue where anytime the servers(s) are rebooted the time is changed to be several hours ahead (I think it's 4 hours, but may be 6 hours). My local office is located in CST time zone and that is what we want the server to display. In GCP the virtual servers are in the us-central1a zone. On the virtual server, run the tzutil /g command it shows that the server is set to "central standard time". It also shows Central timezone if I click the clock on the toolbar then choosing "change date and time settings"
After the server has been rebooted (and reports wrong time) I can correct the time by clicking the "update now" options (found on toolbar clock, "change date and time settings", internet time tab, change settings" "update now" (this points to time server time.nist.gov).
This issue only began occurring after migrating into GCP so I believe it to be a Compute Engine issue and not an OS issue.
any thoughts on why this might be happening? I have this on occurring on all 4 windows servers that were migrated into Google Cloud. three are win2008r2, and one is Win2012r2
I appreciate any help that can be given to get this resolved, as I can't even reboot without connecting to the server afterwards and checking/fixing the time, I do have set a startup script to delay and then sync time after rebooting, but it has not worked 100% of the time, so this is more of a band-aid than a fix.
I do have set a startup script to delay and then sync time after rebooting, but it has not worked 100% of the time, so this is more of a band-aid
Getting this script working is probably the solution, here. For what it's worth, you'd need to do the same thing on both Azure and AWS as well, since they also set Windows timezones to UTC by default using the same mechanism.
See AWS docs on the Specialize Phase
See this Stackoverflow question for a similar question about Windows on Azure
Normally all servers run on UTC time, its clients (applications, browsers, etc) set their timezones according to where they are, and its up to them to translate UTC time to whichever locale they are in. (Put another way, you wouldn't want a server with a million client connections to have to keep track of each client's timezone in order to work properly). In your case, the bottom line is that requiring a custom timezone on the server will also require a custom server configuration, and the behavior you're seeing is by design. That's why your best bet is to understand why the startup script isn't working like you expect it to.
For reference, these docs may be helpful:
Google Compute Engine: Providing a startup script for Windows instances
Google Compute Engine: Creating a Windows Image
If you looked at the VM instance logs in the GCP Console you'd see that VM BIOS reports time in UTC
2019/10/3 14:9:44 Begin firmware boot time
After a while BIOS hands over to the bootloader
2019/10/3 14:9:45 End firmware boot time
Booting from Hard Disk 0...
The OS boots up. Behind the scene the OS time service recognizes the system timezone, then sets up and synchronizes time with the time source. From that time forward running programs and services report events based on the local system time:
...
2019/10/03 09:10:05 GCEWindowsAgent: GCE Agent Started (version 4.6.0#1)
In the Windows Event Log you should see entries made by the Time-Service:
Log Name: System
Source: Time-Service
Level: Information
The time provider NtpClient is currently receiving valid time data from metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).
The time service is now synchronizing the system time with the time source metadata.google.internal,0x1 (ntp.m|0x1|0.0.0.0:123->169.254.169.254:123).
In the command prompt you can ensure that the time configuration and state are correct:
C:\Users\user>systeminfo | find /i "Time"
System Boot Time: 10/3/2019, 9:09:49 AM
Time Zone: (UTC-06:00) Central Time (US & Canada)
Hence you don't need synchronizing time neither manually or with with a startup script. The time service will do it for you: to synchronize the system time right after the boot and to keep it in sync afterwards.
All you need is to set correct Time zone and the Internet time server for Windows, and then make sure the time server is reachable via the network.
Related
It seems to happen every couple months or so and while it auto-recovers on its own usually within ~10 minutes I'd still like to find out how to change the Windows Update schedule since it frequently occurs during business hours.
We have several web apps in various Azure subscriptions, and they all behave this way. Once we get a notification that one goes down, the others usually go down over the next few days/week.
I used remote desktop to view the Event Viewer for the web role and see the following (this down time took place between 9:48am and 10:02am on the east coast, so definitely not ideal):
8/6/2020 1:48:15 PM - "Automatic Updates is now paused."
Followed by several services stopping, and then:
8/6/2020 1:52:53 PM - "The process C:\43..61\Setup.exe (RD..33) has initiated the restart of computer RD..3 on behalf of user NT AUTHORITY\SYSTEM for the following reason: Other (Planned)
Reason Code: 0x80000000
Shutdown Type: restart
Comment: "
8/6/2020 1:52:53 PM - "Automatic Updates is now resumed."
8/6/2020 1:53:10 PM - "The operating system is shutting down at system time 2020-08-06T13:53:10.614704600Z."
8/6/2020 1:53:12 PM - The operating system started at system time 2020-08-06T13:53:12.487679900Z.
Obviously it takes a while for everything to come back up, and I finally get notified that the site is back up about 9 minutes later.
Is there a way to specify when the Windows Updates should take place?
I can tell you clearly that it is not possible to schedule windows updates.
The windows update in this cloud services is about once a month. The time is not fixed. There is no way to control this.
Azure Guest OS releases and SDK compatibility matrix
solution:
We can create 2 webroles so that we can solve the situation that the program is closed due to windows update.
principle:
Create 2 webroles to load balance the server pressure. When the windows is updated, it will not be updated at the same time, but a planned instance update ends, and the next instance update is performed.
In this way, as long as you create >=2 webrols, there will be 2 instances, so that the program can guarantee that it will not stop due to updates.
I want to create an Azure Virtual Machine that I only need to run approximately for 1 or 2 hours once or twice per day. I don't want to pay for the server when I'm not using it.
I know I can just go to the dashboard and shut it off, but I often forget to do so, I'm getting senile! I would like for a timer to start when the system (Windows 10) is started, and when the timer reaches zero, the image is made inactive (no charges incurred) unless I request more time.
Any ideas would be appreciated.
The dashboard has an automatic shutdown feature. This can also be configured to send a webhook notification with a link which will delay the shutdown. Currently in-machine notifications are not supported.
Although there are many tools like PowerShell scripts and apps that you could use from within the VM to trigger automatic shutdown, there are some billing gotchas to be aware of.
With an Azure VM, you pay per second and cease paying only when the machine is completely deallocated and no longer reserving memory and cores on the platform. (There is still a nominal storage charge associated with storage of the VM image). You cannot deallocate the VM from within itself.
To ensure the VM isn't incurring charges, check that the status is 'Stopped (deallocated').
I've got the following totally reproducible scenario, which I'm unable to understand:
There is a very simple application, which does nothing else than calling CreateObject("Word.Application"), that is creating an instance of MS Word for COM interop. This application is located on a Windows Terminal Server. The test case is to connect via RDP, execute the application and the application will output the time taken for the CreateObject call.
The problem now is that the execution time is significantly longer, if I connect from a specific notebook (HP Spectre): It takes 1,7s (+/- 0.1s).
If I connect from any other machine (notebook or desktop computer), then the execution time is between 0,2-0,4s.
The execution times don't depend on the used RDP account, or screen resolution, or local printers. I even did a fresh install of Windows on that HP notebook to rule out any other side-effects. It doesn't matter if the HP notebook is connected via WLAN or an USB network card. I'm at a loss understanding the 4x to 8x execution time difference to any other machine.
Which reason (component/setting) could explain this big difference in execution time?
Some additional information: I tried debugging the process using an API monitor and could see that >90% of the execution time is actually being spent between a call to RpcSend and RpcReceive. Unfortunately I can't make sense of this information.
It could be the credential management somehow being in the way.
Open the .rdp file with notepad and add
enablecredsspsupport:i:0
This setting determines whether RDP will use the Credential Security Support Provider (CredSSP) for authentication if it is available
Related documentation
https://learn.microsoft.com/en-us/previous-versions/windows/it-pro/windows-server-2008-R2-and-2008/ff393716%28v%3dws.10%29
According to your information about RpcSend and RpcReceive time consumption, it could be the case you have some service stopped on your client machine, like DCOM server or some other COM-related (they usually have "COM" or "transaction" in their names).
Some of that services could be started/stopped (if Manually mode selected) by system to/after transfer your request, but there is a time delay to starting service.
I suggest you to open Computer Management - Services or run -> services.msc and compare COM-related services running on your "slow" client and on your "fast" clients, and try to set Automatically running instead Manually or Disabled.
Also, try to run API Monitor on such processes to determine the time-consuming place more precisely.
I am running a LTI tool for my university LMS on a Windows 12 Server and it was failing today. It turned out that the server time was about 20 minutes ahead of the correct time and my tool was timing out.
It was synched with the windows.com time service, which was 20 minutes ahead, and so were the NIST time services available. I ended up unsynching and adjusting. I don't see anyone else with the same issue anywhere, and the NIST internet clocks all look correct.
What could possibly be the issue here?
Aha. My Windows Server is a VPS, so it does not really connect to any of the time services, but the time is probably set at the backend. So I contacted my VPS provider. Fortunately, it was not the timer service apocalypse.
During the teamwork development process that shares the same instance of Vagrant I always had trouble relaunching Vagrant Share due to it's session expiration. Documentation says that it's currently 1 hour (even though sometimes it worked only for 10-15 minutes). Is it possible to remove or extend session expiration time?
Currently (June 2016) the expiration time has been extended even more to 8 hours based on VagrantCloud's documentation:
Share sessions expire after a short time (currently 8 hours), but can
also be expired manually by ctrl-c from the sharing machine or via the
web interface.
However it doesn't seem to be any option to set the expiration interval yourself. And I don't believe it will ever be. The purpose of vagrant share is to share your work for a limited time just for your client to have a look or for your partners to do some testing and come back with feedback, not mid-term hosting.
It is not currently possible to change the vagrant share session expiration timeout.