PackageDeploy.com

I was on the repackaging of Skype 3.2.0.175 in the last week. In fact there is nothing much to do with it if the Automatic proxy detection works. But unfortunately in my network Skype seems unable to extract the proxy settings from Internet explorer. This made thing worse and helped me to learn a lot about the deployment of files in to user profiles!

The Repackaging Style
For a normal network we can easily use the Business version ( MSI release) of the latest Skype. Thsi can be downloaded from here. It has got three features. The main app, Plugin for IE and Plugin for Firefox. The msi is a bit complex with few custom actions to detect firefox and IE. As per my organization’s standards the browser plugins need to be removed from the final release. Also on validaion with Orca the msi is having a lot of ICE errors, most of them cannot be fixed. This leaves me with an option to create an msi using Wise setup capture.

The Development and problems with the shared.xml file

As I have mentioned already skype fails to auto detect the proxy settings which makes the deployment complex. On investigation I found out that the settings are getting saved in the shared.xml file in the path %USERPROFILE%\Application Data\Skype . What i need to do is let the customer set the proxy settings ( which will be different from site to site) and make the shared.xml file populated to each and every user’s profiles. Hmm.. This means i need to create the msi in uncompressed form so that the shared.xml file of the package can be edited from client site to site.

For populating a file to individual user’s profile we have a few options.

Advertsize the file directly to user profiles: But since the msi is having uncompressed files the self healing requires access to the source files in the network drive. Thus for restricted users having no access permissions in the packages network drive, the self healing won’t work.

Use active setup:Active setup can be used to run a script or bat file when a user logs in for the first time. We can write a script/Bat file to copy the file from the Program Files folder to the user profile. The only problem is active setup will work only once per user. ie. Once a user logs in windows will compare the active setup entry in the HK Local Machine and those in HK Current User. Once it find a new entry in HKLM the stubpath entry ( our script/bat file) will be invoked and an HKCU entry will be added. This makes the changing of the network settings impossible if we use active setup.

Using Duplicate files Table: It’s the best method for deploying a file to the userprofiles. This can be done by adding the file in the msi in to some where in the C:\ drive and creating a duplicate file entry for this entry with the destination path to the user profile. The component of the duplicate file entry should be in the current user feature which in turn needs to be advertised. Here also we are having a problem with changing the connection settings and re-deploying the app. ie. for the component holding the duplicate files entry we need to set a dummy HKCU entry as the keypath. But since it’s an HKCU entry it won’t be get removed while uninstalling the app. NO we changed the network settings and reinstalled the app. For an existing user the keypath HKCU key is already there which makes the self healing won’t run at all, which means we failed to re-deliver the updated settings.

Solution! At last – A dirty one though!

Ok.. At last I found a work-around. Skype is not having any options to set the ath of the shared.xml file. But when i tried putting that file in the path %AllUsersProfile%\Application Data\Skype Skype showed a strange behavior! It moved ( Not copying) the shared.xml file to the currently logged in users profile. Damn.. If this was a copy action instead of a move it’ll be easy. So at last here is what I did for the final release.

1. The shared.xml file is added to the folder %AllUsersProfile%\Application Data\Skype and the msi is created in uncompressed form so that in the client site that file can be replaced with a customized one.

2. The %AllUsersProfile%\Application Data\Skype\shared.xml is advertized and the folder %AllUsersProfile%\Application Data\Skype will be given a modify permissions to all users.

3. When a new user invokes the app Skype will move the shared.xml file to the user’s profile and read the customized settings. Now the user closes the app and invokes it again (though the advertised shortcut) the self healing will heal the %AllUsersProfile%\Application Data\Skype\shared.xml file.

4. For changing the settings the admin needs to remove the shared.xml file from all the user’s profiles, replace the existing file in the package and re-deploy it.

This works but needs some action from the sysadmin’s side for changing the settings.

A word to Skype Developers!

I have contacted the skype support with the details of my problem and asked them about any option to configure the path of the shared.xml file. All I got is a reply with one sentence.

Are you trying to modify the skype core code?

Hell no! I replied. Still no word from there end. The thread i have posted in their forums is also left unanswered.

So what you guys at Skype can do to make the app a little more deployment friendly. Add a settings registry entry on a config file to set the path for the shared.xml file. If there is anything like this i can keep that file in a network drive and keep a common connection settings for all computers and users. If you make such a change you may need to add another file in the user profile to save the skype user details, which is currently getting appended to the shared.xml file itself!

Or at least copy the shared.xml from %AllUsersProfile%\Application Data\Skype\ to the user profile, instead of a move.

Thank God.. I’ve finished it!!

Deploying K-Lite Codec Pack

Deploying Google Earth 4.3 – Finding the MSI

About

Deploying Security updates for MS Office XP and MS Office 2003 – No Uninstall Option?

Repackaging Google Earth 4.1.7087 : The Wise Setup Capturing & MST stories