New Free Tool: Citrix Director Notification Service

DirectorNotificationCitrix Director for XenApp and XenDesktop can be a great utility for information about your Application / Desktop virtualisation environment. In Director you can find a wealth of information about the provisioned assets, the Controller, Licensing and Hypervisor status and the current running resources.

One area it’s always lacked is real time alerting. In order to really know what’s going on in your environment you need to be logged into director and watching. This is less than ideal and few monitoring vendors have endeavored to actually pull this data into their own solutions.

With the help of Rachel Berry, Prateek Kansal and Sridhar Mullapudi from Citrix. I set about diving into the logic and monitoring options within the FMA architecture. Citrix did a great job here and most if not all of it was readily available in PowerShell and oData. So, with the help of Citrix and a little bit of hard work, I’m very pleased to announce my latest free tool!

Continue reading

ThinKiosk 4.5 is here!

ThinKioskJust a quick blog post to let you know ThinKiosk 4.5 is here and with it comes a huge list of new features and functionality requested by you.

ThinKiosk 4.5 is a big update, so without further ado, lets get right to it:

ThinKiosk Broker Service:

  • HA features are now available in the ThinKiosk Broker.
  • The Broker service can now utilise Microsoft SQL for the database and an easy migration utility can be utilised to do so.
  • Brokers can now be load balanced via Citrix Netscaler or Microsoft DNS round robin.
  • The ThinKiosk Broker can now deliver software updates directly to clients.
  • The ThinKiosk Broker can now authenticate against active directory.

ThinKiosk Client:

  • The ThinKiosk receiver functionality has been moved to the applications tab in our new ThinScale Connector functionality.
  • The Client can now communicate directly with Microsoft RDS Broker services. Allowing customers using Microsoft RDS or VDI to use ThinKiosk to connect, enumerate and launch resources within ThinKiosk, without RDP files.
  • The Client now supports password changing and legal notices for the ThinScale Connector.
  • The Client now supports “auto launch” logic to specify which desktops to auto launch on logon.
  • The Client now starts up at least 40% quicker than previous versions.
  • The Client’s communication logic has been redesigned to allow management even when nobody is logged in.
  • The Client now supports central software updates from the Broker, allowing push software updates.
  • The Client now has an authentication API for use with Imprivata tap and go cards or similar technology.
  • The Client is now smart enough to detect DNS round robin when connecting to a Broker and will use the list retrieved from DNS as a broker list to try when starting up.
  • The Clients will delete stale or old user profiles periodically to keep machines clean.
  • Many, many improved administrative features allowing ease of access to the system for administrators.

 

We’re extremely proud of this update and we look forward to hearing from you!

 

Accurately checking the Citrix PVS “cache in Ram, Overflow to disk” RAM cache size

Citrix_Provisioning_Services_ImplementationCitrix Provisioning services “Cache in RAM, overflow to disk”, even with it’s challenges is something I’ve always felt was a great idea, hell, I foresaw it’s implementation back in 2012!

Not withstanding the issues that can occur when the cache is heavily in use, it’s a great piece of technology. One of the features you see on twitter repeatedly is trying to report on the exact size of the PVS cache in RAM.

Many blogs and scripts (Matt’s here, as an example) will take the raw performance counter details for Non Paged Pool memory and assume this is the size of the cache. This is faulty logic, but close enough. It’s like looking into a can of beans and trying to determine which one gave you gas.

The Non paged Pool is a collective pool of memory used by the system that guarantee’s the services using it (drivers, etc) that the contents will never reach the disk and will always be maintained in memory. As an example, imagine you created your own disk driver, but the disk driver tried to reference it’s memory and it had since been flushed to the disk…. Chicken and Egg stuff!

Microsoft has a fairly clear description here:

The memory manager creates the following memory pools that the system uses to allocate memory: nonpaged pool and paged pool. Both memory pools are located in the region of the address space that is reserved for the system and mapped into the virtual address space of each process. The nonpaged pool consists of virtual memory addresses that are guaranteed to reside in physical memory as long as the corresponding kernel objects are allocated.

So with this in mind, taking a total of the Non Paged Pool memory and assuming it’s PVS is “OK”… But not accurate. Many other sources can bloat that memory cache, particularly in x64 systems where limits on these pools are now enormous compared to the tiny pools we had to deal with in x86 architectures.

Nerdy digression aside, if you REALLY want accurate information on what’s going on inside of this pool. You need to grab a copy of Poolmon from the Windows Driver Kit (WDK). Download the WDK, install it and you’ll find your poolmon in:

C:\Program Files (x86)\Windows Kits\10\Tools\x64\poolmon.exe

Once you have a copy, fire up poolmon and you’ll see in all their glory.

pvs

Pro tip: Press “p” once to sort my non pooled, then “b” to sort by bytes used.

Each pool tag and the respective space they are using. Interestingly, the Citrix caching technology seems to use the “VhdR” pooltag allocation. There’s also a Microsoft Pool tag for this (http://blogs.technet.com/b/yongrhee/archive/2009/06/24/pool-tag-list.aspx) but the case sensitivity differences between VhdR and VHDr may make all the difference.

I did reach out to Citrix on this one, but they didn’t provide any further insight.

Any-who, if you want to see the size of your PVS cache accurately? Use PoolMon. Here’s a quick script using poolmon to get the GB value back:

$poolmonpath= "d:\poolmon.exe"
$poollog= "$env:temp\poolmon.txt"
if(test-path $poollog){Remove-Item $poollog}
Start-Process-FilePath $poolmonpath -ArgumentList "-n $poollog" -Wait
((Get-Content $poollog | ? {$_ -like "*VhdR*"}) -split "\s+")[6] /1gb
if(test-path $poollog){Remove-Item $poollog}

Adding a list of Authorised files to RES Workspace Manager Building Block

Windows_PowerShell_iconThis is just a quick article on how to search for exe’s recursively in a specific path and add them to an RES Workspace Manager building block to be imported back in.

I needed to do this recently as the customer in question had an application that lived on a network share and after 14+ years of development in this style, everyone was afraid to move it!

Steps to use this script:

  • Export an existing building block for the application you wish to authorize
  • Ensure the exported building block has at least one authorized file
  • Modify the $import and $exportbuildingblockpath
  • Modify the $exedirpath to be the path you wish to search recursively for exe’s.
$importBuildingBlockPath = 'H:\path\bb.xml'
$exportBuildingBlockPath = 'h:\path\export.xml'
 
$alreadyauth=@()
$ExeForAuth=@()
$exedirpath = "\\servername\Share\APPS"
 
 
Get-ChildItem -Recurse $dirpath | ?{!($_.psiscontainer) -and $_.Extension -like ".exe"}  | %{
    $ExeForAuth+=$_.fullname.ToLower()
}
 
 
[xml]$bb = Get-Content $importBuildingBlockPath
 
 
$bb.respowerfuse.buildingblock.application.appguard.authorizedfiles.authfile | %{
    $alreadyauth+=$_.authorizedfile.tolower()
}
 
 
Compare-Object $alreadyauth $ExeForAuth | ? {$_.SideIndicator -eq "=>"} | % {
    $newnode=$bb.respowerfuse.buildingblock.application.appguard.authorizedfiles.authfile[0].Clone()
    $newnode.authorizedfile=$_.inputobject.tostring()                                                                                     
    $newnode.description="Auto Appended item via script"                                                                                        
    $newnode.process="*"                                                                                          
    $newnode.learningmode="no"                                                                                               
    $newnode.enabled="yes"   
    $bb.respowerfuse.buildingblock.application.appguard.authorizedfiles.AppendChild($newnode)
}
 
$bb.save($exportBuildingBlockPath)

Blocking the new Citrix VPN iOS connection to Netscaler gateway:

This is a fast publish article, more detail will follow.

We have discovered a potential security issue or undesired functionality with the new application release from Citrix titled Citrix VPN.

vpn

Description:

In situations where customers have netscaler gateways configured for client access from iOS devices (think integration with citrix receiver app on mobile devices) configured users can now download this application, point the application at your internet facing Netscaler Gateway and Achieve a VPN connection directly to your internal network providing their credentials.
Worryingly, where the Netscaler may be on the internal network, or not be restricted with access lists or firewall rules, the users will achieve internal connectivity via the IP Address of the Netscaler gateway and impersonate the gateway to browse the network.

Am I affected:

If you configured the Netscaler Gateway via the Wizard, used the XenMobile Access Wizard or have a configuration as above, your users will be able to utilise the VPN to achieve internal network connectivity. The best way to find out is to test.
Work around:
<-Disclaimer->
The work around may break current functionality whereby your environment may require the “Windows / MAC OS X” plugin type to function correctly. It is highly advisable that you speak with your Citrix partner / integrator if you are concerned about this issue or wish to make the change.
Work Around 1:
To work around this issue and to block any connections while we engage with Citrix, consider changing the Plugin Type to “Java”. This will block VPN connections.
Work Around 2: 
Bind the following statement, with action of “drop” to a global responder policy:
HTTP.REQ.HEADER(“User-Agent”).CONTAINS(“CitrixReceiver/NSGiOSplugin”)
more info here:
Credits of find:
  • Andrew Morgan – Initial functionality discovery.
  • Bobby Maher – Confirmation of functionality & session type work around.
  • Rick Roetenberg – Confirmation of functionality & responder work around.