Monthly Archives: June 2012

Citrix XenDesktop Remote PC. This has the potential to be a winner, what do you think?

At Synergy San Fran this year, there was alot of disapointment from the community over the lack of love or attention that XenApp and XenDesktop received. I too felt this disapointment at first until the possibilities sank in for the new feature in the XenDesktop product line, XenDesktop Remote PC.

XenDesktop Remote PC has been touted as a new offering in the Flexcast model, Jarian (the Citrix Forums super hero and all round cool guy) Gibson does a great job of writing up the current challenges with remote pc technologies and the benefits this will add to his customer use cases here.

I think there’s more to this product than meets the eye, I think this product is so simple and clever it will really bolster Citrix’s VDI offerings to the point that I’m beginning to wish I had this product now, and for the last few projects. It would have saved me some hair.

With most VDI projects, building the environment, application packaging the core applications, testing and migrating users takes the least time. By that I mean, with most VDI projects and Proof of concepts 70-80% of the work is visible, addressable and goes off without too many hitches.

The bulk of the work comes (and lets be honest guys and gal’s, we love to do it) when we attempt to drive a square peg into a round hole to satisfy a small percentage of this initial user group.

These square pegs could be applications developed by anonymous cretins with a fetish for disk activity, developers sitting on robust hardware, graphic’s guys with funny mice and expensive GPU’s. Hell, a square peg I’ve come across once was a user who liked to play World of Warcraft at lunch… yep, I’m not joking. She was obviously romantically involved with somebody who was willing to overlook her nonsense and cancel the migration / project.

And despite how hard we try, these square pegs require ALOT of time and investment to reverse engineer their craplications, to change their mind sets, to reeducate the users or just bang our heads against a wall over the gamer with a louder voice than IT. These square pegs will often turn an SBC project into a XenDesktop project, then a XenDesktop stateless model to a XenDesktop stateful model… aka utter failure.

And even in the face of defeat we still defer the decision to leave them where they are as they want the same benefits as their task worker colleagues aka working from home… or bed, as is more likely.

For me, XenDesktop Remote PC, in these cases will allow us to focus on the low hanging fruit, delivering a good VDI model for the correct use cases while still delivering the remote working option for the square peg users who don’t yet fit into the circular hole.

Allowing us to come back to this use case as the customer reinvests in more suitable applications, or when vendors improves their products further to encompass these small use cases.

As a student of the K.I.S.S* methodology, remote PC is a no-brainer for me, and here’s why:

*Keep It Simple, Stupid

  • Spend weeks/months working with graphical users, virtualising GPU’s and funny mice? or Remote their PC?
  • Spend thousands fighting with fledgling virtual GPU’s on hypervisors? or Remote their PC?
  • Spend weeks/months reverse engineering this crapplication that requires a hardware dongle? or Remote their PC?
  • Allow the CFO’s secretary you upset by asking her to stop watching cookery classes derail your project? or Remote their PC?
  • Call the World of Warcraft player’s shenanigans and risk your own neck? or Remote their PC?
  • Attempt to deliver a developer desktop, with 8 cores / 16gb ram, with user installed apps, on stupidly expensive shared storage? or Remote their PC?
  • Attempt to provide an application that requires 2gb / 2 cores per user on SBC? or Remote their PC?


For me the answer is so painfully clear, its brilliant.

So I for one am waiting with baited breath for XenDesktop remote PC. I just really hope Citrix allows this product to reach its full potential, not release it then allow it to flounder like so many before it (Power and Capacity management, Workflow Studio, Edgesight, etc).

What do you think? will Remote PC allow for easier roll outs and safe fall backs?

ThinKiosk 2.1 Released

This update has been a while coming, thanks to all who’s helped!

 

New features in 2.1:

  • German Language pack. (Thanks Michael)
  • A nifty clock.
  • CloudGateway Express support.
  • VDI in a box support.
  • Pass through Authentication support (documented here)
  • the offline Configuration tool is now a one stop shop with shell replacement and auto login options.
  • The client details and windows version menu items can now also be removed or moved.
  • Debug mode (activated via admin menu).
  • ThinKiosk can be configured to log users off after the session ends (if you are using passthrough).

Bug Fixes in 2.1:

  • The offline configuration tool now obeys UAC.
  • ThinKiosk is now aware of its browser rendering version and will attempt to fix it on the fly.
  • ThinKiosk has been rolled back to 32bit. This was due to compatibility issues. It is 64bit aware and will handle 64bit seamlessly.

You can download it here:

Citrix XenDesktop Login screen improvements.

In this blog post I’m going to talk about the XenDesktop login screen and how to improve its appearance / performance.

Issue 1, Login screen difference:

My first issue with the XenDesktop login screen is its dramatically different appearance to the XenApp login screen for published desktops. By default the XenApp login desktop is simple, to the point and quick to render across latent lines as below:

The Xendesktop login however is the default windows 7 login and is quite graphical as below:

Citrix by default don’t recommend using a desktop wallpaper and under load or high latency this screen can render in black chunks leaving a poor initial user experience. So why use such a graphical login screen?

The other problem I often see, is this vast difference here also causes a headache I call User Envy. User envy occurs when you deploy the Citrix flexcast model using XenDesktop and XenApp published desktops depending on the type of user you are deploying.

User envy occurs when a user using the XenApp published desktop see’s the login screen for xendesktop and immediately thinks they also want a XenDesktop desktop:

  • “because its prettier”
  • “because they have it, I want it too”
  • “its a dedicated desktop, i need a dedicated desktop too”
  • etc.

When using both models in a successful VDI implementation, its quite important to level the user experience.

Issue 2, Sluggish mouse syndrome:

When deploying xendesktop with a Domain welcome message, the cursor on this screen performs really poorly.The cursor sticks and skips across the screen, giving the impression of poor performance from the earliest stage of the session.

I should point out this isn’t a citrix problem, the Windows Aero cursor performs like crap when it’s remoted, regardless of technology. Citrix make a point of disabling the cursor in the session, but left it at the login screen for some reason.

I’ve uploaded an example of this sluggishness below, but anyone who has used XenDesktop in this setup will understand what I’m talking about immediately.

So with these two little niggles on my list of things to fix. I set about making the following improvements:

Creating the same, quick loading screen as XenApp.

This was actually really simple to do, Since windows 7, you have been able to change the login page’s wallpaper using the OEMBackground Key in the registry. Once I knew how to use this key, I took a sample of the XenApp login screen and created a (tiny) jpg file in the correct dimensions.

To do as I have did, follow the below Guide:

  • Download the OEMBackground I have already created here, no point in recreating the wheel.
  • Open C:windowssystem32OOBE and create a folder called info.
  • inside the info folder, create a folder called backgrounds.
  • Paste the file you have downloaded here as below:

  • Now open Regedit and browse to:
HKLMSoftwareMicrosoftWindowsCurrentVersionAuthenticationLogonUIBackground
  • Create a Dword (if it doesnt exist) named OEMBackground with the value of 1.

That’s it, reboot and test!

The login screen should now appear as below, result!:


Removing the Aero Cursor from the login screen.

The login screen that appears on a Windows 7 machine is running as the system account. Once we know this, its just a matter of changing the system accounts mouse settings!

Browse to:

HKEY_USERS.DEFAULTControl PanelCursors

Now replace all values as you see below:

That’s it, reboot and the cursor should be the default (non aero) cursor.

Now once you’ve combined both changes, the login screen becomes crisp, quick to load and nearly identical to the XenApp login screen as below:

Citrix Provisioning Server, questionable assumptions & why I don’t trust people.

This blog post may seem like a bit of a strange title, but this is a subject I’ve been struggling with for the longest of time and really just need to get it off my chest. I’ve put off this blog post for the longest time, but I still feel it needs to be said.

Firstly I’ll start by saying I think Citrix Provisioning services is an amazing piece of technology. Hosting, maintaining and deploying a single image to as many servers as you like is a solution you would have killed for a few years ago; and the fact that it’s rolled into the platinum licensing model only further wets the appetites of potential customers. In short, it’s a wonderful product and you would be mad (in most cases) not to use it.

Citrix provisioning services is also a consultants best friend, you need only install a a single XenApp server, configure it with best practices, install some software, negotiate some caveats with AntiVirus/Edgesight, document the change procedure then deploy en mass. The customer is amazed you got the job done so quick and you can retreat in success safe in the knowledge that if the customers are capable of reading and following instructions, it should be ok.

This will work great for a small, local company deployment where a single administrator will oversee the changes and understands the process himself. But as it scales up paranoia (for me) sets in.

Here’s the bit I dont like:

1: Citrix provisioning Services employs the assumption you must store as many of the changes to the golden images as you can afford to reduce your chances of being caught out. This may not sound like a big issue to some, but with large rates of change in environments (say even 5 changes a month) and large golden images (lets say 100gb) your storage costs will quickly become unjustifiable over time.

I am aware Provisioning services 6 has the ability to layer changes, but even Citrix recommend chaining 8 or less layers before consolidating these images. Even with the above figures this would spiral quickly.

2: Citrix Provisioning Services employs the assumption that the administrators are going to fully document the changes they made between images.

I’ll openly admit I dont trust techies to follow even the simplest personal hygiene routine never mind change management procedures and you can try to protect yourself with these procedures till you are blue in the face, a process is only as good as your laziest / least forgetful administrator and ultimately its your ass in the hotseat when the shit hits the fan.

3: Corruption. If infrequently accessed parts of the registry, file system or corruption in an infrequently used application occurs before your oldest golden image backup you are well and truly sunk, unless you have full and concise documentation on how this oldest image came to be and all the necessary steps there after.

4: Ever troubleshooted an application under intense pressure, made 4-5 changes at once and found it fixed the problem but the urgency dictated this change needs to go live yesterday? This basically.

Even the most meticulous administrator will suffer pressure related shortcuts and when the pressure is off its all to easy to forget that you need to route cause analysis the issue. Provisioning services allows these shortcuts all too easily.

But what are the alternatives to ensure control?

Who said scripting?

Products that use scripted installs, such as RES Automation manager, Frontrange DSM, Microsoft’s WDS / MDT etc have the benefit of forcing the technical guys to script the task ahead of time. This means they must fully test the install procedure before it gets to the production environment. Scripting the install forces documentation of some kind before time and ensures the package sources are kept in a shared, backed up location.

The downside to this method is the time taken to script a deployment, the potential (albeit, rare) unscriptable changes and the time taken to deploy an image from baremetal to the last job can be quite lengthy.

“But what if you use these tools to manage the golden image, then deploy via Citrix PVS?”

Well, you could do this, but then what are you really achieving? Sure you have a scripted install of your golden image but you’ve to go to the bother of scripting everything, performing a full reinstall (to ensure full operation) then importing the image into PVS. You’ve also now a licensing overhead (in most cases) for each server you deploy thereafter as their software is installed in the Golden Image.

I’ve spoken to three vendors in this market and they all got a little uncomfortable with the idea of using their product up to the finish of the build then uninstalling it in favour of PVS before sealing the image. In RES Automation manager’s case, if you leave it installed at least you then have the benefit of automating user based tasks as well, so i suppose its not a great loss.

In all directions, ask yourself what are you really still achieving using PVS if you have already scripted the entire process?

And what could Citrix do to address my concerns?

To be honest, I’m not sure, I spoke about this frequently at Synergy last year and there were quite a few people with similar concerns. Either way, here’s my 2 cents.

Scan and report:

I would like to see Provisioning Services scan the file system, registry and known keys (e.g. installed applications) of the old and new image, then perform a comparison (alike regshot) and report on the changes each time a new revision is added. This scan would identify key changes to both structures and provide a report of change. E.G.:

Basic Reporting:

  • new folder c:program files (x86)application1
  • new file: c:program files (x86)application1runme.exe
  • newer file: c:windowssystem32driversetchosts
  • Deleted file c:windowssystem32some.dll
  • New registry value: hklmsoftwaresomevendordangerouskey – Dword – 1
Smart reporting too:
  • new system odbc connection: application1
  • new Installed Application: Application1
  • Windows updates applied: KBxxxxx, kbxxxxy
Etc, you get the idea…

This scan should be mandatory and the results should be stored in the Provisioning services database which can be referenced or searched for keywords at a later point. This scan should also include a mandatory sign off from the upgrading administrator in question so you have accountability for who made the change.

I can’t see this as being difficult, I mean, I’m sure a powershell script wouldn’t be too difficult and it would really address the change comparison to be sure you are aware of what has happened between images.

To really get across what I’m trying to say, I figured as techies we love detailed exam questions, so below are some real life examples of where I’ve seen Citrix Provisioning Services fall down in a production environments.

Example:

George works as an architect in Company A, George’s SBC environment publishes hosted desktops for over 5,000 users on roughly 200 XenApp servers.

  • Company A has a large application land scape of roughly 1,000 applications.
  • Company A has a rapid rate of change, with an estimated 2-4 changes per week.
  • Company A’s golden image including App-V cache is over 100gb’s.
  • Due to the vast size of the golden image, only the last 20 images are stored.
  • George has employed a strategy to ensure all changes to the XenApp environment are fully documented in a sharepoint instance.
  • The corporate policy on acceptance testing dictates no additional changes can be processed until the acceptance test is complete. The acceptance testing period is 10 business days.

Scenario A: An issue has been experienced recently and an office application is crashing. This crash has been ongoing for roughly 6 months but has never generated enough steam until now, after troubleshooting George finds a DLL called OpenEX.dll has been added to excel generating random crashes.

Due to a fall down in documentation there is no record of where this Dll came from. This Dll has been included in the last twenty images and it’s unclear who needs it….

A: FUUUUUUUUUU…

Scenario B:

After a recent purge and merge of layers to the master golden image, the Super Calculation 1 application requires an upgrade to version 2. During upgrade testing it is found that this application requires an un-installation of version 1 before installing version 2

The uninstallation fails and cannot be completed. No golden image stored contains an image before Super calculation 1 was installed. The support vendor cannot assist as they insist a reinstall is required.

A: FUUUUUUUUU…

Scenario C: Roughly a year ago, a new piece of software (Craptastic app) was purchased by the Finance team. A consultant was employed to assist the administration team in deploying the software, due to a communication error between project manager and the consultant no documentation or source files were provided on how to install the application.

The administrator involved has since been fired for stealing pens.

Finance are performing end of year calculations and a seldom used part of Craptastic app is no longer working, it worked last year when they performed closing statements but this year it errors out. At some point you realise an ODBC connection was removed from your image but you are not sure which image contains the correct one. You have 20 images, one or none of which may contain the right value.

The software vendor’s is closed early for a christmas party. They wont be back till Monday, you wont have a job on Monday.

This issue needs to be fixed yesterday.

A: FUUUUUUUUUU……

Andrew, you’re being a pedantic, paranoid, eejit.

Maybe, but I’d rather be the above than suffer a major loss of face, or loss of job from the wrong recommendation!

I’d really be interested in your real world experiences in similar scenarios to the above;

  • How do you enforce documentation and change management?
  • Do you need to regularly police these kinds of changes?
  • Do you share these concerns?
  • Is a certain amount of trust (or faith) in administrators required?

Configuring Citrix CloudGateway Express / Storefront services 1.1 for native SQL authentication.

One of my quibbles with Cloud Gateway is the database connection method. By default (and as per the edocs) CloudGateway Express will attempt to connect to the backed SQL database as the computer account on which Storefront services is running.

Citrix recommend you create a local user group on the SQL server and place the computer account in here… Wait.. what?

If you are running an SQL cluster, this will create a bit of a headache, as in a database failover event, the local group may not exist on the node onto which the cluster has failed to. Running into this event first hand, I decided to investigate how to change this connection string to an SQL account.

My first clue, came in the form of the Citrix edocs, with this document here, Citrix describe how to configure database failover for the store service. The connection string is stored in C:inetpubwwwrootCitrix<storename>web.config

Now that we know where the connection string lives, it should simply be a case of modifying this string to suit ourselves!

Open the above file, and search for “DazzleResources.DataSource

Paste in the below, replacing the string and modify the bolded items below:

<add name="DazzleResources.DataSource" connectionString="Integrated Security=SSPI;server=servernameinstance ; Database=cloudgateway ; user id=sa ;Password=Password;Trusted_Connection=False" providerName="System.Data.SqlClient" />

Once complete, restart the Receiver Storefront server. Then open the console again. You should now see the updated connection string (in clear text sadly) on the store:

Thats it!

Note: theres no reason you couldnt use an AD account for this either. But the plain text view of this string sucks to be honest.