Liquidwarelabs Profile Unity
LiquidwareLabs Profile Unity
In my line of work with PQR, I’ve come across several products that are used to manage a user environment. Some of them manage the user environment, others manage the user profile and only a few offer both. Profile Unity offers both, in this article I’ll discuss ProfileUnity and give my opinion.
First let’s take a look at the installation of Profile unity. The installation is straight forward, there is no client installation. There are only four steps.
- Install Profile Unity into the NETLOGONProfileUnity folder.
- Copy the license file to the same folder
- Create an AD group for the Profile Unity users. Match it with the group in the license file.
- Add the startup, logon and logoff scripts to the GPO
The license file is copied into the NETLOGON folder, the AD group name that is used to verify the validity of the user is also written in this file. ProfileUnity does a license count of the licenses based on the users present in AD group as written in the file.
Now let’s walk through the features available in Profile Unity. It has five major components;
- Configuration management
- Filter management
- Portability management
- User management
When starting a deployment first thing to do is setup Filter management. Based on different criteria it’s determined which users are targeted.
This is done with filters that can be set based on several criteria like;
- Computer type
- Operating system
- AD group name
- IP addresses
- Domain or logon Domain
There’s also an option to set a criteria based on LAN or Dail-up/VPN. I’m wondering how it’s determined that a user is Dail-up/VPN connected. Perhaps it’s meant to detect slow connections.
Multiple filters can be set to create filters for different logon scenario’s.
Next stop is Configuration management.
Configuration management is used after you created the filters. Configuration management is where you configure the user environment and where you determine how the user profile is handled. The last one is not completely true but more about it later. At the beginning there is nothing (heard that one before) you need to create a configuration set, name it something and off you go.
Configuration management offers two methods of configuring user environments, you can set global settings and settings based on the filter you created.
With larger customers you will have multiple filters to configure, one for each log-on scenario. Each filter gives you access to the configuration of the user environment of that log-on scenario. the screenshot (a bit small) shows multiple filters.
If you look at the screenshot above it show a standard view from drive mappings created in Configuration Management. This view comes back in all sections of configuration management. With using multiple filters you can control the cluttering of the list.
Let’s talk about the neat features of Profile Unity. Let’s go back to Configuration manager and take a look at the features there.
There are some features I like to discuss;
- User defined aliases
There are some features you just expect to be there, like drive mappings, printers, shortcuts and stuff like that. There are some you wouldn’t expect, at least I didn’t. MAPI profiles is one of them, of course I expected it to be there but not in the way the added it. Most similar products offer creation of MAPI profiles but here you can specify what to do when a profile already exist, and it’s not just a ticketing box saying “only once”. I think this is a neat feature.
But there is more, User defined aliases. Everyone knows (everyone in IT) that the AD holds various user details ready to be used when asked for in e.g. a script. Some of these details are not always at hand right away. For this reason User defined aliases are there, you set a User defined alias and can determine which characters have to be used.
I want to talk about the registry option. Look at the screenshot below to see the scope of registry the can handle. all registry settings have to be done with user permissions. they can not handle anything the users has no rights for.
There are more features that are interesting, let me finish this part with listing all features for you. It’s too much to discuss all features in-depth. The features that you can set in Configuration management are;
|Portability settings||Microsoft shared fax|
|User defined aliases||Office file locations|
|User Defined scripts||Office options|
|Drive mappings||Outlook Express|
|INI files||RDP client|
|MAPI Profiles||Windows options|
One of the features listed is the portability settings, this is what controls the user profile. Portability settings are not set in Configuration management but it has its own management section. In Portability management you can configure which settings have to be saved from the user profile, these settings can then be used in configuration management together with a filter. There’s a standard pre-configured set of settings in place which makes starting up easy. Of course you still need to create your own set for specific application but it gives you a good start.
Look at the screenshot below to see a standard predefined set op Portability settings.
Below is a screenshot of how the portability settings are deployed with a configuration. Again they can be deployed based on different filters.
After you’ve created a configuration, the INI file is saved into the NETLOGONProfileUnity folder and you’re good to go. The screenshot show the saving of the configuration to a INI file.
After the INI file is saved to the NETLOGONProfile Unity folder, the user will see the following screen when logging on to the machine.
My final words
I’ve taken a short look in a test environment, I’ve not done any real test in a real live environment. I like the features that are available, it certainly is worth looking at in projects to come. There are some features I don’t like, one is the license file in the NETLOGON. I don’t like to have a license file in places where users can access them. Another thing is the INI files, with all the configuration, that is also present in the NETLOGON. It’s just not the place to place thing like this.
Note: just heard that the NETLOGON folder is just the default location, any location can be chosen as long as the user can access it. Still the fact that a license file is saved in that location is a bit weird.
What I really do like is the client, the client doesn’t need to be installed.
Is it a complete solution? Yes if you just look at configuring and profiles. Not if you look a security management of the user environment and supporting the users. Is this a bad thing? I don’t know, it will depend on the scale of the implementation. Large implementations will require security management and user support, these projects will need another product next to Profile Unity. Smaller implementations might have less demands for security and might do with Profile Unity.