Despite enabling Gallery access on the MDX App settings, for some reason on Android access to the upload from device page was being blocked when “document Exchange (open in)” was set to restricted.

If you lifted this restriction, all worked well. but Nobody wants that.

Anywho, with much pain and wandering around the Google Android Developer documentation, the following exception list allows you to restrict the App successfully while still allowing access to local files for upload.

{action=android.speech.tts.engine.CHECK_TTS_DATA}{action=android.app.action.SET_NEW_PASSWORD}{action=android.app.action.START_ENCRYPTION}{action=android.intent.action.GET_CONTENT}{action=android.intent.action.PICK}{action=android.intent.action.CHOOSER}{action=android.intent.action.OPEN_DOCUMENT}{action=android.intent.action.RINGTONE_PICKER}{action=android.intent.action.DIAL}{action=android.intent.action.MAIN}{action=android.media.action.IMAGE_CAPTURE}{action=android.provider.MediaStore.RECORD_SOUND}{action=android.media.action.VIDEO_CAPTURE}[action=android.intent.category.APP_GALLERY}

C:\inetpub\wwwroot\Citrix\StorageCenter\cifs\AppSettingsRelease.config

Add the following line the config:

<add key="disable-folder-permission-verification" value="1" />

Once added, recycle the StorageCenterAppPool in IIS as below: I have it on strong authority this will be resolved in a future build, but no promises. A big thank you to Dan Brinkmann, George Christophi and Citrix Support for this fix.

After creating an AppDisk, it got a little stuck. I tried deleting the task and AppDisk but the disk just seemed to be stuck in the “creating” phase indefinately.

To remove it, I had to do the following in Powershell from a delivery controller:

ASNP Citrix*
get-applibtask -active $true

Once i had identified the TaskID, i ran:

Stop-AppLibTask -TaskId 5be48afc-263b-454e-b3e9-5a2db6b966ff
remove-AppLibTask -TaskId 5be48afc-263b-454e-b3e9-5a2db6b966ff

Now just one last thing to do!

get-applibappdisk and find the entry in the “creating” state:Now finish with a:

remove-AppLibAppDisk -AppDiskUid d54681d3-6d0a-4259-b3ee-b90a899033bd

using the DiskUid that you saw in the previous get-applibappdisk command.

Thats it!

Update:

if you find that the machine you usually use to capture app disks is no longer available. use the following command to release it:

set-BrokerMachine -IsReserved $false -MachineName <MachineName>

PS: I could have piped a lot of that, sure! but my mac pipe symbol is currently out of action so i did it the hard way. if you are the type who reads others blogs and leaves comments to improve the scripting, I’m sure there are new people on the Microsoft forums you could be bawking at right now.

My issue was simple, as a developer and powershell zealot, I regularly used the pipe Symbol (|) in anger. Well in anger i mean, I was literally angry as despite pressing the frickin pipe key, an imposter appeared in the remote console…

• Looked like a pipe? Yes!
• Acted like a pipe? NO!

So anyway, being a Citrix CTP has it’s benefits, I reached out to the aforementioned blokes and sure enough a few emails were exchanged and poof! issue resolved.

To paraphrase Dustins email:

1. Open ~/Library/Application Support/Citrix Receiver/Config in a text editor
2. Find the KeyboardLayout setting in the [WFClient] section
3. Change KeyboardLayout to: British
4. Save the file
5. Launch the session

Tada! Pipe back to normal. Thanks again Simon and Dustin.

You can read all about the original concept here. My good friend and fellow CTP Barry Schiffer also wrote a really good article about the need for a product like ThreadLocker here.

Some history:

In essence, ThreadLocker was a utility for both shared and 1:1 desktop environments. It allowed you to layer in rules for processes that had a history of high or discruptive CPU usage, to protect the other users (in a shared environment) or to protect other running processes and the users interface (explorer.exe) while a large compute job was occurring.

ThreadLocker exploded with popularity and has received well over 100,000 downloads in the last three years. Alike ThinKiosk, ThreadLocker is a tool I regularly come across in my customers environments while consulting and it always suprised me with it’s uptake and popularity. I have observed ThreadLocker in VDI, SBC and even on stand alone workstations with great levels of success.

Moving on:

One of the frustrations I had with ThreadLocker, was any .NET based language (c#, vb.net, etc.) was never quick enough to be able to add an intelligent aspect to the utility without actually making CPU usage worse by implementing. ThreadLocker 1.0 relied on static rules and any new processes would have to be observed and added.

Recently David Coombes and I undertook the side project of redesigning ThreadLocker to run in c++, adding the raw speed we needed to be able to make intelligent decisions based on CPU usage and react in a fraction of a second to a sudden CPU spike. ThreadLocker 2.0 was designed to specifically tackle two issues:

• Processes comsuming a large % of CPU and is multithreaded.
• Many buggy or heavy processes, each consuming a core each.

We didnt want to tackle this with the approach of many others, where they’ll pause and resume threads many times a second creating a “SawTooth” effect on the processes CPU usage. We wanted the processes to run as fast as they need up to a certain threshold and only be restricted when contention is likely.

Having experienced other vendors approaches where process priority is dropped, many times this simply does not cut it as a heavy process, even at idle priority, will cause the other users and processes to feel slow and sluggish.

Why is ThreadLocker different?

With ThreadLocker 2.0, you can elect a percentage of your CPU cores that ThreadLocker can use for isolating these processes. When a process violates the ThreadLocking criteria, they are locked into these subset of cores to contend with any other processes that are also ThreadLocked, leaving well behaved processes to be able to take advantage of all cores in system. Once they start to behave again and do so for a certain amount of time, the processes are dropped back into the “wild” unless they decide to misbehave again.

This approach is extremely fast (ThreadLocker consumes less CPU than Microsoft’s own Task Manager) from a processing point of view and also has the benefit of allowing users to multitask with other applications while, for example, Excel hammers the ThreadLocking cores during a calculation.

The end result has been fantastic. Threadlocker can be installed and up and running in seconds. There is no longer a requirement for static rules and out of box, all aspects of the logic can be tuned to suit your environment, but more than likely wont be needed.

 Demo Video:

Availability

We are proud to announce the general availability of ThreadLocker 2.0 and more information can be found on our website at http://www.thinscaletechnology.com/threadlocker.

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!

About the tool:

The Citrix Director Notification service sits on an edge server as a service (or local to the delivery controller) and periodically checks the health of:

• Citrix Licensing.
• Database Connections.
• Broker Service.
• Core Services.
• Hypervisor Connections.

And if any of these items fall out of bounds, an SMTP alert is sent to the mailbox of your choice for action. The tool will also send “All Clear” emails when these items are resolved, ensuring you are aware when the service has resumed a healthy state, neat huh?

An example of one of these alarm emails can be seen below:

Hypervisor Alerts, too!

Did you know that the Citrix XenDesktop and XenApp 7.x suite also keep track of Hypervisor alarms? It was news to me! Any-who, if you are lucky enough to be running XenServer or vSphere. The director Notification service can be configured to also catch these alarms, allowing you to also be alerted.

An example of a Hypervisor alarm is below:

Installation guide:

Below you’ll find the steps to get the director notification service installed:

 Download:

Director Notification Service 1.0.5

Setup:

• Download the Tool from the above URL.
• Install the service on a server running Windows Server 2008 R2 or above with .Net Framework 4.

Provisioning the Account:

The service account maintains a WinRM remote session to your delivery controllers and performs checks on a frequency you determine. Setting up this account is the meat of the install.

• Create an Active Directory Service account for monitoring director (this is needed later).
• Copy the XDServiceAccountProvision.ps1 file from the installation directory and run this script on all delivery controllers to automatically create the correct permissions for your service account.
• If you’re curious, read the script. A copy is below if you feel like doing it manually.

Using the configuration tool:

You’ll find the configuration utility on the start menu, under Direct Notify Configuration (this tool requires admin permissions).

Once open, configure the tool to suit your environment:

Ensure to use the test buttons.

Once happy all is working. Start or restart the “Director Notification Service”.

Advanced Logging:

A debugging option exists in the configuration tool, this will log to a trace.log in the installation directory of the machine. If you have issues, first enable this and review the log.

Provisioning Script contents:

write-warning "Before proceeding, Ensure you have: "
write-warning "1: Created a service account for monitoring XenDesktop."
write-warning "2: Ensure you have local administrative access to the local machine."
write-warning "3: Ensure this powershell instance is elevated."
write-warning "4: Ensure you have Administrative access to the XenDesktop site."
read-host "Press Any Key To Continue"

asnp citrix* -ea 0

$domain=Read-Host -Prompt "enter domain name the monitoring user is a member of: e.g. lab"
$username=Read-Host -Prompt "enter monitoring user name: e.g. john.doe"
$group="Remote Management Users"

if(!(Get-AdminRole "Direct Notify Role")){
#create new administrative role
new-adminrole -Name "Direct Notify Role" -Description "used for Direct Notify Service"
Add-AdminPermission -Role "Direct Notify Role" -Permission Configuration_Read
Add-AdminPermission -Role "Direct Notify Role" -Permission Configuration_Write # needed for some unknown reason, thanks citrix ¯\_(ツ)_/¯
Add-AdminPermission -Role "Direct Notify Role" -Permission EnvTest
Add-AdminPermission -Role "Direct Notify Role" -Permission Global_Read
Add-AdminPermission -Role "Direct Notify Role" -Permission Hosts_Read
Add-AdminPermission -Role "Direct Notify Role" -Permission Licensing_Read

#create administrator
New-AdminAdministrator -Name $domain\$username
add-adminright -Administrator $domain\$username -Role "Direct Notify Role" -Scope all
}
#configure remote management if not configured
winrm quickconfig -quiet

#add the monitoring user to the remote management group
([ADSI]"WinNT://$env:computername/$Group,group").psbase.Invoke("Add",([ADSI]"WinNT://$domain/$username").path)

 Fine Print:

Just a few things to be aware of:

Application Dependencies:

• The Notification service requires .Net 4.0
• PowerShell Remoting must be enabled on the Broker Servers
• A service account should be created to monitor the brokers (included in the script).

Tested on:

• Citrix XenDesktop 7.6.
• (Previous versions should work fine too.)

Support:

Drop me an email on andrew@andrewmorgan.ie if you have any trouble!

Enjoy and i hope this is very useful to you.

Future plans:

I’ll be diving into the oData values in the Citrix monitoring database in the next itteration. This work has already begun and will be updated soon.

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.

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}

I had neglected to update this tool for a while, until I actually needed it and the remote screen saver annoyed the hell out of me. necessity is the mother of product maintenance it seems!

Anyway, I digress, check the original blog post here for the downloads and configuration options.

In other news, if you’re familiar with ThreadLocker, watch this space, it’s about to get a serious overhaul!

PS: stop asking me for a mac client, it’s not possible as there is no ICA SDK / API for mac.