Month: July 2017

Environment

My environment is a Xenapp 7.13 test lab using a 2016 image delivered via PVS.

I am using UPM best practices and folder redirection. It is fully patched as of time of writing.(16/07/2017)

Citrix OPTIMISER

The optimised image used the new Citrix Optimiser provided here:

https://support.citrix.com/article/CTX224676

When you run the Optimiser executable you are presented with a choice of predefined templates.
I chose the 2016 template.
 

As you can see it already has predefined best practice settings such as services to disable.

 
It also easily allows you to disable scheduled tasks with ease.
 There is also an analyse option which will let you know if settings for best practice are applied or not.


When you choose Execute mode the settings are applied.


A lot easier than manually carrying out individual optimisation!

Initiating LOGIN PI Workload

The login PI process once configured will start to initiate a launched desktop session.

The launcher will verify connectivity.


You will see a desktop session launch.


Within the session a workload will initialise.




In my example, I chose native apps to launch such as Paint, Calculator, Notepad and Wordpad.





The apps will close.
We will then see the session log off.

Results of non-optimised and Optimised Image

I ran the Workload for a good few hours in each scenario.

The LOGIN PI dashboard provided the following Insights:

NON OPTIMISED 

I could see the applications were all within their action response times the last 15 minutes. Login times were as follows.

OPTIMISED

Non- optimised

OPTIMISED

Director Console Results

NON OPTIMISED

OPTIMISED

NON OPTIMISED

OPTIMISED

Conclusion

The results are not what I was expecting. There was not much difference between my 2016 optimised image from my standard. I would therefore suggest moving to a 2016 O/S if you have not already done so as this is a very good base O/S for your workloads.

There were 137 login sessions in a 2 hours window as shown by the optimised screen shots compared to around 70 on the non optimised image in an hour. Almost the same.

The optimised image was slightly better but there was not much in it.

These results are based on a single user workload. I would like to run through the tests using multiple workloads and I will post results later.

I would also like to try my own set of customisation's to see if I can improve on the results found here.

What I hope to highlight is the usefulness and insights provided by Director and Login PI in order to assess login issues. 
Moving forward we are entering a world of automation and having the capability to simulate Xenapp workflows is very much welcome.

I have more work to be done so expect future posts on optimisation.

Login PI Dashboard

Let me take you through the Dashboard for Login PI.

Once you have configured your information in the initial setup as described in part 2 of my blog posts here http://wp.me/p8leEE-9M
and you have run your workloads we get a nice graphical console showing us useful insights.

You can see your login success rate, performance and Application performance.

We can see the response times of our configured workloads.

Scrolling down the console we can see the following collected statistics.

- Avg latency for the last 24 hours

- Alerts for the last 24 hours

- Avg login for last 8 hours

- Alerts for the last hour

The time for each can be adjusted to 1hr, 2hr, 8hr, 24hr,1 week.

If we highlight some data in the GUI we will be presented with further information.

The picture below shows the details in the Avg latency section.

This highlights memory was at 86%.

The next example breaks down the login times over a 24 hr time period. Remember the time period is adjustable.

In the initial setup you set threshold values. Any time these threshold values are exceeded you can configure e mail notifications to go out to your IT.



Explanation on threshold values:

For certain applications, you might want to know how long it takes to respond or perform a workload action. This section lets you customise thresholds for each action, so you receive an alert regarding any overrun. The thresholds for non-customised values will be calculated as “Median * (100_Auto Threshold)%”.

To set the default threshold value that applies to all workload actions, simply adjust the Auto Thresholds slider

To set a specific threshold for each workload action, enter the appropriate value (in seconds) in the relevant Threshold value field and turn on the Actions switch at the end of each row.

The email configuration settings are shown below.The settings are self explanatory.

We can see all alerts exceeding thresholds highlighted in the console.

So, now we have familiarity with the Login PI Dashboard feature which provides very useful stats and alerts to provide proactive support.

The next section of posts will provide results of a 2016 non optimised image and then optimised using the Citrix Optimiser tool.

We will take a look at the comparison of the 2016 images via the dashboard insights of Login PI and Citrix Director.

Lets get optimising!

Issue

I had an interesting case where no office applications would open on network shares and if you went to Save As within the office applications the apps would crash (Excel/Word)

So, the steps to reproduce issue were:

Launch Citrix published Excel





and click Save As 

EXCEL CRASH



Launch published Excel and click open and browse to network share location. Click an Excel document on the network share -

Now this message

First Diagnosis

First, I believed the fix was to go into the Trust Center as shown below and the issue was to do with trusted network share locations. I set some settings manually.










Once I entered out of the Trust Center and ticked the boxes highlighted above, I repeated steps and no longer had an issue.

Then I thought this is a GPO setting. So I set the following in a GPO -



However, what I soon found out was no matter what GPO settings you made, if you disable UPM, Roaming Profiles, unlink the GPO, the problem would continue on a fresh relaunch of Excel or Word as a seamless application.

Then I figured out all I had to do was simply go in to the Trust Center without changing a thing and everything would work. At this point I started to scratch my head.

Thinking about this I decided to use a tool called PROCMON (good to see what is writing to files or registry when an action is performed) to capture any registry write values that applied when I entered the Trust Center.

Interestingly I applied the filters below and the following keys were captured.

Process name is Excel.exe

Operation is RegSetValue



I saw some IE Cache keys being written when I captured the trace and performed the user action of clicking on the Trust Center within published Excel.

That got me thinking.

All these registry keys were IE Cache.

I extracted these keys from registry by going to the Jump To setting.



I exported the keys on to my  desktop on the Xenapp server.



Now when I opened published Excel as my test user and imported the registry keys in to the users HKEY USER hive whilst they were logged on to my Xenapp server, I witnessed no issues with Excel.

I then traced it down to one exported registry key.



No crash on Save As within Excel and I could open office documents on network shares.

Next step I launched Published IE as the test user and deleted the IE cache as shown below.



I launched a new published Excel whilst IE was open and there was no issue. This confirmed my belief it was to do with the IE cache.

Further to this I also checked the following registry key where cache data is stored.

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\User Shell Folders

Reason For The Issue

Looking at UPM and Folder redirection I could see no obvious issues.

Looking deeper to see what was happening with the user when logged in to a session I could see that the user did not have any INetCache in their folder location.

%USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache

Solution

The solution is quite simple.

I added the following GPO preference to be created when users log in.

%USERPROFILE%\AppData\Local\Microsoft\Windows\INetCache







I set some specific Item Level Targeting to the newly created policy so the new GPO would apply only to my test users for verification.



Once I repeated tests I no longer had the issue.

This can be seen by checking the folder location whilst logged in as the user via published cmd prompt.Now you can see the INetCache folder!



Interestingly when I went to show this to my colleague he new the issue as they had come across this before but was not sure of the reason.

I could have saved hours! Always ask your co-workers to save time ;-)

Although that was time I definitely was not getting back I am hoping my troubleshooting analysis will help some of you who may have similar issues.

Happy troubleshooting!