Latest Entries »


I had a user who reported he would connect to his system at work and the session would go “wonky” with rendering issues.

Going through basic troubleshooting steps did not produce any interesting messages or errors.

Reviewing the Net, I did find a couple Xenapp articles mentioning the same issue and reported there was a fix (KB4039884) to address the rendering problem.  However, I read it was quickly pulled.

Researching a little more; I found that it had been re-released as part of a roll-up.  I went through a couple “replaced by” and found the November roll-up was the latest (at the time I had the issue).  I installed it on my master image (using PVS) and all was good!

Advertisements

I have a new farm with a new VIP.

All the proper firewall rules were in place but access from the Net would only give:

Http/1.1 Internal Server Error 43531

I went through and did all the proper DNS checks, etc., and did not find anything wrong.

The Netscaler had green lights on the basic setup and internally, Storefront was accessible. I reviewed load balancing services and found my two storefronts had yellow lights!

It turns out the security people only updated the firewall rules for one of the firewalls.  A simple update and all was good!

What was strange was the fact we kept hitting the firewall without the rules!  If only I was that lucky with the lottery.

 

 

XenServer CPU information.


A resource pool was transferred and missing where specifics to the cpus.

The command needed for this : lscpu

Architecture: x86_64
CPU op-mode(s): 32-bit, 64-bit
Byte Order: Little Endian
CPU(s): 16
On-line CPU(s) list: 0-15
Thread(s) per core: 2
Core(s) per socket: 8
Socket(s): 1
Vendor ID: GenuineIntel
CPU family: 6
Model: 63
Model name: Intel(R) Xeon(R) CPU E5-2660 v3 @ 2.60GHz
Stepping: 2
CPU MHz: 2600.082
BogoMIPS: 5200.16
Hypervisor vendor: Xen
Virtualization type: none
L1d cache: 32K
L1i cache: 32K
L2 cache: 256K
L3 cache: 25600K


I had a user report when he uses the Citrix Receiver to access our XenDesktop environment all sessions would reconnect and open windows. He liked XenDesktop but was annoyed by getting all his sessions opened. I explained that it was by design and that the receiver was “helping” him by giving him those sessions as he would need them anyway. He would have none of that. He wanted the control to start as he saw the need.

There is a way to disable this feature. I don’t know if the ability was always present but a newer version of the receiver might be needed. You will know if you follow these steps and the options aren’t there.

What to do:

  1. The receiver should already be installed.
  2. Look on the toolbar to the bottom right for the “^” and click it (this is for Windows 7 and up).
  3. Look for the Citrix Icon which looks like a “C” and right-click it.
  4. Select Advanced Preferences.
  5. Click the Settings Option link.
  6. Click the Reconnect Options tab.
  7. De-select Enable for Workspace Control Support.
  8. Click OK

This will restart the Receiver and should disable the starting of all disabled sessions when a user connects via the receiver. I did have an instance where it required a reboot but that should not be needed.

 


Our new Xendesktop setup solved a few problems and of course introduced new ones.

A user asked the question of how to get gnome to load .Xdefaults automatically as it was not working.

Old software tends to evolve.  Such was the case with Genome.  It now favors .Xresources now.  A quick link and the problem was solved.

ln -s .Xdefaults .Xresources

Citrix VDA version check


I had a question as to the VDA version installed on a Linux virtual machine. I didn’t find anything obvious through the basic ctx commands.

Why not the check the VDA module?

rpm -q XenDesktopVDA

Which in turn showed:

XenDesktopVDA-7.13.0.382-1.el6_7.x86_64

Now let’s see why director is giving me the wrong version information…..

 

 


Minor issue and one of those “DOH!” moments.

Installing a new XenDesktop Delivery Controller. I get as far as creating the connection and my connection address is rewarded with:

The Name Resolver service could not resolve the supplied name.

I checked DNS and sure enough it was there!

The “DOH!” moment?

This is a semi-isolated setup which has it’s own DNS.  The company DNS had the record.

This setup did not.

Oh well!


A brand new XenServer pool in an external office had an interesting problem. Two hosts were added to the pool and yet they could not access two mounts on a NetApp filer.

A repair of the SR would give an error message:

There was an error while attempting to mount the NFS share.

Three other XenServer hosts had no issues.

Checked all the obvious and yet they would not repair. I considered a reload but how would that solve it?

Tried using the mount command to mount one of the shares to a directory and received an error that the server rejected the request.

I mentioned this to the administrator who owned the filer and it turns out he likes to use host lists to control access.

He added the hosts to the list and I was able to repair the SRs.

 


I was creating a new Xenserver test pool.  A simple thrasher setup that would have two hosts.  I created the pool and when I tried to add the second server; I received an error message:

This server has a different Active Directory configuration to the master

Odd message what has AD have to do with anything? Then….I remembered this was a temporary setup and was added to AD at one point.

I removed it by clicking the “Leave Domain” button found under the Users tab.

It didn’t need a reboot and was added to the new pool.

Some errors were encountered…..


My xencenter events start displaying blank errors which when expanded showed:

Some errors were encountered. See the XenCenter log for more information.

I searched for the log file as it was not in an obvious place.

It’s easy to forget xencenter is a client application. After hunting around I found it was stored at:

C:\Users\<USER>\AppData\Roaming\Citrix\XenCenter\logs\XenCenter.log

Note: If you don’t see “AppData” enable show hidden files and it will appear.

Noticing the time of the error; I searched the log file and found the following error messages:

2016-09-29 13:24:11,019 ERROR XenAdmin.Actions.AsyncAction [252] –    at System.Net.HttpWebRequest.GetResponse()

at XenAdmin.Actions.GetHealthCheckAnalysisResultAction.GetAnalysisResult(String diagnosticToken, String uploadUuid)

at XenAdmin.Actions.GetHealthCheckAnalysisResultAction.Run()

at XenAdmin.Actions.AsyncAction.RunWorkerThread(Object o)

at XenAdmin.Actions.AsyncAction.RunWorkerThread(Object o)

It can be a confusing message but I remembered the new health check analysis ability with Xenserver 7.0. It turns out a couple of pools were trying to use the logged in account rather then the actual Citrix site account.

I changed the configuration to the correct account and these errors went away.