Category Archives: Citrix

Why Citrix and Microsoft’s new servicing models now make sense

OK, so I wasted a little bit of time. I know.. it’s a shame when that happens, but it’s even worse to make the same mistake twice! So please read on in case you head down the same road without keeping your eyes peeled for the pitfalls. So what’s the take home message of this post? Microsoft and Citrix now need us (no actually, require us) to do as every professional should always do, and plan our release schedules properly!

This post discusses an issue I experienced installing Citrix XenDesktop VDA 7.15 on Windows 10 Fall Creator’s Update – receiving error 1603 when the Citrix Diagnostic Facility component failed to install. If you’re short on time, skip to the end for a series of helpful links – otherwise, bear with me and I’ll take you on a short journey to grudging mindset shift!

I’d wasted a morning patching a Citrix base image from Windows 10 build 1703 to 1709 Creator’s Fall update because we were looking to create a clean desktop for some developers to test their software releases on. But try as I might, the Citrix 7.15 VDA installer wouldn’t complete and always terminated with error 1603 –  the Citrix Diagnostic Facility (CDF) service had failed to install. After investigating the logs though it wasn’t clear why, other than a permissions failure on C:\Windows\assembly\tmp – and even checking those showed little evidence for the cause of the problem.

But here goes, after a little bit more digging I discovered that the latest Citrix VDA does NOT support the latest semi-annual ‘targeted’ release of Windows 10 (1709). See issue #1 on Citrix blog post.

Could I believe it? No, not at first really – how could a desktop OS release made generally available on 17th October 2017 not be compatible with the latest Citrix VDA which has also been chosen recently as the most recent Long Term Service Release version? Surely this new XenDesktop LTSR release would have been coordinated with Microsoft’s own release schedule, with release candidates being shared well in advance so that both vendor’s would have had a chance to test their interaction together?

Apparently not – and therein lies the message. You cannot expect that each vendor is attempting to align their minor and major servicing schedules with each other! ..Assuming.. that the latest Citrix VDA will work with the latest release of Windows is no longer going to float, and that’s why we all need to fully commit to the “test, test and test again” approach.

In fact, the logic was established a long time ago.  The last LTSR release of XenDesktop (7.6) did not support Windows 10 claiming this as a ‘notable exclusion’ despite the fact that early Windows 10 versions had been around for some time.

Notable Exclusions: These are components or features that are just not well suited for the extended lifecycle typically because this is newer technology that we plan on making significant enhancements to over time.  This is where Windows 10 fell when we originally launched 7.6 LTSR.

Citrix then later added retrospective support for Windows 10 by encouraging the use of VDA 7.9 in conjunction with the XenDesktop 7.6 LTSR release when it appeared that this combination worked well. However hope for the future compatibility was even made clear at this time with the following statement being added to the end of that post.

Finally, we want to note that Citrix is targeting to announce a new LTSR version in 2017 adding full LTSR benefits for the Windows 10 platform. However, this current announcement makes it easier for you to jump on Windows 10 desktop virtualization today while still maintaining all the benefits of being LTSR compliant.

And whilst it is indeed true that XenDesktop 7.15 LTSR release fully supports Windows 10 current branch/semi annual channel, it seems that only a simple statement on ‘requiring VDA 7.9 or later’ was made as long as you are happy to stick to the ‘Current release’ path:

Note about Windows 10: Regular support for Windows 10 is available through the Current Release path. Windows 10 does not get the full set of 7.15 LTSR benefits. For deployments that include Windows 10 machines, Citrix recommends that you use the Current Release Version 7.9 or later of the VDA for Desktop OS and of Provisioning Services.

A separate article entitled Windows 10 Compatibility with Citrix XenDesktop makes this clearer,

  • VDA: Although Semi-Annual Channel Targeted releases are intended for pilot trials, Citrix will provide limited support (configuration only) for VDA installations on Windows 10 Semi-Annual Channel Targeted releases, starting from version 1709 forward.

..and goes on further to say that ‘targeted’ releases such as Windows 10 Fall Creator’s Update are not guaranteed to be compatible:

While the Desktop OS VDA is expected to install and work on Windows 10 Semi-Annual Channel Targeted versions, Citrix does not guarantee proper functionality with these builds.

So there – it’s now clear. The LTSR releases, even the most recent, were never intended to deliver the latest compatibility with Microsoft’s own servicing schedule. It just happens in this case that VDA 7.15 is the most recent VDA available currently and for some reason Citrix also chose to adopt this as the version included in the latest LTSR release.

If you’re intending to use LTSR versions and maintain full compatibility with Windows 10 it seems that the only sensible way forward is to fall back on the most recent Semi-Annual Channel release (build 1703) and wait for the next LTSR cumulative release that adds support for the previously circulated Win10 ‘targeted’ version after all of the wrinkles have been ironed out. This is very well explained at the end of the linked article above, which simply states that you can’t be sure of support for specific Windows 10 versions unless you match them with the approved VDA for that Semi-annual channel release. Anything newer just might not work.

  • Windows 10 Creator’s Update (Version 1703) – use VDA 7.9/7.15 for LTSR support
  • Windows 10 Fall Creator’s Update (Version 1709) – Not supported!

So what’s the moral of the story, after all? Citrix and Microsoft have taken the stance to deliver frequent releases for those who are happy to trail-blaze and hotfix, depending upon their current release and semi-annual targeted releases respectively. But if you want to rely upon well-tested and proven operating system and VDA platforms – which are likely to survive the test of time (without high levels of maintenance and unpredictable results) then stick to the aligned Citrix LTSR and Windows Semi-Annual channel versions and plan your releases several months in advance. Anything else, and you could be left scratching your head for a short while until the penny drops!

Update: Since writing this post I’ve become aware of a clear summary of the current situation documented within Carl Stalhood’s excellent VDA 7.15 installation notes under point #7. Citrix have stated that they plan to provide retrospective support for VDA 7.15 on Windows 10 Version 1709 under two scenarios:

  • A new patch (now released) on Nov 14th 2017 (KB4051314) will provide the ability to update an existing Windows installation and existing VDA to Windows 10 version 1709
  • A new patch to be released via the Microsoft Update Catalogue in November Week 4 will allow you to do a fresh new VDA install on a clean Windows 10 version 1709.

NB This is a first draft of this post with minor edits. If you believe that anything included here is erroneous or misleading please get in contact/drop me a line so that I can clean it up. Thanks for reading!

Useful references:

Windows 10 Compatibility with Citrix XenDesktop

Windows 10 Fall Creators Update (v1709) – Citrix Known Issues

Windows 10 Creators Update (v1703) – Citrix Known Issues

XenApp and XenDesktop 7.15 LTSR

Adding Windows 10 Compatibility to XenApp and XenDesktop 7.6 LTSR

FAQ: XenApp, XenDesktop, and XenServer Servicing Options (LTSR)

Windows 10 update history

Windows as a service: Simplified and Aligned

How to get the Windows 10 Fall Creators Update



XenApp 7.x open published apps session report PowerShell script

Whilst there’s many amazing things being introduced by Citrix recently (in the XenApp/XenDesktop space) I do sometimes feel that Citrix Studio can be somewhat limited in comparison to previous admin tools.

I would say one of the common things that administrators and consultants need to know on a daily basis is how many instances of each published app are being run within a Citrix environment. I was a little perplexed at first why this wasn’t easily available through Citrix Director without making connections directly to the database through an OData connection, but I guess in the end they decided that it simply wasn’t relevant . So I’ve been working on a PowerShell script to give me a very simple view of how an environment’s application usage stacks up, and from there on in I can decide whether everything’s running fine or dig a little deeper.


PowerShell App Instances

The first drafts of the script originally required me to manually specify the delivery group(s) against which it would be run, but in this example I’m using a multi-select list box to allow me to choose more than one (just hold down the CTRL key). However,  since each execution of the script only gives me a point-in-time view this example script will refresh every 60 seconds until the maximum interval of one day has passed.

The sort order is currently defined based upon the total number of application instances running, ordered by largest to least, so bear this in mind when selecting multiple delivery groups as the resulting view may not be what you’re looking for.

if ((Get-PSSnapin -Name “Citrix.Broker.Admin.V2” -ErrorAction SilentlyContinue) -eq $Null){Add-PSSnapin Citrix.Broker.Admin.V2}

$selectmachines = @()

$count = 1440 # Script will run until 1 day has passed, updating every 60 seconds

$selectdg = Get-BrokerDesktopGroup | Select-Object -Property Name, UID | Sort-Object -Property UID | Out-GridView -OutputMode Multiple -Title ‘Select one or more delivery groups to display active sessions’

foreach ($i in $selectdg) {

$selectmachines+=Get-BrokerMachine -DesktopGroupUid $i.Uid | Select-Object MachineName -ExpandProperty MachineName


Do {

clear #Reset the screen contents before redisplaying the connection count

Get-BrokerApplicationInstance -Filter ‘MachineName -in $selectmachines’| group-Object -Property ApplicationName | sort-object -property Count -Descending | Format-Table -AutoSize -Property Count,Name


Start-sleep -Seconds 60

} while ($count -ne 0)

Listing Citrix session count by application using PowerShell

You may have found that Citrix Director offers fairly limited set of information regarding the number of users which are connected to each XenApp host, and there was no simple way (until I think XA7.9 update) to view the published app session count for each application.

Here’s a useful PowerShell snippet which should help you out if you didn’t upgrade yet. It’s a concatenation of several commands which basically list off all of the sessions and then group and sort them into a convenient list.

You’ll need to open PowerShell on a Citrix delivery controller and then type:

Add-PSsnapin Citrix*

Following which, you should enter the following command:

Get-BrokerApplicationInstance | group-Object -Property ApplicationName | sort-object -property Count -Descending | Format-Table -AutoSize -Property Count,Name

The output generated should be as follows:


You can of course tailor the verb Get-BrokerApplicationInstance to select a smaller subset of sessions on which to group and sort using:

Get-BrokerApplicationInstance -MachineName DOM\HOXENAPP01

Which will simply tell you the distribution of published application sessions for an individual XenApp host. Hope this helps!


Locating Personal vDisk with PowerShell script

Dell vRanger is a backup solution for VMware which I’ve been using for a while to backup a customer’s ESXi environment. It’s generally OK, however the vRanger backup configuration wizard does not allow you to specifically exclude Citrix MCS base image disks which cannot themselves be backed up (.delta disk file types) – instead opting to force you to define the disks to exclude based upon Hard disk 1, Hard disk 2 names which apply to the whole job identically for each VM. In this example I DO want to backup the pvDisk but DO NOT want to backup the other two disks which are deemed unnecessary.

The issue which I’ve got with this approach is that sometimes (and I don’t quite understand why!) the virtual desktops added to the catalog sometimes use Hard disk 3 for the user’s pvDisk and others use Hard disk 2. Perhaps this is just a timing issue with vCenter but nevertheless I needed to figure out a simple way of easily searching a group of VMs and selecting those which use Hard disk 2, and 3 and create separate backup jobs which exclude the non-backup targets i.e. the delta disk (non-persistent independent) and identity disk (persistent independent).

See below the script which I ended up with after a bit of tinkering. It makes an assumption that the identity disk is less than 1GB in size and that your pvDisk is greater than 1GB (otherwise you may not see anything returned):

#Connect-VIServer -Server vcentersrv1.domain.internal

$VMfilter = ‘Win7-XD-C*’

$XenDesktopVMs = Get-VM -Name $VMfilter

Write-Host ‘Listing pvDisks names for selected VMs:’

foreach ($vm in $XenDesktopVMs) {

$hdd=Get-HardDisk -VM $vm | Where {$_.Persistence -eq “Persistent”}

foreach ($diskin$hdd | where-object {$_.CapacityGB -ge 1}) {

Write-Host $vm.Name $Disk.Name ‘=’ $disk.CapacityGB }


Updating password field names with multiple NetScaler Gateway virtual servers

Imagine a situation where you want to change your NetScaler Gateway’s logon page to include alternative prompts for the Username, Password 1 and Password 2 fields and need to update the language specific .XML files. This has been documented before, and isn’t too hard to figure out once you’ve found a couple of ‘How to’ guides on the Internet. However I have since come across a limitation in trying to apply the NetScaler’s new ‘Custom’ design template to several different NetScaler Gateway virtual servers at the same time, because essentially whilst you can define your own custom design it is automatically applied to all instances of the virtual server residing on the NetScaler – so if you define custom fields then you’ve defined them for all. This may not be a problem for some people, but what if the secondary authentication mechanism is an RSA token for one site, and a VASCO token for another? How do you go about configuring alternative sets of custom logon fields?

Most of the answers are already out there in one form or another, but I lacked one simple beginning to end description of the solution (I tried several alternate options including rewrite policies which didn’t quite work before I opted for this approach):

Background (NetScaler 10.5.x build)

The Citrix NetScaler VPN default logon page has already been modified in order to ask for ‘AD password’ and ‘VASCO token’ values instead of Password 1: and Password 2:, as detailed in

This was achieved by editing index.html and login.js files in /var/netscaler/gui/vpn of the NS as per the Citrix article above. In addition, the resources path which holds the language based .XML files in /var/netscaler/gui/vpn/resources has been backed up into /var/customisations so that the /nsconfig/rc.netscaler file can copy them back into the correct location if they get overwritten or lost following reboot.

Contents of rc.netscaler file

cp /var/customisations/login.js.mod /netscaler/ns_gui/vpn/login.js
cp /var/customisations/en.xml.mod /netscaler/ns_gui/vpn/resources/en.xml
cp /var/customisations/de.xml.mod /netscaler/ns_gui/vpn/resources/de.xml
cp /var/customisations/es.xml.mod /netscaler/ns_gui/vpn/resources/es.xml
cp /var/customisations/fr.xml.mod /netscaler/ns_gui/vpn/resources/fr.xml

However, because these values apply globally there is an issue if a second NetScaler virtual server does not use a VASCO token as a secondary authentication mechanism. This causes the normal ‘Password’ entry box to be displayed as ‘VASCO token’. The only suitable workaround for this is to create a parallel set of logon files for each additional NS gateway virtual server and use a responder policy on the NS to redirect incoming requests for the index.html page of the VPN to a different file. In the following examples, I have created a second configuration for a ‘Training NetScaler’, abbreviated to TrainingNS throughout.

In summary,

Create separate login.js and index.html files for the alternate parameters, create a new /resources folder specifically for those and edit references within those before defining a responder action & policy in NS:

1. Copy existing login.js to loginTrainingNS.js
2. Copy existing index.html to indexTrainingNS.html
3. Create a new folder called /netscaler/ns_gui/vpn/resourcesTrainingNS and give it the same owner/group permissions as the /netscaler/ns_gui/vpn/resources folder (use WinSCP to define the permissions, right click Properties on the file)
4. Copy all of the .XML files from /netscaler/ns_gui/vpn/resources into the new folder
5. Edit the indexTraining.html file and make the following change to reflect the new location of the resource files

var Resources = new ResourceManager("resourcesTrainingNS/{lang}", "logon");

6. Edit the indexTrainingNS.html file and make the modifications described in CTX126206

7. Edit the individual .XML files in the new folder as per the explanation in CTX126206

AD Password:
TwoFactorAuth Password:

(this second option will not be used if only a primary authentication mechanism is defined)

8. When all of the file changes are complete, using as a guide, define the responder action and policy on the NS:

Create a responder action using the URL: “”
Create a responder policy using the expression: HTTP.REQ.HOSTNAME.EQ(“”) && HTTP.REQ.URL.CONTAINS(“index.html”)
Bind the policy to the global defaults

8. Now when you launch the URL for the Training NetScaler it will redirect to the custom index.html file and load a separate logon.js and .xml resource files so that the logon box will be name differently.

In addition, the following article hints at an alternative resolution if the Responder feature cannot be licensed:

Citrix XenApp 6.5 server does not allow published app launch

I’ve come across this issue a couple of times now and am not quite sure of the reason why this setting gets changed. A system typically is working fine, but suddenly stops allowing published apps to be launched. The error message indicates that the user cannot access the path to the executable and that you should check file permissions, however this normally can be disproved by simply opening a published desktop and launching the app manually.

The following article explains the resolution and links back to the original Citrix problem description:

Unable to create new IMA database on Oracle DB with Citrix XenApp 6.5

Due to an issue I experienced this week it would appear that Citrix XenApp 6.5 does not currently support the creation of a new IMA database on the Oracle DB 11.204 64-bit platform without some further (no doubt unsupported) modifications to your Oracle configuration.

The basic DB requirements are outlined within the XenApp documentation, and suggest that only Oracle 11g R2 32-bit Enterprise Edition is supported, but no further reference is made towards whether this is a Windows or Linux platform (it is assumed here that they mean both).

We know from previous installations that only the 32-bit Oracle 11.2.x client will work correctly with XenApp 6.5 on a 64-bit platform; and the database compatibility chart found here ..seems to indicate also that only 32-bit Oracle DB 11.2.x is permitted.

For efficiency reasons in one particular environment we have deployed and tested successfully several farms hosted upon Linux based Oracle DB 11gR2 64-bit using the 32-bit Windows Oracle client on Windows Server 2008 R2.

Is this supported? It seems not, but database creation and IMA service stability appears on the face of it to be quite acceptable, until we came across the following problem when trying to deploy a new farm on a new Linux based Oracle DB platform:

Initializing the Citrix data store failed.


This occurs during the role creation, new farm wizard; despite being able previously to test and verify login credentials successfully. Other people have run into this issue before, and suggest running the wizard as an administrator, but this did not provide any assistance when using either the base release of XA6.5 or with FR1, or FR3 installed. The log files generated by the wizard do not shed any light on the issue whatsoever.

See thread below for details of the issue when related to other causes:

In order to troubleshoot the issue further I decided to build a new farm on an Oracle DB database, and as per previous experience – no surprise – this was successful. My plan was to export the working DB user onto the platform and see if the IMA service would then start.

I didn’t get much further beyond the export process, because the import failed – generating an error concerning the inability to compile triggers in the DBMS_REPUTIL package. Hands up, at this point I was pretty stumped until I did a bit of lucky web searching and came across the following article:

Basically, it seems that Citrix are trying to create new triggers during the IMA DB creation process and these involve the DBMS_REPUTIL package which is no longer publically executable.

During the creation of a new database user (e.g.  CTX_IMA_DB) you would enter via SQL*Plus as the sys/system user:

create user CTX_IMA_DB identified by password.. (rest of command removed for brevity)

grant connect, resource to CTX_IMA_DB;

But due to the additional restriction relating to DBMS_REPUTIL in

grant execute on DBMS_REPUTIL to CTX_IMA_DB with grant option;

This single additional command is sufficient to then allow the IMA DB database creation wizard to complete successfully.


NB since it would appear from the links provided that Citrix DO NOT support Oracle DB 11.x running on a 64-bit platform; this may be for very good reasons which are presently unknown. For reasons of common sense I should add that this solution is not recommended for production use whatsoever, and therefore you must take responsibility to thoroughly test and verify this solution within your own environment.

Hope this helps! If so, drop me a comment to let me know.

Personal vDisk was unable to find a storage disk for user personalization settings

A colleague of mine called today with an issue affecting his Citrix XenDesktop 7.1 hosted Windows 7 virtual machine, which following some unrelated system maintenance would no longer register with the Citrix desktop broker / delivery controller.

I took a look at the VM via the console and saw the on-screen popup message “Personal vDisk was unable to find a storage disk for user personalization settings” and noticed that the Personal vDisk was present, but was showing up incorrectly as the F: drive (rather than the P: drive letter as defined in the machine catalog).

I wondered if the SCSI ID order had changed for any reason, perhaps giving the desktop identity ID disk a drive letter, but this wasn’t the case. I removed and re-added all of the disks correctly, and yet this still did not correct the problem.

The issue at this point appeared unresolvable, and I performed a couple of restores of the personal vDisk using the vRanger backup solution which was running in-house, but again – once reattaching all of the disks correctly (vRanger strips them out if a full restore of a VM is done with some disks excluded due to their non-persistent nature) it still would not start up correctly and register with the DDC.

However, my colleague was pretty adamant that he did not want to lose his desktop customisations so I started looking at the individual files which were located in the pvDisk. After turning on ‘view operating system files and folders’ in Explorer and comparing with my own working desktop I noticed that the .GUID and .VDESK files were missing from his P: drive, and went back through the vRanger backups until I could locate the point when these got removed.

Quite simply, after restoring these files (I’m not sure which was causing the issue, maybe both) I rebooted the desktop VM and it registered successfully with the desktop broker.

The volume GUID file must relate to an entry stored within the registry, or indeed the XenDesktop database, and if the correct disk cannot be found then pvDisk will not start correctly and the VM will not register. This seems like a sensible precaution, because if the wrong pvDisk is attached to the machine then it would invalidate the changes if the base image were different.

See screenshot below of the typical files that are present in a normal user’s pvDisk:

Personal vDisk error 1

Just for interest sakes, the VHD file and thick provision component (last two files shown above), in combination, make up the cabinet into which any user-installed applications are placed. As disk space is consumed (by growth in the thin provisioned disk) the thick provisioned reservation can be released in order to guarantee/reserve 50% of the overall pvDisk capacity. The other remaining 50% is normally free for user redirections, e.g. files placed upon the desktop, documents etc.

This isn’t meant to be an exhaustive explanation of how a personal vDisk works, but if it helps explain why a user suddenly seems to lose access, then it could be because the GUID file has been removed.

I also noticed when inspecting the file level restore checkpoints on different days that the user had also tried to install Microsoft Skydrive (now known as OneDrive) onto his pvDisk, so this may have interfered with some of the files, or caused him to remove the .VDESK & .GUID files accidentally when it was later removed.

Citrix Storefront Services and Access Gateway VPX integration

I’ve been promising myself that I’d write up a short lessons learned post on an installation of Citrix’s new Storefront Services which I recently completed for a customer. Unfortunately for those embarking on a similar mission it’s worth mentioning that the documentation for this product is limited at this point in time to Citrix’s eDocs site located here:

Citrix Storefront 1.0 replaces Citrix Delivery Services 1.0, and is a slick means of allowing users to subscribe to published applications/desktops via either a Citrix Receiver plugin or web interface. The web interface is called ‘Receiver for Web’ and offers exactly the same look and feel as when double clicking on the Receiver desktop icon.

In contrast to Citrix Web Interface 5.4 (with its blue and white styling) Citrix Storefront 1.0 offers a pretty green ‘Receiver’ workspace with initially no applications. Users are prompted to add applications from a pull-out list determined by an XML broker exchange with one or more Citrix farms. This approach allows users to add from a larger catalogue only those applications that they want to have available within their primary list of applications. Once added, these application subscriptions are stored within a simple SQL database so that each time that the user logs in his/her favourite applications are available for use. Additional applications can be added to their workspace at any point in the future by revisiting the pull-out menu.

Figure 1 – subscribed list of applications (with two auto-subscribed apps on the right hand side)

What Storefront offers is a hybrid between what was known as PNAgent or XenApp Services and the Web Interface, with the exception that applications cannot be launched directly from the pull-out menu. They must be either subscribed manually, or auto-subscribed by an administrator (with a simple KEYWORD:Auto tag being appended to the published application’s description in XenApp). Once this process is done, an end user is empowered by new application icons being written to their Start Menu and the Add/Remove Programs entry of Windows. It should and does feel like the user can just browse and add applications as if they’re shopping in a store.

One of the things that I really like is that by default the user is prompted to authenticate every time they visit either the online or desktop integrated store, or when they launch an app. This offers some degree of security in a shared desktop or kiosk environment, but can easily be overridden by saving the password entered as an access token. This token is exchanged with the Storefront so that even if the user logs out and back in again (maybe as a different user) their store based apps remain authenticated so that they can be launched by double-clicking an icon in their Start Menu. Once you have ‘purchased’ the apps from the store, they should remain functional until the token lifetime expires – which is around 6 months by default if I recall correctly.

Lessons learned during the installation:

  1. Storefront will not be able to use an SSL certificate if you haven’t configured a certificate in IIS before beginning the install. Using Storefront without SSL causes problems as the Receiver client won’t connect to the store using HTTP unless you make an additional registry key setting. Uninstall, add a cert and reinstall if this is the case
  2. When installing Storefront you are prompted to choose the location where subscription information will be saved. However in my case the option to detect an existing SQL Express 2008 R2 installation did not work – however choosing SQL Server and pointing to an instance called .\SQLExpress worked fine
  3. If you’re integrating Merchandising Server 2.1 with Storefront you should make sure that the Store name mentioned on the Configuration tab of the delivery rule matches the actual Store name you configured in Storefront, otherwise it won’t connect.
  4. When adding Access Gateway appliances into the list of trusted appliances to enable silent authentication you must make sure that you use the same hostname as is configured on the AG itself. If you have only entered a hostname on the gateway but configure a FQDN for the trusted appliance entry it won’t connect

Hopefully that’s just a little taster of what Storefront has to offer, there’s plenty more to learn and discover – but for the meantime I guess that the couple of pointers above may help someone out of trouble!