Are Recycle Bins Wasting a Lot of Space on Your Windows Servers?

You might not know it, but Recycle Bins could be taking up a considerable amount of space on your Windows servers. This might not be a concern on newer beefed-up servers built with 10GB to 12GB OS partitions. However, if you have older servers with 4GB OS partitions for instance, regaining even a few hundred megabytes of space could be the difference between a functional system and an unstable one. Even if you have a lot of space on your servers, you probably don’t want to leave Recycle Bins full of deleted files, especially if the files might contain sensitive information (e.g., administrators', executives', managers', or HR staff members' Recycle Bins).

To monitor the space consumption of Recycle Bins, I wrote RecycleBinInfo.vbs. This script produces a Microsoft Excel spreadsheet that reports on how much disk space is being used by the Recycle Bins on a server and how much space is available on that server's local hard drive. The script doesn’t just report on the Recycle Bins located on the C drives; it reports on all local hard drives. So for example, if there’s a Recycle Bin on a server's F drive, you’ll also receive information about that Recycle Bin. Before I describe how to use RecycleBinInfo.vbs and how it works, you need to know about the temporary SID database that the script creates.

The SID Database
When a user deletes a file, the file is stored in the Recycle Bin on the user's local computer. The server that users log on to contains the Recycler folder, which contains each user's Recycle Bin. In the Recycler folder, Recycle Bins are named after users' SIDs rather than their user IDs, which makes it difficult to identify the users that the Recycle Bins belong to. So, RecycleBinInfo.vbs uses ActiveX Data Objects (ADO) disconnected recordsets to create a temporary SID database. This database is an XML file that contains SIDs, user IDs, and SID types that have been obtained from a domain controller (DC). RecycleBinInfo.vbs uses this database to get the user IDs associated with the SIDs. If there isn't a user ID associated with a SID, the amount of disk space used will still appear for that SID in the report. The SID just won’t have a user ID associated with it.

Two situations can result in a missing user ID:

• As you probably know, SIDs are used for not only domain accounts but also local accounts. However, because the SID database contains only domain accounts and any local accounts on the DC used to populate the database, the user ID will be blank if the SID refers to a local account on a member server. Most systems administrators restrict the creation of local accounts on member servers, so when the report is produced, you’ll probably see only a few SIDs with no associated user IDs. One account that will undoubtedly be blank will belong to the local administrator of the member server, which you can easily identify because any SID ending in -500 refers to the Local Administrator account.
• When a SID belongs to a deleted account, the user ID will be missing. There's an advantage to this situation: The script provides you with a means of identifying old and unnecessary folders that you can delete.

RecycleBinInfo.vbs uses the same SID database used by the UpdateSIDdb.vbs script, which I discuss in "Turn On, Tune In, and Disconnect, Part 1" and "Turn On, Tune In, and Disconnect, Part 2." If you currently use UpdateSIDdb.vbs to maintain a SID database, you can have RecycleBinInfo.vbs use that database. (I explain how in the "How to Use RecycleBinInfo.vbs" section.)

How to Use RecycleBinInfo.vbs
You can download RecycleBinInfo.vbs by clicking the Download the Code Here button near the top of the page. You need to run this script with a Domain Admins–level account on a machine running Excel. If you're running the script on Windows Vista, see the sidebar "Vista's UAC Can Cause Problems When Writing and Running Scripts." RecycleBinInfo.vbs is set up to use the C:\Temp folder as the location for the SID database. You can modify the script to use another location, but you need to make sure that all references to C:\Temp in the script are changed to the path you selected. Before you run RecycleBinInfo.vbs, you need to do the following:

1. Create a text file that contains a list of the servers on which you want to check the Recycler folder. This input file should contain just the names of the servers. Each server name needs to be on a separate line. In RecycleBinInfo.vbs, the input file's path and filename are hard-coded as C:\Temp\RecyclerMasterList.txt, but you can change the filename and store the file in any folder you want.
2. Customize the MasterComputerSIDSource variable. In the line

MasterComputerSIDSource = "DomainControllerName"

replace DomainControllerName with the name of your closest DC. If the SID database already exists in your network because you regularly run UpdateSIDdb.vbs, replace DomainControllerName with the name of the DC that you specified in UpdateSIDdb.vbs.

3. Customize the RecyclerServerList variable. In the line

RecyclerServerList = "C:\Temp\RecyclerMasterList.txt"

replace C:\Temp\RecyclerMasterList.txt with your input file's path and filename. If you named your input file RecyclerMasterList.txt and you stored it in the C:\Temp folder you can leave this line as is.

How RecycleBinInfo.vbs Works
Let’s take a look at RecycleBinInfo.vbs to see how the code comes together. Listing 1 shows the main block of code in this script. I begin RecycleBinInfo.vbs by declaring and setting the variables and constants and disabling error handling. One of the variables being set is FileString, which contains the SID database's path and filename. Instead of naming the SID database solely after the DC name stored in the MasterComputerSIDSource variable, I opted to add a little more description to the database's filename by adding DRS- (short for disconnected recordset) in front of the DC's name and -SID after the DC's name. So, the database's filename is DRS-DomainControllerName-SID.xml, where DomainControllerName is your DC's name. As the line

FileString = "C:\Temp\DRS-" & MasterComputerSIDSource & "-SID.xml"

shows, the database resides in the C:\Temp folder.

Next, the script ascertains the name of the user's domain and assigns it the DomName variable. This variable is used later to search the database for specific SIDs. You might be wondering why the domain is needed. After all, SIDs are supposed to be unique, so why not just search for the SID? After doing some tests, I found that SIDs aren’t necessarily unique when it comes to member servers. In my domain, I found two identical SIDs on two member servers—and those SIDs referred to different users.