Fredrik and I had the opportunity to build a proof of concept environment showcasing various aspects of federated web SSO for a customer. The requirements, while not overly strict, mandated that we build an environment consisting of three federation parties: One resource partner hosting some form of claims-aware web application and the remaining two acting as account partners supplying users.
Before building an environment like this it is helpful to have something to run it on and therefore part one of this epic series we will focus on the set up of the environment and how we right at the start got completely sidetracked by some new features in System Center Virtual Machine Manager (SCVMM).
We started out with a HP ML370 with a quad-core CPU, 6 GB of RAM and a total of 290 GB disc. Techies as we are we unanimously decided that it wouldn’t be enough to run our entire Hyper-V based demo environment. One phone call and a few hours later we were at 20 GB of RAM. And if Joachim at this point hadn’t dragged up the System Center Virtual Machine Manager beta and its ESX managing capabilities we would have started building the demo right then and there. Like children in a toy store we said “Demo? What demo?” to each other and rushed off to commandeer a HP ML350 with a quad-core CPU, 12 GB of RAM , 438 GB disc for a VM Ware ESX installation.
The only thing that disturbed our nerd nirvana was the networking aspect which consisted of a really old and slow DLINK switch that can at best be described as cute. It just had to go.
All your base are belong to us (the virtual machines)
After we figured out the virtual machine template feature in SVCMM our environment quickly got taken over by a horde of virtual machines. To the tune of Baby one more time by Britney Spears we deployed virtual machines like Darth Vader deployed Tie Fighters in episode 2 (or was it 5?). This lead to the inevitable: overload!
After some cleaning up we started configuring our demo environment, which we will tell you about in the forthcoming episodes.