DABCC Radio Podcast: AppSense User Rights Management!

October 26, 2010

AppSense has further enhanced our world leading ‘User Virtualization solution, adding the much awaited User Rights Management functionality.  Doug Brown has posted a Radio Podcast interview, details below:

In episode 141, Douglas Brown interviews Simon Rust, Vice President of Technology at AppSense. Simon and Doug discuss new AppSense User Rights Management technology available now as part of AppSense Application Manager 8.1. Simon does a great job explaining what is it, how it works, what is takes to install, why we should care, and much more.

User rights management benefits users by:

  • Elevating user privileges for running applications – by specifying applications to run with administrative privileges. This enables the user to be removed from the local administrators group, thus removing the risk of all applications executing under the administrative user context.
  • Organizing user rights for running control panel applets – by allowing a standard user to make the required changes and complete their job tasks without running as a local administrator. This is extremely useful when users need to change printer, wireless network, time and date settings, etc.
  • Prioritizing user rights to restrict application rights – by enabling system administrators to set and enforce policy for specific applications so that the user runs as an administrator but other applications are forced to run as a standard user, ensuring security is not compromised.
  • Managing access to system settings – by permitting system administrators to prevent admin level users from changing configuration settings that can expose enterprises to new security concerns such as security or firewall settings.
  • User rights management is available now as part of AppSense Application Manager 8.1.

To listen to the Podcast, please click on the image below or use this link here

 

A special thanks to Doug for taking the time to record and post this Podcast, thanks buddy :)

We hope you enjoy it…

Thanks

Gaz




The case of the failing signed driver install

February 11, 2010

I was asked recently to look at a couple of support cases that had been logged where installations of our Application Manager and Performance Manager products were failing. The logs from the failed installations, obtained from invoking msiexec with the /l*vx syntax, gave the following error:

(Error code 0x800B0109: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.)

A web search for the error gave many matches which didn’t really help so I then tried to reproduce the error in a Windows Server 2003 x86 virtual machine but the installation worked fine, as it usually does. Analysis of the msiexec log from the failing system indicated that the error was occurring when installing our signed device drivers. So next I ran the great Process Monitor tool from SysInternals, now Microsoft, to try and understand what was happening, file system and registry wise, during the installation, particularly around the area where the msiexec process installs the device drivers.

What this showed me was immediately before our driver catalog (.cat) file was read, the “State” registry value in the following key was being read:

HKEY_USERS\.DEFAULT\Software\Microsoft\Windows\CurrentVersion\WinTrust\Trust Providers\Software Publishing

Given the error text from the failed installation, this looked relevant. A quick web search threw up a number of interesting articles, namely:

http://msdn.microsoft.com/en-us/library/aa388201(VS.85).aspx

and

http://blogs.msdn.com/spatdsg/archive/2006/06/05/618082.aspx

which led me to try changing the “state” value in the registry in my test VM from 0x23c00 to 0x40000  (WTPF_ALLOWONLYPERTRUST as per the MSDN link above and the wintrust.h header file so effectively much more restrictive than what was in this value by default).

Retrying the previously successful installation in my test VM then gave exactly the same error that our customers had been experiencing. On passing this information on, both customers confirmed that their “state” registry values were either not as per the default or were missing, due to the parent key being absent, and that setting the “state” value to the default allowed the drivers to be successfully installed.

Case(s) solved! But this leaves me with the desire to know what caused this to happen, particularly as we have had two cases from different customers logged so closely together, given that I stopped believing in coincidences many years ago. This is the main reason for me blogging about this issue – I hope that by the power of search engine indexing that if others suffer this issue then they will be brought here and their problem solved.

Guy Leech

10th Feb 2010






Some Citrix XenDesktop Troubleshooting Tips

September 23, 2009

I have recently had to build a new Citrix XenDesktop environment for some testing which included Citrix Provisioning Server and Citrix XenServer. Along the way, I had various issues and struggled to find a single, comprehensive, troubleshooting article so I am going to have a stab at it here since I had to go through various tests in order to sort my issues. Having said this, there are some very good technotes on the Citrix web site here – http://support.citrix.com/product/xd/v3.0/technote/

  1. Enable logging for the Workstation Agent and ensure that access to the C$ share of the master XenDesktop image is enabled, including a firewall exception for file sharing. This is so that you can get at the log file without having to log on interactively to the image. See this article for how to enable the logging by a simple edit to the WorkstationAgent.exe.config file:  http://support.citrix.com/article/CTX117452 

    Obviously ensure that the Workstation Agent (Citrix Desktop Service) is successfully starting, as are other Citrix services, and the log shows it registering with the DDC.

  2. The event logs are also obviously another place to look when things fail although this can be tricky if your VM has been connected enough to want to reboot when the connection attempt has failed.
  3. You can also enable logging for the Desktop Delivery Controller service which is detailed in the link above. Ensure that the DDC service and other Citrix ones start successfully.
  4. PortICA logging can be enabled – http://support.citrix.com/article/CTX118837 – which could show potential ICA problems. It didn’t for me but will stay enabled in my base image whilst I am still testing.
  5. Citrix tracing tool (CDF – Citrix Diagnostic Facility) – this didn’t help me as it only currently supports a small number of client side features such as USB. It can also be run on the machine running the Workstation Agent but I didn’t do this.  http://support.citrix.com/article/CTX120269
  6. I did have some errors when using the XenDesktop Setup Wizard so I followed the steps to get a log file for this. I couldn’t get the log produced via the command line so ended up modifying the .config file as described here: http://support.citrix.com/article/CTX118278 

    My issues actually turned out, I think, to do with the fact that the template I was specifying in the wizard had an 8GB disk attached (it was my Gold Build VM that was booting off the PvS disk but still had the original hard drive in case I needed to rebuild the PvS disk) so each new VM created by the wizard was creating a new 8GB disk and I simply didn’t have the storage for it (not that I got an error suggesting this). I therefore created a new VM in XenServer that had the memory, NIC and CPUs I wanted but had no hard disk so actually didn’t have an OS installed (it never even got booted). This doesn’t matter since the OS comes from the vdisk/vhd you specify, separately, in the wizard.

  7. Check that you can logon with the required accounts to the VMs in your XenCenter/XenServer console. This should show any domain joining or account issues, e.g. expiry or permissions. Also check network connectivity to/from them.
  8. Fire up your gold image VM, since it should be on a standard image disk so the changes will be lost when it shuts down, add it to a new desktop group without a hosting infrastructure so that you just use the name of the VM in the group. This should tell you if the problem was something funny about the desktop group or the VMs that comprised it.
  9. My issue was that I was launching the connection from Web Interface but I wasn’t getting a session, just a failure popup – “Unable to connect to the desktop. This may be a temporary problem. Click OK and then try starting the desktop again. If the problem persists, contact your system administrator”. Before acknowledging the failure popup, look in your %temp% folder for the ICA file that it dynamically created. It won’t be a .ica file but instead will most likely be a .tmp file although will probably start “ica*”– easily spotted by modification time, particularly if you sort on modification time. It is actually the argument to cdsbar.exe if you look in Task Manger on Vista or with SysInternals/Microsoft Process Explorer. Open the ica file in notepad and check that it makes sense – e.g. is connecting to the right thing (“Address=”) and that the entity can be resolved/contacted. Note that the ica file, in best Mission Impossible style, will self destruct, i.e. be deleted, when you ok the failure popup thanks to the “RemoveICAFile=On” line. Note also that there is little point in saving the ica file for later use since it has a logon ticket in there which most likely will have expired.
  10. This leads on to checking that port 1494 is accessible in the virtual desktop by telnetting to it. However, port 1494 is only alive for a brief while after the connection is initiated so wait a few seconds after you have clicked on the icon to launch the session in Web Interface, or Program Neighborhood, before trying the telnet. When accessing a pool, look at the temporary ICA file to figure out which machine to check or reduce the pool to a single machine. We are not really looking for anything here other than the connection succeeds although you will probably see the characters “ICA” displayed.
  11. As by this stage all logs were looking fine and port 1494 was working, I put on a network monitor, in this case SysInternals/Microsoft Process Monitor, on my client machine (the one accessing Web Interface) and filtered on wfica32.exe. This is when I found that some traffic was going through my proxy that I hadn’t allowed for – bingo, problem solved when the proxy was disabled. In my defence, I had tried accessing from a different client (this should probably be a separate line item in this troubleshooting “guide”) but that had also failed, albeit probably for different reasons as it wasn’t using a proxy.
  12. Watch for proxies! Obviously configure them as necessary or disable them.
  13. I did have some “funnies” with my XP VMs created by the XenDesktop Setup Wizard and running off PvS. I think they were because after creation I had switched the master disk away from Standard Image mode. My excuse is that you have to manually hit F5 to do a refresh after changing vDisk properties and I didn’t! I was actually getting the error described here: http://forums.citrix.com/message.jspa?messageID=1393521 

    Sometimes the streaming console (StreamConsole.exe) on the PvS box can help diagnose these kinds of issue. Unfortunately it didn’t in this case.

  14. I also got caught by my base image having miniscule event log sizes (64KB) so even though they weren’t up for long, it was enough for them to fill up and not to overwrite so it was back to the base image to set larger sizes and set them to overwrite as needed.