// This is the script to give summary on the main page.
Think IPM

Wednesday, July 16, 2014

Some VDI Myths and a PDF!

A couple of weeks ago, I had the opportunity to help present at a Goldman Sachs’ hedge fund event with my CIO, Phil Alberta.  The event brought together about 70- or so CIO/CTOs from various hedge funds that Goldman does business with.  We ran a breakout workshop that spoke about and worked through challenges and some of the decisions involved in a VDI project/deployment.

image 

We ran 3 very interactive sessions and here were some the takeaways we got from the audience (via a show of hands) that I thought were interesting:

  • Almost ALL of the firms were already running a version of Citrix XenApp.
  • All except a single hand were running VMware vSphere as a hypervisor (The lone hand belonged to a Microsoft Hyper-V implementation).
  • It was about a 60/40 split between Citrix XenDesktop and VMware View implementations.

I was actually surprised to see so many View installs with the level of XenApp penetration already in the crowd.  I’ve normally thought that once in bed with Citrix XA, Netscalers, Web Interface etc… XenDesktop becomes the natural progression for most clients.

As a takeaway for the audience, Phil put together a high level list of some of the VDI myths he has come across while talking with clients and engineers alike.  His presentation (which I will try to get him to link via SlideShare) was built around confronting and knocking down a lot of these myths.

You can read the ‘Myth’ paper here.

Click Here to Continue Reading >>

Monday, July 14, 2014

Installing the Citrix Provisioning Services Console on XenApp

-- Great How to by Jacques Bensimon:

First, why would you want to do that?

Well, besides the obvious ability to manage your Provisioning environment directly from your XenApp servers without having to remote into your PVS servers, installing the console also installs the PVS MCLI.exe command line tool and the MCLIPSSnapin PowerShell snap-in that provides a number of PVS-related cmdlets.  This opens up the potential for all sorts of automation ideas, including a server assigning itself a different vDisk (under whatever circumstances you decide) and restarting itself to run that image.  Let your imagination soar!

Okay then, what’s the issue?

The PVS console (MMC snap-in) wants to run under the .NET Framework v4.0, and takes steps via a .config file and a couple of Registry entries to force the use of that Framework both by the Microsoft Management Console mmc.exe (when it must load a .NET-based snap-in) and to some extent by other .NET assemblies installed on the machine, with unpredictable results.  At the very least, it will cause an ugly error message when starting the XenApp console (I believe AppCenter is its name this week, at least in XA 6.5) because one of its components (the Single Sign-on piece) is designed to run under the .NET Framework v2.0, but that’s probably the least of the issues it could potentially cause with other consoles and apps.

So, is there a solution?

I’m insulted you’d even ask that question! J  Here’s what you can do on your XenApp image:

1.       Install the (x64) PVS console.

2.      Copy mmc.exe and the (newly added) mmc.exe.config from %SystemRoot%\System32 to the installed PVS console folder.

3.      Also copy "en-us\mmc.exe.mui" from System32 to the same folder (in a new "en-us" folder).

4.     *Delete* mmc.exe.config from System32!

5.      *Delete* the (newly added) "OnlyUseLatestCLR" entries from "HKLM\SOFTWARE\Microsoft\.NETFramework" *and* from the same Wow6432Node subkey!

6.      Change the PVS console shortcut to explicitly specify the use of the "mmc.exe" copy in the installed PVS console folder.

Then what?

1.       To configure MCLI.exe for remote script execution (after installation of the PVS Console), run:

MCLI.exe run setupconnection -p server=pvs_server_name port=54321

This will create the following Registry entries:

[HKEY_LOCAL_MACHINE\SOFTWARE\Citrix\ProvisioningServices\Mcli]

"Server"="pvs_server_name"

"Port"="54321"

"User"=""

2.      To register the PVS PowerShell snap-in, run:

%SystemRoot%\Microsoft.NET\Framework64\v2.0.50727\installutil.exe "%ProgramFiles%\Citrix\Provisioning Services Console\McliPSSnapIn.dll"

To set up a connection to your PVS farm within PowerShell (to remotely execute all subsequent PVS cmdlets against the specified server), use the MCLI-Run cmdlet as follows:

MCLI-Run setupconnection -p server= pvs_server_name,port=54321

That’s it!  (Note that all of the above applies equally to any non-PVS machine on which you wish to install the PVS console and execute remote PVS commands via either MCLI.exe or the equivalent PowerShell snap-in, not just to XenApp).

Later,
Jacques

Click Here to Continue Reading >>