Main manual is here.

But it can be easier. Download the latest 2008 R2 SP1 (or newer if available). Install only Remote Desktop Session Host.

Then select "Do not require Network Level Authentication". Terminal, that receives IP from DHCP, boots by network and downloads configs by TFTP, can say nothing about him. If you want security, use smart cards.

All other default values will do.

Install, reboot. Then specify Control Panel - Administrative Tools - Remote Desktop Services - Remote Desktop Session Host Configuration - ... Limit Maximum Color Depth 32 bit. Remote FX works with color not less than 32 bit. Also in terminal configuration file specify bpp=32.

The last one. To enable RemoteFX compression:

1. Log on to RDSH-SRV as a member of the local Administrators group.
2. Click Start, click Run, type gpedit.msc and then click OK.
3. Navigate to Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment.
4. Double-click Configure RemoteFX, click Enabled, and then click OK.

Reboot server. Connect wtware terminal to server and view terminal log. If in last log lines you'll see line "RemoteFX compression", then it works:

Here are some testing results. For tests we used video file 720p, size 1.5Gb, 43 minutes video. Test terminal is on i510mo (intel atom 1.66GHz). Network 1Gbit.

RemoteFX has two settings on server. Both are available using gpedit.msc, they are in Computer Configuration\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Remote Session Environment\Optimize visual experience when using RemoteFX

Image quality is set by Screen Image quality.

Highest: for image of highest quality. Full-screen video in 1280x1024 resolution consumes 2.5% of gigabit network bandwidth. It shows 4-10 frames per second (fps) depending on image contents, video is shown stepwise. Screen capture rate doesn't help to increase framerate, for terminal can't process more data, terminal CPU usage is 100%.

Medium (default): 9-12 fps, 2% of network bandwidth. Screen capture rate is set to Highest, terminal CPU usage is 100%.

Lowest: 10-13 fps, 1.5% of network bandwidth. Screen capture rate is set to Highest, terminal CPU usage is 100%. Image with no significant defects. Not as distinct as with Highest image quality, but it's quite enough to watch movie and work.

WTware doesn't use videocard while RemoteFX decoding, all work is performed by processor. Codec code is written in SSE and is optimized. It would be interesting to compare with other terminal clients, but how to find out real framerate on client: video player shows 24 frames with any Screen Image quality value.

Result 1: Screen capture rate can be set to Highest, anyway real replay speed is limited by terminal processor.

Result 2: Intel Atom 1.6GHz is not so great. Windows Aero and other graphically loaded technologies are waiting for us, and terminal processor will have to draw all of them. It makes no sense to buy terminals on weaker processors than Intel Atom, i.e. forget about Geode VIA and AMD.

We took another video file for tests, significantly LOWER quality, than in test before: 512x384, 650Mb, 50 minutes.

In screen 1:1 video is ideal, with Screen Image quality : Highest it shows the same 30 frames per second as it is recorded. Just like while playing on local computer. Terminal CPU usage is 60-70%.

Full screen mode with Screen Image quality : Lowest gives 4-5 frames per second. For image consists of squares (stretched pixels of original image in low resolution), and squares with sharp color borders are hardly compressed by RemoteFX codec. Video with higher quality in earlier test gave more frames per second.

Result 3: playback speed DEPENDS A LOT from what is played.

One more notice. RemoteFX codec is very demanding to terminal server processor. If other applications load the processor, it's not enough for encoding video and frame frequency lowers. Player doesn't see it and says that video plays with full frequency with no lost frames. Perhaps, there's no way to accurately estimate frame frequency, that user will see on terminal.