I won’t go into great detail here but in short, if VSSAdmin is not letting you delete shadow copies and is throwing this message:
Error: Snapshots were found, but they were outside of your allowed context. Try removing them with the backup application which created them.
There is another (less safe…) program called DiskShadow which will.
It’s built into windows server… and using it to get rid of pesky shadow copies that won’t otherwise goes away looks like this:
DISKSHADOW> Delete Shadows All
and away they go…
One of the best blog articles I came across that details both VSSADMIN and DiskShadow tool and why VSSAdmin sometimes falls short is here:
I regularly use the Microsoft Windows sysprep tool to create template Windows Server 2012 R2 systems for wider deploy using cloning. Sysprep is used to modify a pre-configured Windows system and create an image or “template” so that you can create unique copies of it for faster system deployment. Failure to use syprep before cloning a windows machine can cause odd issues, especially in an enterprise environment with Active Directory.
Sysprep is a wonderful tool but it has a few quirks. One such quirk is that it routinely wipes out all of the mounted drive information other than the system drive. This means every time you create a clone from a sysprep’d system image you have to go through and re-assign drive letters. This is fine on a simple server with one extra data server. This is a hassle on a database server which might have five extra drives.
After dealing with this again recently I finally decided to do a google search and came across a simple solution: (more…)
I will keep this short and sweet. We have servers in our environment that have multiple IP addresses assigned to a single NIC. That’s normally just fine. However on occasion I will have very strange issues occur where essentially all networking appears to be working and yet web browsing won’t work. I can ping my default gateway, ping other systems in the same subnet, telnet out on port 80 and 443, etc, etc. But the network connectivity still behaves oddly. What’s the issue?
It all has to do with networking logic decisions made many years ago (I believe as far back as Windows Server 2000) by someone at Microsoft. (more…)
One of the items I had to do a bit of digging to find was the location of the startup folder for all users.
If you aren’t familiar with the “startup” folder on your system I will explain it briefly.
The startup folder is a place you can put executable files (.exe), batch files (.bat), etc. that you want Windows to run every time a user logs into the system. There are a lot of usage scenarios for such a folder, my specific use case is mapping a remote windows share as a drive, for which I use a batch file. (more…)