From the So-Ein-Ding-Muss-Ich-Auch-Haben Department. Here the other day I came across a nice article by Michel Stevelmans, where he’s taken the time to dig out some really useful explorer registry keys. These are the settings one needs to pick up from the users registry in order to serve up a consistent desktop experience, when moving across a computing estate. While the article was written with a competing vendor in mind, I have the luxury of really not having to care about that. This article will show you how to to put this knowledge into practice with RES Workspace Manager – and yes, you guessed it: BuildingBlock Included!

<<< Click here to read the full article

From the RES Community Hero dept. My good friend Iain Brighton over at Virtual Engine in the UK has for quite some time offered a pretty amazing toolkit which will help you in your daily work with RES Workspace Manager. It’s about time I gave it a proper review. The VEToolkit is to the RES Workspace Manager what Robin is to Batman! It’s a great sidekick as it picks up where WM leaves off by offering multiple functions, which are all triggered by the green button in the lower right of the app.

This application is in continued development (beta 3) at the time of writing. In this article I’ll give you a detailed introduction to it’s capabilities along with usecases and show you where to download. I should probably also mention the VEToolkit is free! Interested?

BuildingBlock Spinner – This feature helps move buildingblocks between test and production environments. As you may know, buildingblocks are configuration exports from within RES products. Let’s say you have two domains; TEST and PRODUCTION. You have created some applications which in your test environment, assigned to groups in that domain. When you export building blocks of said apps, the access control info (i.e. domain+groupnames) will be exported as well. This means you would either have to manually edit the apps, or search and replace the TEST domain name with PRODUCTION. This is exactly what the spinner does. On top of this it can use the domain names as prefix and you can chose if you want to save the resulting changes in multiple or just one merged buildingblock.

POL Converter – This most excellent feature helps you grab the live user policies of any production system and convert them into registry settings, which you in turn can import into RES Workspace Manager. This effectively will speed up getting rid of existing AD based user policies in a RES WM managed environment. This way you don’t have to go back and enumerate the policies via the templates loaded into AD and build them manually into Workspace Manager. Using this feature is easy: Simply run the toolkit on your DC and point the policy converter to your C:\WINDOWS\SYSVOL\sysvol\<your domain>\Policies\ and look for the .POL files to convert. The resulting regfile will be placed where you specify it.

ADM(x) Template Merger – This is useful if you have several NT policy templates which you always need to use together anyway. The way the RES Workspace Manager handles .ADM(x) files is that it will import them into the WM Datastore so you don’t have to worry about distribution. When using the settings from the policy admin templates, you can however only edit one at a time. Using the merge functionality in VEToolkit you can combine the ADM(x) files which you need to have in one tree inside the Workspace Manager policy editor. There are two separate tabs as you can’t mix .ADM and .ADMX files as they have different formats.

GUID Locator – One of the powerful features of the RES Workspace Manager is the ability to set many configuration settings to Run-Once. This allows you to apply settings to users on a voluntary basis, such as “We think your Terminal Emulator app should use Courier as the default font – but if you hate it, you are allowed to change it.” When a Run-Once setting is applied to a user, a check/semaphore file is created in the users RES homedrive under <X:>\pwrmenu. The file will have the format of: <GUID>_<TYPE>.once. The file content itself is just a clear text time-stamp. The GUID will be generated when the RES object (registry setting, etc) is created.

The challenge with the Run-Once feature, is resetting it on a per-user basis. I covered this process a year ago in article RG020. It’s very easy if you know what .once file to delete, but mapping the right setting to the right GUID can be quite time consuming as the article illustrates. Again the VEtoolkit to the rescue! Using the GUID Locator, finding these is a snap. Just point the tool to C:\Program Files\RES Software\Workspace Manager\Data\DBCache\Objects and the GUID’s along with the name+description of the config items will be displayed. Note: It seems currently the name field is blank at the moment, but I’ve let Iain know about it. The resulting output looks like this:

Once you have the GUID of the .once file you need to delete, you could use it create a Managed App which reset an application to “factory settings” by deleting the .once file. This is useful if you’re not currently employing the User Settings feature of Workspace Manager, or if you in addition to the Restore User-Settings wizard want to provide a way to reset an app all the way, where initial Configuration actions on the app are re-applied.

With this article, I hope to have peaked your interest in the VEToolkit. Only thing remaining is where to download. You can pick it up at Virtual Engine’s site. Registration is required. It’s well worth your time though, so go have a look.

From the we-work-harder-so-you-don’t-have-to dept. My esteemed co-authors Patrick Kaak and Sascha Maier have produced a couple of new articles, which you may find interesting. Patrick has reworked another blog article he found, which compares different profile manager technologies, while Sacha has created an article that describes how you can first-time set up the correct initial keyboard for users in an international organization. This article also includes a buildingblock. Have a look at the articles in the Technote Library below:

<<< RG038 – Differences between profile managers

<<< RG039 – Mapping the right keyboard to the right people

From the we-work-harder-so-you-don’t-have-to dept. As an administrator or integrator, you may often find yourself in the situation you need to offer certain Controlpanel applets to the users. Unfortunatly PowerFuse doesn’t (yet) offer the ability to import Control Panels as easily as it does regular applications.

To address this, I’ve created a set of buildingblocks which includes every single applet to be found in the standard Windows XP and Windows 7 control panels. On top of that there’s a set of Extras which includes some other nice control panel applets often found. Have a look at what’s inside below: (click to enlarge).

Click here to view the article and download buildingblocks.

A technote was published in the technote library in late March. This one will help you clean up any embarrasing log entries, which you need to clean out for one reason or another. Suppose you are running PowerTrace with WebTrace enabled in your environment and you or somebody else manage to surf to a webpage which everybody just rather forget about, then you need to find a way to surgically remove the skeletons from the closet, as you may want to retain the remainer of your PowerTrace logs.

In order to do this, you need to have the proper credentials for the PowerFuse datastore.

The article available here, will show you how to deal with this problem. A nifty buildingblock for Wisdom has also been included in the article.

Over the last couple of months, two nice Wisdom buildingblocks have been posted by users on the RES Forum. The latest BB will help you install Windows Deployment services on a Windows 2003 server. The other available buildingblock is able to turn off those pesky Cached Offline Folders.  This buildingblock is designed for target computers running Windows XP.

Great work chaps, thanks for sharing!

Click here to see the postings and download the Buildingblocks

By Max Ranzau

This little blurb was inspired by an email to a partner, explaining the differences between the old PoweFuse products PowerLaunch section and the User Preferences (these are now known as User Settings from Powerfuse 2010 and up. This lead to an example on how you can combine these two parts of PowerFuse. The goal is to be able to provide the user with preconfigured, voluntary settings – in a mandatory profile environment. Let’s take a real-world example on this:

We have some users which share a mandatory profile, where the default webpage for IE has been set to about:blank or something else long ago. This setting coded into the .man profile and we don’t want to bother hacking into it since our goal would be to have it changed dynamically, according to group membership.

For example: We want to have users in group1 initially having www.batman.com as their homepage and group2 should have www.superman.com as their homepage. To make the entire thing a bit more interesting, we want to provide the user with the option to change their homepage to something else if they prefer to do so.

To summarize we are talking about creating a dynamic, group assigned voulentary user registry setting on top of a mandatory profile. Sounds iffy? Not at all. This example is easy to follow, but you can of course just download the PowerFuse buildingblock at the end of the article. The registry key we use for this example is HKCUSoftwareMicrosoftInternet ExplorerMainStart Page (REG_SZ)

1. If you haven’t already done so, create a PowerFuse application for Internet Explorer (other browsers can be used, but you’ll have to figure out the registrysettings then for yourself)
2. Edit the IE app and go to the Configuration | PowerLaunch tab, click Add.
3. Create a powerlaunch user registry setting for the IE startup page www.batman.com. using the HKCU registry path above. Make sure to mark the reghack with the Run-Once checkmark.
4. Go to the Access Control tab of the reghack, assign it to group1.
5. Export the newly created reghack to a temporary file. This done in the “Registry|Export registry file…” menu inside the PowerFuse registry buffer editor. We are going to use this export one steap further ahead.
6. Save the reghack and return to the PowerLaunch tab of the application
7. Repeat step 2 above, then go to the Registry|Import registry file… and pull the temporary regfile in again (it can safely be deleted after this btw).  In the new reghack, change the startup page to www.superman.com and assign this one to group2. Notice that the name and any comments you added before was preserved in the regfile. Once you’ve configured the reghacks for both groups it should look like this:
8. Let’s setup the User Preferences. Go to Properties|User Preferences, while still editing the app. Here we can specify one or more seperate items which should be saved before the logoff destroys the mandatory profle. Using the Add button, you can choose to add:
   1. A single registry value (like we are using here)
   2. A registry key (containing multiple values)
   3. A registry tree (a branch containing multiple registry keys)
   4. A single file in the profile (such as normal.dot for office)
   5. A folder in the profile (such as cookies or favorites)
9. Fashion the user preference so it looks something like this (remember, you can download the buildingblock below if you want to make sure you build it right). Click on the image to zoom.

When the app has been saved and the user sessions refreshed, PowerFuse will write the correct IE startup page to the registry uppon first time user launch of IE. During the session, the user may perhaps change the homepage of IE to something completely different. Regardless of this, User Preferences will capture the current value of the IE startpage key at logoff and save it, just before the mandatory profile is tossed into Mount Doom. To try all this out for yourself, download the BuildingBlock:

Rightclick and save-target-as here:

This is a handfull of nice buildingblocks for both PowerFuse and Wisdom. These are not insanely advanced or anything, just some handy tools that every RES admin out there ought to have in his toolbelt. An up-to-date list of all available buildingblocks on this site, can be found respectively in the PowerFuse and Wisdom Buildingblock archives. Click on the RAR files below to download the buildingblocks:

 PowerFuse BuildingBlock: Default Global authorizations. This buildingblock will help you get from pilot to production much faster, by implementing some best practices for authorizations. The buildingblock contains a set of Global Authorized files which will enable the most common authorisations for Windows XP and VMware workstation. This will enable you to switch both Application Security and Read-Only Blanketing into Blocking mode much faster. For those of you out there using Vista, a seperate buildingblock will be made available later, as there are loads more stuff that Vista wants to pull up at logon. Besides, XP/2003 administrators will probably be happy not having to weed out a ton of unnecessary authorizations. If you want to have a look what’s in the box :), check out this nifty PowerFuse Instant-Report:  

 PowerFuse BuildingBlock: Best Practice Registry settings. This is another buildingblock which will help you speed up initial deployment by implementing some of the most common HKCU registry settings. These cover a lot of common stuff, best practices, etc. For example you can redirect shell folders, disable the XP tour, configure the explorer windows properly and much more. You can preview the contens of the buildingblock by having a look at an Instant-Report for the module here:  

  Wisdom BuildingBlock: Add a computer to the domain. This is a simple module, however it ought to be in the toolbox of every Wisdom admin out there. It simply enters a computer into a domain, but also modifies the DefaultDomain registry key, so the user logging on afterwards does not have to change the domain dropdown. Believe it or not, this is a frequent item which helpdesks have to deal with, so why not eliminate it all together? The module should need no editing at all. When you import it into your Wisdom 2009 environment, it will prompt you for all necessary information.

  Wisdom BuildingBlock: Super Security Audit (21MB). With this module you will quickly get an overview of any outstanding security issues, related to missing updates, vunerabilities etc. The module installs MBSA 2.1 + the security cab files and report everything back to the Wisdom console. Also the module will report you MS product keys and do a WGA check on the machines you schedule the job on. There are several cool things worth mentioning about this module.

• The module contains all the components ready to go. No extra downloads are necessary.
• Just download, import and execute.
• It can operate offline, which makes it great for those kinds of datacenters where allowing the servers to access the Internet is not an option
• The module supports execution on both 32 and 64 bit OS’s. Wisdom will make sure the right bit-version of MBSA is executed on the righ platform

If you would like a sneak-peak of what this module can do look here:

A brand new article has been posted to the Technote Library. This time we’re diving into the PowerTrace tables. Being new to PowerFuse, some will be inclined to switch on everything, including PowerTrace turned to the Maxx, resulting in a potentially very unwanted huge heap of logdata and perhaps even a slow performing DBMS too.

This article explains how to both cure that situation if things have gone megabad, but also how to prevent it from happening in the future. 

Click here to read the full article.

Here is another Wisdom BuildingBlock for your consideration. This one will help you correctly set an environment variable across all your different computers in your organization, which will point to the local path of a mandatory profile, which should be used for the given operating system.

This may at first sound like utter nonsense, but think of it like this: Let’s say that you want to enable users to have the same profile across different systems, say Vista, XP and Terminal Services 2003. Impossible you say? Nope, this can be done.  There is a nifty whitepaper from RES, available here which describes the entire procedure:  

To sum up the whitepaper, you can:

• Create a mandatory profile for each of the operating systems which require it
• Upload these profiles to PowerFuse Custom Resources, which will automagically replicate them out locally to the %programfiles%\res powerfuse\data\dbcache \resources\customresources folder on all machines running PowerFuse. Make a structure in PowerFuse Custom Ressources as seen here on the right (note you do not have to create all the folders etc. just point to the root folder of an existing mandatory profile and the RES console will import it with all subdirectories)
• Run the module on all target machines where users will be logging in.
• Configure User Preferences to grab the stuff which you want to store for the users uppon logout.
• Modify the User records in AD, change the user profile path of the users to the variable, say %manprofile% (remember, this can be done in Wisdom too! – perhaps a subject for another buildingblock)

This result is quite spectacular:  All users share one singular profile path (which is dynamic).  The user session will be loading the right mandator profile, as it will be specified by the variable. The path will be local, resulting in zero network traffic as result of loading the profile locally.

The Wisdom module has been designed with module parameters, so you can customize your own paths etc, making it quite easy to use.

Click here to download the module: