Virtual Engine Toolkit BETA 2 Released

The Virtual Engine Toolkit BETA 2 (VET) has been released and can be downloaded from the web site here. This tool is free and will always be free although registration is required. At present there is currently no help available within the BETA 2 download so there will be a lot of blog posts to explain how all the features work to allow you to get you up to speed promptly.

So what does the Virtual Engine Toolkit do and what is its purpose?

The Virtual Engine Toolkit was originally developed (as the Building Block Spinner) to help automate the process of moving RES Workspace Manager Building Blocks between two domain environments. For example, you may have a development or test infrastructure that the RES Workspace Manager configurations are built/tested in and a live/production environment that is servicing your users. If our test and live databases are configured against the same Active Directory domain then they can typically be imported directly into the second environment. This scenario is covered in more detail in the Building Block Spinner (BETA 1) post.

This tool has since been extended to help with migrating and implementing Group Policy Objects within the RES Workspace Manager Management Console. The development won’t stop here so keep an eye out for future releases and future blog posts!

How can the Virtual Engine Toolkit help me?

The Virtual Engine Toolkit allows an administrator to specify different domain names for each of the two environments and select multiple Building Block files. When run it will create two sets of Building Blocks; one for the test environment and one for the live environment. Once the process is complete the Building Blocks can be loaded straight into the RES Workspace Manager Management Console. This saves you from having to perform a find and replace on each individual Building Block file which is both time consuming and error prone.

Existing Group Policy Objects (GPOs) can be converted in to .REG files for importation into RES Workspace Manager. This functionality mitigates the requirement of having to manually recreate existing GPOs within the RES Workspace Manager console.

Group Policy definition (both ADM and ADMX) files can be merged into a single file for more simple, logical management within RES Workspace Manager.

What next?

There are some additional use case scenarios for all you RES Workspace Manager consultants out there but we’ll save them for a future post. If you have any feedback, have found a bug or would like to see additional functionality put into the product then please Contact Us via the web site.

Remote Assistance Troubleshooting

With any VDI technology that leverages Microsoft’s RDP (Quest’s vWorkspace and VMware’s View) deploying Microsoft’s Remote Assistance (RA) is a requirement for support as the typical remote console solutions do not work as originally intended. RES integrated the Remote Assistance technologies with the release of RES PowerFuse 2010 (Service Release 1?) and as a result we’re seeing more people attempting to integrate Remote Assistance with their VDI deployments. There are few things that can, and do go wrong.

RES Workspace Manager will configure the Remote Assistance registry settings on the local computer via the RES Workspace Manager agent without requiring Group Policy Objects or manual configuration of the registry. This includes ensuring that RA is enabled, the firewall ports are open and the RA Helper Active Directory accounts are populated with the specified groups. Once a Remote Assistance session is offered by the administrator via the RES Workspace Management console, this is handed off to the underlying infrastructure and RES Workspace Manager has nothing more to do with the remote session. If you’re having problems with Remote Assistance you might want to double check the following.

Local Helper Account

Ensure that the local HelpAssistant account is not disabled (on Windows XP). This account needs to be enabled on both the machine offering the Remote Assistance session and the target machine. If this is not enabled on the source computer, you may receive the “There is a problem with the invitation and it cannot be opened. To use Remote Assistance, the sender of this invitation will have to send you a new invitation.”

Remote Assistance HelpAssistant Error

Windows XP Help and Support Service

Double check that the “Help and Support” Service is enabled on Windows XP machines. There may be an old Group Policy Object somewhere that has disabled this and without this running, Remote Assistance is not going to be going anywhere! This service has been deprecated with Windows Vista and Windows 7.

DNS

The standard name resolution process is used to contact the destination computer when a Remote Assistance session is initialised. We have seen issues in VDI environments where the DNS records for desktops become stale. Here is a particular example:

  • VMware View is deployed with linked clone technology.
  • As VDI is booted it registers in DNS for the first time.
  • When the VM is recomposed it ends up with a new computer SID/MAC address but the same hostname.
  • The VDI attempts to update the DNS record but can’t because the SID associated with the DNS entry is incorrect.
  • If the RES PowerFuse console is located on a different subnet to the destination computer, Remote Assistance fails.

To ensure this isn’t a problem, make sure the computers are shutdown cleanly (and double-check their DNS entries are removed) before recomposing!

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.

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..