Customize the RDS Title “Work Resources” using PowerShell on Windows Server

When using Windows Server to access RemoteApps or desktops through RD WebAccess or the new Remote Desktop app, the workspace is titled “Work Resources” by default. This title can be changed using PowerShell cmdlets.

To change the title, open up a new PowerShell window on the connection broker server and import the RemoteDesktop module with the following command.

    Import-Module RemoteDesktop

Next, use the Set-RDWorkspace command to change the workspace name.

    Set-RDWorkspace [-Name] <string> [-ConnectionBroker <string>]  [<CommonParameters>]

For example, you can use the following command to change the workspace name to “My Business RemoteApps”

    Set-RDWorkspace -Name "Contoso RemoteApps" -ConnectionBroker broker01.contoso.com

If you are running multiple Connection Brokers in High Availability mode, you must run this against the active broker. You can use this command:

    Set-RDWorkspace -Name "Contoso RemoteApps" -ConnectionBroker (Get-RDConnectionBrokerHighAvailability).ActiveManagementServer

For more information about the Set-RDWorkspace cmdlet, see the Set-RDSWorkspace reference.

Setting up SSH public / private key authentication in Linux

This is a very generic and basic configuration to setup SSH key authentication for Linux.  I will not go into great detail nor do I assume that this configuration is the most secure or practical.  I am simply identifying the requirements to configure SSH authentication using public and private key pairs. To start you want to make sure that openSSH is installed on your OS.  For Debian based operating systems, this can be as simple as issuing the following command: sudo apt-get update sudo apt-get install openssh-server openssh-client (where openssh-server installs the server and openssh-client installs the client) or review the website for details on installing it.  http://www.openssh.org/once the server is installed, you will want to configure it to use public key authentication as by default it is disabled.  This can be done by editing 2 files /etc/ssh/sshd_config to modify the server settings and /etc/ssh/ssh_config to modify the client settings.  If you plan to use this installation to both connect to other servers and connect to, you will need to modify both of the files. First, the /etc/ssh/sshd_config file will allow changes to be made to the ssh server.  The following lines will need to be added or uncommented based on the original configuration file provided.  I would highly recommend creating a backup copy of the file before making any changes in case something goes horribly wrong.

PubkeyAuthentication yes
AuthorizedKeysFile     %h/.ssh/authorized_keys

While there are other options that I would also configure at this point, they do not relate to the configuration of public key authentication and so will not be discussed here.  This will “enable” authentication using a public / private key exchange and it will direct the server where to look for keys that it will accept.  The “%h” is the variable for the home location, and then the default filename is authorized_keys but really any name can be used here. Restart the ssh server by issuing the following command:

sudo /etc/init.d/ssh restart

Now, we need to set the client.  Open the /etc/ssh/ssh_config file and add or uncomment the following lines (again, I recommend making a backup of this file as well.  This can be as simple as:

cp ssh_config ssh_confg.orig

Once you have your backup, the only line that needs to be changed is:

IdentityFile ~/.ssh/identity

where this provides the system the location of the file to use to identify yourself to the remote server.  In the next step we will create this file, so for now it can be named anything identity is simply a default.  The “~/” refers to the current users home folder (or your folder in this case). Since the identity file doesn’t exist, we need to create it.  To make things easy, I type “~/” and press return to make sure I am in my home directory.  It really isn’t necessary, but when you want to verify the creation of the .ssh folder and the identity file, it is nice to already be here. Issuing the following command will generate the public and private key pair that we will use to identify ourselves to other servers.

ssh-keygen -t dsa

This will walk through a short process and ask you to name your keys.  The default location is fine, but you may want to name your keys something special.  Just note that whatever you set the name to here will need to be also set in the ssh_config file.  So if you use the name “~/.ssh/mykey” for example, this location and name will need to be provided in the ssh_config file so that the ssh client will know where to find the key you would like to use.

Once the key generation is complete (if you didn’t before and you are using the default location) you will have a .ssh folder in your home directory.  It is a dot file and therefore hidden by default, but typing

ls -a

you will be shown the hidden files and folders in your directory.  if you change directory into that folder you will see [your key name] and [your key name].pub.  The [your key name] is the private key, you will want to guard this with your life.  If someone gains access to this key they will be able to access any location / server that where you have uploaded your public key.  Now, the last step to ssh key authentication is to put the public key in the “authorized_keys” file or the file on the server you want to access that verifies the keys for access.

The best way I have found to do this is to connect to the server via ssh and password one last time to upload the public key using the following command.

cat ~/.ssh/id_rsa.pub | ssh user@machine "mkdir ~/.ssh; cat >> ~/.ssh/authorized_keys"

If the .ssh directory already exists on the server the alternate to just place the key in the file would be

cat ~/.ssh/id_rsa.pub | ssh user@machine "cat >> ~/.ssh/authorized_keys"

where cat reads the file “id_rsa.pub” (or whatever the file name happens to be) and then it “pipes” it to the ssh session, and finally using cat we append the new key to the authorized_keys file.

Once these steps are complete, and no errors were encountered, you should be able to enter ssh user@machine and authenticate via key.  If you provided a pass-phrase for your key, you will be asked to enter it, otherwise you will be logged on and ready to go.  On Windows platforms using pass-phrases can be frustrating as it will ask for the pass-phrase every time a connection is attempted.  This can be helped by using something like Pageant for PuTTY which will “capture” your pass-phrase for your key and use it when logging on.  You will need to supply the pass-phrase 1 time every time you log on to the Windows computer, but it beats having to repeatedly type it when connecting to a server.

Citrix Receiver, PnaAuthDialog_popup window solution

The Citrix receiver has always been a tremendous thorn in my side to install on Linux, and adding that I have been using 64 bit lately, this is only amplified.  The latest issue came with the receiver actually starting, but along with it a blank window entitled “PnaAuthDialog_popup” is displayed.  It is displayed over the top of the receiver window and it can’t be closed, the windows is set to always on top apparently and nothing happens when it is sitting there.  The windows is movable but that doesn’t help too much.  I found a help page in the internet that suggest adding an extra line in /etc/sysctl.conf with:
net.ipv4.tcp_window_scaling=0
…and reboot.
I can’t locate the page anymore to give credit, but this seemed to correct the issue for me.

Disable the Universal Access accessibility menu in Gnome

In Gnome Shell, also known as Gnome 3, there is an accessibility menu called “Universal Access” that cannot be removed, at least not by any method that I had tried.

There are  a couple of ways to disable the universal access accessibility menu in the Gnome 3 interface.  The first is to use an extension by adding the following repository and then installing the corresponding extension.

sudo add-apt-repository ppa:webupd8team/gnome3
sudo apt-get update
sudo apt-get install gnome-shell-extensions-noa11y

In order to use the extension you must have installed “advanced features” for Gnome 3 using the following command or synaptic, searching for gnome-tweak-tool and installing.

sudo apt-get install gnome-tweak-tool

Oddly enough, the package is called gnome-tweak-tool, but once the installation is complete, it will be listed as Advanced Settings in the menus.

The Universal Access accessibility menu can also easily be removed, hidden, or disabled by editing a file and restarting the shell as well.

Edit the file /usr/share/gnome-shell/js/ui/panel.js

Look for the following line:

'a11y': imports.ui.status.accessibility.ATIndicator,

Comment out this line like so:

//'a11y': imports.ui.status.accessibility.ATIndicator,

Then restart gnome-shell by typing Alt-F2 to run command, enter “r” without the quotes, and hit enter. This will quickly restart the shell and you should find that the Universal Access menu no longer appears.

If you should find a use for it in the future, simply undo your changes by either disabling the extension or un-comment the lines found in /usr/share/gnome-shell/js/ui/panel.js

Manage the startup applications in Gnome

Normally I don’t have too much difficulty determining how to set or change what application will start-up automatically on login.  When I started using Gnome 3 however, I was not able to find any way to easily configure them.  I found this finally when I gave up and searched the internet.  This information was obtained from the following location:  http://gnomeshell.wordpress.com/2011/08/28/manage-the-startup-applications/

Thank you to the person that took the time to write up that explanation.

The tool that was used in previous versions is still there, it just seems to be hidden.  You can run it by executing from a terminal or from the ALT+F2 dialog the command:

gnome-session-properties

Startup Applications Preferences dialog
The list will show many of the commands that will be automatically executed after a successful login.

Add a startup command
You can add just about anything you would like to execute at user login by clicking the Add button and entering the required information in the fields. Name is the first line in the preferences dialog, while Comment is the second line and is used as an additional and longer description. The Command field will contain the command to execute automatically at the start up.  Remember if it is not in your path, the full path to the location of the file is required.

The Browse… button will allow to explore the disk content and search for an exact file. If the command requires some arguments they can be added along with the command after the name of the command to be executed.

Change your Mac Hostname via Terminal

Here’s how to change a Mac hostname with the command line and make it permanent:

scutil --set HostName [new hostname]

Simply replace [new hostname] with whatever you want the hostname of your Mac to be changed to.

An example would be let’s say I want to change my Mac laptop’s hostname to MacBookPro, I will use this command:

scutil --set HostName MacBookPro

(Note the “–” before set is two dashes next to each other, –set)

You will be asked for your admin password since you’re using the sudo command. After the command is executed you can verify that the changes took place by typing:
hostname

You can also set a temporary hostname change by using the following command:
sudo hostname [new hostname]
This will reset itself after your Mac reboots though, so if you want a permanent hostname change, use the scutil command instead.

That’s all there is to it. By default Mac OS X will usually assign the hostname as whatever the admin account username is. Changing your Mac’s hostname can make it easier to find your Mac on a network and to connect to.

This was completely taken from the following website; http://osxdaily.com/2010/09/06/change-your-mac-hostname-via-terminal/, but I liked the way it was put and I don’t like reinventing the wheel.

Reset Ubuntu Desktop

If you are careful and avoid using cutting edge repositories, then the following commands may not be really important to you.  However, if like me you always have to try and tweak that one last thing, the day that you fail to have a desktop materialize on your screen, these commands will help you get things reset and hopefully you will be back up and running in no time.  To access a terminal use the Ctrl-Alt-Fn(#) keys shortcut where # is 1-6.  You can log in with your standard account and follow the instructions below.

If you don’t have dconf-tools installed, issue this command (otherwise proceed to the next command):

sudo apt-get install dconf-tools

To reset Unity desktop use the following command:

setsid unity

If Compiz appears to be the problem, Compiz can be reset with the following:

dconf reset -f /org/compiz/

Please understand, these commands will reset everything back to the day you installed.

Disclaimer:  I take no responsibility for any issues that may occur as a result of any of these commands.  These commands have worked successfully for me in the past and should work fine in most cases.

Useful “which” command

I ran across this gem just the other day and I have been working with Linux for years now.  I know I will get a lot of use out of this command.  If you would like to know the full executable path for a program in Linux, if you issue the following command in a terminal window, it returns the full path of the program executable.

which [program name]

So for example, if you are looking for the location of the guake terminal executable, the following screenshot shows the results from a Ubuntu platform.

This is definitely going to come in handy with startup programs.  See the post on Gnome 3 startup applications for information on getting to the startup programs on the Gnome 3 desktop.

Install Citrix Receiver on 64bit Ubuntu

Prepare yourself for this, it will more than likely be time consuming and frustrating…. even with these instructions.  This process and apparently Citrix software is not for the beginner and it is seriously disappointing that Citrix brags about cross platform compatibility, but to them that apparently means Windows and iPad.

First, I can’t guarantee this will work for everyone or for anyone for that matter.  This is only what worked for me.

Start by meeting all the requirements.  There should be a distinction made between the 32bit and 64bit requirements as this is what held me up for a while.  I followed this guide originally and while the general process seems to be correct, the versions are not defined.

https://help.ubuntu.com/community/CitrixICAClientHowTo

The process was started by installing libmotif4 nspluginwrapper and the Citrix Receiver client as the guide above suggested.  Next libmotif-dev was installed and finally the 32bit drivers were installed.  This may have been obvious for most, but when the Citrix download site has a completely seperate section for 64bit versions, it was assumed a 64bit version actually existed:

sudo apt-get install libmotif4 nspluginwrapper

The offical Citrix receiver client was installed from the deb package obtained from the Citrix website but the configuration steps failed (shown below).

 dpkg: error processing icaclient (--install): subprocess installed post-installation script returned error exit status 2 
Errors were encountered while processing: icaclient

A search found the following information which allowed the installation to complete successfully.

Changing line 2648 in icaclient.postinst found in /var/lib/dpkg/info/

$ cd /var/lib/dpkg/info
$ nano icaclient.postinst

The original code:

echo $Arch|grep "i[0-9]86" &gt;/dev/null

What the code should be in order to complete configuration successful on a 64bit platform:

echo $Arch|grep -E "i[0-9]86|x86_64" &gt;/dev/null

And then executing the following completed the installation of the Citrix receiver client successfully.

$ sudo dpkg --configure icaclient

Attempting to open the Citrix Receiver resulted in the following error:

error while loading shared libraries: libXm.so.4

After verifying the libraries were installed, it was the next step to install the development libraries with the following.

sudo apt-get install libmotif-dev

This resulted in the same error when attempting to open the Citrix Receiver again.

The solution, (maybe) or it may have been a mixture of the commands, was to install the 32 bit versions.  Below is what I believe will get the Citrix Receiver working in Ubuntu 13.04 64bit.

sudo apt-get install libmotif4 flashplugin-installer curl nspluginwrapper ia32-libs libmotif4:i386

The other issue that you might face is a certificate issue that prevents connection after the Citrix Receiver has been configured and a connection is attempted.  You may get the following message and it will fail to connect.

Citrix SSL Error

This is because, Citrix requires certificate validation, but be default installation fails to include any certificates that are trusted.  This can be easily resolved by creating a symbolic link to the trusted certificates for Mozilla using the following command:

sudo ln -s /usr/share/ca-certificates/mozilla/* /opt/Citrix/ICAClient/keystore/cacerts/

Once all these steps were completed, successful access to the company Citrix environment was achieved.  Thank you Citrix for making this so easy.  Boo.  How difficult would it be to modify the file in the “64bit version” to include the right syntax? Actually it would work for both version since it is only a check.  The worst part of this whole thing is apparently it has been this way for several versions of Ubuntu and the Receiver.

A personal note:  Please get things together Citrix, if you tout full cross platform support, then you better be ready to deliver just that.