Windows Server 2008 R2 will be 64-bit only. Think about what this means for terminal services!

Yes, Windows Server 2008 R2 will be 64 bit only. But what if Microsoft is able to enhance the set of filter drivers integrated into the platform in a way that 32 bit apps believe they are running on 32 bit Windows? If you look at the stuff the Microsoft OS guys are already doing with redirecting file and registry access, I truly believe that it is possible to "fool" 32 bit apps.

Most of us already know this technology since there is install mode and execute mode for TS, modifying the standard behaviour of the application runtime environment through a filter driver called TsAppCmp.dll. With this experinece and with an App-V team in the background, why should MS not be able to make the 64 bit platform truly compatible to 32 bit apps? And I'm not talking about true integration of App-V into the standard OS platform.

Just my two cents...

Benny

not a single 32 bit app i have in the edu world has complained about being ran under 64bit 2008 terminal services...

and a few of them that are 64bit are happpy since they can eat more resources

I think that Benny has a good point. This goes the same way like we had with the 16 bits apps on the 32 bits OS, only a few problems and there's always a way to fix this.

Thanks Brian I agree with you "h*** Sh**"

When talking about 64 bit terminal services, application compatibility is not the problem. That lies elsewhere: as I have detailed in the sixth part of my seven part article on Windows x64 (blogs.sepago.de/.../windows-x64-all-the-same-yet-very-different-part-6), all (OS | application) installation and system management scripts must be reviewed and tested. Many of your existing scripts will not run without modification due to out of process COM objects not being present as both 32 and 64 bit binaries.

And then there is printing. Even though 32 bit print servers can host 64 bit drivers, it may in practice be advisable to set up an additional 64 bit printing infrastructure.

These and other topics amount to quite some work, which is why so few (large) organizations have moved to 64 bit terminal services (including Citrix PS/XA, of course). This huge effort may even stall the adoption of 2008 R2 terminal servers.

Please do not get me wrong:

1) This mostly applies to larger organizations with complex infrastructures.

2) Windows x64 is a great platform. Once you are there, you can reap the benefits. But getting there is the hard part.

I agree on the fact that there will be dificulties in the transistion, however i also see a trend where products tend to hold on till the last minute.

What i mean is that, knowing now that Windows Server 2008 R2 will only be 64-bit also sends a signal to the vendors with driver compatibility issues etc. that they cannot wait forever. The date is set.. Sure there will be hesitations but i think knowing the fact that 32-bit OS is coming to an end from Microsoft is going to cause a good development in drivers, apps etc. Vendors will join the 64-bit ranks and we will all reap the benefits :-)

From a historical point of view i think we cant really do anything, but prepare, and find the benefits. And for the Apps that does not run under 64bit there will always be VDI? ;-)

Rene Vester

With the Virtulization space as big as it is today, there is should be NO worries about x32, x16 etc.. etc.. really.  Load up Vmware, HyperV then install Win08, Win08 R2, Win03, XP, Linux and choose the appropriate OS for your application.   What I want to see from MS is say that Windows 7 will also be x64 only and not only that but Windows 7 will be running ontop of HyperV by default on all installs meaning you could also run a second OS say, Windows Xp for x32 compatibility, think of what that would mean. I can dream right?

I still believe x64 application compatibility is a killer depending on your environment. No x64 App-V client pretty much kills adoption for several of my clients and then if I look at copy protection schemes I have a bunch of applications that need creative hosting solutions.

I know it's not the end of the world but introducing a x64 OS will complicate application hosting and the support / management surrounding these applications. To me if I can avoid a client hosted VM such as MED-V or another custom Citrix silo by holding back on x64 I see the merit in not moving forward. To me it's not all about server consolidation and if I need to go that way VMware can virtualize a bunch of x86 hosts on a big box and call it a day.

I see the market being rather close to a x64 mass transition but I still don't see it being a compelling platform for the masses just yet.

I think the problem areas are elsewhere on server apps, as 32 bit apps generally are OK on x64 OS, just taking a little more memory.  But just as Microsoft forced Exchange to be 64bit only we should expect other "servers" to follow suit.  For example, IIS will (probably) need to be 64 bit only.  I don't really know what that will do to all of the stuff that people host.  SQL.  Great Plains?  SharePoint?  and so on...

You are right that Windows Server 2008 R2 will be 64-bit only. But this refers to the supported processor architecture.

Windows Server 2008 R2 will still enable 32-bit applications to be executed through WoW64 as in Windows Server 2003 x64 Edition.

So there is no need to worry about application compatibility. Just be sure to know your way around x64 and its pitfalls.

Nicholas.

This will really inpact high-impact printing environments who depend on 32bit drivers matching exactly for the both the client and server in situations where the UPD comes up short.

I can see a lot of applications being weened off of TS and migrated to Virtual Desktops for that reason alone.

A quiet "Dear John" letter to Citrix as 32bit users are nudged to Virtual Desktops instead of TS?

A UPD solution covering both client and session/network printers takes care of the x86/x64 printing issues.

Almost everyone (Quest, ThinPrint, Tricerat, Uniprint etc) have a comprehensive UPD printing solution for TS, x86 or x64.

Maybe if the XenApp developers weren't spread so thin Citrix would have one too.

While the UPD works for "most" there are a lot of environments where the UPD does not provide the full funtionality of the printers and is a total show stopper. Same goes for any of the third-party prints solutions.

Multiple trays, diferent paper configs per drawer, multiple feeders....something always gets missed with the UPD.

In my environment, we rely heavily on the OEM drivers from the printer vendor as there is no subsititute.

Besides, if I have to go spend more money to keep the same funtionality, then it's time to re-eval the  value of the product and service.

Oh well, just got reminded of this as I tried to install R2 beta using VMWare Fusion on a 32-bit Macbook Pro ..... :(

Time to upgrade the laptop to 64-bit .....