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.”
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.
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!
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.
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 ). Kudos RES!
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.
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):
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.