Preconfigured voluntary settings in a mandatory profile

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:

Mo’ Blocks for the Builders!

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:

Configure global PowerFuse settings via registry

Here’s an interesting item which was shared a while back. This is a policy template for controlling the global settings of RES PowerFuse. It is believed to have been created by Sander over at the RES Inside blog. This template adresses an important need, since several options in the management console are still only globally configurable through the console GUI and may not apply to all users.

Using this policy template, it’s not the intention for you to start managing PowerFuse through AD. While possible it would be crossing the bridge for water, as PowerFuse in it self is perfectly capable of applying the user-specific parts of any policy template file. So, what we’re dealing with here is a way for PowerFuse to configure itself, using registry settings, while remaining inside the RES console. Sounds iffy? Don’t worry, it’s not – just do the following:

• Download the .ADM file from the link below
• Dump it somewhere  you can browse to it with a PowerFuse console
• Go to the configuration management | powerlaunch | user registry node
• Click the Add Policy button at the bottom
• Hit the Add button in the new dialog to browse for the .ADM file. It will now be uploaded to the PowerFuse SQL database, so you needn’t worry about distributing it anymore.
• Add some descriptive text in the name and description fields. You’ll thank yourself for this some months later down the road.
• Set to whom this applies on the Access Control tab.
• Start clicking away in the policy template, enabeling the desired settings.

There is a nice description of the entire thing in this PDF: 

Download the ADM file here (rightclick, save as): 

Important note: The PowerFuse policy template available above does not include the latest registy settings in the PowerFuse update pack 8.0.4.5.  Also, there may be some additional registry settings in this article about the PowerFuse registry, which are not included at the moment. If someone would be kind enough to update the policy template and share it with RESguru, we’ll post it.

Reducing the size of the PowerFuse database

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.

The Scoop on WorkSpace containers

A new article has been added to the RESus Technote library. The goal of this article is to help you come to grips with what a Workspace Container in RES PowerFuse 200x really is, what we can use it for, and how this may benefit you. To perhaps give you an initial idea of what a Workspace container is, think of it like this:

A WorkSpace Container is for settings and objects in PowerFuse, what an OU is for settings and objects in Active Directory.

In this day and age, where Virtualization is peddeled on every streetcorner, Marketing trolls are always on the lookout for the next buzzphrase to sodomize. It would seem likely that Workspace Management is up for grabs any time soon. Before all the circus clowns enter and start confusing everybody, let’s spend a little while together to get the low-down on what this Workspace Container thing really is. This also will be usefull for you to cut through all the saleswaffle when evaluating products claiming to do workspace management.

Click here to read the full article

PowerFuse 2008 SR4 update 8.0.4.5

By Max Ranzau

Febuary 19th 2009,  RES Software released an update of the Service Release 4 for PowerFuse 2008. It is now version 8.0.4.5. This update contains many important fixes. At the bottom of this posting, there is a link to download the releasenotes. There are also several cool enhancements to this update. These are mainly some interesting registry keys which you can use to tweak PowerFuse with. Here is an overview of these new settings, quoting from the releasenotes:

Configure cache timer interval. It is now possible to configure the cache timer interval. This interval determines how often the cache checks for changes in the database or for new transactions. The default for this interval is 5 seconds. This interval can be changed by setting the following registry key:

Key   : HKEY_LOCAL_MACHINESoftwareRESPowerFuse

Value : CacheTimerInterval (REG_SZ)

Data  : A value between 5 and 60 (seconds)

Warning: Changing the default of 5 seconds should only be done in special cases, such as a heavy load on the database server. 

Disable screensaver when RES PowerFuse Workspace Extender is active: When a RES PowerFuse session is started from a workstation with the RES PowerFuse Workspace Extender or the RES Subscriber Agent, the RES PowerFuse session will enable a Screensaver by default. It is now possible to change this behavior, by setting the following registry string value in either HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER

Key   : SOFTWARERESPowerFuse

Value : NoAgentScreensaver (REG_SZ)

Data  : Yes

Force LogOff of disconnected sessions after timeout: It is now possible to force a logoff of disconnected sessions after a specified timeout expires. This can be enabled by setting the following registry keys in either HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER

Key   : SoftwareRESPowerFuse

Value : ForceLogoffEnabled (REG_SZ)

  Data  : Yes or No (to enable/disable the mechanism)

Value : ForceLogoffTimeout or ForceLogoffTimeoutOnDisconnect (REG_SZ)

  Data: value in minutes

Value : ForceLogoffOnDisconnect

  Data  : Yes or No

If you are already using the ForceLogoffOnIdle mechanism, the timeout in ForceLogoffTimeout can be used to use the same timeout for both mechanisms, or you can use a different timeout to disconnect by setting a value in ForceLogoffTimeoutOnDisconnect.

Silent refresh of RES PowerFuse sessions: A silent refresh of RES PowerFuse will not show a splash screen during a refresh of the Workspace Manager, which in some cases is less intrusive for the user. A silent refresh will only be used when the refresh is a result of a display change, a USB device change or a reconnect of a disconnected session. “Silent refresh” can be enabled by setting the following registry key in either HKEY_LOCAL_MACHINE or HKEY_CURRENT_USER:

Key   : SOFTWARERESPowerFuse

Value : SilentRefresh (REG_SZ)

Data  : Yes or No 

The release notes for the 8.0.4.5 update can be downloaded here:

Parsing Remote User Access via PowerFuse and Citrix

Here is a new technote, kindly provided by one of the cool folks over at RES. This technote explains how you can configure an application for the PowerFuse Desktop. What’s special in this scenario is that the application will be made available to all users logging onto the network internally, however only certain managers will be able to access the application remotely via Citrix Web Interface. This could come in quite handy.

Have a look at the document here:  

Building a kickass Workspace Extender demo!

A new technote has been added to the library. This one takes you through how to set up the RES Workspace Extender, so you can play around with it in you own test/lab environment. The article offers usefull info into how the technology works and takes you step-by-step through setting up a really cool demo on either Terminal Services or citrix, using either a videoclip or an application.

The net result is that you now can run heavy, graphic-intensive apps as part of a centrally managed remote desktop, regardles of the underlying delivery technology.

A buildingblock is available at the end of the article so you can get started quickly using the RES Workspace extender. Read all about it here

Enjoy! /TRG

Switching off – Still a good idea!

Remember a little while back, we looked into how much money can be saved by turning off computers? An article was posted last month on how and how much money you can save if you can turn off selected computers and servers for a few hours every week. In case you missed it, the article can be read here. 

To make  the point that we here at RESguru.com are not completely bonkers (that is besides the point :), here’s a newspaper clip from the Reading Post (in the UK) of Febuary 11th. Click on it to view full-size.

Wisdom BuildingBlock: Mandatory Profile Path

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: