Latest Entries »


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.

 

Advertisements

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.

 


There was an odd issue with one of my xenserver pools.  I looked at xencenter and found the following as offline pool SRs:

DVD drives
Local storage
Removable storage

Rather strange and I was too busy to review the log files for errors. I wasn’t sure when those appeared and of course nobody knew anything.

How to get rid of them?

Trying the GUI had no options to remove them.  Time for the command line.

Right-Clicking an entry and selecting properties, I copied the UUID.

I opened a shell and entered:

xe sr-forget uuid=<pasting the UUID>

Repeated two more times and the entries disappeared.

Back to regular work……


One of the odd things about xenserver (there are a few) is the way you configure a search domain for /etc/resolv.conf. You can’t simply edit the file and it’s not part of the install.

You have to use the xe commands to establish a permanent search domain.

From the console on the host:

  • You need UUID of the management NIC; the following command will list it:

xe pif-list host-name-label=<hostname> management=true

  • Add the search domain by entering:

xe pif-param-set uuid=<uuid from above> other-config:domain=<your domain>

Note: you can tab through the UUID by simply entering a couple letters and pressing the tab key.

To enter multiple search domains, simply separate by commas:

xe pif-param-set uuid=<uuid> other-config:domain=<domain>,<domain>

  •  Reboot the host and the search domain line appears in /etc/resolv.conf

 

Acknowledgement time!

Xenserver NIC teaming


Creating a bonded NIC can be a little confusing; especially when considering the options. I found a nice little blog post which discusses the process.