When talking with clients, this topic comes up from time to time.  To understand the claim of “Infinitely Scalable and Highly Available” you first have to understand ProfileUnity’s architecture.

ProfileUnity consists of four main parts:

  1. Management Console
  2. Configuration file
  3. Agent files
  4. User profile files

ProfileUnity’s Management Console: The console installs on a windows 2008 R2 or windows 7 server (support for 2012/win8 will be added shortly). It comes with its own Web server and database. It’s a rich HTML5 admin experience. The admin console is only used to build configurations, it is not in line to users logging in. In fact, the management console can be powered off and it wouldn’t interrupt a user’s ability to login or get their profile.

Configuration Files:  When you build your configuration within the console, you then download your Configuration file to a DFS share. We tend to ride on your existing DFS share you have with your domain controllers netlogon share. This is a self-replicating share that is already redundant and highly available. This allows for as much redundancy and high availability as your have domain controllers.  You can use any DFS share you would like if using the netlogon is a problem for your organization. The Configuration file is the instruction set that tells ProfileUnity what to do. Once you drop this file(s) in your netlogon share, these files are read at login to tell ProfileUnity how to execute.

Agent files: The binaries are able to hold off windows from loading completely during login, so ProfileUnity can apply a user’s profile and/or other settings the administrator might want for their users. The agent reads its instructions from \domainnetlogon, because of this action the most available domain controller would respond to our request creating a redundant and highly available environment. Each desktop executes its own copy of the agent and each agent reads its instructions from the first responding domain controller. When you think about how this works, the agent and its configuration files don’t have a single point of failure.

User profile files: These file are mainly stored where your user stores their documents. This location might already be scaled out and highly available. For example, it might be an existing DFS share. When ProfileUnity uses a DFS share for its user profile files it becomes as scale and highly available as your DFS configuration is.

Back to the statement of “Infinitely Scalable and Highly Available”, ProfileUnity’s execute is distributed across desktops and DFS file shares. We don’t have any Web Servers or SQL servers in the path of the user and it’s profile. It’s very likely you have more than one domain controller and a redundant file share for your users files that ProfileUnity can leverage.  We automatically scale with you, based on your DFS shares and/or Domain controller roll out without extra in the infrastructure. We not only come in at a lower price than other products on the market, but we don’t need more infrastructure which is going to lower OPEX and CAPEX.

For more information on Liquidware Labs ProfileUnity visit the ProfileUnity Product Page or contact sales at Liquidware Labs.