Archive

Archive
<May 2012>
SunMonTueWedThuFriSat
293012345
6789101112
13141516171819
20212223242526
272829303112
3456789
Monthly
Go

Search

Pierre's Blog

Author: Created: 8/2/2009 6:11 PM RssIcon
Personal Blog reflecting my insights on Virtual Desktops technologies and misc tech stuff
By Pierre Marmignon on 7/16/2011 4:07 PM

Following a blog post I've made some time ago, Are virtual desktops ready for mass adoption, I wanted to add my contribution to a debate that seems to finally resurge forgetting opposite marketing messages.

Andy Paul (@Andy_Paul_) has made a good overview of the subject in his article published last week To VDI or not VDI, while Stephane Thirion detailed his opinion in a blog post called VDI is overrated.

After reading these two articles, I wanted to write my 2cents on it.

Why not using HVD / VDI for the mainstream? Because of costs !

Even if I love the TVO (True Value of Ownership) concept, I have to say that when I'm designing a solution for task workers, costs are still driving the choice between VDI and Not VDI.

For my customers, this true value of ownership concept does exist, but not for task workers, only for executives and / or VIPs.

Infrastructure costs

Extra costs are bound to infrastructure (storage, hardware ...) but also to management, the one that are the most hidden, the most difficult to estimate but the one that can be the highest.

All major virtual desktops and infrastructure vendors are working on lowering (or trying to lower) infrastructure costs, like Citrix with the implementation of MCS, but it's not enough to make customers massively adopting this model.

Why? Because along with the storage cost, the scalability point has to be mentionned as it is a big disadvantage for HVD / VDI.

Even if you can read incredible ratios between cores and VMs, the reality is not as pretty if you look into the performances of the provided virtual desktops and the memory footprint required for each single Windows 7 instance running in a VM.

HVD / VDI Management costs are underrated

Plus, the management side is still a place where major vendors are not, relying on ecosystem partners, which can do a very good job but are still an extra cost in the model.

My question to VDI / HVD supporters : Do you really think that customers really want to switch from managing thousands of desktops remotely to managing them centrally in the datacenter as thousands (virtual) machines?

By Pierre Marmignon on 6/26/2011 7:05 PM

Introduction

I've decided to write this blog post because I've read some blog posts around the web talking about XenApp / XenDesktop automation, explaining how to, with a little script, automate the setup part of the deployment.

While these posts are great and useful, they're hiding the real complexity of building a fully automated XenApp / XenDesktop deployment.

That's why I've decided to write this post explaining, in my opinion, what a real automated deployment is and how it could be difficult to build.

I've been working on automating XenApp since the old Metaframe XP Time, first with small batch scripts then with more intelligent scripts.

My goal has always been to automate the whole product deployment, not only to care about getting consistency on large deployments, but also to have a consistent an reliable deployment method embedding all well known best practices and methods.

That's how it started and how I went to tools development to then automate configuration settings and administrative tasks.

I've started this project, called "Project Andromeda", 8 years ago, aiming to provide a zero touch XenApp (then XenDesktop) deployment.

In 8 years, Project Andromeda has evolved and is now composed of many subprojects like the well known XenApp Cloning Tool or XenApp Sessions Cleaner.

The subproject handling the automated deployments is called EasyFit (subject to change) and manages to provide a zero touch Virtual Desktops (XenApp / XenDesktop) best practices environment ...

By Pierre Marmignon on 12/31/2010 2:00 PM

I'm working a lot with XenApp 6 Policies and C# to automate XenApp Best Practices / Tuned Configuration as default policies.

First I started with dealing only with settings I needed and the more I've worked on it, the more I felt like a wrapper would be a must !

Why ? First because for each setting, a powershell invoke is needed.

Then because of all settings, it's not easy to remember all of them, their states and values (a state can have 3 different kinds of values, and lots of objects do have their own type enums which are not documented in the SDK Help ...).

That's how a policy setting looks when configured through a dedicated function embedded in a new edition of the XA 6 Policies helper I'm coding :

 To Set Settings :

public bool SetIcaListenerTimeout(String strCompPolName, XAPolicyObjectType.XAPolicySettingState3 sSettingState)
        {
            bool ret = true;
 
            try
            {
                ps.AddCommand("Set-Location").AddArgument(PolicyDriveRoot + "Computer" + @"\" + strCompPolName + @"\" + "Settings" + @"\" + "ICA");
                ps.Invoke();
                ps.Commands.Clear();
 
                ps.AddCommand("Set-ItemProperty").AddArgument("IcaListenerTimeout").AddParameter("Name", "State").AddParameter("Value", sSettingState.ToString());
                ps.Invoke();
                ps.Commands.Clear();
 
            }
            catch (PSSnapInException ex)
            {
                //throw;
                ret = false;
           }
            finally
            {
                ps.Commands.Clear();
            }
 
            return ret;
        }
 
        public bool SetIcaListenerTimeout(String strCompPolName, int icaTimeOut)
        {
            bool ret = true;
 
            try
            {
                ps.AddCommand("Set-Location").AddArgument(PolicyDriveRoot + "Computer" + @"\" + strCompPolName + @"\" + "Settings" + @"\" + "ICA");
                ps.Invoke();
                ps.Commands.Clear();
 
                ps.AddCommand("Set-ItemProperty").AddArgument("IcaListenerTimeout").AddParameter("Name", "Value").AddParameter("Value", icaTimeOut);
                ps.Invoke();
                ps.Commands.Clear();
            }
            catch (PSSnapInException ex)
            {
                //throw;
                ret = false;
            }
            finally
            {
                ps.Commands.Clear();
            }
 
            return ret;
        }
 

...

By Pierre Marmignon on 12/9/2010 9:33 PM

Following my way through the XenApp 6.0 SDK and more especially with policies, I've had to write functions to create and delete policies objects.

My first tests were successfull but my tools were facing Sync issues with the Citrix Delivery Center Console : actually it looked like the tools and the console were overriding each other.

To overcome this issue (Thanks Felipe !), I've had to play with the policy ...

By Pierre Marmignon on 11/25/2010 9:32 AM

Working on XenApp 6.0 SDK (Yes for tools updates !) I've had to deal with the Citrix Group Policies Provider.

While working on it, I've noticed that this module is really CPU intensive because of all the Powershell drives creation process.

To optimize tools using this feature, the best way I've found is to load it only once for all child requests.

To do so, calling it from a class constructor is the best approach ...

By Pierre Marmignon on 11/25/2010 9:23 AM

As a XenApp / XenDesktop user, I've sometimes faced some clipboard issues while using copy / paste between local and remote applications / desktops.

This can be really annoying while you're working and can't just copy and paste the content of some documents.

While trying to investigate on this issue I found that in most cases it was a local clipboard problem and I've looked for some tips to be able to handle it without having to close my remote session and open it again ...

By Pierre Marmignon on 12/15/2009 11:18 PM

This blog post title can look a little agressive but that's intended

Why ? Simply because this post is my 2 cents regarding the marketing vs technical thing and reflects my feedback from the "trenches".

I'm now working with Citrix products for years and I've followed the move from Winframe to Metaframe then Presentation server, Access Suite and Now XenApp / XenDesktop Platinum.

Every new product release (mainly XenApp) was really expected because it was adding lots of highly requested features.

Unfortunately, starting with XenApp 5.0 for Windows 2008, even if new features were added, some (very important ones) were removed without notice although I did not see many articles / posts about it.

The fact is that XenApp 5.0 for Windows 2008 is not that much deployed and regarding my customers that's mainly because of these features removal.

Which Features ? : I'm thinking of Installation Manager, Application Isolation, Resource Manager and some other ones.

Let's now take the marketing answers and my comments ...

By Pierre Marmignon on 11/11/2009 5:53 PM

Following my experience, discussions with customers, other partners and CTPs, I've decided to write this blog post reflecting my thoughts about the "Virtual Desktop" buzz and the fact that for almost all vendors this is the place to go regarding the future of Desktop Computers, and moreover this is the place to go NOW.

At first glance, I'd say that the "Virtual" term does not apply really well to what the companies are really expecting from a new way of managing desktop computers, it's a good term for marketing things but not reflecting the reality of desktops, let me explain :

From the Datacenter to the Desktops

For the last years companies have moved to the server virtualisation solutions aiming to optimize their servers management and decrease costs by consolidating their infrastructure while rationalizing their deployments and management processes.

Servers virtualization solutions are now mature, but the thing that we should not forget is that even if we have more and more customers using them, they "only" represent 40.85% of the actual market (Forrester) and are supposed to hit the 60% within two years.

After optimizing their datacenters (servers) costs, IT departments are now looking for new costs centers to optimize them. This move has naturally led them to work on the Desktops side, a side they've "neglected" for years.

Why ? First because of the vendors marketing buzz, amplified by the economic crisis. These new constraints have quite "forced" IT departments to have a look at a question they had like "forgotten" : How much do my desktops cost ?

And that's not an easy question, because for some of my customers the answer is still based on the hardware cost only !

Many IT departments still do not have any figures reflecting the real cost of their distributed computing architecture and even if this is now changing, this will take time (also because these kind of figures may be kept hidden because they could be "bad").

The "Virtual" Desktop term is answering (from a marketing point of view) to all goals IT Department are trying to aim regarding their Desktops in the future, because it seems logic for them to optimize Desktops like they've done on datacenters : "optimize management and decrease costs by consolidating their infrastructure while rationalizing their deployments and management processes" .

However, from a technical point of view, I'd prefer the "Centralized" term to reflect the Desktop reality, instead of the "Virtual" one.

Why ? Because the Desktops world is far away too complex to summarize it to only one solution like Pooled Desktops running within VMs in the datacenter, just like it was (and is) possible for servers ...
 

 

By Pierre Marmignon on 10/18/2009 9:55 PM

Working on a tool I had to face the specific case of writing large integers into a REG_DWORD value.

The problem is that basically you cannot write anything superior to the Integer.MaxValue() object in a DWORD value using the .Net Managed APIs Registry.SetValue(), which can be problematic (in my case that was for XenApp DefaultPRNFlags and I really need to be able to write these settings down).

To overcome this issue ...

By Pierre Marmignon on 10/16/2009 1:50 PM

Following my First Blog Post regarding this subject we've been able to work on this issue with both Microsoft and Citrix support.

To find an alternative to the workaround mentionned in the first article, we did some tests and found that the issue could be stopped by disabling ...