Like me you may need to deploy Fonts in your Enterpise network via Active Directory.

In past we have seen some tools on the net that made this Font installation an easy task, but all of them have faded away or have been commerialized with questionable feature lists in basic payed version. It took me an unacceptable hard time to find the way to go as the search results give tons of bad results and none of these tools around is really easy to use. I wished I would have found a GUI tool that works like drag and drop, browse registry and other stuff to create at least easy type setups, but this seems only to be a very big wish. After some weeks with MSI and WiX I understand more and more that such a tool cannot be easy - except it would be very limited in functionality and what is more worse than using 5 tools in a long term view? In a small world you may only need a Font installer, but later you need much more and it's better to learn MSI and WiX the hard way. You cannot get around if you need to deploy software in daily business.

Multilingual user interface (MUI) setups are really common in todays world. Mostly seen with NSIS setups. If your software is multilingual you don't need to maintain tons of setups (aka - one MSI for every language). Nevertheless the below is officially not supported by Microsoft, it's possible and widly used - also by Microsoft. The most popular software I came across in the last days is Apples Safari 5.x browser. I'm sure if you search more, you will find much more setups.

See Available Language Packs for the available LangID's and cultures.

How are the multilingual user interface MSIs created?

Everytime I need to install Microsoft Orca for editing and/or reviewing MSI files or to create transforms (.MST), I'm searching again where Microsoft have hidden this tool... :-) If you do not like Orca you can also use InstEdit. In opposite of some comments on the Internet; Orca is not gone and it's still downloadable!

Required:

If you are running a ShoreTel System (at least in Germany or Switzerland) and you have some people forwarding calls to external phones like mobile phones and/or land lines. They may not see the incomming caller ID on their external device. They will only see your system default PRI caller ID. This is very bad if these guys miss the call, they cannot call back.

This behavior can be changed since 11.x with a registry hack and since 11.2 it has been integrated much better into the system, but it does not exists by default and leaves you in the rain; if you are not aware of this feature. Until today these settings are not documented in the public.

UPDATE 01/20/2012: We rolled back all below settings, after we have been migrated from Nokia to Siemens EWSD and are now using a Custom Trunk Group Dialing Rule with a value of ;3E only.

In previous 11.x builds this was done by appending a registry hack flip_rnie 0:

If you are installing a CommCell Console GUI on your Administrator PC it normally download and installs all patches from the CommCell Server to the client. You do not need to do anything manually, but with this bug these feature is more or less broken.

Symptoms:

• CommCell Console GUI 9.x SP3 is not installing patches at all.
• CommCell Console GUI starts up and update dialog is shown. After you press Yes for installing the patches, nothing at all happens and patches are not installed.

Reason:

• Upgrade logs complain about some missing dependencies that are not fullfilled. Looks like the patch references table on CommCell is broken again and missing required references.

Solution:

• Upgrade your CommCell from SP3 to SP3a

History:

Checking JRE can be done with below code. I found this on the net, but it failed for me with WixUI_FeatureTree and WixUI_Mondo setup interfaces. The problem was that the condition has not checked on install only. Therefore I got the condition message also if I tried to modify features and this blocked me from changing installed features. The added Installed OR makes sure this condition is only checked on the very first install and not later. It would otherwise cause serious issues for the user if the application should be removed after the JRE has been uninstalled, but your application not before.

Sometimes applications are creating files after an MSI installation has completed that are therefore not visible to the MSI setup. These files may need to be removed before install or at least on uninstall to free up disk space and for other cleanup reasons. In WiX Toolkit 3.6 and later there is a new feature named RemoveFolderEx to solve this problem very easily.

In case that you install or uninstall an application you are able to recursively remove directories without writing strange CustomActions for this task. For install I'm using it to upgrade from a manual "copy" type installation to an MSI version. It's also a must if you do not have any idea about the file names created in the application directories or simply for files left behind for unknown reasons. There are a few requirements if you'd like to use the tag in your WXS scripts.

If you create MSI setups with WiX Toolkit you should be aware that tags in your .WXS file will cause your resulting MSI file to grow by the size of EXE file linked in SourceFile attribute.

Don't do this:

<icon id="example.ico" sourcefile="SourceDir\MyApp.EXE" />

Always use small .ICO files.

If you are running Simpana 9.0 SP2a and you backup Windows 2003 servers they are no longer backed up after you have installed SP2a. There is no notice or warning at all. You will not get an email if the job has failed to backup your data. Hopefully you have no data loss before you came aware of this bug...

Symtoms:

• Windows 2003 machines are not backed up. Windows 2008 or Windows R2 is not affected.
• Alert system does not notify you about the data backup failure.
• It does not matter if you use VSS or not.
• It does not matter if you have selected some files or all files for backup.
• Only the Commvault Jobs folder and SystemState is backed up.

Solution:

Commvault has an Exchange public folder archiver and you are running it to get your public folder store size reduced.

If you are running Simpana 8.0 you should be aware that all written public Commvault documentation has told by fault that Exchange 2010 is suppported, but it wasn't. This wrong documenation was public until Oktober 2010 and has been removed in a "cloak-and-dagger operation" with my support call. We banged on this migration wall while moving from Exchange 2003 to 2010 and have been made by Commvault to wait for Simpana 9.0 SP1 that came available in mid January 2011. Because of so many bugs in the product we have been made waiting until mid May 2011 (SP2). You may be working with Exchange 2010 since November 2009 and you may have just waited for Exchange 2010 SP1 that has been released in June 2010 to get a more stable Exchange 2010 and to finish migration.