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.

The Windows ACI: Decisions...

There are a number of technologies available for developing and managing virtual Windows computing environments. We decided to focus initially on products available from Microsoft and will then compare against the benefits of alternatives such as Citrix and VMWare.

The design we are considering would leverage the University of Michigan Active Directory (AD) infrastructure for user and computer account management. Residing in the cloud would be a public facing Remote Desktop (RD) Gateway through which users of this system would access their research group's ACI. Each ACI would be a Remote Desktop Services (RDS) server, formerly known as Terminal Server, configured based on the information provided by their PI through the ACI Chooser. The RD Gateway would validate the users credentials and redirect them to their assigned ACI.

This approach allows us to managed a single entry point for access to the cloud based resources and utilizing AD permits policy based management of the configuration of the Windows ACIs and associated user accounts. However a requirement of this approach is that a connection must be permitted to the UM network for the RD Gateway residing in the cloud. In the short term we are working with University engineers to permit this connection. Long term we will evaluate alternative approaches to facilitate this design, such as: using dedicated VPN appliance gateways to establish the connection; foregoing the connection to the UM AD and instead create an AD infrastructure in the cloud; and determine whether we should setup a Virtual Private Cloud (VPC) in the EC2 as an added layer for security. Right now our focus is on developing a working prototype RDS that can be tested by our PI and the ICPSR staff.

My next few blog posts will drill down in the merits of this design, its components and their roles, and the decisions required if we were to proceed with a production implementation of this approach.

Customizing an ACI

One of the tasks associated with bring up an ACI is configuring it for a particular group of researchers. There are (at least) three steps that have to be taken:

• create user accounts
• make required statistical software available
• copy the specified dataset(s) to the ACI

My plan was to create an archive containing the following pieces:

• a list of users for whom accounts needed to be created
• a list of statistical packages to be activated
• an inner archive containing the dataset(s)
• a script which would use the two lists to create accounts and activate software, and then expand the dataset archive

The ACI creation script would then pass that archive to the instance via the '--user-data-file' option of the 'ec2-run-instances' script. At first run, the ACI will fetch the user data, unpack it, and execute the included script.

Unfortunately, there is a 16,384-byte limit on the size of the user data, which meant that this approach was not practical.

My current idea is to create two archives. The main archive is as described above; the second is a bootstrap archive that will contain:

• a pointer to a location from which the main archive should be fetched
• a set of credentials that can be used to do that fetching
• a script that can use those credentials to fetch the specified archive

The bootstrap archive will be small enough to be passed to the instance via the '--user-data-file' option of the 'ec2-run-instances' script. At first run, the ACI will fetch the bootstrap archive, unpack it, and execute its included script, fetching the main archive. Once the main archive has been fetched, the credentials will be destroyed, the just-fetched archive will be unpacked, and its included script executed.

I'm working on that process now.

Clarifying the Cloud

In vacation weeks and those that follow, the group working on the Data in the Cloud do not usually meet. But we are always working on something....

A couple things of interest for this project include (1) what other services at ICPSR we have put in the cloud and (2) what resources Steve Burling (our 70% man ....we call him that because 70% of his time is dedicated to the project....it isn't meant to imply that he is only 70% of a man ...I think) are using to build the applications and images for this project.

First, a link to Bryan's ICPSR Tech blog about the other ICPSR services running in the cloud. On-going experiences with these service will be useful in monitoring service performance primarily. Bryan will keep us informed about problems or triumphs so we can evaluate other sources of information that will inform what we do. Synergy is fantastic, don't you think?

Second, Steve reports that these are the specific resources he has been using to build our ACI (remember this is our fancy acronym for the customized analytic space we are creating for users) in the cloud. The primary source is Amazon's documentation on the AWS service. In particular from there, he has used the Getting Started Guide, the Developer Guide, and the Command Line Reference.

ACI Chooser --- what a terrible name

We met today to decide how to put together the place where we gather information from the contract holder so that we can configure their space. I think that's what Bryan means by "Chooser" ---ugh. The inelegance of tech speak is legendary but this one is a real winner. The restricted contracting portal will already provide us with a great deal of information about the primary investigator that we can "populate" (another elegant use of a term) the forms with but we need to confirm the identity of the primary investigator and his/her research team. We will do that with an entry screen that confirms the identities through a MyData registration on the PI and a list of research team members and their emails. We then need to identify their choice of stat package and OS (the on-going argument between Steve Burling --our 70% man and Bryan is that almost 90% of the folks coming through this will choose a Windows environment as an OS and thus it makes both the OS choice and Burling an anachronism). We will also bring information from the RCS to determine the structure of the security for the data system the PI and team are accessing.

The things left to research are (1) how to bring users through to a firewalled entry to the site so that they do not have find and identify their IP addresses; (2) whether and how the PI would set up read/right permissions within the workspace for their affiliated researchers; (3) whether to allow content to be uploaded to the ACI without scrutiny. This research belongs to Steve.