02/8/13

Application Virtualization Smackdown

I am very pleased and proud, that in the past few months I got to collaborate with Ruben Spruijt, Jurjen van Leeuwen and other leading Industry experts in producing the 2013 Application Virtualization Smackdown. It was great working with these guys and I am humbled to have my name on this document. I hope others find the information useful.

Download HERE

Article about this on BrianMadden.com

Thanks to all involved!

11/2/12

How to: Disable Initial Welcome Screen in Lync 2010 via the Registry

So if you’ve deployed or installed Lync 2010 the expected behavior on first launch is to be greeted with a nice Silverlight driven welcome screen or tutorial or whatever you’d like to call it. A couple of my colleagues and I took a look at disabling this today. We had expected this to be straight forward, it turned out a little more complicated than expected.

Our problem was a two part problem.

1.) Disable the Welcome Screen on desktops and laptops. We found a plethora of suggestions online, most of which did not work. After trying combinations of the suggested fixes we rolled up our sleeves and started doing our own investigation. We found one HKCU registry which controlled this. So if you set the reg, the Welcome screen will not appear. That Registry entry is as follows:

[HKEY_CURRENT_USER\Software\Microsoft\Communicator]

“FirstRunPlayed”=dword:00000001

2.) Disable the Welcome Screen on Citrix Terminal Servers. So we also found that when installed on our Citrix Terminal Servers, even after the initial launch, if we closed the application out and opened it again the damn Welcome screen appeared on each launch. This is because in Citrix environments certain HKCU registry should get re-directed to a shadow registry hive. We went to this path and found the registry did not get set there and thus it was not found on App launch and each time the Welcome screen appeared. To fix this we set the following registry on our Citrix Terminal Servers:
[HKEY_LOCAL_MACHINE\SOFTWARE\

Microsoft\Windows NT\CurrentVersion\Terminal Server\Install\Software\Microsoft\Communicator]
“FirstRunPlayed”=dword:00000001
10/9/12

App-V Decision Matrix v2

A year ago this month I posted a decision matrix I put together listing some of the common issues when trying to sequence applications, it can be seen HERE. I gathered some feedback in the comments. I appreciate all the feedback I can get here. I have since updated the matrix to include the feedback and I also made it look slightly better. Let’s face it, it still looks like a smacked arse! A new addition here though is the fact I included Citrix as a possible end point. I figure it will be relevant to a lot more people out there now. So Again. Any feedback. Please let me know. You’ll need to click on it to enlarge. It got bigger!

All of these considerations listed are based on 4.6SP1 and do not account for the cool new features in App-V 5.0. Some of those features included extended support for Shell extensions\Context Menus, Improved handling for COM objects, Increased File Size Limits etc.

So firstly once again the detail behind each limitation:

Hardcoded licensing. What I mean by this is the kind of licensing that is configured to the machines MAC address. In this instance the licensing can live only for that machine and is not a good candidate to be sequenced.

Middleware. You are free to sequence middleware and then subsequently dynamically suite the middleware with the dependent applications, however you should be aware. If an application you have cannot be sequenced and needs a certain piece of middleware that you decided to sequence all of a sudden you are in a situation in which this app now needs the middleware installed on the local machine because the virtualized middleware is isolated and cannot be seen. My personal preference is to install all shared middleware onto the local machine, any middleware that is a once off or only used by a handful of apps that CAN be sequenced can then be sequenced to accomodate those apps.

Boot Time Services appear in some applications and as per the explanation for Shell extensions APP-V applications exist session based. You could try to see if it’s acceptable for your application to only work on launch and then reconfigure the service to start on launch rather than on startup. Another possibility is to configure the service to start on launch and setup an action to startup the virtual application. I wouldn’t do that though, it does work and I’ve done it before but I don’t like the idea of doing that for performance reasons.

Continue reading