Copying files over RDP that are larger than 2G

Ran across this nice little gem today.  I was trying to copy a file to my personal server that I got from a friend so I could do some work to it.  I kept getting the error “unspecified error.”


After a quick Bing search, it turns out this is a known error.  In fact, here is the KB article from Microsoft.  Short version:  copying files across an RDP connection by right-clicking the file on your desktop then choosing copy in the RDP screen (aka clipboard redirection) is not supported.  You’ll need to map the drive to the remote computer using the RDP client as the KB article suggests.



If you get this blue screen during installation of Windows, one of the most likely causes is bad media.  Replace your DVD or download a new ISO image.

If you get this error installing Windows 7 in a VMWare Workstation virtual machine, VMWare has that “easy install” feature were you can type in the product key in VMWare’s set up screen before installation of Windows starts (as well as specify username and password).  Make double sure you have a legitimate product key.



The Windows Directory Consumes a Lot of Disk Space

I got a call from a colleague who was asking why the Windows directory on a Windows Server 2008 R2 machine was taking up almost 40GB of disk space.  I checked one of my servers and noticed almost the same – about 30GB on mine.  He noticed more readily than I did because his Windows install was on a partitioned drive where the C volume was only 60GB.  I, however, do not practice partitioning drives.  If I want more volumes, I get more drives. 

After some research, we noticed that the WinSXS fold was the culprit.  He was about to delete the folder when I asked him to stop.  I found it hard to believe this folder was so large just for the fun of it so I did some research.  I found many blogs and so forth that “tried” to explain the WinSXS folder, but most failed horribly.  As always, if you want the low down you have to go to the source.  I found this post on the Microsoft Ask The Core Team blog that did a fantastic job of explaining the WinSXS folder.  I highly recommend giving this post a full read.  You should also subscribe to the Ask The Core Team blog.

There are some things you can do to combat this problem.  I recommend the following:

  • Do not partition out a single drive into multiple partitions.  If you want your OS on one volume and your data on another volume, then get multiple drives and place one set of drives in one volume for the OS and the rest of the drives in a volume for data.  For example, you could do a RAID 1 for the OS and a RAID 5 for data.  This way, you’ll always have plenty of room for the OS.  Partitioning one drive into multiple volumes, in my opinion, makes little sense any more.
  • Install only those applications you need on the computer.  The more applications you install, the more your C drive will fill up.  The same is true for Windows features.  Install only those you need.
  • Run the disk cleanup wizard.
  • You can free up some space by removing the roll back files for the last service pack you installed.

That last point bears some discussion.  When you install a service pack for Windows, you can always uninstall it.  This is made possible by the fact that Windows stores copies of the original files replaced by the service pack in the WinSXS folder.  If you have been running the service pack for a while and are very confident you will never need to uninstall it, you can remove the backup files which will make the service pack permanent (you can’t remove it).  On one of my systems, this freed up 10GB of disk space.

For Windows Server 2008 and Windows Vista after installing Service Pack 1:
Open a command prompt and run the command VSP1CLN.EXE.  This file is found in the %windir%\system32\ directory.

For Windows Server 2008 and Windows Vista after installing Service Pack 2:
Open a command prompt and run the command COMPCLN.EXE. This file is found in the %windir%\system32\ directory.

For Windows Server 2008 R2 and Windows 7 after installing Service Pack 1:
Open a command prompt and run the command DSIM.exe /online /Cleanup-Image /spsuperseded

Again, be reminded that should you run any of the commands above, the service pack will become permanent.  You will not be able to uninstall it.  However, you will free up some pretty significant disk space.  Be certain to test on a test machine before running this on a production computer.


Recovering from a Lost SUSDB

Imagine the following scenario:

  • You installed the Windows Internal Database role on Server 2008 64-bit.
  • You installed the WSUS role on the same server and set it to use the Windows Internal Database.
  • One day, you notice WSUS is not giving out updates and you cannot start the WSUS management console.  It tells you that SQL may not be started on the machine.

If your SUSDB has become corrupt, you cannot access WSUS.  Furthermore, you cannot uninstall WSUS.  And, as if matters can’t get even worse, you cannot uninstall the Windows Internal Database since WSUS is dependent on it.  Fortunately, you can resolve this issue by re-creating the SUSDB.  First, log on to your Windows Internal database using SQL Server Management Studio Express 2005 or higher.  If the SUSDB is listed, then delete it.  You will then need to go to the following location to remove the files:


Delete the SUSDB database and log file.

Next, open up the following SQL file in SQL Server Management Studio Express and execute it to recreate the database:

%windir%\program files\update services\database\createdatabase.sql

This file will create and empty SUSDB database.  Once this is done, you can now remove WSUS from your server and re-install it if you need it back.  I recommend reinstallation as that will put your settings back in place like you had them.  Remember, the SUSDB you just created is empty with no tables in it.

I hope this information helps.  If anyone has a better solution, please add it to the comments section.


Raymond Chen: The TEMP Directory

Mr. Raymond Chen of Microsoft has made an interesting post on his blog regarding the TEMP directory in Windows.  In his post, he states that “The TEMP directory is a dumping ground of random junk.”  He’s quite correct.  Many programs, including installers, use the TEMP directory for storing temporary data.  Unfortunately, there are many programs who use the TEMP directory for permanent storage. 

Obviously, as time moves on, some of these programs are bound to bump heads as they copy files with the same name, etc. to that same directory.  The most common issue I have seen is installations failing because of stuff left behind from previous installs.

Fortunately, there is a fix that I have found works often.  Use the disk cleanup tool in Windows.  Open up Windows Explorer, go to My Computer, and then right-click your C drive and choose Properties.  You should see a button called Disk Cleanup right there on the General tab.  You will want to change some of the options for the Disk Cleanup tool to make sure it does get temporary files. 

Once you run the wizard, you should have a few Gigs back on your drive and the issue with files in the TEMP folder interfering with new installs should be mitigated.



How Windows Handles Applying Service Packs and Patches

My programming god, Raymond Chen, has written an article on TechNet Magazine about how everything is kept straight and organized when you apply security patches and service packs to Windows 7.  It’s a great read.  He doesn’t cover all the details, but he does cover some interesting bits.  Check out the article here:


One Group of Users, Two Terminal Servers, and Two GPO’s in one Group Policy Container

Imagine you have the following situation:  You have a group of users who need to access two different terminal servers.  If both machines required the same settings, that would be a no-brainer, but this isn’t the case.  One terminal server requires a certain set of Group Policy Settings and the other terminal server requires different settings (in my case, the settings in question were the start-up application).  And both servers are members of the same GPO.  How do we handle this situation?

Although there are probably a few solutions to this problem, the one I used was implementing a WMI – Windows Management Instrumentation – filter. 

Open the Group Policy Management Console and go to Forest | Domains | Domain Name | WMI Filters and create a new filter.


The two filters I created are called WMI Legacy Terminal Server and WMI New Terminal Server.  Edit the WMI filter you just made and enter the following WMI Query statement:

SELECT * FROM Win32_ComputerSystem WHERE Name = “servername” and Name <> “servername”

Your screen should show something like this (don’t forget to replace “servername” with the names of your servers):


The statement should give away what we are doing.  We are going to apply a filter to each of the two GPO’s so it will process only for a computer matching the name of the server we want.  Therefore, for one Group Policy Container, we are going to have two terminal servers and two GPO’s that are all members of that one container but only a certain GPO will execute for a certain terminal server.  After you have made your two filters, click on the Group Policy Objects in question and apply the correct filter.  Your screen should look something like this:


So when User A logs on to the Legacy Terminal Server, one GPO will be applied (in my case start up application X), but when logging into the New Terminal Server, another GPO will be applied (in my case starting up application Y). 

One significant drawback to this approach is that each GPO can have only one filter.  Make certain this isn’t of significance to you before using this approach.