VDI: Xenith Pro Endpoints and Imprivata SSO High Availability

This is the first in, I imagine, a series of articles regarding VDI processes, lessons learned, tech issues overcome, etc. as it relates to my experience planning, configuring, deploying, and managing a Virtual Desktop Infrastructure roll out.
One issue that had cropped up after the pilot deployment was how fail over of single sign-on (SSO) authentication would work on the 0-client endpoints that use the ProveID Web API calls to the SSO infrastructure (2 Imprivata appliances, single site).  On the Windows side, HA was built in to the agent, whereas it downloads the SSO topology from an appliance after agent install.  Appliance failovers are seamless and Offline mode is configured to prevent authentication failure even if both appliances go offline.  However, all documentation on the ProveID side was sparse from Imprivata and further research did not reveal any answers to these questions:

Q. If the appliance configured in 'OneSignServer=https://<servername or IP> SignOn=yes' is down, will the endpoint go into an offline mode? Will it fail over to another appliance?
A. The answer is no to both. You will not be able to authenticate after the endpoint boots.  A visual cue is that the Imprivata logo will be missing from the logon box.

Q. Does the entry for OneSignServer accept multiple servers then?  If so, what is the syntax?
A. Yes, you can specify multiple servers.

OneSignServer=https://server1.domain.com,server2.domain.com SignOn=yes

Note: You can use a comma or semi-colon for separation.  Do not add the https:// to additional servers.

A GUI front-end for your Powershell scripts!

     I've recently discovered that it is possible to create a windows form for your powershell script.  As it just so happens, I've recently started creating scripts to automate tasks that are run by non-techhies.  Right now, all they can do is kick off the script that already contains all the necessary information and then sends an email with the results. I am starting to rework these scripts to include a GUI interface which will give them the ability to set their own options and also provide them instant feedback of the result without having to wait for an email.

•  Get PrimalForms (Community Edition) from here.
• You will use this tool to design the form and modify the attributes of the controls.  It will then generate the powershell script.

• Edit the powershell script to make the controls do something with your favorite ISE

It's actually not too difficult to learn to make your scripts work from button clicks or to read input from a text box.  I'm not a big VB guy but I hear that in some cases, you can make the same program with powershell with a lot less code.

So is Powershell still just for scripting?

Stateless Servers

  For a few months now, I have been learning all about the stateless server architecture as I will be one of six analysts supporting it when my employer chooses a vendor and purchases the hardware as part of our virtual server and desktop initiative.  Its a great technology that I thought I'd write a little about.

State of the Union a Server
  Let's learn about what stateless servers are by learning what a stateful server is.
What I am referring to when I say "state" is the settings of all the different components of a server.  Some of these are:

• BIOS Settings
• Boot Order
• CPU Settings
• Power Settings
• Etc...
• RAID Settings
• Fiber Channel Adapter Settings
• WWN
• Boot From SAN
• NIC Settings
• Speed/Duplex
• IP Address
• Subnet Mask

  This is a small subset of all the states a server can have.  These settings are stored in various places on the local server and you would have to configure these settings on every server.  If (when?) the server crashes and burns, you must go through the process of restoring the state of the server by reconfiguring all the settings affected by replacing hardware (or entire server!)  Obviously, in a situation like this you need local access to the server (or have an environment where the out-of-band management controller gets network settings automatically assigned (and the "state" of the out-of-band managenent controller itself does not need manually configured!))

Stateless = Simple Management and Recovery
  Now that we know what a stateful server is, we can infer that a stateless server is the opposite.  By moving the ownership of all the configuration points of a server to a centralized location, we can create server (or service) profiles (collection of server settings) for the servers and assign them to the hardware to create a server.  If something happens to the hardware, we can simply move the profile to different hardware and, Presto! the server is back.
  If you haven't guessed by now,  this model works best with blade servers with no local storage (all blades boot from SAN). Keep an extra blade in the chassis you can use if you lose a blade and you can have a failed server back in service in about 10 minutes.


I am sure I am not doing this explanation justice so I will point you to a blog that should make the concept of stateless computing more clear:  http://www.mseanmcgee.com/2010/04/the-state-of-statelessness-cisco-ucs-vs-hp-virtual-connect/

Keep in mind that Cisco really pioneered this with their UCS blade servers.  HP later released Virtual Connect which attempts to compete with UCS but IMO falls short.