In 2011, Scense decided to add support to its software for non-domain machines: home-pcs or personal laptops and Windows tablets that are not part of a Windows domain. The first customers adopting this scenario were large educational institutes that needed to address student requests to use educational software on personal laptops. These institutes were also eager to support this scenario because of potential savings on hardware en license costs. Recently we have seen this scenario to be adopted in other industries as well.

Scense unmanaged client.

Until now, we used to refer to our Scense client software, adapted for non-domain scenarios, as unmanaged client (1). This name has led to confusion about the functionality delivered by our client software in this scenario. In this blog we will address this and, as of today, will start using the phrase Scense client in a non-domain scenario.

The Scense unmanaged client is not a stripped version of the regular Scense client.

Although wrapped in two different installers (to simplify the installation), the Scense managed client and unmanaged client is the exact same software (2). In a small number of cases, the client software does behave differently because of the different expectations in both use cases. In a non-domain scenario, for instance, the machine is owned and managed by the end user. As a result, the end user decides when Scense functionality is activated and deactivated while in a domain scenario, the administrator decides when Scense functionality is activated and deactivated.

The Scense client in non-domain scenarios is fully functional ..

When activated by the end-user, all Scense functionality becomes available. When the Scense client is stopped by the end-user, all Scense functionality is deactivated.

  • Corporate applications will be installed, streamed or activated on user request.
  • Corporate applications are configured and managed by the IT department (while the Scense Client is active). Scense Adaptive Installer will take care of any application conflicts.
  • User settings of these applications are managed by Scense Live profile (if installed).
  • Self-service functionality is available.
  • Printer management is available.

with slightly different behavior.

Because of differences in expectations in a non-domain use case, the Scense client behaves differently in a number of occasions:

  • Pre-install of applications. In a non-domain scenario, the end user decides when and if applications are installed on his machine. The automated installation of software outside the scope of the end user is not desirable and therefore not available.
  • No pushing of Scense clients and third party software. In a non-domain scenario, the client software will have to be installed by the end user together with third party software that might be necessary (e.g. an App-V agent). This process is not automated by default.  The installation of third party software can off course be automated differently by using application dependencies within Scense.
  • No management of generic Windows settings. Personal Windows settings that do not relate to applications distributed by Scense will not be managed by Scense. Some Windows settings might be synchronized by Scense Live Profiles, but only if the Live Profiles Client is installed and configured correctly.

Hybrid environments.

Because one agent (the Scense client) supports multiple scenarios, there is no need to reinstall agent software when machines are joining domains or leaving domains. Scense will remain functional whatever scenario the machine is part of. The Scense client will automatically detect the mode in which it is run and adapt its behavior accordingly!

(1) as opposed to the regular managed client for domain-joined machines

(2) and the same pricing applies