They always seem to open maximized, glued to the upper left-hand corner of my monitor. I hate that. After much googling, I found:

http://www.simmonsconsulting.com/2005/09/26/remote-desktop-rdp-window-state/

http://msdn.microsoft.com/en-us/library/ms632612(VS.85).aspx

and

http://blogs.msdn.com/rds/archive/2008/09/02/specifying-the-ts-client-start-location-on-the-virtual-desktop.aspx

These settings work for me:

desktopwidth:i:1600
desktopheight:i:1200
session bpp:i:32

I have a 2560x1600 display, so I like my sessions to be 1600x1200.

winposstr:s:0,1,500,200,2560,1600

1st is always set to zero according to the MS Blog post.
2nd is 1 because I like my remote sessions windowed. Often I have multiple connections open at once.
3rd is 500 because I want my window offset 500 pixels from the left of my primary monitor.
4th is 200 because I want my window offset 200 pixels from the top of my primary monitor.
5th and 6th are kinda funny. They are supposed to represent the bottom right coordinate of the window, so I would expect them to be the top left offset plus the window size. Setting them to 2100 and 1400 should make the window fully sized given my window size and offsets, but I guess it doesn't work that way. Maybe you have to compensate for the frame of the window itself. I found that there is no harm at all in simply setting the size to something larger than the window to assure that it is fully sized. So, I set these values to the size of my largest display.

As the author of the first article mentions, you need to use a text editor that won't corrupt the header of the RDP file. Notepad2 did NOT corrupt it, nor did BeyondCompare 3. TextPad 5.2 did corrupt it.

BeyondCompare 3 was a great way to fix the rest of my RDP files. I just pasted most of the contents of my new, working file over to the files that needed to be fixed, letting only the fulladdress and username fields remain.

The Event Log shows: "Volume Shadow Copy Service error: An internal inconsistency was detected in trying to contact shadow copy service writers."

I noticed that if, at a command prompt, I ran "vssadmin list writers", I got nothing back. I was under the impression that all the VSS-compatible writers should be listed, such as SQL Server.

This was KILLING ME all morning. I'd been running backups just fine on this server for the longest time, and it stopped working. I think it was related to my uninstallation of Windows Desktop Search 4.0, but the KB article related to that didn't help. Maybe it was some update? Other articles and forum posts suggesting that I stop the VSS and SWPRV services and register a bunch of DLLs didn't help either.

Finally I found the solution. Well, it worked for me anyway. It was a variation of a forum post I found in google's cache. Here's what I did:

1. Remove the registry key "HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}". You should probably export it first so you can restore it if this doesn't work for you.
2. Reboot.
3. The key is re-created.
4. "vssadmin list writers" returns several writers.
5. The Backup Utility no longer hangs on "Preparing to backup using shadow copy..." longer than maybe 20 seconds. The backup runs normally now!

This server is a VMWare virtual machine, in case that matters.