Citrix XenApp 6.5 Lab

 

I realized that I forgot to include a post on my Citrix XenApp 6.5 lab, the lab that I used to prepare for CCA and CCAA.
It does not take much to build a fully functioning lab for the exam. All the software including Windows can be obtain as a free trial that is valid for a few months, long enough to prepare and pass the exam.

Software Downloads

• XenApp 6.5 Software
• NetScaler VPX Trial
• Windows Server 2008 R2 Trial
• Microsoft SQL Server 2008 R2 Trial
• Windows 8 Trial

Virtual Machine Configuration

• Citrix XenApp 6.5 (2 servers)
• NetScaler VPX (Configured as Access Gateway)
• Domain Controller (Windows Server 2008 R2)
• Client Workstation (Windows 8)
• SQL Server 2008 R2 (Hosting Data Store)
• Citrix Merchendising Server (Deployment of Citrix Plugins)

Here’s a screenshot of the Virtual Machines I created

Material Used To Prepare For The Exam

• Getting Started with Citrix XenApp 6.5
• Citrix XenApp 6 and Citrix XenApp 6.5 TrainSignal Videos
• Citrix eDocs
• Various blogs

Final Thoughts

Take your time to prepare for the exam, learn the stuff well, do some practice tests (avoid braindumps) and take the exam!
Good luck!

Part 13: Working with Citrix XenApp 6.5 – Deploying EdgeSight 5.4

 

EdgeSight is a service that allows us to monitor things like applications, sessions, devices, license usage, network, etc in real time. Normally we install the EdgeSight service on a dedicated server, installing EdgeSight on a XenApp server is not recommended.
The system requirements for EdgeSight 5.4 can be found here.

Deploying EdgeSight Server Role

Launch the installer within Citrix XenApp 6.5 Installation media
Accept the language options and click Continue
At this point the installation Wizard will be displayed, so let’s continue
Chose the first option “EdgeSight Server Website and Database” option as this is the first EdgeSight installation
A prerequisites check will run and prompt us if there are any issues
Next, let’s accept the license agreement and continue
Keep the Typical choice and continue
We now need to specify the SQL server that we’re going to use for the EdgeSight database
At this point, make sure not to chose the existing Citrix Farm database, but instead provide a database name for the new EdgeSight database
Specify the account that will connect to the SQL database
We can now begin the installation

Once the installation is complete, we can begin with the initial configuration
Once we click on Finish, an initial configuration page will open. We can begin the configuration by clicking Next
Provide the company name, timezone, and language information and click Next
We now need to create the superuser account, fill in the information and proceed to the next step
Next, configure the correct email settings
At this point, we’ll need to make sure we can connect to the license server
 Review the information, if all is good, click Finish
Let’s test the login with the superuser account we created earlier
There you go! We can now successfully login!

Part 12: Working with Citrix XenApp 6.5 – Managing Sessions [2/2]

Session Reliability
Session reliability helps improve the connection for users. The reason why we would use session reliability is if the users who access the XenApp applications are in a remote location with poor internet connectivity, wireless connections that might drop from time to time, and so on. What session reliability does, is if the user looses network access temporarily, the session is kept active until the user reconnects and it does so without prompting the user for his/her credentials.
We can manage session reliability through Citrix Computer Policies

These polices are:

• Session reliability connections – Keeps sessions active when network connectivity is interrupted
• Session reliability port number – TCP port number for incoming session reliability connections
• Session reliability timeout – The length of time in seconds the session reliability proxy waits for a client to reconnect before allowing the session to be disconnected

Client Reconnection
We can configure Auto Client Reconnect so that if the sessions are monitored by the Citrix plugins and if the connection gets disconnected or breaks, the plugin will automatically fix the issue by reconnecting the session without having to involve the user. We do have policies in place to control Auto Client Reconnect

The policies are:

• Auto Client Reconnect – Allows or prevents automatic reconnection by the same client after a connection has been interrupted
• Auto client reconnect logging – Records or prevents recording auto client reconnections in the event log

ICA Keep-Alive Packets
We can configure ICA Keep-Alive packets which prevents some connections from disconnecting. What happens is XenApp server will send what is called a Keep-Alive packet every couple of seconds to make sure the session is alive, kind of like we do with some VPN connection. Now, if the session is not active, in other words the user left home for the day and forgot to log-off his/her session, then XenApp is smart enough to know, that the session can be disconnected. It is worth noting that if Session Reliability is enabled, then Keep-Alive won’t work as Session Reliability has its own mechanism for doing this. Again, just like other session options, we can configure Keep-Alive settings within the policies of the servers

The description of the polices are:

• ICA keep alive timeout – Seconds between successive ICA keep-Alive messages (60 seconds by default)
• ICA keep alives – Sends or prevents sending ICA keep-alive messages periodically

It’s important to note that the ICA settings override the Windows Group Policy settings

Part 11: Working with Citrix XenApp 6.5 – Managing Sessions [1/2]

 

Session management is an important part of managing the XenApp environment, after all every time a successful connection is made to the XenApp farm, resources and licenses are being utilized and thus at times, require our attention.
Normally, we use ICA as the protocol when we connect to the XenApp servers, that is on port 1494, however if we configure Session Reliability, we end up using port 2598 instead. We have three types of session states:

1. Active – Session is currently in use by a user
2. Idle – Session is idle, that is, the user is connected to the server, but not doing anything on the session
3. Disconnected – user disconnected from the session, but the session is still open

It is worth noting, that even if the sessions are idle or disconnected, the resources on the server are still being utilized, this includes licenses.
Managing Sessions
Sessions can be managed through Citrix AppCenter by navigating to XenApp -> Farm -> Servers -> [XenApp Server] and clicking the Sessions tab

As you can see under the sessions tab, we have a number of sessions that are currently open, including the console session. To better understand the information we’re presented, below is a description of the columns under the sessions/Users tab:

• User – User that is currently connected
• Session ID – a unique number that is given to each session, with 0 being the console session just like with remote desktop when we connect to the console. The listener sessions are numbered from 65537 and backward sequentially
• Application – Application that is currently open
• Type – The type of session that is currently open, either ICA or RDP
• State – The state of the session, whether it’s disconnected, idle, listening, down, or active
• Client Name – The name of the workstation that the session was imitated on
• Logon Time – When the session was created
• Idle Time – How long the session has been idle for
• Server – Which XenApp server the session is currently open

Within users tab, we have the option of controlling the user session, for example, we could disconnect, reset, log off, send message, shadow, etc

We can also manage sessions using Remote Desktop Services Manager, basically, we’ll see very similar information. We can access RDSM through Administrative Tools under Remote Desktop Services

Session Shadowing
what I do like to mention here, is the option of shadowing a user session. All we have to do chose Shadow when we right click on a user then log in

And now we’re able to see the application that the user has opened, in this case the application is remote desktop

We can leverage the Shadow toolbar for more control over shadowing user sessions. The tool bar can be accessed by navigating to the CitrixAdministration ToolsShadow Taskbar

We can now see our XenApp environment along with the applications/users/servers which then allows us to shadow user’s session

Other session shadowing options can be configured through Citrix Policies, for example, under the Shadowing options of the policy, we can configure settings like:

• Input from shadow Connections
• Log Shadow attempts
• Notify user of pending shadow connections
• Users who can shadow other users
• Users who cannot shadow other users

We can also send the user a message as a reminder to log off their session

The user should now receive this message

Terminating User Process
Sometimes there are instances where a user opens an application through XenApp and that application then crashes. Other times, that application can cause high CPU usage on the XenApp server and impact the performance of the server which in turn, impacts user experience. We can terminate these application instances on a per user basis. This is effective when more than one user has the same application open, instead of closing the entire app for all the users, we can just terminate this application for that one user.
We can do this in two ways:

1. Task Manager on the XenApp server
2. Processes under Users tab on the XenApp server

The first option will do, however you’d have to RDP to the XenApp server in order to close the processes, however with the second option, we can do this remotely using the AppCenter console.

Task Manager

App Center

As you can see from above, we have two adobe acrobat process running for the user: Administrator, we can easily close one of those sessions by right clicking the process and choosing to terminate

Be Sociable, Share!

Part 10: Working with Citrix XenApp 6.5 – Printer Configuration

Printing in Citrix is a pretty important feature if you ask me. After all, if the users are going to use Citrix for their applications, they need to be able to print from the application like they would normally do from an application that would be installed locally on their workstations.
Printing Environment Overview

• Print Server
• Printer Device
• Printers
• Printer Driver
• Printer Job
• Printer Queue
• Print Spooler Service
• Citrix Print Manager Service

In a somewhat of a decent size infrastructure we normally see print servers deployed. What are print servers? these are dedicated servers that have printer queues/drivers configured on them for users to connect and print their data. This configuration might not be the same for everyone, we could have users with locally attached printers, for example, an administrative assistant might have a printer dedicated to his or her job, so the printer might be connected by a USB or LPT connection to his or her PC. With Citrix, we’re able to use these printing devices to print the data whether the printers are locally attached or attached on the network.
Deploying Print Server Role
In this part, we’re going to deploy the printer server role on a Windows Server 2008 R2. The steps are pretty straight forward, we just need to launch server manager and select Print and Document Services

Click Next on the Intro page

Chose the Print Server role

Now, click Install which should get the printer server role installed

Configuring Printing Policy
Now that we have the printer role installed, we should not configure at the very least a few printing policies. There are a couple of basic policies we can configure to get started, those are:

• Client Printer Redirection – Alows or Prevents client printers to be mapped to a server when a user logs on to a session
• Default Printer – Specifies how the client’s default printer is established in an ICA session
• Wait for printers to be created (desktop) – Allows or prevents a delay in connecting to a session so that desktop printers can be auto-created
• Auto-create client printers – Specifies which client printers are auto-created
• Auto-create generic universal printer – Enables or disables auto-creation of the Citrix Universal Printer generic printing object for sessions with a UPD capable client
• Client printer names – Selects the naming convention for auto-created client printers
• Direct connections to print servers – Enables or disables direct connections from the host to a printer server for client printers hosted on an accessible network share
• Printer driver mapping and compatibility – Lists driver substitution rules for auto-created client printers
• Printer properties retention – Specifies whether and where to store printer properties
• Retained and restored client printers – Enables or disables the retention and re-creation of client printers
• Automatic installation of in-box printer drivers – Enables or disables automatic installation of printer drivers from the Windows in-box driver set or from driver packages which have been staged onto the host using “pnputil.exe /a”.
• Universal driver preference – Specifies the order in which XenApp attempts to use Universal Printer drivers, beginning with the first entry in the list
• Universal print driver usage – Specifies when to use universal printing
• Universal printing preview preference – Specifies whether to use the print preview function for auto-created or generic universal printers

One important piece to keep in mind, is that the printer driver on the server and the driver used by the client device must match exactly, otherwise, printing will fail. Please refer to this Citrix KB article for more information.

Replicating Printer Drivers To Other Servers
Printer driver replication can be a common scenario where we have a large Citrix/Printing environment. Why would we use printer replication? Well, if we have a lot of printers to deploy, doing so on a server per server basis can prove to be a long, inefficient, and error-prone task, so it is for this reason, printer replication can greatly assist with such tasks.
Replicating printers is quite simple, once we installed the printer driver on the server, we’ll need to open powershell and run the replication command to replicate the printer across. For example, let’s say that we wanted to replicate a printer driver on server XenApp called HP Laserjet 4250 PCL6 on to server XenApp1

In powershell, we’ll need to add the Citrix SnapIn with the following command:

Next, let’s get a list of all the printer drivers that are currently installed on XenApp:

If we check XenApp1 server to see if the HP LaserJet 4250 PCL6 printer driver exists, we can see that presently, it does not:

So, now, we’ll need to replicate the printer HP LaserJet 4250 PCL6 over to XenApp1 server. The powershell command that we would run from XenApp server is:

Start-XAPrinterDriverReplication -DriverName "HP LaserJet 4250 PCL6" -TargetServerName XenApp1

Now we can see that the printer driver was successfully replicated over to XenApp1 server

We can also automate this process by using Auto-Replication Lists. By Adding the printer driver to the Auto Replication lists, we can have those drivers automatically replicated over to other print servers. To add the printer HP LaserJet 4250 PCL6 to the auto replication list, we can use the following command: