An article by Frederic Serriere from Citrix Blogs

In multi-lingual environments, where let’s say the Windows 2008 R2 installation is in English and you add MUI languages packs, the XenApp 6.5 AppCenter console will pick up the language of the current user while many would need the console to use the English language.

Also, customers with XenApp Enterprise can’t use Citrix Single-Sign On (formely Password Manager) product as it isn’t included in the XenApp licensing model (see http://www.citrix.com/products/xenapp/features/editions.html).

I wanted to share with you two possible, yet officially not supported, customizations to avoid installing the Single-Sign On module within the Citrix AppCenter console and to change the console language before or after installation.

1) Avoid Citrix Single-Sign On discovery prompt and display within AppCenter

Before installing the AppCenter or XenApp:

On the location where the XenApp 6.5 ISO was extracted, browse to the Administration\Delivery Services Console\Resource folder. The Global.xml file contains the default configuration used when installing AppCenter console either via the XenApp autorun or via the AppCenter installation package (CtxInstall.msi in Administration\Delivery Services Console folder).

Locate the <Key>ASC-CPMConsole</Key> line in the Global.xml file (should be line 13) and change the value from True to False in the <Selected> section (line 17).

Save the changes and upon intallation the Citrix Single-Sign On console will not be installed.

After AppCenter or XenApp installation:

Once installed, Citrix AppCenter is located in C:\Program Files (x86)\Citrix\Citrix Delivery Services Console\Framework. However, the Citrix Single-Sign On console folder is C:\Program Files (x86)\Citrix\MetaFrame Password Manager Console.

To prevent the Single-Sign On discovery prompt and displaying the Single-Sign On component in Citrix AppCenter, rename the MetaFrame Password Manager Console folder.

2) Change Citrix AppCenter language after installation

Unfortunately, I could not find a nice and proper way to force the display language for Citrix AppCenter to English via a registry entry or a configuration file modification.

The quickest solution is to simply rename the language folders from \Citrix\Citrix Delivery Services Console\Framework (by default in C:\Program Files (x86) on a XenApp 6.5 server). At the next launch, Citrix AppCenter will automatically display all details in English.

Read More

An article by Nick Rintalan from Citrix Blogs

This used to be a very popular topic back in the day, so I’m sure “old school” MetaFrame and CPS admins will appreciate this article. It also makes me happy to write about good ‘ol XenApp, because it seems like I spend most of my time these days working with newer products like XenDesktop, Provisioning Services and XenMobile. And the reason I am writing this article is because I received 2 almost identical inquiries this week about this topic. And while most of the concepts around farm and zone design haven’t changed in a decade, a few things have and that’s why I’ve appended the title of this article, since it’s the “2013 version”. Before we review the various options for designing large XA environments with distributed data, first let me tell you about the 2 customers or inquiries so you have a bit more context…

The first customer is a large oil company with global operations – they have data distributed around the world in 7 locations. The second inquiry came in from one of my colleagues in APAC – the customer has data in 10 or 11 regions. So almost identical scenarios and both asked the question – how should we design the XenApp farm and zones? Ah – a good question, but a loaded question. I responded to both with something along the lines of the following:

You have 4 options the way I see it:

1. Single farm with 10 zones – essentially a zone per site
2. Single farm with maybe 5 zones – the premise here being to “group” sites with each other to collapse zones
3. Regional farms – one per continent (i.e. Americas, APAC, EMEA)
4. Multiple farms – essentially 1 farm for each site

I’ll start by saying I’ve done options 2, 3 and 4 with success before. I’ve never designed a farm with over 5 zones, so 10 would certainly be pushing the envelope. Remember, XenApp uses a star topology for replication among zones. So the more zones or ZDCs you have, the more network traffic (and it becomes exponential since we’re using a star topology). But the last time I did one of these global XA designs myself, the product was not version 6.5 with all the architecture improvements. So while we used to advise customers to not create more than 5 zones in a single farm, that was pre-6.5 advice (i.e. MPS 3.0, CPS 4.0, CPS 4.5, XA 5/6). With the new enhancements to the Data Store, LHC, IMA and XML services in v6.5, we might be able to push that zone limit a bit more. So maybe the magic number might be more like 7 or 8 with the improvements (by the way – we still say not to exceed 5 zones in our 6.5 documentation). But I really don’t know what the magic number is and that would be something you’d definitely want to test before pursuing option 1 – that’s honestly my least favorite option personally.

I did option 2 for a large communications company a few years back – they had about 15 sites in the US. I essentially grouped the smaller sites with the “best” larger site nearby. And notice I put “best” in quotes there – it’s all about network bandwidth & latency – not necessarily the closest geographical distance! In the end, I got down to like 4 or 5 zones total. To illustrate this “hub and spoke” zone consolidation design a bit better, let me give you an example – the customer’s New Orleans site had a small number of users and data (less than 10 XA servers required) and was connected “best” to a large data center in Atlanta via ~20 ms link, so I would form a zone called “South” or something for those 2 sites.

Read More

An article by cloudtweaks from CloudTweaks

In the modern world of big data, cloud computing is becoming a greater part of both the business world and our personal lives. While cloud computing provides us with convenient access to data from many locations, it had also introduced new security issues that were not present back when all of our data existed on our own personal hard drives. How can you be sure that your personal or business information is safe? Here are a few useful cloud computing security tips.

First of all, it is important to remember that when it comes to cloud computing, your data is only as a safe as your weakest password. Everyone who has access to the cloud needs to be trained on how to make their password as secure as possible. When it comes to the primary server access, the fewer who know the password, the better. Make the password difficult to guess, and change it on a regular basis to ensure security.

Authentication is becoming more and more common in the Internet world. Often times to check a credit card balance you need to provide an additional piece of information. Having a security question or two on each person with access can give you a second line of defense against would be hackers. It’s one thing to get someone’s password, but to know the make and model of their first car or the name of the city they were born means personal knowledge. Not having the security question always be a person’s mother’s maiden name, like in the past, means a criminal doesn’t know what personal info they need to acquire to hack an account.

Your next line of defense is data encryption. Even if someone manages to get through a password and answer a personal question, they still won’t have any useful data. This will make users more confident in your cloud security and give you greater peace of mind. A firewall will shore things up even further.

Logs are important in case there is a breach in security. Knowing every IP and MAC address that have been in and out of the cloud can help authorities to track criminals down later. Finally, you want to be sure that data is backed up so that there is no catastrophic loss in case of a server problem.

With all of these fail safes in place, you can rest a lot easier performing your cloud computing. The proper security lets you just focus on the convenience.

By Sam

The post Simple And Useful Cloud Computing Security Tips appeared first on CloudTweaks.

An article by Ather Beg from Xtravirt | Dedicated to Virtualization » Blog

Consulting throws up many challenges during the design and implementation stages but none more than the actual environment integration. Being at the ‘coal face’ invariably provides a point at which things don’t always go to plan and it’s this real world experience that we at Xtravirt excel at.

In this, my first blog posting, I’m going to discuss VMware snapshots and the possibility that you can recover from corrupted ones.

Particular events can create situations where a VM might start rebooting or shut down completely, and during this unplanned process one or more snapshots for that machine may get corrupted.

A common scenario for this kind of corruption is when:

•  A VM starts displaying the message in the console:

 “The redo log of <Machine Name>.vmdk is corrupted.  Power off the virtual machine.  If the problem still persists, discard the redo log.”

• Pressing OK to the message mentioned above, causes the machine to display the message again
• Powering-off the VM might not be possible and could be displaying the message in the console:

 “The attempted operation cannot be performed in the current state”

Depending on the type of failure, recovery from such a situation is possible and at times, with all data intact.  The latter is especially true in the case for backup solutions that utilize the snapshot feature as part of their process but become corrupt just after it’s taken; therefore there isn’t a lot of changed data at that point.  A complete recovery in this example is achievable.

I’ve recovered from such scenarios a few times and thought the process should be documented to help others.  This blog posting came about as I felt that while different KB articles document the process in parts, I couldn’t find one that guides someone through the whole recovery process.

Some of the assumptions that I am making here are:

• The failure is occurring on VM(s) with one or more snapshots, created either manually or via an automated mechanism eg: a backup solution
• The virtual machine is displaying errors about inconsistent, corrupt or invalid snapshots
• The person working through the issue is familiar with VMware operations and can deal with minor variations in the discussed scenario
• The process to force shutdown of a VM is required for ESXi 5.x hosts (while syntax for other versions will be different, the process remains the same)

Virtual Machine Restore Process

Step 1: Save Virtual Machine Logs

The first action is to save logs for this VM; these can be found in the virtual machine folder on the datastore.  This is to avoid losing potentially valuable diagnostic data in the event of a catastrophic failure.  Due to the state the virtual machine is in, it might not be able to save vmware.log but the other log files should be copied directly from the datastore to a safe location.

Step 2: Shutdown Virtual Machine

This is to avoid having any further damage to the current snapshots before a copy of the machine is made.  It’s possible for vCenter to lose control of the virtual machine in such situations and power operations might not work from the VI Client.  If that happens, refer to “Force Virtual Machine Shutdown Process” section near the end of this posting for techniques to force the shutdown of the machine.

Step 3: Make a copy of the Virtual Machine folder

Once the virtual machine is shut down, make a copy of the virtual machine folder to another location on the same or another datastore.  Name the folder something appropriate eg: <Machine Name>-Backup.

Note: A clone is not what is required and it probably won’t work in such a situation.

Step 4: Attempt to fix the snapshots

First check if the datastore has enough space remaining; snapshots do become corrupted if there isn’t enough space available.  As there might be other snapshots in the background, estimate generously and if there isn’t enough space, use Storage vMotion to migrate machines off that datastore, to have a safe level of headroom available.

Once there is enough space available, try taking another snapshot, and if successful, try committing it.  This operation might fix the snapshot chain and consolidate all data into the disks.  If this process fails, then follow the remainder of the process to manually restore the machine from remaining snapshots.

Step 5: Confirmation of existing virtual disk configuration

Go into the VM settings and confirm the number and names of the existing virtual disks.  As there are snapshots present, the disk(s) will be pointing to the last-known snapshot(s).  Also, make note of the datastore the machine resides on.

Step 6: Command-Line access to ESXi server

Gain shell access to an ESXi server in the cluster which can see the datastore with the virtual machine in question.  The ESXi server should also have access to the datastore where the repair will be carried out.  As SSH may be disabled (by default), you may have to start the service manually.

Note: Seek approval (if security policy requires it) before this is done.

Once SSH is enabled, use PuTTY (or a similar tool) to connect and login using “root” credentials

Step 7: Confirmation of snapshots present

Once logged in, change directory to:

/vmfs/volumes/<Datastore Name>/<Machine Name>

Run:

ls *.vmdk –lrt

to display all virtual disk components.

Make note of what “Flat” and “Delta” disks are present.  While it can vary in certain situations, the virtual machine’s original disks will be named the same as the virtual machine name by default.  If there is more than one virtual disk present, it should have “_1” appended to the base name and so on.  If there are snapshots present, they will have “-000001” appended to each disk name for the first snapshot and “-000002” for the second and so on, by default.  Make note of all this information.

Step 8: Repair of the virtual disks

Start with the highest set of snapshots and for each disk in that set run the following command, where <Source Disk> is the source snapshot:

vmkfstools –i <Source Disk> <Destination Disk>

Please note: <Source Disk> is the base .vmdk name, ie: not the one with –flat, -delta or –ctk in the name.  <Destination Disk> is the new disk, where all disk changes need to be consolidated.  The new name should be similar to the source but not identical.  <Machine Name>-Recovered.vmdk is one example for the first disk.  Keep the same naming convention throughout for all disk names eg: <Machine Name>-Recovered_1.vmdk, <Machine Name>-Recovered_2.vmdk and so on.

For example:

vmkfstools –i <Machine Name>-000003.vmdk <Machine Name>-Recovered.vmdk

for the first disk from the third snapshot set.

vmkfstools –i <Machine Name>_1-000003.vmdk <Machine Name>-Recovered_1.vmdk

for the second disk in the same set and so on.

Repeat the process for all disks in the snapshot set identified earlier in step 7.  If the process is successful, move on to step 9.

If there is failure on one or more disks in the set, the following error message may be displayed:

Failed to clone disk: Bad File descriptor (589833)

If that error occurs, skip that disk and keep running the process for other disks as they might still be useful.  However, the set will likely be rejected to run as production so the next recent snapshot set should be tried.  Follow the same process until all disks in a snapshot set are successfully consolidated into a new disk set  If this is an investigation into the events leading up to the failure then additional sets might have to be consolidated in the same way.  All sets should now consolidate successfully.

Step 9: Restoration of the virtual machine

Using the “Datastore Browser”, create a new folder called “<Machine Name>-Recovered”, either on the same datastore or another.  Move the newly-created “Recovered” vmdk file(s) to the new folder.  Also, copy <Machine Name>.vmx and <Machine Name>.nvram to the new folder and rename both files to become <Machine Name>-Recovered.*

Download <Machine Name>-Recovered.vmx to the local machine and edit it in Wordpad or similar.  Replace all instances of <Machine Name>-00000x (where “x” is the last snapshot the machine’s disks are pointing to) with <Machine Name>-Recovered.  Repeat for other disks if present e.g. _1, _2 and save the file.  This should make the .vmx match all newly-consolidated disks.  Rename the original vmx file in the datastore to <Machine Name>.vmx.bak and upload the edited <Machine Name>.vmx back into the same location.  Once uploaded, go to the “Datastore Browser”, right-click the vmx file and follow the standard process of adding a virtual machine to inventory, possibly naming it “<Machine Name>-Recovered”.

Once in the list, edit the VM settings and disconnect the network adapter.  It might require connecting to a valid VM network first but the main thing is that the network adapter should be disconnected.

Once done, take a snapshot of the virtVM and power the machine up.  At this point, a “Virtual Machine Question” will come up.  Answer it by selecting the “I copied it” answer.  If the disk consolidation operation was successful for all disks, the machine will come up successfully.  The machine can now be inspected and put into service or investigated for a problem.

Once operation of the machine has been tested and the decision has been made to bring it into service, shutdown the virtual machine, reconnect the virtual network adapter to the correct network and power it back up.  After boot is complete, login to the machine to confirm service status, network connectivity, domain membership and other operations.  If all operations are as expected then the restore process is complete and the snapshot can be deleted.

Force Virtual Machine Shutdown Process

First Technique: Using vim-cmd to identify and shutdown the VM

While connected to the ESXi shell and logged in as “root”, run the following command to get a list of all VMs running on the target host:

vim-cmd vmsvc/getallvms

The command will return all the VMs currently running on the host.  Note the Vmid of the VM in question.  Get the current state of that VM as seen by the host first, by running:

vim-cmd vmsvc/power.getstate <Vmid>

If the VM is still running, try to shut it down gracefully using:

vim-cmd vmsvc/power.shutdown <Vmid>

If the graceful shutdown fails, try the power.off option:

vim-cmd vmsvc/power.off <Vmid>

Second Technique: Using ps to identify and kill the VM

Warning: Only use the following process as a last resort.  Terminating the wrong process could render the host non-responsive.

While connected to the ESXi shell and logged in as “root”, list all processes for target virtual machine on the current host by running:

ps | grep vmx

That will return a number of lines.  Identify entries containing vmx-vcpu-0:<Machine Name> and others.  Make note of the number in the second column of numbers, which represents the Parent Process ID.  For most of the lines returned for that machine, this number should be the same in the second column.  One line belonging to “vmx” will contain that number in both first and second columns.  That is the ProcessID of the target virtual machine.

Once identified, terminate the process using the following command:

kill <ProcessID>

Wait for a minute or so as it might take some time.  If after that, the VM hasn’t powered-off, then run the following command:

kill -9 <ProcessID>

The method in the section will not result in a graceful shutdown but it should terminate the machine, allowing for the recovery to take place.  If the machine still cannot be terminated, further investigation will be required on the host and the only option left will be to vMotion other virtual machines off this host and rebooting the host in question.

Final Words

The beauty of virtualization is that one can test most service scenarios without actually causing impact to service and this process is no exception.  For that reason, I would strongly recommend practicing this process in your lab environment so that you are well prepared in case disaster strikes.

An article by claws from Riverlite

Recently, we implemented Citrix User Profile Manager (UPM) 4.1.2 in a XenApp 6.5 HFR01 environment and begun to notice a few inconsistencies.

When a user logged in and they had no Remote Desktop Services Profile Path set in AD, everything worked great. A Citrix UPM profile folder would be created and saved to the profile share when logging off.

However, when there was a Remote Desktop Services (RDS) Profile Path set in the user’s account within Active Directory, the Citrix UPM settings appear to be ignored and the existing RDS profile was loaded and then saved to the profile share

The following Citrix UPM GPOs were applied:

a. Enable Profile Management = On
b. Process logons of local administrators = On
c. Path to user store = \\fileshare\share$\%username%
2. Citrix -> Profile Management -> Profile Handling
a. Delete locally cached profiles on logoff = enabled
b. Migration of existing profiles = disabled
c. Local profile conflict handling = Enabled, Delete local profile
3. Citrix -> Profile Management -> Streamed User Profiles
a. Profile Streaming = Enabled

After examining the Citrix UPM logs we could see that when a user logged in, UPM did search the Citrix profile share to identify if the profile folder existed. If a profile folder was not found, an existing RDS profile was loaded.

After a further check of the profile GPO that was set I realised where the mistake had been made. With “Migration of existing profiles = disabled” and no Citrix user profile existing in the user store, the existing Windows mechanism for creating new profiles would be used. To remedy this I amended the migration of existing profiles to enabled and set the value to none.

After this, when a profile could not be found in the user store, a new profile was created.

An article by Trond Eirik Haavarstein from xenappblog.com

In this blog post I will show you my Prepare for PVS script that contains Best Practices obtained after years of experience with Provisioning Services.

Let’s say you’re going to run Windows Updates. Well since you’ve already launched the Target Optimizer tool, that services is disabled and you need to head into services, enable and start it. Run Windows update and all good. When the update is finished you shutdown the machine and switch from Private to Standard Mode.

What you didn’t remember was to reboot the server for Windows Update to complete it’s updates. What happens now, is that every time your servers reboot, Windows Update will kick in and finish it’s things.

So being only one administrator doing all the procedures is one thing, but when you hand over the solution to your customer or maintenance team, everybody would probably do this differently, forgetting to flush DNS and so on.

So this script will do all these thing for you. Just teach your staff to always run the script after maintenance.

Prerequisites :

• Download Wuinstall
• Download and Install XenAppCloning Tools (Now free of use).
• Download Citrix XenApp 6.x Update Script

Copy Wuinstall to C:\Windows. Run XenAppCloning tool, add your free license and then configure your settings and save the settings to the configuration file.

Extract the XAUpdate script to C:\XA65Update, rename the script to XA65Update.cmd and configure the settings required inside that script.

Copy the content below into C:\Program Files\Citrix\Prepare for PVS.cmd

@echo off
cls
echo ************************************************************
echo ***** This will prepare the machine for Standard Image *****
echo ************************************************************
echo.
choice /c yn /m "Do you want to Download and Install Windows Updates"
set DRIVENUM=%ERRORLEVEL%
if %DRIVENUM% EQU 1 goto wsus
if %DRIVENUM% EQU 2 goto ctx
:wsus
echo.
echo Enable and Start Windows Update Service
sc config wuauserv start= auto
net start wuauserv
echo.
echo Applying Windows Updates
wuinstall /install
shutdown /r /t 0
goto ctx
:ctx
echo.
choice /c yn /m "Do you want to Download and Install Citrix Hotfixes"
set DRIVENUM=%ERRORLEVEL%
if %DRIVENUM% EQU 1 goto 65update
if %DRIVENUM% EQU 2 goto cont
:65update
call C:\XA65Update\XA65Update.cmd
:cont
echo.
choice /c yn /m "Do you want Defrag the Disk"
set DRIVENUM=%ERRORLEVEL%
if %DRIVENUM% EQU 1 goto defrag
if %DRIVENUM% EQU 2 goto cont1
:defrag
echo.
defrag C:
:cont1
echo.
ipconfig /flushdns
echo.
echo Deleting Windows Update Download Folder
rmdir /s /q "C:\Windows\SoftwareDistribution\Download"
echo.
echo Deleteing Downloaded Citrix Hotfixes
del C:\XA65Update\*.msp /q /s
echo.
echo Running Provisioning Services Optimization Tool
call "c:\Program Files\Citrix\Provisioning Services\TargetOSOptimizer.exe"
echo.
echo Running XenApp Cloning Tool
call "C:\Program Files (x86)\VirtuAll Solutions\XenApp Cloning Tool\XenAppCloningCmd.exe" -Mode:PVS -ConfigFile SilentCloningConfig.ini
shutdown /s /t 30 /c "The System will Shut Down in 30 seconds - Type shutdown /a to Abort"
[/bash]

To get ride of this annoying boot screen

you just added HKLM\Software\Citrix\ProvisioningServices\SkipBootMenu to your PVS servers. Now your maintenance / test machine will automatically boot to the newest version of the vDisk.

Please be aware that this doesn’t work on Provisioning Services 6.2 hosted on Windows 2012. The good news though, the KMS bug has finally been fixed in Provisioning Services 6.2 (part of Project Excalibur Tech Preview).

So when you e.g. want to patch your Provisioning Services image with the latest Citrix Hotfixes, you just select that option and off you go. The server is rebooted automatically and when it comes back online you just run through the script another time and this time the server will be shutdown ready for you switching from private to standard mode.

If you have any other Best Practices for Provisioning Services, please leave a comment below and share with the community.

An article by Simon Farrugia from Citrix Blogs

Today’s fast-paced business world requires IT organizations to supply the tools that allow employees to quickly react to the demands of a competitive environment. Whether they are in the office or remote, employees need to readily and securely access corporate resources. This is the mobile workstyle – but how did we get here and how can Citrix help? This is the first in a three part blog series that looks at the evolution of the mobile workstyle and how Remote PC Access, as a key component of Citrix FlexCast delivery technology, can help enable mobile workstyles.

Many of you reading this blog will have your own mobile workstyle story. Whether it be working remotely on a permanent basis, adjusting your schedule to be around your family when they need you, or having professional demands that mean work is not a contiguous period of time. Being able to work when it is required, in harmony with your broader life enables you to deliver better outcomes to your customers and employer.

The mobile workstyle is fast becoming the behavioral norm used by workers globally, from all disciplines and across all sizes of business. However the concept is not entirely new and its roots can be traced back to the early 90’s when remote access was becoming all the rage. These initial solutions were by current standards primitive, and it took many advances in devices, networks and applications to get us to where we are today.

Figure 1: The history of mobile workstyles.

In the 1990′s, dial-up networking was the prevalent connection model for access – many organizations would securely connect back to resources with laptops and IPSEC tunnels. The dawn of the new millennium saw SSL VPNs (non IPSEC) come to the forefront and Microsoft introduced RDP for Windows XP with SP2. Citrix admins then began to publish RDP in Metaframe as a way to reduce the VPN/IPSEC footprints, and allow broader device choice. Many XenApp customers still employ this method today.

Read More

An article by Simon Farrugia from Citrix Blogs

In Part 1 of this blog series we looked at how mobile workstyles have emerged from the earlier days of remote access to meet the needs of both businesses and employees in the mobile-first world. This second part takes a closer look at Remote PC Access, an innovative and unique component of Citrix FlexCast delivery technology for virtual desktops.

Remote PC Access delivers fast, secure, remote access to all the corporate apps and data on an office PC from any device. Remote PC Access is a component of FlexCast delivery technology that enables IT to provide users with access to their Windows desktop running on their PC in the office, while working remotely or from mobile devices.

Figure 3: Remote PC is a part of FlexCast Delivery Technology.

It works by placing the Virtual Desktop Agent (VDA) inside the user’s own desktop or laptop – as opposed to a server hosted VM. In doing so, customers can adopt desktop virtualization by utilizing existing distributed computing assets.

Some of the key benefits:

• Ease of deployment: Remote PC Access is a simple-to-deploy solution that can be easily delivered to thousands of physical desktops via a group policy or electronic software delivery system and automatically assigns users to their PCs with one-touch access.
• User Experience: Remote PC Access delivers simple access for every user. It leverages Citrix® HDX™ technologies to optimize the user experience over any network connection, including WAN and international connections to ensure the best possible experience when connecting to a physical desktop. Remote PC Access is integrated with the Citrix Mobility Pack to dynamically transform the PC interface into a touch-friendly format when accessing on a tablet or smartphone.
• Secure and Controlled: While consumer-driven solutions, such as Citrix® GoToMyPC®, are great for self-service consumer cloud desktop access, Remote PC Access provides centralized control and enhances the HDX experience to the physical PC with the SmartAccess policy engine that can configure specific permissions associated with tasks such as drive mapping, clipboard transfers and printing. Remote PC Access can also be configured for two-factor authentication methods, including smart cards, for an extra level of secure user experience.
• Future proof: Because Remote PC Access is a component of FlexCast it integrates with the broader suite of Citrix infrastructure without a need to retrofit the OS or apps.

Read More

An article by Simon Farrugia from Citrix Blogs

Previous installments of this blog series gave a brief history on mobile workstyles, as well as an overview of Citrix Remote PC Access that highlighted Remote PC Access as a component of the broader Citrix desktop virtualization solution. In this blog we look at how Remote PC Access complements other Citrix desktop virtualization solutions.

Remote PC access demonstrates the value of flexible desktop delivery with FlexCast. For VDI , users can start using their desktop image instantly with Receiver and HDX, without waiting for IT to transition their image to the datacenter. After the image is transitioned into the datacenter, or delivered in a different manner, their user experience doesn’t change; they continue to use Receiver and HDX to access the desktop image. This has accelerated multiple VDI deployments by many months.

When it comes to Remote PC Access and GoToMyPC, it’s all about the use case! Remote PC access and GotoMyPC are entirely complimentary of each other! When considering which way to go think about the following choices:

• Cloud control or On-premise
• Receiver and HDX-enabled or web technologies
• Standalone or XenDesktop/XenApp integration
• Self-service or automated

These high-level points, and more, are illustrated below, to help decide which solution is most appropriate for any given situation.

Figure 1: Positioning GoToMyPC and Remote PC access.

Read More

An article by Joel Bejar from Citrix Blogs

Introduction

Pass-through authentication is a simple concept. User credentials are passed to a Web Interface site and then to the XenApp/XenDesktop servers, preventing users from having to explicitly authenticate at any point during the Citrix application launch process. While this authentication method seems straightforward, there are some moving pieces, and this article aims to break these down to provide a more detailed understanding of how this process truly works within Citrix.

Pass-Through Authentication – Web Interface Site

The first step to the pass-through process occurs at the Web Interface site. Users are able to navigate to the web interface site, and their credentials are passed through and they are presented with their Citrix delivered resources. Web Interface is built on Internet Information Services (IIS). For pass-through authentication to work, IIS Integrated Windows Authentication must be leveraged. Formerly called NTLM, this authentication method hashes the user credentials before they are sent over the network. When this type of authentication is enabled, the client browser proves its is authenticated through a cryptographic exchange with the Web Interface server, involving hashing. Because of this, the web browser is responsible for authenticating with the Web Interface Server (IIS). It is important to note, though, that credentials are actually never exchanged. Instead, the signed hash is provided to IIS, proving that said user had already been authenticated at the Windows desktop. The web interface user uses the user’s AD context (sometimes referred to as a token) to retrieve the user’s AD group membership and pass this list of groups directly to the XML service for authentication. At this point, the user has successfully passed through to the Web Interface site, and can now view his/her Citrix resources.

• The WI server must be in the same domain as the user, or in a domain that has a trust relationship with domain of the user.
• If the WI server and user are in different domains, and resources are published using Domain Local AD groups in the user domain, then the WI will not be able to enumerate these, even with a proper AD trust relationship (due to the very nature of Domain Local groups).
• The WI site should be added as a Trusted Site or Intranet Zone site in Internet Explorer. In addition, the security settings should be modified so that User Authentication\Logon is set to ‘Automatic Logon with Username and Password’.
• Pass-through authentication is not supported on Web Interface for NetScaler
• http://support.citrix.com/article/CTX130153
• Please Note: Pass-through authentication and Kerberos authentication are not interchangeable and they have different requirements.

Pass-Through Authentication – XenApp/XenDesktop Session

One of the biggest misconceptions with Pass-Through authentication in Citrix is that it only occurs when a user navigates to the Web Interface site and he/she is automatically passed through. As mentioned above, this IIS authentication method that is being used does not actually exchange the user password. In other words, Web Interface is never in control of the user credentials. This brings up the question: How are users passed through to the actual XenApp/XenDesktop ICA session?

While the web browser has a role in authenticating the user to the web site, the Citrix client (Citrix Receiver) plays an integral role in making sure the user is fully passed through to the application or desktop. Citrix Receiver installs a process called SSONSVR.exe, which is the single sign-on component of the client (no, not password manager SSO, but rather desktop credential pass-through authentication SSO.) This process is fully responsible for passing the user credentials to XenApp or XenDesktop. Without this piece, pass-authentication will not function. In non-Enterprise versions of the Citrix Receiver, the SSON piece is not automatically installed, and must be done during a command line install of the client. For more information, refer to http://support.citrix.com/proddocs/topic/receiver-windows-34/receiver-windows-cfg-command-line.html.

Read More