nickholmquist.com

So last month I did a comparison test with MFCOM vs the new XenApp cmdlets.  My intention was simply to see if the cmdlets had the same (or any) performance issues that plagued MFCOM.  The results initially shocked me since MFCOM in VbScript seemed to be faster (albeit marginally) than the cmdlets.  After posting my results one of the developers of the cmdlets made a comment that my testing method was off.

LoadData loads the app specific data (according to the app type), not its associations, which are more expensive to read (accounts, servers, etc).
This is why I suggested to compare it to Get-XAApplication. – Felipe Leon

I had always been under the impression that LoadData() pulled backed all information about the application including Servers, Users/Groups.  So I did a few tests and realized that I was completely wrong.  When throwing a few for..next loops in to enumerate servers,users and groups the MFCOM time shot up by at least 10-15 seconds.

Felipe also suggest comparing LoadData() vs the Get-XAApplication cmdlet instead of Get-XAApplicationReport since the former does not make a call to obtain servers,users/groups.

Using this method the cmdlet obtained most properties on 100 applications in about 1-2 seconds..That’s FAST.  On the flip side using MFCOM to enumerate the same application set (100) WITHOUT using LoadData() still takes roughly 5-6 seconds.  There are a number of properties that are readable without using LoaData() but I have yet compared those to Get-XAApplication properties.

I plan to do more in depth testing when I have some additional free time but I wanted to post an update to show that my initial results appear to be wrong. As I stated in my previous post the cmdlets easily win for simplicity and ease of use but in my opinion until Powershell V2 is released (not as a CTP) and brings WinRM with it I think MFCOM is still the winner for multi-farm management.  Maybe by the time the XA cmdlets go out of  Tech Preview phase, Powershell V2 will as well?!

MFCOM, Tech

So my last post talked about how much the Citrix developer community site has changed since I started using Citrix products.  What is funny is I had completely forgotten about a site I was creating (MFCOMScripting.com – July 2007) before I knew about the Community site Citrix was working on (I think November or so of 2007 is when it debuted).

The goal was to create a site that would contain code examples for each individual object/property that is accessible via MFCOM.  I have always liked the simplicity of DevGuru.com and how they give clear and precicise examples and thought that would translate to making MFCOM easy to use.  I had hoped to include the most popular languages in the examples and obviously accept user submissions for example code.  I also had ideas for a code repository for community donated code, a wiki for ’super scripts’ (when I was more VBScript focused) and a few other little ideas.

Of course as I was working on this as Citrix released their community page and my site seemed unoriginal and pointless.  Therefore it has been sitting dormant.

I only bring this up since I happened to be looking at the list of my domains and realized how easy it is to forget things in the midst of how busy most of us in the IT field are.

MFCOM

So I have tried creating a few videos for a while. I always ended up screwing up in the middle and in a spot that isn’t easily edited out and replaced. So I tried to do it again tonight and while it didn’t come out perfect or even ‘good’ by most standards it is nevertheless there.

It’s a quick and dirty video and next time I will spend more time getting a better quality audio, first time is always practice, right?

Uploaded at utipu.com: http://citrix.utipu.com/app/tip/id/3346

MFCOM

I took some time to create a basic guide on how to configure DCOM permissions for use with MFCOM.

When I first started using MFCOM I found it somewhat confusing to get DCOM permissions straight. This was probably more about not understanding the details of DCOM more than it was MFCOM. Usually if an administrator was running the script/application I had no problems. It was when an elevated user would run the app that I would have the issues.

Over time I began to identify exactly where the permission errors were and found a good system for keeping permissions in line. While the document is written with step by step instructions that most administrators already know, I thought it would be beneficial to detail for those who may be in the same position I was years ago: Confused by DCOM.

The document could be written much better and is absolutely a work in progress.

Any feedback is appreciated.

AdministratorsViewPoint_ConfiguringDCOM.pdf

MFCOM