This article describes a great way to organize settings for a group of applications belonging to the same suite, using RES Workspace Manager 2012. A prime example of a suite is obviously Microsoft Office. The idea is to create a common container object, where all the applications can store their settings in, thus common settings are shared. This article will show you how to accomplish this, using one of the less known configuration items within RES Workspace Manager; namely User Settings Linking. These have traditionally been used to link virtual apps with their local counterparts installed elsewhere, so this article effectively illustrates another way to use them.
Let’s get the idea visualized before we discuss the why’s and the hows. If you look on the right, a WM User Setting results in one or more .UP* files per application, stored in the users Personal Settings folder. The type of files present here, is determined by the Zero Profile mode you are using; tracking, capturing or both. If you chose to switch on tracking mode per application in a suite without any sharing going on, everything would work in principal – at least initially… However, the nature of of software suites being as it is, components of a suite tend to access the same settings. Office is no stranger to this; the Common settings in the Office registry is evidence of this. Another example in Office is your custom dictionary. The CUSTOM.DIC file is used by all components which offer spell check. It makes sense to configure Workspace Manager to share settings like that – unless you prefer a separate dictionary for Word, PowerPoint, etc. Doing it right is not very complicated, as we will examine below. There are 3 main steps to setting up linked/shared user settings: Create a placeholder, putting User Settings in place and finally linking the individual Suite apps to the placeholder app.
Step 1: Create a placeholder app.
A placeholder application is not a regular managed application, which normally provides the user with an icon to click. While the placeholder app is created as a managed app per definition, we are going to throw a few switches to ensure it won’t appear on the users radar ever. A placeholder app is not necessarily restricted to store User Settings. You can use a placeholder app to contain other things such as Security Rules, to de-clutter your Global Authorized Files list. I have written an article RG026 a while back, describing that use case in detail. Also see the last section of this article for further ideas. Lets proceed to build with User Settings:
First, create a blank managed application. For our example with Office, let’s call it Suite Settings, MS Office . Some admins choose to keep the placeholder app in the Start Menu folder together with the suite it services, others prefer to have a separate folder, called something like Hidden Apps, where you store it. You can always move the app later to your hearts content. For practical reasons I would recommend the first approach; storing your placeholder app together with the suite. The reason is that currently Workspace Manager cannot link Access Control settings in a suite, but you can certainly use QuickEdit to batch-edit all apps within a StartMenu folder, thus it makes sense to store the placeholder there. Also, naming the app with the Suite Settings, prefix is completely intentional, as it allows you to view all similar placeholder apps together in the Application List view, as it’s sorted alphabetically per default.
While we’re at it, lets pretty up the placeholder app, selecting an icon for it. This is strictly cosmetic, since the users will never see the app. On the other hand, as you’re going to be staring at the application in the WM Console, perhaps consider selecting an icon that represents the functional usage, rather than the unsightly default no-icon. Again, if you have more than one Suite Settings placeholder app, this makes some sense. Some people would perhaps chose the icon for Regedit.exe for this purpose. But again, this is just cosmetics with no impact on functionality.
Now let’s get it configured properly. Go to the Properties|Settings tab of the application and check the following 3 settings;
- [X] Do not List in Powerhelp. PowerHelp is a rather obsolete application catalog RES app w1hich these days is disabled by default, chances are slim that you’re using it, but just in case we don’t want the placeholder app to be shown there
- [X] Do not notify about running instances. Strictly not necessary either, as the app won’t run in multiple instances anyway. Nevertheless, we don’t want any announcements what so ever.
- [X] Do not show in “New Applications”. This one is important, as the default behavior of WM is to announce the arrival of any new app to the user. By checking this box, you can fly in new apps under the users radar and (if not hidden) silently be populated into the users start menu
- [X] Hide application. This is likewise important, as it makes sure the assigned users will never see the app in neither their Start Menu nor Workspace Preferences.
- [ ] Hide application if executable is not found. The jury may be out on if this is strictly necessary to have unchecked, but for all intents and purposes I chose to remove it, if not for anything else to spell out the logic that there is no executable on this app, hence no need to check if it’s there or not. Some chose to have this checkbox set as a global default for regular apps, that’s why I mention it here.
As mentioned before, make sure Access Control of the placeholder app matches the rest of the suite, for which it should store settings. If it doesn’t you could end up with one or more suite components having their settings lost, which would suck. Once you’re done you’re ready to move on to user settings.
Step 2 – Putting the UserSettings in place.
This part can either be real easy or real iffy, depending on where you currently are at in your implementation. It’s quite easy if you are at the beginning of your RES Workspace Manager project and haven’t yet created any apps for the suite. In that case, it’s a matter of setting up the proper user settings on the placeholder app from the start. See below. If you on the other hand already have created managed apps for the individual suite components and you want to retain those, you’ll need to export buildingblocks of the apps in question and merge the user-settings XML stuff together. This rather un-elegant hack is due to that you can’t move or copy user settings between apps, as of WM SR3. Oh well… we can hope for this feature in the future. While this article isn’t meant as a tutorial on how to configure user settings, let me give you a few pointers on both approaches below:
Setting up a linked User Settings placeholder app from scratch: If Workspace Manager has a built in User Settings capture template for the suite components you are working with, you would do well to use it. And yes – all relevant versions of Microsoft office are supported. You essentially just would go shopping and add all the relevant templates one by one to the placeholders User Settings, like shown on the right.
If no template is available, there is no need to despair or panic. You probably just want to use the new DiscoWizard (alright, fine! it’s the Discovery Wizard), available in WM SR3 to figure out what’s going on. As with all unknown apps, don’t expect to get the full picture immediately as there may be settings you as an admin would have absolutely no clue about, as they are triggered by some user once a blue moon, invoking some function you didn’t even know anyone used, let alone existed. To get the full picture, I suggest you also consider enabling Sample Mode for a reasonable number of users. Either route you choose, by employing the RES Workspace Manager’s User Settings, you are effectively stepping away from indiscriminately grabbing everything like a traditional roaming profile and going about the whole business of managing settings in a selective, granular and overall intelligent way. That may take a little initial work, but it pays off in the end.
Extracting User Settings from existing apps: This is the second route you can chose to get your placeholder app stood up. You probably have to consider if it’s worth the time, if you’re just using the built-in templates as it would probably be quicker to re-create them in the placeholder app. On the other hand, if you know you’ve got a bunch of customizations and/or additional settings for your suite apps, that you would hate to recreate, you’re probably better off using this method below:
- Create a buildingblock for each of the suite applications, for which you want to merge user settings into a central placeholder app. Be sure to keep these as they are your backups in case you mess things up.
- If the placeholder app is created from scratch, create a dummy UserSetting inside it that picks up something non-consequental. The reason for this is to create the right section in the resulting .XML file when you now create a buildingblock for the placeholder app too.
- In turn, edit each of the resulting .XML files for the suite apps and look/search for the <userpreferences> section. Right underneath, you’ll see a <profile> tag with a corresponding </profile> closing tag. Each of these sets (there may be more than one) represents a set of user settings which are currently being captured or tracked.
- Copy all the <profile></profile> sections for any given suite app and paste them all into the same place of the placeholder app’s .XML file and save the XML file under a new file name. Now you have effectively merged the user settings into a new buildingblock for the placeholder app.
- Edit each of the managed apps and delete all the User settings under the capture. Don’t worry, you’ll have the buildingblock from step 1 to revert to. Second, if you forget to do this, the console will do it for you in step 3 in the next section.
- Now delete the existing placeholder app from the Applications node in the console and re-import the XML file you just doctored.
- Edit the newly imported placeholder app and verify that all user-settings are in place.
A provisional note of safety: If you are doing the above on a production environment, you are better off scheduling the work outside work hours if possible and/or disabling access to all affected suite apps, as things for hopefully obvious reasons, could and probably will go haywire, if people are logging in and using the apps which you modifying. Alternatively if the site is a 24-7 operation, you can choose to work on a set of cloned production apps which you swap in at a later point.
Step 3 – Linking the suite apps
The last step of this exercise is to hook up the suite applications so they all will read and write setting to the placeholder app. This is very easy as you just need to do the following for each application (sorry, no quickedit).
- Edit the application and go to the User Settings/Properties tab.
- If you are using SR3 or higher, hit the Advanced User Settings button at the bottom of the dialog. If not, ignore this step.
- Click the checkbox Use the User Settings from the following application. If you haven’t cleared out the settings as outlined in step 5 above, the console will warn you at this point that all user settings defined on this app will be wiped out. This okay. Answer yes.
- Use the browse button ( ) on the right of the blank field to browse and select the placeholder app.
- Under normal circumstances you should not need to use the override checkboxes. These essentially control the flow of settings between the placeholder app and each individual suite app. Refer to the table below for how they work. Default non-override behavior is that the app will be able to read and write to the shared user settings on the placeholder app.
This is the default behavior even if the ‘Override settings from linked application‘ checkbox is not selected. If this is the desired behavior there is no need to use override.
|In this state, any changes made by the suite application will be ignored, but any changes stored by other apps in the suite will be applied. This can be used if one wants to deny a certain suite app from making changes to any common settings, but still want it to abide by same settings. Effectively making the suite settings mandatory for this particular suite app.|
|By using this combination, one stores all changes made by the suite app, but none are re-applied. One could use this combination to silently pick up current settings for an app in an existing environment where Workspace Manager has been deployed in StealthMode.|
|Turning off both flags is essentially the same as turning off User Settings for this app. No settings will be stored or retrieved for the given suite app. This is probably one best left for debugging scenarios.|
At this point you’re done. If you suspect that you’re not catching all there is to the suite, you can continue monitoring the placeholder app, using the Sample tab.
While the User Settings are very nice to store in a central suite placeholder app, there are other items as well you could consider. While authorized files for the security subsystems have been covered in article RG026 mentioned earlier, you could also consider using linked Configuration Actions. This will allow you from within the scope of the common app to execute common things like setting up the initials for the Office suite apps and other initial configuration pieces. Since the placeholder app is hidden from the user, it would have to be started automatically when the user logs on. You configure this by setting the checkbox Properties|Settings|Autolaunch at Session Start. One could argue that these settings could just as well be applied at logon, but since that has no impact on nether performance or security, I will leave that in your capable hands to decide.