Windows ACI: Terminal Server

Our 'concept' Windows ACI is using Windows Terminal Services. This technology, renamed Remote Desktop Services with the release of Windows Server 2008 R2, has been available as a service/role of the Windows Server operating systems since NT. Its maturity has allowed for a great deal of documentation to be developed about managing it, the quirks, and its strengths and weaknesses. This provided us a sort of head start to assessing the challenges of leveraging it to delivery the robust environment we have envisioned. We are not using the R2 version, hence we continue to refer to it as Terminal Server, due to the fact that Server 2008 R2 is not supported (at least currently) by the major cloud computing service providers. That is fine as it does not appear that any of the enhancements or features provided with the R2 release offer any additional value to our project.

Terminal Server is Microsoft's solution for server based computing (SBC). I find that ironic given it was Microsoft's popularization of desktop computing that lead to it replacing the original SBC... the mainframe. Using SBC allows us to provision access to requested research data by instead focusing on providing the working environment for the researchers to perform their analysis. Researchers can remotely access a server we create for them. Once logged in, they are provided a standard Windows-style desktop with the tools and applications they require to perform their work, using a copy of the requested data. The remote session or connection to the server will appear as just another 'window' on their own desktop or laptop computer. They will not be able to move items to/from the remote server to their computer, but will be able to interact with all the applications installed on the server as they normally would.

The question of course is can we satisfy our security requirements while giving the researcher a rich environment with good performance?

Windows ACI: Concept or Prototype?

I'm not certain which descriptor fits but regardless we have in place a test version of our Windows ACI. At this point its a pretty basic setup of a Windows 2008 server configured to perform the Terminal Server role. I've installed three of the statistical software packages used here at ICPSR along with a few productivity applications such as Word and Excel. Test data has been placed on the device. We are using a mandatory user profile and researchers will connect to their ACIs via a separate Windows 2008 server configured as a Terminal Server Gateway. Its our intent that the TS Gateway will be the only Internet accessible device but we are still working out all the assorted details.

Felicia is current giving it a test spin and I am developing a questionnaire intended to capture observations from testers of the system. This document will likely evolve as we proceed.

I think concept is probably more accurate as this test ACI is extremely rough around the edges and will most assuredly change a great deal before we begin piloting.

What we've been doing during our spring break

The blog has been quiet, but the team has been busy working on components of the system.

Steve has built a prototype of our ACI Chooser, the web application that enables a researcher to link an executed restricted-use contract with ACI preferences, such as operating system, stat package, etc.

Steve has also built an early version of the ACI Launcher. This tool uses preferences set by the researcher, and builds an AWS instance to support the research. The tool also enforces ICPSR's license and access controls related to the research data.

Unlike the world of Linux where it has been pretty easy to define and launch a locked-down, managed AWS instance, the world of Windows has been more difficult. Since joining ICPSR earlier this year, Stu has made great progress building an early version of a Windows-flavored ACI to go along with the Linux-flavored one Steve has already built. Stu has also been researching the best way to tie our ACIs with necessary Windows infrastructure, like Active Directory. We often see Stu weeping, and we are not sure if it is with joy or frustration.