VSS restarting the windows server 2019

Robin 6 Reputation points
2020-12-23T21:50:23.053+00:00

We have a windows server 2019 and we noticed that it restarted twice in a day automatically once at 7AM and second 12PM.

It only started happening after 11 December 2020. I checked the event schedular and saw that there is Volome shadow copy scheduled at the exact same time and when I ran this task, it restarted the server. I re register the VSS but still the issue is there, also checked VSS writes, all are in stable condition. Is there any way to stop this issue ?

Windows Server 2019
Windows Server 2019
A Microsoft server operating system that supports enterprise-level management updated to data storage.
3,457 questions
0 comments No comments
{count} votes

7 answers

Sort by: Most helpful
  1. Mico Mi 1,921 Reputation points
    2020-12-24T07:26:40.21+00:00

    Hi,
    If you have any progress, please feel free to feedback.
    Best regards,
    Mico Mi

    0 comments No comments

  2. Alex Fleener 1 Reputation point
    2021-01-05T20:47:30.14+00:00

    I started having the same issue back in October 2020 after applying Microsoft Server 2019 monthly updates. Removing the updates only temporally fixed the issue because as soon as the next monthly updates rolled out, November 2020, the issue came back. I looks to be some type of conflict, between new MS updates, VSS with a symptom of our Servers rebooting themselves at 7:AM and 12:PM (per Shadow Copy schedules). I was able to verify the Server's reboot time by checking Event Viewer, System Log, and filtering for critical Kernel Power events. You may also want to check Event Viewer, Application Log and filter for VSS. To remedy the issue: You will want to open up Shadow Copy config and remove all schedules. Then take a look at your Task Scheduler and delete or disable any Shadow Copy, VSS entries. Once these steps have being completed I would recommend running Shadow Copy configuration and setup your new schedules. I set my Shadow Copy schedule to run once, every day, at 4:AM. Then verify the next day, say 7:AM for any Event Viewer for Kernel Power critical issues.