I recently had a situation where I had a single folder with 50,000+ files in it (uploaded motion detection JPEG images from a surveillance camera), and I needed to split them up into folders by month to make it manageable. I wanted to look at the Last Modified Date of the file, and send it into its respective folder (i.e. 2009-02, 2009-03, etc).

Out of that came this simple little utility that does just that. I've ended up using it for a few situations so thought I'd go ahead and share it. This is written in .NET, so the .NET framework is required.

Download the utility

Instructions (also in instructions.txt):

This utility will take files in a folder, say, C:Temp, and move files based on their Last Modified date into "monthly" folders.

For example, if two files exist in C:Temp, file1.txt, and file2.txt, and the first was last modified in January 2009, and the second last modified in April 2009, this utility will move them into two respective folders:


By default, it will run in read-only mode, and not actually do anything with the files unless the -noReadOnly parameter is used.

Usage: filefolderdateorganizer "C:Temp" -noReadOnly

This is fairly Network 101, but I created it for our internal knowledge base anyway, and figured it might be useful.

Follow the following procedure to move a shared folder from one drive to another.

Note: The hard part about this is migrating permissions with the files. Using normal "copy" utilities to copy or move the data without the correct options can result in permissions not being applied correctly at the destination.

Part 1 - Copy the Data
Do not move the data, as if something occurs in a "move" operation, half the file structure can be located at Point A and the other half coule be located at Point B, leaving you a mess to clean up. Better to do a successful Copy then delete the source after a few days once you're confident everything has been transferred successfully.

  1. Copy the directory / permissions structure using XCOPY.Go to a command prompt, and issue the following command (tailor to your needs):

    xcopy "C:Source Folder" "D:Destination Folder" /O /E /F /Y /T

    The /T command ensures that you are only copying the folder structure and not actual files within the folders. For more XCOPY commands, use xcopy /?

  2. Using SyncToy (google for "SyncToy" and download the utility), synchronize the source and destination folders together.

Part 2 - Move the Shares

  1. Remove the current Share names.Go to Start > Run... and type compmgmt.msc

    Under the Shared Folders node, expand it to show "Shares". Right click on the Shares node and click the Export List... menu option.

    IMPORTANT: If there are specific permissions settings on each Share entry, make a note of them.

    Once you've saved the list of shares to a file, right click the shares that were previously associated with the source folder you copied, and click Stop Sharing. This will remove the share from the list.

  2. Recreate the exact share names again, with the destination folders.Open Windows Explorer (right click Start and go to Explore) and navigate to your newly copied folders. Refer to the exported list you created in Step 1 to re-create the shares with their exact names.
  3. Set the correct Share permissions (not normal Windows Security) on the "Sharing" tab of the folder properties. This is normally "Full Control" for "Authenticated Users".

If you have moved the shares correctly, using the same names, clients mapped to drives using the \serverShareName will not notice any interruption or change, and no change will need to be made on the client side.

This happened a few weeks ago, on a short one-off application that I wrote.

Here's the situation: ASP.NET web application hosting a web service. I just needed a minimal database, so used a SQL Express database, with the .MDF file contained within the ASP.NET application (connection string .SQLEXPRESS... yada yada).

On our production domain, we use a service account for Windows Authentication, which does not have interactive logon privileges (i.e. this is not an account we use to log on to the servers).

Gotcha #1 - SQL Express needs to rock some temporary data in C:Documents and Settings

My first surprise was that SQL Express could not create an instance because it needed to do some magic in the User folder (in this case it would have been C:Documents and Settings<service account here> etc etc). No problem, I enabled interactive logon for the service account just to get it up and running, logged on once to set up the profile goodness, and off we go.

Gotcha #2 - This is only temporary

To my surprise, I thought after logging on once with the service account once, creating the user profile, et al, we'd be good. No, that's not how technology works. A few days later it stopped working again. Log back on, and we're good.

So, when using SQL Server Express with service accounts, be careful and make sure that the user profile path is available!