Category Archives: MSI Packaging

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 →

02/6/12

Work Around for “You must run setup.exe” Issue

I’ve gone back to my roots this week with doing a lot more MSI work than I have had to do in a while. I noticed that a few applications I had to package presented with a common issue that to me at least, didn’t seem too common a few years ago. That issue is that after extracting the Vendor MSI from my setup.exe, it would not allow me to run the MSI to install the application. The MSI was conditioned to only run when using the setup.exe.

 

 

 

 

After further investigation I found the setup.exe in question appeared to be used to install Installscript as a pre-requisite if required. I already had Installscript on my machine so it shouldn’t have been an issue for me to install the MSI but thanks to that requirement I wasn’t able to. So I looked in my MSI and found the following in the custom actions and sequences. It appeared to be checking for a property that didn’t exist and if it didn’t exist, it would not allow the installation to continue with the MSI. Basically hard coding the MSI so that a user could never install it manually and could only install using the setup.exe

 

So to get around this issue I simply set the property ISSETUPDRIVEN in the properties table of an MST I created. And set it’s value to 1. When I carried out the install again, it worked no problem. In this instance it was obvious to me that the pre-req was Installscript and I knew this was not an issue for me. You should be aware that in some cases you may not be so lucky and so you should thoroughly investigate exactly what the setup.exe is doing before attempting to work around this MSI issue. Try analyzing an install of the setup.exe and then compare to the install of your MSI and MST with the property set. Good Luck!