Field Note Friday #001
As part of my commitment to bringing great quality content as well as technical hints, tips and scripts. This post is the first of my field note Friday series where I will share my experiences of the past week with everything from what has got me thinking to my problem solving activities.
The aim of this series is not only to share my field experiences and real world examples of ConfigMgr deployment but to also focus how I think myself. I think it will be a great exercise and I hope everyone learns something new.
Volume Snapshot Service Event Viewer Errors
I have seen this a few times before if I am honest but never really paid much attention to it. The reasons for this are mainly because we generally don’t monitor the desktop, it doesn’t appear to cause any specific problems and also we generally don’t backup the users desktop using VSS. However this error was pointed out to me again this week and I looked into it a bit further.
Volume Shadow Copy Service warning: VSS was denied
access to the root of volume <Volume ID>. Denying administrators from
accessing volume roots can cause many unexpected failures, and will prevent VSS
from functioning properly. Check security on the volume, and try the operation
What does this error mean? Well it means that VSS does not have access to the root volume to be able to use it if it was required. As I already mentioned most people reading this will have no or little use for VSS on the desktop but if you want to remove these errors simply issue the following command in an elevated command prompt.
icacls.exe <Volume> /grant system:f
Simply replace volume with the partition letter. So for example C: or D:. You could also run this in your task sequence with a run command line task sequence step or simply add it to the SMSTSPostAction variable which is new to ConfigMgr 2012 SP1. You can read up more on this variable from Jörgen Nilsson, fellow ConfigMgr consultant out in Sweden.
Error Messages are Not Always as They Appear
This really comes down to some core computing I learned a long time ago, take error messages at face value. It’s difficult though when an error message is telling you “hash verification failed”, you correctly assume this is in fact the problem and diagnose as needed.
However the actual cause of the problem more accurately may not be as advertised. What we would normally do here is distribute the package to the DPs again and possibly try again and everything works!
Remember though, as I forgot this week, this error has also been attributed to errors with memory in physical devices and also and more importantly problems with Cisco WAAS and Riverbed network devices. Make sure you collect as much information as possible to verify the actual message in the lesson here. I will have a post on this coming up soon.