Microsoft Tools

Terminals – Multi Tab Terminal Services

Wouldn’t it be nice to do all the below from one window?

  1. RDP – Microsoft’s Remote Desktop aka Terminal Services
  2. VNC – Virtual Network Computing
  3. VMRC – Virtual Machine Remote Control
  4. RAS – Remote Access Service (VPN, Dialup)
  5. Telnet – Telecommunication Network
  6. SSH – Secure Shell
  7. ICA Citrix – Independent Computing Architecture

Terminals” is a tool which can do all this from a single window. Terminals is a secure, multi tab terminal services/remote desktop client. It uses Terminal Services ActiveX Client (mstscax.dll).  One of my collegue Rajiv, shared this information, this morning.  I am sure you will also like this and will greatly benefit from the same.

All credits to the developers, who have developed this phenomenal tool.

You can Download the software – Here (The current version available is Terminals 1.7e)

Guest Posts Tools Windows Installer, Application Compatibility and Deployments

Create and Distribute MSI software packages using WinINSTALL

From past few days, there was a thought of implementing a guest post section on Msigeek. This was just to bring-in experts from different areas to showcase their expertise and share their knowledge/product with us!!

Well, Let me introduce the author of this post. His name is Scott Drucker and he has been working as a Senior Systems Engineer with Scalable Software. Scalable is a leading innovator in delivering cost-effective IT Asset Lifecycle Management solutions.

Scott has been building software packages with WinINSTALL for over 10 years now. Scott can be reached at sdrucker[at]

Over to Scott’s Article…

How to Create and Distribute MSI software packages using WinINSTALL

As an engineer, I find myself constantly evaluating software. I comb the internet trying to find products for whatever project I may be working on at that time. When it comes to the packaging of custom MSI files or editing of vendor supplied MSI files; I need a product that will give me maximum configurability with the least amount of headaches. Even before I began working for Scalable Software, I had used WinINSTALL to package minor applications for distribution with Active Directory and created transforms for our vendor supplied MSI files.

What I needed was a product that allowed me to do several things. First, I needed to be able to edit the tables of the MSI files directly; without having to use an external editor tool like ORCA. I also needed a product that would allow me to create shortcuts for the applications I created; push out registry keys when necessary; perform ASCII or INI file edits; push out already configured Services that would run with the credentials that I specify and also be able to edit existing MSI files by creating transforms or merge modules.

The snap-shot process was simple. The User Interface was a breeze to use compared to the other products on the market. I took a clean machine, performed a before snap-shot. Installed the setup.exe I wanted to make into an MSI. I customized the software the way I needed to, by creating shortcuts and a couple of TCP/IP connections for our emulation software. Then I ran the after snap-shot. I took a clean machine without the application installed, pushed it down to the machine and it installed like it was supposed. Creating the shortcuts and the TCP.IP connections.

WinINSTALL gave me the ability to perform all of these functions. Now I am not a scripting genius by any means, and for me WinINSTALL was perfect because its geared towards the Desktop Administrator and not the software developer. I looked at numerous products and compared each one to see which product would meet my needs. In the end, WinINSTALL was the wisest choice for me. I was able to take a vendor supplied MSI such as Office and create transforms for the installation, so that each group or department I pushed Office to, would get a different installation. Maybe some departments needed Higher Macro Security set and other departments needed certain options enabled that are out of the scope of a cookie cutter installation. With Adobe, I was able suppress the Eula agreement and disable the Update messages that plague users on a daily basis. I was also able to delete the Adobe Acrobat Reader icon from the Desktop, since in effect, this is a useless icon. WinINSTALL gave me that flexibility. It also allowed me to create Printer MSI installations and edit config files for existing applications not originally packaged with WinINSTALL.

Best of all, and well worth its weight in gold, was the ability to then distribute these applications to my end users. I was able to mass deploy Office 2003 to over 500 users which performed an Upgrade from Office 2000 and set the specific options that my users required.

So the benefit here, is that you can take a Suite product like WinINSTALL’s Desktop Availability Suite or Desktop Management Suite; create your packages with all the customizations necessary and then distribute them from one product. Scalable Software’s WinINSTALL Desktop Availability Suite combines the standard desktop management functions that administrators use for day to day asset management, software packaging and deployment, and patch management; while automating with a Zero-touch methodology, three of the most labor-intensive IT management tasks: PC Refresh, OS Migration, and PC Recovery.

If you already have a distribution process, you can download either the free version of Scalable’s MSI Packager or for your advanced MSI packaging needs, the MSI Packager Professional. You can find all of these products here

Scott’s Thoughts on
“ is a very informative site for any MSI user. You don’t need to be an expert to work with MSI’s, and MSIGeek’s How To’s and Best Practices sections, provide some valuable information to not only newbies but experienced end users. I myself, am very impressed with how well they have been covering the maturity of Windows 7. Way to go guys and keep the information coming!!”

How-to Microsoft Tools

How to Develop an MSI using MSBuild?

This Afternoon, Harish asked me if I had any document on creating MSi Installers with MS-Build. Fortunately / Unfortunately I did not have any, as I have hardly worked on it. 🙂

Thats when it striked my mind and I started pondering over internet and found these fantastic links!! Found it worthwhile, to share the same on Msigeek as well.

7 Steps to MS-Build –
Building a Setup Project in MS-Build –
MSI Schema Explained –
Microsoft Forums –

Other Links –

All Credit to the great Authors who had made these posts on thier blogs.

How-to Microsoft Tools Windows Installer, Application Compatibility and Deployments

Creating your first WiX project

The Wix tools allow you to define the structure of a windows installer package using an XML file. This gives you all of the usual benefits of XML: easy editing with a variety of tools, the ability to modify the files using well-known technologies, and the ability to put the source file under source code control, for ex. the Wix tools themselves are command-line tools, so they fit well with almost any build process. In this post, we will look at creating a WiX project using Visual Studio.

A little note on MSi Engineering
Windows Installer setup package can be described as a three-level hierarchy. The product is at the top of that hierarchy. Users can interact with a Windows Installer setup package at the product level, as during a default or typical install, or they might interact with the setup package at the features level, as during a custom install. Developers, on the other hand, have to interact with the setup package at the component and individual resource level.

Packages are built from components. A component is a group of one or more related resources—files, shortcuts, registry entries, etc.

Components are grouped into features. A feature is a group of one or more components that are installed together. A component can belong to one or more features, but each component is installed only once on a give machine.

Every Windows Installer product, package, and component is identified internally by a unique GUID. The product code GUID remains constant for all releases within the same major version of a product. The package code GUID changes for each build that is released into the wild. The component code GUID changes according to the rules governing components.

For more information on Component Rules Click Here

Starting a WiX project in Visual Studio

Step 1: Launch Visual Studio, and create a new project.

Step 2: Select Setup Project, Windows Installer XML Section

Step 3: Your first Wix Script and template is ready, you will get intuitive help when you start typing – Thanks to Votive

Explaining WiX script Elements

The product element defines the product that the installer will install. The name of the element corresponds to a table in the windows installer database, and the attributes correspond to the columns in the table. For instance, the installer database includes foreign key columns to relates many tables, while the WiX source files use nesting to accomplish the same relation. The WiX tools take care of defining the appropriate foreign key values for you.

–Package Id=”6697CCC3-B351-4DCE-820E-DEAC87F57A2A” Comments=”Demo Installer” Manufacturer=”” InstallerVersion=”200″ Languages=”1033″ Compressed=”yes”

Within the product element, you’ll find a single package element, defining the package that corresponds to this WiX file.

–Media Id=”1″ EmbedCab=”yes” Cabinet=””

The media element defines the distribution media where the MSI file and any associated CAB files will be stored.

The directory elements define the hierarchy of directories that the installer service will use with this software. Note that the Id attributes are not completely arbitrary. The windows installer defines a number of special directories, including the two (the program files folder and the program menu folder) that I’m using in this example.

The Component elements and their child elements define the exact software that will be installed. In this case, the first component consists of a single file, while the second includes a file and a shortcut to the file. Note that WiX will look for the files that you include relative to the XML file. The best plan is probably to place the XML file in the same folder as your source files, and place the wix tools on your path.

The feature element defines both the single feature in this package and the mapping between features and components.

One will need both the Windows Installer SDK and the WiX documentation to develop Wix Scripts and MSis.

Microsoft Tools Windows Installer, Application Compatibility and Deployments

WiX v3.0 now available for download

The final build of WiX v3.0 is 3.0.5419 has been released to SourceForge and marked RTM/stable. You can download it from

Also, Votive is now available for Visual Studio 2010 beta. I would suggest all Visual Studio 2010 Beta users to upgrade to the latest build of WiX v3.5 to try out the feature. You can download it from
You also get,
A new set of detection properties for .NET Framework 4 beta installation states in the WixNetfxExtension
A new set of detection properties and registration custom actions for Visual Studio 2010 beta editions in the WixVsExtension.

Call to Actions
Votive –
WiX v3.0 online documentation –
Rob Mensching’s announcement about the release of the final version of WiX v3.0 –
Tips to migrate from wix v2 to wix v3
Bob Arnson’s announcement –
WiX site on SourceForge
WiX tutorial

Folks, who aren’t aware about WiX….
The Windows Installer XML (WiX) is a toolset that builds Windows installation packages from XML source code. The toolset provides a command line environment that developers may integrate into their build processes to build MSI and MSM setup packages.

WiX is an open source project, originally developed by Microsoft and maintained by Rob Mensching. You can download the latest binary and source code releases from SourceForge. This tutorial originally describes version 2.0, the stable release. Version 3 is still under development and although it is still a moving target, we have started to add material that describes the changes brought about by the new version.

The toolset is written in C# and requires the .NET Framework 1.1 and its Service Pack 1 to run. However, this only applies to the toolset itself. The installation packages you create with the toolset do not require any extra framework or software to be installed on the target computer. Similarly, there might be a few additional utilities required for some special applications (merge modules, patches) but only on your build computer, the client will only need the finished and self-contained installer package, nothing else.

Join WiX Group:
There is a friendly community of Wix developers and users in a dedicated mailing list, hosted at SourceForge. This is the best place to ask for advice about any aspect of WiX. If you already have a SourceForge account, you can join on the website, too, but the simplest way is to send an empty message to the subscription address.

Tools Windows Installer, Application Compatibility and Deployments

WiX Tutorial

Hey all, do you wanna try hands on Wix?? These below links should be really useful.

Best Practices How-to Microsoft Tools Windows Installer, Application Compatibility and Deployments

How to create a Windows Installer Patch using Wise Package

Step 1: Launch the Patch Creation tool from within your Wise product. The Patch Creation tool’s Welcome dialog appears. This dialog offers an outline of the steps for creating a patch.

Step 2:
Read the information on the Welcome dialog, and click Next when finished. The Specify Patch Settings File dialog appears.

Step 3: The radio buttons on the Specify Patch File Settings dialog indicate whether to create a new patch file or Open an existing patch settings file. A patch file (.PCP) stores settings from the Patch Creation tool, such as the names of the previous and new .MSIs and whether to include whole files or file patches when compiling the patch. For this exercise, select the radio button to create a new patch file and click Next. The Specify Previous Versions dialog appears.

Step 4: Use the Specify Previous Versions dialog to add entries for each of the previous versions of an installation that the latest version can patch. Click Add to add a previous version. The Previous Version Details dialog appears.

Step 5: Click Browse to browse to the .MSI for the previous version of your application. Click Open after locating the .MSI.

Step 6: Make any desired changes on the Previous Version Details dialog. The settings in the Validation section of the dialog indicate the requirements of the previous installation on the destination computer in order to install this patch. Please view the online help by pressing F1 on the Previous Version Details dialog for more information about the various fields.

Step 7: Click OK when finished making changes on the Previous Version Details dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI and the Specify Previous Versions dialog shows a target path pointing to a temporary directory where the extracted .MSI resides.

Step 8:
Add other previous versions if applicable, then click Next on the Specify Previous Versions dialog. The Specify Upgrade Version dialog appears.

Step 9: The Specify Upgrade Version dialog shows the path to the .MSI that upgrades the previous versions enumerated on the Specified Previous Versions dialog. When launching the Patch Creation tool with an installation project already open, the Upgrade MSI path field contains the path to the .MSI for the current installation project. Click Browse to browse to the upgrade .MSI if the Upgrade MSI path field doesn’t already contain the correct information.

Step 10:
Click Advanced to display the Advanced Upgrade Version Details dialog. This dialog shows the Patch GUID and a field for Previous Patch GUIDs to replace. Please view the online help by pressing F1 on the Advanced Upgrade Version Details dialog for more information about the fields on the dialog. Click OK when finished making changes to the Advanced Upgrade Version Details.

Step 11: Click Next on the Specify Upgrade Version dialog. A dialog might appear, saying that the installation database is marked as compressed and PatchWiz.dll does not operate on compressed databases. Click Yes to run an admin install to extract the files from the .MSI and continue creating the patch. Windows Installer extracts the .MSI to a temporary directory, and then the Compile Patch dialog appears.

Step 12: The Compile Patch dialog shows several options for compiling the patch. The first field is the name of the Output .MSP file. Browse to the location where to store the .MSP file, or type in the full path including the file name.

Step 13: The Advanced Settings on the Compile Patch dialog determine whether to create file patches or to use entire files, whether to allow the Product Code or Version Number to differ between the previous and upgrade, and whether to create a log file. Mark the checkboxes for these options to enable them.

Step 14:
The Multi-patch Media settings indicate the starting file sequence and disk ID numbers as well as the volume label for the .MSP and the prompt that displays when the application needs to be repaired. Again, please view the online help by pressing F1 on the Compile Patch dialog for more information. Note that the Volume Label on this dialog must match the volume label on the CD or other write-protected media that distributes the patch. Click Next on the Compile Patch dialog to continue the patch creation process.

Step 15: The Patch Creation tool begins creating the patch. A dialog might appear, saying “ProductCodes between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop. Another dialog might appear, saying “ProductVersions between Target and Upgraded images do not match; do you want to proceed anyway?” Click Yes to continue creating the patch, or click No to stop.

Step 16: When the Patch Creation tool has finished creating the patch, the Compile Patch dialog says Patch creation completed and has a View Log button. Click View Log to view the patch creation log, or click Finish to close the Patch Creation tool.