Best Of

With larger environments, it’s important to consider the implications of different architectures and system types when building a ProfileUnity Console cluster. Some of the key things to note are how many geographic locations will be home to machines running the ProfileUnity Client Tools and what type of environment is being delivered. For example, single-user Desktop OSes or multi-user Server OSes with the RDSH Server Role enabled.

ProfileUnity Cluster notes to keep in mind:

1. ProfileUnity uses MongoDB for the database back end and RabbitMQ for the license fabric - both are clustered automatically when you build a ProfileUnity Console cluster.
2. MongoDB requires a cluster containing an odd-number of nodes under a 100% node-up scenario. This ensures a tiebreaker for cluster operations. Generally, this means 3, 5 or 7 nodes.
3. MongoDB, while clustered, always requires at least 2 running nodes, hence the minimum node-count of 3.

Architecture examples:

1. If you have a single site you likely only need a 3-node cluster. This would spread the load out among all nodes and allow for a single node to fail while maintaining normal operations. An example benefit would be a rolling Windows Update/reboot cycle or even a ProfileUnity Console version upgrade without service interruption. 
2. If you have 3 geographic regions and want to make sure that you have license and FlexDisk redundancy at each location, you might deploy a 7-node cluster. Site 1 would have 3 nodes while sites 2 and 3 would each have 2 nodes. In this configuration, the MongoDB cluster would span all 3 sites while the RabbitMQ license/FlexDisk fabric would be isolated within each site. This would allow for a single node at each site to be rebooted for maintenance, while maintaining normal operations at all sites. It would also allow for 2 of 3 sites to go dark and not interrupt ProfileUnity license or FlexDisk operations at the remaining site.

ProfileUnity Cluster sizing considerations:

1. Environments with a majority of Desktop OSes, or Server OSes without the RDSH role acting as single-user desktops, can require a cluster with higher CPU requirements and lower memory requirements. The main reason is that the Liquidware Client License Service in the Client Tools only connects to the fabric to make a license "consume" or "release" request and then immediately disconnects.
2. Environments running a majority of Server OSes with the RDSH role enabled will require both CPU and additional memory as the number of client machines increases. In this situation, because the server will be making many license "consume" and "release" requests throughout the day, the Liquidware Client License Service connects to make the first license "consume" request and remains connected until rebooted. These open connections require the ProfileUnity Console cluster to have a higher memory requirement.

 For cluster sizing suggestions, please refer to this KB article: https://liquidwarelabs.zendesk.com/hc/en-us/articles/360039686092-ProfileUnity-Cluster-Sizing-Suggestions

6.8.3 is available now.

Yup, I have already started sending this out to my customers.

Recently, I was asked how the “Only Migrate Existing Files on Primary Client” works. More specifically I was asked how to update the primary client. For example, if an end user that has been sync'ing data from the primary client gets a new laptop, how does the synchronization continue? Let's dig in!

First off, here is what the help file says about Primary Client.

Only Migrate Existing Files on Primary Client:

Enabling this option causes ProfileUnity to only migrate existing files on the user's Primary Client. The user's Primary Client is the first computer a user logs on to after a folder redirection rule is configured.

Where is the Primary Client tracked?

The primary client is tracked in an ini file called FD.ini. This file has been marked as system file (attrib +S FD.ini). In order to see it in File Explorer, the view will need to be set to show “protected operating system files”. FD.ini is located in the root of the redirected or synchronized folder on the network share where the files are redirected. 

What Happens if Primary Client Option is Not Checked?

When the “Only Migrate Existing Files on Primary Client” is not checked, any time the user logs into a machine running a ProfileUnity configuration to sync folders, the folder contents will by synchronized (one-way) to the share on the server. Each end point will only see the local files, not the total of both client files sync'd.

Here is a screenshot of my configuration, where I'm synchronizing, not redirecting, my desktop. Customer can do this to protect the "My Documents" and "My Desktop" shell folders on notebooks that either have a VPN or vist the office with a local area network. In this configuration, I'm only synchronizing new files to keep the changes to a minimum.

On the first Windows 7 laptop (GP-Win7a) the user logs in and executes the ProfileUnity configuration set to sync the "My Desktop" shell folder. The contents of the desktop is synchronized in the background to the network share configured in the "Redirect to Folder" required setting. Here is a screenshot of my network share after the first logon. Notice I created a folder and several text documents with the host name as the file name.

As you can see, the FD.ini file is placed in the root of the desktop folder on the network. The contents of the FD.ini file contains the PrimaryClient, the shell folder being redirected, and the last synch time.

Next, I logged into a second machine (GP-Win7b), again with dummy data on the desktop, named with a the different host name. Upon logon, the ProfileUnity configuration was executed and the local desktop shell folder sync'd to the network share, resulting in the network share containing fires from both systems, as seen below.

The FD.ini file was updated to include the second host that sync'd files. Now the FD.ini file has both GP-Win7a and GP-Win7b last sync times. However, only GP-Win7a is the Primary Client.

What is the behavior when the Primary Client Option is Checked?

When the “Only Migrate Existing Files on Primary Client” is checked the first client logged into still becomes the Primary Client, but ProfileUnity will not synchronize any data from any other host. This is a convenient option when a end user has multiple machines they log into and you only want to capture the data from one. Here is the ProfileUnity Folder Redirection config for the My Document shell folder. The only difference than above is the check mark in the "Only Migrate Existing Files on Primary Client".

When I logged into the first laptop (GP-Win7a), the desktop folder was created on the network share the the data synchronized in the background as seen in the below screenshot.

The FD.ini file is once again created on the synchronization target, and again it includes the host name as the Primary Client as well as the last synchronization time.

I logged in to another laptop (GP-Win7b) and the network share contents didn't change because the host name didn't match the PrimaryClient name in the FD.ini file. There isn't much to show on the network as no change as made and there wasn't a change to the FD.ini log. However the local log on the client (my logs are set to debug) shows that the host name doesn't match the Primary_Client in the log.

The above log entry was found in %temp%\ProfileUnity for the user and was located in the Client_FolderRedirection_Logon log.

What happens when a user gets a new desktop?

In this scenario, the user has been logging into GP-Win7a and the hard drive failed. IT has replaced the machine with a new machine with a new name, GP-Win7b. IT has also utilized ProfileUnity to copy the files back to the user’s desktop. Now the user needs to have a one-way sync to the share, but the name of the primary client has changed.

1. Delete the FD.ini file from the share. Do not modify the file. Modifying the file as an administrator didn’t work in the tests. Simply delete the file.
2. Log in on the new desktop with the same user account on the system that is to be the primary client.
3. The folder redirection module creates an updated FD.ini file and sync’s the data. The share will have the contents of the new desktop and the old, in the event there was data that did not get copied back to the new system. 

Below is the resulting files on the network share, a mixture of both any new files on the desktop as well as all the old files from the old desktop.

The FD.ini now lists GP-Win7b as the Primary Client rather than GP-WIn7a.

Environment Note: This was tested in a controlled lab environment to replicate a customer situation using ProfileUnity 6.8.2 with the latest hotfix.

Nice work @Adam, this will now be part of the 6.8.3 default templates shipping next month. Customer's can just enable the rule if they dont have hardware GPU's and get performance back!