I. Security

As with any application you write, security needs to be a major concern.
Because of the far reaching arm of the DynaGroups process, access control and security must be paramount.
This will require a full on game plan to insure that the management site, accounts and all processing servers are locked down. Any service accounts used to process Dynagroups need to be under the strictest of control and that the source code is written in a way that it limits the chance for exploitation.

The Hardware Environment
The minimal requirement would be two servers. One server for the web interface and one server for the processing server.
Since the web interface is probably the lowest when it comes to utilization it can possibly combined onto the processing server but it is not recommended.
This will allow the processing server to process without possibly affecting the web front end.
The perfect scenario would be multiple clustered front end web servers and multiple processing servers but that will depend on the size of your environment.
Due to the way it functions, a single processing server can actually handle DynaGroup processing of hundreds of groups with tens of thousands of members.
Additional servers will simply allow you to spread the wealth of processing to multiple servers.
These serves however should be correctly patched and updated so they are themselves secure.
Maintaining servers is beyond the scope of this document.

To note: The processing server will need to be configured so that it allows the ability to CRUD the running tasks on the processing server from the web server.
In a Windows environment this will require that RSAT and Power Shell is installed. To scope, this document will not cover these installations. In a linux environment it will require remote management of the cron jobs.