AppSense DesktopNow remains one of the leaders in the User State Virtualization market, an important consideration for those deploying non-persistent virtualized desktops and SBC solutions. Besides the deployment of desktop settings and personalization, it also offers application management, user rights management, performance management, and a raft of other features around data and mobility.
There is, however, a perception among virtualization practitioners that AppSense is complex and bloated, and that it relies on heavily redundant SQL and IIS infrastructure to function. For some, this is discouraging, as the product appears to require significant resource investment to get it up and running. This perception, though, is not necessarily accurate.
AppSense DesktopNow normally operates using client configurations deployed via a number of client agents. The agents typically connect to a web-based broker, and from there to an SQL backend (see below).
The client agents and client configurations, though, can actually be deployed to endpoints individually, rather than running through the IIS broker (the “Management Server”) and the SQL backend (the “Management Server database”). As the agents and configurations are saved as Windows Installer files, they can be saved to disk, instead of into the Management Console, and then can be pushed out via any software deployment tool that a business has access to. The main benefit is complexity reduction, as there is no requirement to provide redundancy, HA, or load balancing to the web and database server roles.
In a nod toward more mainstream adoption of this simplified method, the AppSense consoles themselves, in recent incarnations, actually support saving the client configurations directly into SCCM.
From there, SCCM (or your tool of choice) can be used to distribute the client agents and configurations to your endpoints. As long as a software license is also deployed to the endpoints via this method—there is an Export function in the AppSense Licensing Console that allows you to create an MSI for the license—then the AppSense configurations will function exactly as they have been set up.
The trade-off for not utilizing the SQL management server database is that events, reports, and alerts are not submitted to a central location, and you can’t take advantage of features such as deployment groups, security options, etc. However, if you’re using a third-party deployment tool such as SCCM, a lot of this functionality will be provided to you in it. AppSense also has monitoring functions available, such as SCOM management packs, to make your life easier.
There is another big element to DesktopNow, besides the management server, that also, in many people’s opinion, contributes significantly to the complexity of the solution. It’s AppSense’s personalization server, an SQL database that contains user application and desktop preferences and streams them on demand to the user session. This part of the suite does require SQL to function. It functions in exactly the same way as the management server: via an IIS broker to the database backend.
However, the fact is often overlooked that other functions inside of AppSense Environment Manager—Registry Hiving and File/Folder Copies—can be utilized to perform the same user virtualization without standing up the SQL Server or any of the personalization server features. In fact, AppSense prior to version 8 (when the personalization server was introduced) used this method exclusively. Also, saving and restoring your user settings by using this non-SQL method actually provides a speed increase, as AppSense’s policy engine runs multi-threaded, whereas the personalization server operates single-threaded.
The trade-off here is that the non-SQL method requires more application analysis and testing to set up, and it also necessitates file shares, rather than a database, to hold the user data. The personalization server database also has its own security model, options for profile rollbacks and restores, wizards and import/export features, and various redundancy options. These sort of things would have to be factored in specifically (if required) should you choose to deploy the non-SQL solution.
AppSense themselves have been keen to highlight that their DesktopNow product isn’t tied to SQL Server, which is how it is widely perceived. In version 8.7 of Application Manager, they actually introduced a method to save the configurations directly into Group Policy to allow deployment without the management server backend, or indeed a third-party tool.
This is another good way to simplify and streamline an AppSense deployment, although whether they will extend this functionality to the other two parts of DesktopNow, Environment Manager and Performance Manager, remains to be seen.
Viewing AppSense DesktopNow in this way makes it significantly more palatable to businesses that don’t have the time or resources to put together highly available, load-balanced SQL and IIS infrastructure. It also allows DesktopNow to integrate with other technologies—such as Citrix UPM—that businesses may already be using, rather than being a direct competitor to them. DesktopNow is a powerful tool with a lot of potential value-add, and reducing the perceived complexity of it will make it more acceptable to those who may benefit from deploying it in their VDI or SBC environments.