With the current low prices for servers and the need for processing power, even a small company may end up with quite a few of them. If ten years ago it was still common to see an entire company using just one server, these days that's no longer the case.
New computers are added to the network with the understanding that they will be taken care of by the admins. Keeping an eye on these servers is a tedious, time-consuming process. Even with 5 minutes per server (to check the logs and other parameters), it may take an hour to make sure that everything is ok and no "red lights" are blinking on any of the servers.

In Scheduled tasks, delete the "ShadowVolumeCopy" commands that do not match the IDs listed in your results. Leave the matching commands in place and you will not lose your existing Shadow Copies.
x
65

George Simos
This error happened when I restored a Windows 2003 SBS Server (the SBS version is not relevant though, because this may happen to a non SBS Win 2003 server also). The issue was that the volume ID has changed after the disaster recovery procedure of backup exec.
There was a scheduled task for the Volume Shadow Copies of the Data Volume (D:) which has another ID in the new installation (despite that the data was not touched during and after the disaster recovery procedure). The O/S changed the volume ID and the task was not able to find the corresponding volume in order to run the scheduled snapshot activity.
Simply put I have checked the shadow copies properties of volume D: and checked that there is a task in Task scheduler. Then I deleted the obsolete task, which had the same volume ID as the event reported.
x
38

Robert Rupert
This event appears if you remove a volume when the Shadow Copies of Shared Folders feature is turned on. See Microsoft article ME833779 to fix this problem.
x
28

EventID.Net
- Error details: "Either the specified volume was not found or it is not a local volume" - From a newsgroup post: "Volume Shadow Copy is not recognizing the volume that it is supposed to save files on. This might be related with an Windows Server 2003 RC1 issue (this issue is gone in RTM). During the RC1 -> RTM upgrade, there might be some leftover bogus VSS tasks. Try these steps to fix the problem:
1) Disable shadow copy for all volumes (using the property dialog box of the volumes, "Shadow Copy" tab).
2) After that, open the Task Scheduler and delete all the remaining tasks that start with VSSxxxx (tasks for RC1 version of VSS) or ShadowCopyVolumeXXXX (tasks for RTM version of VSS).
3) Re-enable shadow copies for the volumes you want.
Now, you should not have any new VSS errors appearing in the event log".

- Error details: "Ran out of resources while running the command" - From a newsgroup post: "The issue is in volsnap.sys - allocating the memory data structures, might fail on very large volumes. This issue appears on very large NTFS volumes (terabytes in size) when the NTFS cluster size is 4-8K. We are actively working on a hotfix/KB for this issue (also this issue will be fixed in Win2k3 SP1). In the meantime, the only workaround that I know is this one:
1) Backup all data on your volume.
2) Reformat the volume with 16K or larger cluster size.
3) Restore the data on your volume".
x
32