Current and Future Clients/Partners are Welcome.
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.
- 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.
- Log in on the new desktop with the same user account on the system that is to be the primary client.
- 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.
Setup /download configuration-Office365-xXX.xml
Once downloaded start FPC Capture
Setup /configure configuration-Office365-x64.xml
Once complete Save FPC Capture, Save Icon
Playback and add script to post activate
Bat script details.
"C:\Program Files\Microsoft Office\root\Integration\integrator.exe" /R /Msi MsiName="SPPRedist.msi,SPPRedist64.msi" PackageGUID="9AC08E99-230B-47e8-9721-4577B7F124EA" PackageRoot="C:\Program Files\Microsoft Office\root"
Makes adjustments for your environment
<!-- Office 365 client configuration file sample. To be used for Office 365 ProPlus apps,
Office 365 Business apps, Project Pro for Office 365 and Visio Pro for Office 365.
For detailed information regarding configuration options visit: http://aka.ms/ODT.
To use the configuration file be sure to remove the comments
The following sample allows you to download and install the 64 bit version of the Office 365 ProPlus apps
and Visio Pro for Office 365 directly from the Office CDN using the Monthly Channel
<Language ID="en-us" />
<ExcludeApp ID="OneDrive" />
<ExcludeApp ID="Lync" />
<ExcludeApp ID="Groove" />
<ExcludeApp ID="Teams" />
<ExcludeApp ID="Lync" />
<ExcludeApp ID="Publisher" />
<Updates Enabled="False" />
<Display Level="Full" AcceptEULA="TRUE" />
<Property Name="AUTOACTIVATE" Value="1" />
<Property Name="FORCEAPPSHUTDOWN" Value="FALSE"/>
<Property Name="SharedComputerLicensing" Value="1"/>
<Property Name="SCLCacheOverride" Value="1" />
<Property Name="SCLCacheOverrideDirectory" Value="%appdata%\Microsoft" />
<Property Name="PinIconsToTaskbar" Value="TRUE"/>
perparim test edit
Working with our clients in Physical, Virtual/VDI and Cloud environments we see many of the same issues. This video shows the top 5 issues that we have found and helped clients resolve.
Need the ability to give users direct links to dashboards in Stratusphere. Some links need no login and others need to request a login.
The Stratusphere UX Optimization feature automatically optimizes CPU/Memory and keeps “Bad Actor Applications/Processes” from hurting the performance of the users on priority applications brought to the forground.
Since release of the Process Optimization feature many clients have reported extending life cycles for physical machine by 6-18 months with greater User Experience. This has resulted in a huge capital savings for many clients.
Think about it: Why should windows updates or any process running in the background slow my applications running in the foreground down?
Process Optimization is a very simple, automated and almost zero impact feature that is included with Stratusphere UX. You can turn it on for single machines, groups or globally from the administration pages in Stratusphere UX. There are 4 Profiles that you can select depending on the type of machine(s) that you are targeting. Other options include: (Path\Executable to be exclude), (Processes to be Raised\Lowered), (Processes to be Terminated).
Optimizer can be use in Physical, Virtual and Cloud environments. It is recommended by Liquidware SEs that all attempts be used to “Fix” the issue using the data provided in Stratusphere UX before turning on Optimizer. The reason is that Optimizer does not fix bad actors. It only lowers their impact on the “In Focus” application.
Note: Optimizer was designed with security and reliability in mind from day one. Our “Do No Harm” philosophy is at the heart of the Process Optimization feature. If the machine is not under stress Optimizer does nothing! If optimizer ask a process to lower its CPU priority and it says no, optimizer will not force the change and it will not ask again. For example, you should never change the CPU priority of a security/virus application.
How to Enable Optimizer in Stratusphere UX:
The goal was to increase RAM for specific users within a pool due to work role or requirements. I created a powershell script that uses PowerCLI Set-VM cmdlet to change the VM RAM. By placing a user in a specific AD Group we were able to leverage ProfileUnity Elevated Privileges and Application Launcher settings to initiate the command that was compiled into an EXE. The steps below document the process in more detail.
1) On the Template image, change the hardware settings to Enable 'Memory Hot Plug'
2) Power up the template and Install VMware.PowerCLI component on Template image
Install-Module VMware.PowerCLI -Scope:AllUsers -Force -AllowClobber
3) Shutdown template, snapshot and recompose Non-Persistent pool
4) In vSphere create an account with appropriate permissions to modify a Virtual Machine to be used in Powershell/PowerCLI script.
5) Create a PowerShell script (I used Sapien Tools because I will later compile it into an EXE) (Note: might not be the most efficient or robust code feel free to expand error checking)
#Get Argument from Commandline default to 4GB if nothing passe
$envVM =Get-ChileItem env:computername
#Setup PowerCLI Environment
Set-PowerCLIConfiguration -InvalidCertificateAction Ignore -ParticipateInCeip $false -Confirm $false
#Connect to VirtualCenter
Connect-viserver -server <vcenter name> -Username '<account with perms to modify>' -Password 'password' -ErrorAction Stop
#Check to determine VM Available before attempting to change RAM setting
Get-VM $VM -ErrorAction Stop
$Set the VM's memory in GB, also update Notes field in vSphere to reflect the change was done dynamically
Set-VM -vm $VM -memoryGB $sizeInGB -notes "Dynamic increase to $sizeInGB GB" -Confirm:$false
6) Compile the script into an EXE (sure there are other ways to do it, but don’t want the password to be clear text).
7) In ProfileUnity create a Filter Management to target the Dynamic RAM increase. In my case I created 3 different groups (6GB, 8GB, 12GB)
8) In ProfileUnity Configuration Management click on Privilege Elevation and create a new privilege elevation rule for each Group (or you could nest the groups into another Filter Management group within ProfileUnity if you like that method better).
9) In ProfileUnity go to Application Launchers and create a new application launcher rule. In this example I am sending the argument of 6 to the script which will increase it to 6GB of memory. Likewise I have 8GB and 12GB application launcher rules.
10) Update the Configuration file and deploy to your share.
11) After login you should see it update in vSphere (Memory and Notes).
This would be a welcome addition to the logon process, or better yet, integration with the default Windows logon process typically used by gpsvc to better integrate/modernise the look and feel.
In the blog below you can read step by step on how you can talk directly against the Stratusphere API using Microsoft Power BI.