My Crazy Adventures with RemoteFX, Part Two

[This is part two of the "My Crazy Adventures with RemoteFX" series] Back in Part 1, I left off just before describing what was needed to set up RemoteFX (in a VDI scenario). Let's dive into that now.

Software requirements

It shouldn't come as a shock that Windows Server is required for RemoteFX. Specifically, you'll need to install:

  • Windows Server 2008 R2 SP1 or higher (I am specifically covering Windows Server 2012)
  • Remote Desktop Services (see licensing below)
  • Hyper-V

Hardware requirements

While RemoteFX inherits its hardware compatibility from Windows itself, you will need two key pieces of hardware:

  • A processor capable of Second Level Address Translation (SLAT)*. Intel calls their implementation of this technology Extended Page Table (EPT). AMD instead chose Rapid Virtualization Indexing (RVI). Newer processors today have this technology; if you want to check if your processor is supported, use Sysinternals Coreinfo.
  • A DirectX 11* capable GPU (with WDDM 1.2 drivers). Previous versions of RemoteFX required a DirectX 10.0 card. But with RemoteFX's ability to now handle DirectX 11-class graphics, this requirement has been bumped up. If you're looking to color within the lines, you'll need to drop some serious cash for an officially supported video card (e.g. AMD FirePro). But in reality and in my testing, a consumer card -- like the Radeon 5970 HD -- will work slightly slower but otherwise operate just fine.

But wait, what do the little *s mean? Those stars mean these requirements can be bypassed, using some trickery. Using a non-SLAT processor, however, incurs a huge performance penalty and isn't worth the trouble. Bypassing the DirectX 11 requirement -- for say a DirectX 10 card -- isn't as crazy and could make sense in scenarios where DirectX 11 acceleration isn't needed. But that's a very dark cave to be wandering in. Get a newer card.

That said, Hyper-V on Windows Server 8 supports a software-emulated GPU that provides DirectX 11-class support without RemoteFX. I could not, however, convince my 3D applications it existed so won't be exploring that option further.

Licensing requirements

RemoteFX has no ties to the host OS's licensing status. But Because RemoteFX is ultimately a Remote Desktop Services (RDS) technology, RDS licensing applies. That means you need to obtain a license per client accessing the server and have a license server installed on your network somewhere. Per client in this case can mean either a device or user, depending on what makes sense. But don't let this scare you. RDS provides an ample 180-day (6 month) grace period before a license server needs to be installed. (After setting that up, you're afforded another 90 days in way of temporary access licenses.)

If you run out of time, you can of course purchase a retail copy of Windows Server and some RDS CALs. But for testing purposes, I would instead recommend looking into acquiring a MSDN subscription. With any level of subscription, you'll gain access to Windows Server and RDS CALs. (Just make sure you read the MSDN Terms of Use to ensure you're eligible.)

Looking forward

In the next post, I'll cover actual installation and configuration. Stay tuned!

Dissecting the //build/ Badge (Part 1)

If you were at //build/ this year, you probably remember tapping your badge on a reader before picking up your free Surface and Nokia Lumia 920 devices. It turns out, the badge hides NFC tech as opposed to that boring ol' RFID stuff. Tear down photos follow.

8168776248_f443bae6f7.jpg
8168777656_033c190f0c.jpg
8168778444_876ea786b7.jpg

But what secrets does it store within? Sadly, the tag doesn't appear to have been NDEF formatted so reading it with Windows Phone is out. (It is detected just fine, though.) I ordered an ACR122T reader/writer to lend a hand so check back in a week or so for the big reveal.

A closer look at the Windows 8 post-RTM update process

So, last week, Steven Sinofsky announced the availability of a cumulative update for Windows 8. Bundled with that announcement was some insight into what happens with fixes made after the OS goes gold (or RTM). Specifically, Sinofsky explained that certain fixes get delivered to OEMs prior to the public:

We would often create dozens of changes for each OEM for these new PCs. Those changes would be deployed during manufacturing of those PCs and thus would be invisible to customers. While those changes could potentially apply to a broader range of PCs, we did not have in place the testing and certification to broadly distribute these updates. As a result, customers would have to wait until the first service pack to see these enhancements.

He continued, indicating that with Windows 8 some internal processes changed, allowing Microsoft to deliver these updates sooner than general availability (GA):

During the final months of Windows 8 we challenged ourselves to create the tools and processes to be able to deliver these “post-RTM” updates sooner than a service pack. By developing better test automation and test coverage tools we are happy to say that Windows 8 will be totally up to date for all customers starting at General Availability. If you are an MSDN or enterprise customer, these updates will be available for your Windows 8 PCs via Windows Update as of today (October 9), following our standard cadence for Windows Updates on the second Tuesday of each month at about 10:00am.

Sounds good to me.

But let’s not fool ourselves into thinking this process is new. Gregg Keizer (Computerworld) fell into that trap, writing:

In Microsoft's terminology, RTM designates the point at which it considers the code completed, and ready to ship to computer makers for installing on new PCs. Microsoft has never updated a version of Windows between RTM and when the OS hits retail and PCs powered by it reach stores.

Matthew Siegler did too, mumbling:

Probably not the best sign in the world that Microsoft has to release service packs [sic] to the RTM version of Windows 8 before it has even launched. I mean, why declare RTM then? Well one possibility is that you’re working to meet a deadline rather than releasing when a product is fully baked.

Look, guys. Microsoft has been updating Windows in this manner for ages – at least since Windows Vista. That was so 6 years ago. To be more specific, Windows Vista saw a heap of updates, including the infamous Ultimate Extras pack, January 29, 2007 (a day before GA). Windows 7 received similar reliability updates on October 12, 2009 (10 days before GA).

Here's what the timelines look like, with the pre-GA/post-RTM release cadences in red:

What’s really new here is the delivery of updates previously reserved for OEM first use. (Ever wondered why OEMs had those atrocious software download pages with a weird assortment of Windows hotfixes?) It is the inclusion of these specific updates as part of the old patch delivery cycle that likely required the tooling and engineering improvements Sinofsky mentioned -- something definitely worth lauding.

Okay, maybe it's about app restrictions on Windows 8? Not that either.

[This is part 3 of the Minecraft/Windows saga. Go back and read part 1. Or part 2.] So if all this Minecraft noise isn't about closed marketplaces, then maybe it's about changes to how desktop applications get installed/run on Windows 8. That must be it, right?

Nope.

Windows 8 will run all your existing desktop applications from Windows 7. Windows 8 simply introduces new channels to advertise and obtain software for your PC. A common mistake is to confuse Windows 8 with Windows RT, a subset of Windows 8 tailored for devices (like how iOS is a subset of Mac OS).

Here's a chart showing app options available to users, starting with Windows 7. As you can see, Windows 8 didn't lose any features. To claim it's closed or more restrictive than Windows 7 is just completely bogus.

Rev 1: Changed marketplace accessibility row label, removing the 120 markets it's not clear if App Store reaches 120 markets. (Not likely.) Added the 120 number onto the value for Windows 8 in this row.

Maybe it's about closed marketplaces? Nope.

[This is part 2 of an on-going saga. Re-read part 1. Or move on to part 3.] Yesterday, I brain dumped in response to Notch's complaints on Twitter. My goal with that post was to point out that Microsoft reached out to Notch in a friendly attempt to get Minecraft listed in the Windows Store as a desktop app, not a "Metro" app. His reaction to the email appeared to be based on confusion surrounding how apps work on Windows 8 and the new Windows Store.

But a buddy of mine -- Leo Davidson -- suggested that I may have missed Notch's point, writing:

[...] he disagrees with the move to a model where Microsoft control[s] which [what] software people find [...] Rather than support that model, as easy as it might be for him, he would rather have nothing to do with it, even if it means his games reach a smaller audience as a result.

That would be a fair point, ... if Mojang AB wasn't already participating in identical models:

Rev 1: Added Amazon's App Store, thanks to reader Ian A.