Sync or swim – ways to check your user’s data is safe

*This post originally appeared on the AppSense blog prior to the rebrand in January 2017, when AppSense, LANDESK, Shavlik, Wavelink, and HEAT Software merged under the new name Ivanti.

In this blog, I’ll discuss the different ways in which you as the administrator can report on users with DataNow who have not synced with the file server for a period of time.

In DataNow, we try and stay out of the end user’s way wherever possible. This is popular with many enterprise DataNow customers, who often deploy DataNow with single-sign on, in-location sync and will often disable product sync notifications / file overlays in order to minimise the cross-section of DataNow to their end users. All users need to do is keep working in the way they usually do, safe in the knowledge that DataNow will sync their data back to their file server in the background.

Ensuring user’s data availability and integrity is high on the list of any sysadmin’s priorities, and so identifying users that haven’t contacted the DataNow appliance in a while for whatever reason is an important exercise to ensure that user’s data is getting backed up.

There’s a few ways of doing this:

1. Admin Console
Looking in the admin console at the ‘last activity’ column in the users & devices section:

2. Syslog reporting
For example, in Splunk you could use a query like;
operation="User Logon" clientplatform="Windows DNClient" | dedup deviceid | eval time=strftime(_time, "%d/%m/%y %H:%M:%S")| stats latest(_time) by username,time,deviceid |sort by time
This will return a time ordered list showing earliest-first the last time a Windows user/device combination logged into DataNow:

With this raw data, it’s possible (depending on your syslog application) to create alerts and visual dashboard items to allow the IT team to follow up with users who don’t appear to be syncing for any reason (be it that they’re on vacation, or maybe working from a location without Internet access).

But what if you want to take automated action on the endpoint in the event that a user hasn’t been syncing for a period of time? Maybe you would like to alert the end user, or take other actions.

3. Via the Endpoint (Leveraging Environment Manager as a monitoring component)
The good news is that this is possible via an Environment Manager custom condition, thanks to a client side registry value DataNow updates each time it syncs with the file server via the DataNow Appliance:

Registry Key: HKCU\Software\AppSense\DataNow
Value Type: REG_QWORD
Value Name: LastSyncTime
Value Data:

The value is a 64 bit integer, representing the number of nanosecond increments since 1601 (UTC) (FILETIME structure)

It’s possible using Microsoft PowerShell to read this value from the registry, convert it to a string, compare it to the current data and pass or fail a condition based on the age of the cache:

start-sleep -s 20
$days = 7
$key = 'HKCU:\SOFTWARE\AppSense\DataNow'
$lastsynctime = (Get-ItemProperty -Path $key -Name LastSyncTime).LastSyncTime
$friendlylocalsynctime = [datetime]::FromFileTime($lastsynctime)
$delta = NEW-TIMESPAN –Start $friendlylocalsynctime –End (get-date)
IF ($delta.TotalDays -ge $days)
{
exit (0)
}ELSE{
exit (1)
}

Note: I sleep this script for 20 seconds at start on the assumption that this condition is triggered at user logon, and gives an arbitrary period of time for DataNow to connect to the appliance and sync, to avoid false-positives for a user returning from a vacation for example.

This condition could be paired with an associated action to take if the user has not synced beyond a certain threshold (controlled by the $days variable in the script above)

Example:

In the following example, I’ve created a pair of conditions that will trigger a PowerShell custom action based on the time of the last sync

These are variations of the above condition which are satisfied when the last sync time falls between a definable range.

The ‘Is last sync time between 7 and 20 days’ associated action uses $objNotifyIcon and write-eventlog functions to provide a warning tray notification to the user along with a Windows event log entry:

If the user has not synced in over 21 days, the second condition is satisfied which has a similar action, but both the tray notification and event log messages are at the ‘error’ level and prompt the user to take urgent action to remediate the issue:

If you want to test out these examples, be aware that there is a prerequisite to enable the following custom setting in Environment Manager, which is required for displaying the system tray notification when executing PowerShell via Environment Manager:

The scripts (which are provided for example purposes only and care should be used as they’re considered experimental) are contained within an Environment Manager policy template configuration snippet can be found here.

I hope this blog has been useful, we’re always looking for novel ways in which our products can complement each other so stay tuned for future blogs from myself and other members of our Solution Engineering team.

Thanks for reading.