Service Orchestration Client for iPhone/iPad

Did you know that RES Software have an iPhone/iPad application available on the iTunes AppStore for the Service Orchestration components of RES Automation Manager 2011? No? Neither did we until we accidentally stumbled upon it!

Users are now able to both request services and approve/deny services directly from their mobile device. Included within the app is a demo mode to demonstrate how the approval process and workflows are performed. Here is a screenshot from the AppStore complete with BIG BUTTONS for denying or approving a service request.

 

We can only hope that there is also an Android application in development! Windows Phone anyone!? Remember that if you receive emails on your mobile device you can still be in control of the workflow processes – it’s just not as intuitive as links are launched in the mobile web browser.

Automation Manager 2011 – Master Dispatchers

RES Automation Manager (AM) Master Dispatchers now enable an administrator to remove replicated SQL instances that have historically been used for scalability purposes. In prior versions of RES Wisdom, if two or more dispatchers are deployed over a WAN link it was recommended to place a replicated SQL instance on the remote site. The reasoning behind this was sound. As every Dispatcher talked directly to the SQL database placing two Dispatchers would require the resources to be downloaded twice. If we replicated the SQL database instance the resources would only traverse the WAN once as the Dispatchers would get their resources from the replicated SQL database instance.

Unfortunately the replication was only supported by Microsoft SQL Standard and up. Microsoft SQL Express was out the question so we had additional licensing costs. The setup and maintenance of SQL replication is also complicated and generally requires dedicated DBAs. Adding SQL database instances in large environments with many sites was challenging. Note: In large RES Wisdom/Automation Manager installations a replicated SQL instance is still highly recommended for resilience.

Enter 2010 and RES Automation Manager 2011! The new Dispatcher (now known as an “Engine”) model now includes the notion of Master and Slave Dispatchers. We don’t need to configure the Master Dispatchers per se, but we can point a “Slave” Dispatcher at a particular “Master” Dispatcher (or Master Dispatcher List). Now if there is more than 1 Dispatcher required at a remote site, we configure all but one as Slaves and the resources are only downloaded once over the WAN via the Master Dispatcher. The “Slave” Dispatchers download their resources from their Master Dispatchers; no more additional Microsoft SQL licensing and no need for DBAs (if you don’t already employ them!).

From a “RES Wisdom/Automation Manager Service Provider” (RAMSP – yes I did just make that acronym up!) point of view it now means you can protect your SQL instance and configure all remote Dispatchers as Slave Dispatchers, pointed at the hosted Master Dispatchers. Only the hosted Master Dispatchers will ever need to talk the SQL database improving security and reducing the number of open ports.

Note: It is possible and supported to daisy-chain or tier the Engines. I have no confirmation on the official tested/support limits, but being able to tier the AM Engines to two or three levels deep should enable us to support even the largest infrastructures (just wish Workspace Manager used this model Smile). Kudos RES!

Automation Manager 2011 – Evaluators

One of the major failings of RES Wisdom 2009 (and prior) was the inability to automatically action the results based on a query. For example, there has never been an easy way to defragment computers if the local drives were above a threshold. We could always automate the querying of machines and automate the defragmenting of disks drives, but basing an action on the results of a query involved manual intervention.

Some if this has been remedied in RES Automation Manager 2011. The list of queries that support the new “Evaluators” is limited, but it certainly a good start and hopefully this list will grow in future Service Releases (or are they now Service Packs?) and/or RES Automation Manager releases. These are the query types that are supported:

  • Query Computer Properties
  • Query Disk Space
  • Query Installed programs
  • Query Service Properties
  • Query TCP/IP Properties

This new feature provides us with an additional tab on particular queries. We can evaluate (now you know why they’re called Evaluators!) the results of the query and set whether query is successful or not. RES Automation Manager 2011 will fail the task if the evaluator fails our criteria enabling us to have some logic control. Note: setting Evaluators automatically sets the job to “Continue On Error” where the normal default is “Stop On Error.” Unlike Conditions, Evaluators are evaluated after the task and not before (like Conditions).

The example RES provides in the Help takes a Windows Installer job that queries the amount of disk space first. An Evaluator can be set to fail the query and the job (assuming you alter the task error control). Here is an example of this Evaluator that will fail the query if there is less than 500MB of free disk space.

RW2001-Evaluator-1

If we alter the task properties like this then we can fail the job as a whole (which we would probably do in this instance):

RW2001-Evaluator-2

Notice that we still can’t do this with the disk defragmentation example at the beginning of this post as it’s not a supported query type!

Note: If the query fails the job as a whole is reported as failed which makes managing by exception difficult when evaluators are used and clouds the job results view. Hopefully this behaviour will be updated (tested with the Release Candidate) in the RTM or a Service Pack release.

Migrating GPOs to RES PowerFuse (Part 3)

So far in our ambition to migrate existing Group Policy Objects into RES PowerFuse we have detailed the shortcomings of doing so (Part 1) and discovered that all the registry settings for the User Container settings (“Administrative Templates” only) in a GPO are stored in the SYSVOL share as a REGISTRY.POL file (Part 2). Now we need to transpose the settings contained within the .POL file into a .REG file that is useable by RES PowerFuse.

Unfortunately, the .POL file format is a binary format that is not the same as the text-based .REG file format. There appears to be no easy way to view the contents of these files. The binary format is documented on the MSDN web site if you feel inclined to have a look. When we open a .POL file with notepad this is what we get:

Registry.pol

Therefore, before we can import this into RES PowerFuse we need to convert it to a text-based .REG file. After many hours scouring the internet, only a handful of solutions seem to be available.

There do appear to be some commercial registry utilities, i.e. Registry Workshop, that permit the loading/viewing of .POL files. The evaluation version of Registry Workshop does not allow exporting so it is unclear as to whether a .POL file can be exported as a .REG file that we can use with RES PowerFuse. In addition, we’re after a solution that doesn’t cost any money.

An alternative is the REGVIEW.EXE utility in the Windows 2003 Server Resource Kit. This does allow us to view the contents of the REGISTRY.POL file. Running the utility displays the contents of a .POL in text format like this:

regview_registry.pol

Unfortunately, this utility does not allow us to convert the REGISTRY.POL to a useful format, e.g. CSV. To utilise this tool we will have to redirect the output to a .TXT file, e.g. REGVIEW REGISTRY.POL > OUTPUT.TXT. Once in a plain text format we would then have to run another tool or script to convert the output to .REG. This is going to require some development time to implement.

To be continued…

RES Automation Manager 2011 Release Date

According to the new look RES Software web site, RES Automation Manager 2011 (formerly RES Wisdom) product will ship on the 1st November 2010. I can reveal that the RES Wisdom 2011 Release Candidate has already been rebranded as RES Automation Manager 2011. More details/information on the new features will published once the final product is available from the RES Software web site.

RES Software have Rebranded

RES 2010 Logo

Today, RES Software’s web site has a new look and feel. In addition the RES PowerFuse and RES Wisdom products have also been rebranded. Here are the highlights:

  • RES PowerFuse will be now known as RES Workspace Manager.
  • RES Workspace Manager will no longer be licensed as different Editions, rather each module will be licensed separately (Yay!).
  • RES Workspace Manager Modules:
    • Composition & Personalization
    • Advanced Administration
    • Security & Performance
  • RES Wisdom will be known as RES Automation Manager.
  • RES Automation Manager Modules:
    • Task Automation
    • Resource Provisioning
    • Service Orchestration
  • The RES Dynamic Desktop Studio will be available as the new bundle of all technologies.
  • RES Subscriber/Workspace Extender will be known as Virtual Desktop Extender (VDX) and available as a standalone product from January 2011.

Overall – exciting times!

The Power Of 3

With the release of RES Wisdom 2011 hopefully dropping in our laps by the end of this calendar year, I thought it would be wise to revisit the Orchestration Pack for Wisdom. Having delivered many, many training courses this year, it is something that is discussed during both the RES Wisdom 2009 and RES PowerFuse 2010 courses. However, that is it – generally it is just a passing mention! I think this will be changing with RES Wisdom 2011 so we’d better get to grips with it.

RES Orchestra was always going to be the 3rd product in the RES Software suite, but RES instead rebranded it and announced it as an add-on for RES Wisdom (announced back in August 2009). The theory behind the Orchestration Pack is to be able to add business logic and workflows to both RES PowerFuse and RES Wisdom. When all three products are combined together we end up with a very powerful solution, driven by the business and not the IT department.

At a high level we define a “Catalog” of “Services” that are available to “Subscribers”. These Services could be anything that the business offers that requires some automated process and/or workflow to be performed (you’re only limited by your imagination). To get you off to a flying start we normally start with the basics; like granting access to applications or provisioning of a new user. These are IT related tasks, but they help you “get what Orchestration is all about.”

Let’s take our typical RES Wisdom Run Book example; provisioning a new user. You might have a Run Book defined within RES Wisdom that creates the user account in Active Directory (and configures it), creates their Exchange mailbox, creates the user’s home directory and then secures it. In addition you may have multiple Run Books that adds the user account into different sets of AD groups or creates MS SQL accounts depending on the user’s role.

Here is a “typical” new user (with RES Wisdom) workflow:

  • A manager in the business requests a new employee.
  • HR authorises the request and passes the request to IT.
  • IT provisions the user (via the RES Wisdom Run Book!).
  • IT adds the user to the relevant AD groups for the proposed role (via another RES Wisdom Run Book(s)).
  • IT send the details of the new user account to HR.
  • HR forwards the details back on to the requesting business manager.

In the above example, the RES Orchestration Pack will enable us to encapsulate the business logic and the workflow processes via the Orchestration Client (32-bit client executable) or via email and the Orchestration Web Client (hosted on IIS). We can offer the “New Employee” “Service” via the “Catalog” to the business managers. The RES Orchestration Pack will allow the business manager to complete the new starter request via an internal web site (with all the required new starter information) and automatically notify the HR department. Once HR approves the request, the RES Wisdom Run Book is automatically started to create the AD user account and mailbox etc. Once complete the details of the user account can then automatically be sent back the business manager.

We can take this process further and define what happens when the “New Starter” request is reversed. Now we have the power to start an alternative Run Book to decommission the user account when initiated by HR.

So what about “The Power Of 3?”, I hear you ask. We can connect the RES Orchestration Pack to RES Wisdom, but what about RES PowerFuse? Well, it’s good news here too. Within RES PowerFuse 2010 we have the ability to assign access control principal to a RES Orchestration Pack “Service”. When a “Service” is provisioned/authorised then we can grant access to RES PowerFuse 2010 applications. Here is a scenario that takes our HR example another step further on:

  • A user can request a “Service”, i.e. Adobe Acrobat.
  • The request is sent to the user’s line manager for approval.
  • If the business manager approves it then a notification is delivered to the account department for recharging.
  • Once a user has been granted access to the “Service” we can now make applications available to the user automatically via RES PowerFuse.
  • We can configure RES PowerFuse to launch a RES Wisdom module to check for the existence of the application prior to launch.
  • If it’s not installed, pop up a message and install it on demand.
  • Once installed, it will launch.
  • If the user is revoked access in due course, RES PowerFuse will not display the application to the user.

Now we can automate the business workflow, authorisation, delivery, presentation and installation of services and/or applications without being involved. The business has the power to decide where and when things happen, not IT. That my good friends, is the power of 3; RES Wisdom, RES Orchestration Pack and RES PowerFuse!

Decoding the PWRMENU.INI Colours

Setting the desktop foreground and background colours is something that trips most of us up when we’re first picking up RES PowerFuse. The default PWRMENU.INI file contains default colours that are created at install that apply to all users. If these colours are changed via the Composition > Desktop > Background node in the RES PowerFuse Management Console, then the template PWRMENU.INI file is updated. Any time a change is made to the desktop colours, it won’t affect users that have already launched a RES PowerFuse session as the user’s PWRMENU.INI file won’t get updated (with the default settings). For an explanation and work around this, see RES Knowledgebase Article Q200186.

This however, is not what this post is about. Typically when uploading a custom background image we normally wish the background colour to match the background colour in our .BMP file (remember only the RES PowerFuse Shell supports .JPEGs). This is certainly true if we’re not stretching the image to fill the screen. If it’s not changed you’ll see the default blue background applied before the background image is applied and/or borders around the background image.

Unfortunately for us, when selecting the colours using the RES PowerFuse Management Console it is not necessarily intuitive or easy to pick the right colour that matches your uploaded .BMP file. We have to specify a custom colour, enter the RGB values, save the changes to make sure the default PWRMENU.INI is updated, open the default PWRMENU.INI file, note the colour “number” specified next to the DesktopColor property and then create a Home Directory Maintenance Task to update this value for existing users (as per the aforementioned KB article). Not particularly quick nor intuitive. Note: If you’re after a tool to pick up colours then you can use ColorPic and it freeware.

We’ll take Virtual Engine as an example. Internally there is a colour that is known as VE-Blue (or Virtual Engine Blue). This is the standard shade of blue used in email communication, on business cards and the on web site etc. The RGB (Red, Green and Blue) representations of this are; 4 (Red), 73 (Green) and 157 (Blue) or 04499D in hex. Is there an alternative process available to set the background colour used by RES PowerFuse without jumping through all the hoops listed above?

In the user’s PWRMENU.INI configuration file the colours are not specified in the standard hex/web format, they’re represented as a decimal number. Using the “Programmer” view available in the standard Windows 7 Calculator we can convert 04499D (hex) into decimal (280989). We now have the decimal representation that can be put straight in to the Home Directory maintenance task. Knowing this information we update the default PWRMENU.INI file and create a Home Directory Maintenance Task that updates this for all existing users… Ah – when testing this we end up with a nice brown, muddy background. Not what was expected!

After a little bit of reverse engineering, it turns out that the number is reversed and actually stored as a BGR (Blue, Green and Red) value. In our example we need to convert 9D4904 (hex) to its decimal value, i.e. 10307844. Putting this value in our Home Directory Maintenance Task and the default PWRMENU.INI file works first time and is an exact match. If you happen to have lots of different coloured backgrounds for various departments in your environment, this little bit of knowledge might save you 30 minutes and a lot of frustration one day..

Staging RES PowerFuse 2010 Agent Deployment

Disclaimer: This is definitely something that  is not supported or endorsed by RES Software in any way shape or form. If you can avoid doing this then do not use it. Use at your own risk!

In large RES PowerFuse deployments where RES PowerFuse agents are located over a WAN link, deploying RES PowerFuse can place an unwanted strain on those WAN links during initial deployment. When the RES PowerFuse agent is first installed, it connects to the database and downloads the cache. Until this is complete (and if the Workspace Composer is enabled) a user is unable to log in.

In instances like this it is ideal to have database instances located on the local sites but this is not always possible due to licensing issues etc. If this is the case, then having 100+ agents download 50MB+ leads to a lot of unwanted bandwidth being consumed! This guide will help you stage the deployment so that the agents only download the deltas from our “database snapshot” that is deployed as and when we install RES PowerFuse.

To accomplish this, we need to think about the database structure and how the agent caches its information. The RES PowerFuse 2010 database contains GUIDs for each of the configuration database tables and a master GUID. Whenever anything is updated within the Management Console, the master GUID is updated and this update is cascaded to all corresponding configuration tables that have changed, updating their GUIDs in turn. When an agent connects it checks the master GUID and if different from its own master GUID, compares the GUIDs on each table and downloads the differences. The agent stores its cache and state information in a few places:

  • The local state of the database cache is maintained in the registry (HKLM\Software\RES\PowerFuse\UpdateGUIDs). These values are the GUIDs that the agent uses when connecting to the database. If any database configuration table GUID is different from what is stored here, an update is performed and the GUID changed to match the GUID in the central database.
  • The cached database tables are stored in XML format in the ‘%RESPFDIR%\Data\DBCache\Objects’ directory.
  • All other supporting resources are located within the ‘%RESPFDIR%\Data\DBCache\Resources’ directory and ‘%RESPFDIR%\Data\DBCache\IconCache’ directories.

Now, in theory all we need to do to pre-stage the agent cache is make sure that the UpdateGUIDs in the registry match what is in the \Objects, \Resources and \IconCache folders when the agent service is started. To capture our pre-staged “snapshot” we need to perform the following actions:

  1. Stop the RES PowerFuse agent service.
  2. Copy the \Objects, \Resources and \IconCache folders somewhere safe.
  3. Copy all the UpdateGUIDs from HKLM\Software\RES\PowerFuse\UpdateGUIDs (probably an export to a .REG file)

Herein lies the key to this operation. When we deploy the agent, the RES PowerFuse agent service is going to automatically start and proceed to populate the local cache and update the UpdateGUIDs in the registry. We do not want this to happen until we’re ready. Therefore, this is the process that we need to achieve:

  1. Install the RES PowerFuse agent unattended in the supported fashion, i.e. with Wisdom, ensuring that the agent service does not start.
  2. Copy our “snapshot” files to the \Objects, \Resources and \IconCache folders. How we do this depends on your deployment methodology. Typically the “snapshot” files would be captured as a RES Wisdom Resource Package, but it doesn’t really matter.
  3. Set the HKLM\Software\RES\PowerFuse\UpdateGUIDs registry values to our point-in-time ““snapshot” to match what is representative of the “snapshot cache” folders. Again, this can be achieved quite simply with a RES Wisdom “Apply Registry Settings” task, but could also be achieved via a batch file calling REG.EXE.
  4. Start the agent service (a reboot is still required for the kernel mode drivers to start). If we just reboot the service state is left as “Automatic” and will start after just a reboot.
  5. The agent will check the database and only download the deltas from the point-in-time “snapshot” hopefully saving a whole load of bandwidth!

The only real “gotcha” in this entire process is ensuring that the agent service does not start when the agent is installed, e.g. in Step #1 above. As the agent does not support the public properties to accomplish this we need to do it via a .MST file. To save you a whole load of time and pain we’ve kindly left one here for you called “RPF-NoServiceStartAfterInstall”.

Our example deployment command for Step #1 might look a little like this: MSIEXEC.EXE /i RES-PowerFuse-2010-SR2.msi TRANSFORMS=RPF-NoServiceStartAfterInstall.mst DBTYPE=MSSQL DBSERVER=<DatabaseServer> DBNAME=<DatabaseName> DBUSER=<DatabaseUser> DBPASSWORD=<DatabasePassword> /norestart /qn

Please remember; test and test again!

Migrating GPOs to RES PowerFuse (Part 2)

In Part 1 we covered the basics of Group Policy Objects (GPOs), how they are implemented and the shortcomings of implementing Policy objects as User Registry Policies within RES PowerFuse. In our quest to work out how to migrate existing GPOs in to RES PowerFuse we’ll take a deeper dive in to how GPOs are stored and how we can get the existing settings out and allow us to import them into RES PowerFuse.

GPOs are stored within the SYSVOL share on Domain Controllers within the Active Directory infrastructure. The following information is from Group Policy Storage page from Microsoft.com.

Group Policy objects also store Group Policy information in a folder structure called the Group Policy template that is located in the System Volume folder of domain controllers (Sysvol) in the \Policies sub-folder. The Group Policy template is the container where Security Settings, Administrative Template-based policy settings, applications available for Software Installation, and script files are stored.

When you modify a GPO, the directory name given to the Group Policy template is the GUID of the GPO that you modified. For example, assume that you modified a GPO associated with a domain called Seattle. The resulting Group Policy template folder would be named as follows (the GUID is an example):

%systemroot%\sysvol\<SYSVOL>\Seattle.yourcompanyname.com\Policies\{47636445-af79-11d0-91fe-080036644603}

Registry.pol Files

All settings defined within the “Administrative Templates” section of a GPO are saved into the SYSVOL location indicated above as a REGISTRY.POL file either under the \User or \Machine subfolder depending on whether they are User-based or Machine-based policies. Here is the quote from the MS page:

The Administrative Templates snap-in extension of Group Policy saves information in the Group Policy template in Unicode files referred to as Registry.pol files; they are stored in the Group Policy template. These files contain the customized registry settings that you specify (by using the Group Policy Object Editor) to be applied to the Computer (HKEY_LOCAL_MACHINE) or User (HKEY_CURRENT_USER) portion of the registry.

Two Registry.pol files are created and stored in the Group Policy template, one for Computer Configuration, which is stored in the \Machine subdirectory, and one for User Configuration, which is stored in the \User subdirectory.

When you use the Administrative Templates extension of the Group Policy Object Editor to define customized registry settings, two Registry.pol files are created and stored in the Group Policy template. One Registry.pol file is for Computer Configuration-related registry settings and is stored in the \Machine sub-directory, and the other is for User Configuration settings and is stored in the \User sub-directory.

This means that all the User-based “Administrative Temples” settings within a GPO are stored within a single REGISTRY.POL file under the \User folder in the SYSVOL share. Therefore, if we can import the REGISTRY.POL file into RES PowerFuse we have a simple way of migrating an existing GPO, in its entirety. The custom extension information won’t be imported, e.g. software installation policies etc, but you’re probably using RES Wisdom for this anyway! There will be no need to manually import the ADM/ADMX templates and manually recreate all the individual settings for everything defined under the “Administrative Templates” section. Simples!

To be continued…