Conversations from the MVP Summit: PowerShelling Citrix and Terminal Server login scripts?

I'm at the MVP Summit this week. I was eating lunch the other day with Steve Greenberg, Benny Tritsch, and Tim Mangan.

I'm at the MVP Summit this week. I was eating lunch the other day with Steve Greenberg, Benny Tritsch, and Tim Mangan. We got to talking about how all these "application frameworks" (Java, .NET Framework, Silverlight, etc.) have to load in every user session on a Terminal Server and how slow that is. (And how ultimately, as more apps are written in these ways, some of the "user density" advantages of Terminal Server versus VDI will disappear... But that's a topic for another day.)

We got onto this topic because I mentioned that a student in our 5-day Citrix Master class in Ausralia a few weeks ago told of doing the "right" thing. He said that he had taken the time to learn PowerShell and rewrote all of his VBS Citrix login scripts in PowerShell. The result? Login times went from about 2.5 seconds to over 15 seconds per user!

This is because PowerShell requires the .NET Framework. On a Terminal Server, the .NET Framework has to load in every user session. So not only does this produce a login delay as it loads the framework in each session, it is also very inefficient.

As a quick aside, during this conversation, Tim asked, "What? Powershell requires the .NET Framework? Then how does it work on Windows 2008 Server Core? (Since Server Core doesn't support .NET.)"

Benny's response: "It doesn't."

Join the conversation


Send me notifications when other members comment.

Please create a username to comment.


@Tim - How quickly you've forgotten about the PowerShell SoftGrid package I created while in your training class.  I explicitly left .NET out of the sequence as I always prefer it to be a core installed component.  Especially since there's little app conflict in the .NET Framework world.

@All - Regarding Server Core and PowerShell, this topic has been discussed quite a bit in the PowerShell community.  There has been rumors that Microsoft would include some compact/micro .NET Framework into server core that would allow things like PowerShell to work (considering that PowerShell only requires a small portion of the entire .NET Framework to function).  As far as what you'll do to manage Server Core if they don't make PowerShell available, you can still use WMI/ADSI for remote management.  I'm personally hoping that a micro .NET will be made available in server core, that way you can configure WinRM and use PowerShell 2.0 to remote script execution via SOAP.  Good times indeed.


So what's wrong with vbscipts?  It does the Job, it's easy to learn and it's much faster and more powerful than PowerShell.

VBS does the job, no doubt about that, also the speed... well, this article proves that VBS is indeed faster.
The learning curve, VBS has loads of resources on the internet, while PowerShell isn't here that long (so less resources than VBS). I didn't find it that hard to learn, it's fairly straight-forware.

But about the power... I think PowerShell is much more powerfull than VBS. The weakness of PowerShell, is also a big advantage: the .Net FrameWork.

Just my $0.02 :)


No doubt that VBS is faster than PoSH, so translating is not really an option (if it comes to user-experience).

But I'm very interested how Group Policy Preferences stand up if it comes to speed. The learning curve is much less steep than VBS. The main disadvantage of GPP is compatibility to older systems.


Here's my .02.  VBSScript is not easier to learn than powershell.  It's also not more powerful than PowerShell.  The only advantages that VBS has over PowerShell are this:

1) It's been around for many more years.

2) It's build in to every copy of Windows since what 95-ish?

3) It's pretty closely based on Visual Basic which is probably the most popular dev language in the Microsoft realm.

4) It runs scripts faster than PowerShell because there isn't as much code under the hood.

Now for the PowerShell pluses:

1) It's extremely powerful.  You have the entire power of the .NET Framework at your disposal.

2) Object pipelining.  You can't touch this with VBS.

3) Simplication of scripts.  I can write in 3 lines what would take someone 30-50 in VBS.  And no I'm not talking about some obfucated, no whitespace, code guru throwdown contest.

Once PowerShell is available on more and more systems and the remoting is supported by WinRM, it's going to take off like wildfire.  On the performance side of the fence, DOS batch is faster than VBS but I still see 50 line VBS app launch scripts that do the equiv of what I can do in 5 lines of DOS batch *sigh*



It's all relative to the task at hand...  You don't use a socket wrench to fix your PC.  You use a screw driver (or baseball bat if it's that far gone).

In this context tho,  why would anyone really NEED access to the .NET Framework during the login process?  To me, using PowerShell in the context of a login script doesn't make sense.  Something like Kix does.

As far as code size.. Again this depends on what your trying to accomplish.  If one language is better suited for a task, of course it may be small in size.  But what are the trade offs?  Mapping a drive in DOS is as simple as a NET USE command, but what happens if the share is unavailable?

I blogged about a stupid statement Microsoft made about the InStrRev command here:

You'll notice that the PowerShell version requires an extra line over the VBscript version.  This is because PowerShell wouldn't let me use the result of one function as part of a calculation for the argument of another function.  Even if I could,  the two lines that use the result would have been more difficult to read than the vbscript.


Since powershell uses the .net framework, can you not compile the scripts to native machine code, just like you could with a .net application the first time it runs on a computer?
Unfortunately, .Net apps do not compile to machine code.  .Net apps compile to an intermediary code called MSIL (Microsoft Intermediate Language).  MSIL is interpreted by the .Net framework.
Actually, .net code can be compiled to machine optimized code. A utility called ngen.exe performs this and is found in the .net framework folder. Take a look for  yourself,
Yes, however for a quick script, no matter if NGened not not, you still have to wait for the .net framework to be loaded.  Powerfull it is, but just a awfull lot of overhead for a simple task.  Both will have their usage.

Not true that PowerShell requires more lines.  Try this.

$PathandFile = "C:\myDirectory\myFile.txt"

Write-Host "Path: " (split-path $Pathandfile)

Write-Host "File: " (split-path -leaf $PathandFile)

Pretty simple and 2 lines of less code too ;)



Cool...  I suppose using Path and File isn't the best choice in this instance, but it's the easiest to relate to.  The original example would still be valid for strings that are not in a PSProvider format.   I'm still curious as to why I could not use the result of one function as part of a calculation for an argument of another function.



Ok, you got me.  Split-path is only relevant for filenames, but you could always rewrite your example like this and it would work for all use cases:

$PathandFile = "C:\MyDirectory\myFile.txt'

$Offset = $PathandFile.lastindexofany("\") + 1

write-host "Path    : " ($PathandFile.Substring(0,$Offset))

write-host "Filename: " ($PathandFile.Substring($Offset, $PathandFile.length - $Offset))