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.