Windows ACI: Stu's weeping

That we will utilize Microsoft's Active Directory (AD) to manage our server instances and users (accounts and profiles) has been the assumption from the beginning of this experiment. How best to accomplish this is a very challenging question. Hence the label: "Stu's weeping".

There are several reasons for using AD as part of our management strategy. First, it facilitates a single sign-on (SSO) solution. Without it, users would first need to log into the TS Gateway and then to their individual Terminal Server instance. Second it allows us to centrally manage user accounts, user profiles, and user and server configurations via group policies. And it permits us to leverage our existing management practices and procedures.

If we moved to production and on average only supported 2-3 TS instances and 5-25 user accounts, well then this would probably be overkill. However, we believe that if successful, we will likely be supporting many TS server instances with potentially hundreds of user accounts.

We've spent the better part of the last several weeks working to figure out whether the better approach is to create an AD structure within the cloud or try and join our cloud based servers to the University's test AD forest, under the ICPSR Organizational Unit (OU). We believe the better route is to join them to our on premise AD but it has been more difficult than anticipated for a variety of reasons which I'll explain in the next post.

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.