A Windows Stage 1 Sync (or a Host Sync) fails with an error similar to :
RSP_SYNC_ERROR SYNC_ERROR_SNAPSHOT STATUS_ERROR
Details: Failed to take snapshot: Microsoft DiskShadow version 1.0 Copyright (C) 2007 Microsoft Corporation On computer: HSKPWCLDS008, 1/4/2021 2:21:59 PM -> set context persistent -> add volume \\?\Volume{8550ab22-1b1c-11e3-8d85-806e6f6e6963}\ provider {b5946137-7b9f-4925-af80-51abd60b20d6} alias snap0 -> add volume \\?\Volume{ba1ed544-1ba8-11e3-91a1-0050568651ef}\ provider {b7946137-7b9f-4925-af80-51abd60b20d5} alias snap1 -> add volume \\?\Volume{8550ab20-1b1c-11e3-8d85-806e6f6e6964}\ provider {b5946137-7b9f-4925-af80-51abd60b20d2} alias snap2 -> add volume \\?\Volume{8550ab1f-1b1c-11e3-8d85-806e6f6e6961}\ provider {b7946137-7b9f-4925-af80-51abd60b20d5} alias snap3 -> create (4)
jobid file: /var/log/rackware/by-jobid/00000000000cefb1.log
Afterwards, 'vssadmin list writers' shows the WMI Writer and the System Writer to be in a Failed state.
Possible Solutions:
1) Issue the command "vssadmin list shadowstorage".
If the response is
vssadmin Add ShadowStorage /for=c: /on=c: /MaxSize=15%
2) Check the amount of free space on each of the drives being sync'ed. This can be done by ssh'ing to the source server and issuing the command 'wmic logicaldisk get caption, size, freespace'.
If any of the drives show 0 bytes free space (or even an amount slightly greater than 0), then the issue is that there is not enough space on the drive to hold a snapshot, thus the RMM was not able to take a snapshot. The solution then is to add additional space to the drive (or remove some files from the drive) so that there is free space. We recommend having 15% of the Used Space on the drive available as free space.
Note that while the vss writers 'WMI Writer' and 'System Writer' end up in the Failed state when the drives have 0 bytes free space, moving them back to the Stable state by rebooting the server will not prevent the failure, if there is still no free space on one of the drives being sync'ed.
This is different than if you see an error containing 'Selected writer "System Writer" is in a failed state' and 'VSS_WS_FAILED_AT_FREEZE'; in that case rebooting the server to get the vss writers back to the Stable state will prevent the failure.
3) There are also Windows snapshot related failures that occur because of resource issues on the source server or problems with vss itself. The Windows System Event Log and/or Windows Application Event Log mayke have errors in them pointing out the issue.
To get the Windows System Event log, from the RMM issue the command
scp <Userid>@<ip addr>:/cygdrive/c/windows/system32/winevt/Logs/system.evtx /tmp/system.evtx
where Userid is the userid that is used to ssh to the windows server, and 'ip addr' is the ip address of the windows server
At this point /tmp/system.evtx is on your RMM. Give it read permission with the command "chmod 454 /tmp/system.evtx"
Copy the system.evtx file to a Windows PC and look at it with the Event Viewer from Control Panel. Look for records in that file from around the time of the snapshot-related failure.
Keep in mind that the RMM may be in a different time zone than the source host. Issue a 'date' command on the RMM and on the source host to see if they are in different time zones.
To get the Windows Application Event log, from the RMM issue the command
scp <Userid>@<ip addr>:/cygdrive/c/windows/system32/winevt/Logs/application.evtx /tmp/application.evtx
where Userid is the userid that is used to ssh to the windows server, and 'ip addr' is the ip address of the windows server
At this point /tmp/application.evtx is on your RMM. Give it read permission with the command "chmod 454 /tmp/application.evtx"
Copy the application.evtx file to a Windows PC and look at it with the Event Viewer from Control Panel. Look for records in that file from around the time of the snapshot-related failure.
Keep in mind that the RMM may be in a different time zone than the source host. Issue a 'date' command on the RMM and on the source host to see if they are in different time zones.