General How-to Microsoft

Packaging and deploying applications for Windows Mobile

Here is a noteworthy blog which explains on Packaging and deploying applications for Windows Mobile..


How does User Account Control (UAC) work in Windows 7?

When an administrator user logs on to a Windows Vista computer, two access tokens are created: a filtered standard user access token, and a full administrator access token. Instead of launching the desktop (Explorer.exe) with the administrator’s access token, the standard user access token is used. All child processes inherit from this initial launch of the desktop (the explorer.exe process), which helps limit Windows Vista’s attack surface. By default, all users, including administrators, log on to a Windows Vista computer as standard users.

When a standard user, attempts to perform a task that requires administrative privileges, such as accessing C:\Windows folder, UAC prompts the user to enter valid credentials for an administrator account. (Elevation from standard user account to Administrator Account). When an administrator, attempts to perform a task that requires administrative privileges, such as accessing C:\Windows folder or installing component for that application, UAC prompts the user to approve the action. When the user approves the action, the task is launched with the administrator’s full administrator access token.

  • ActiveX installer Service which is enable enterprise to delegate ActiveX control installation for standard users.
  • Installer Detection which detects installation programs and requests administration credential and approval from the administrator user in order to run with access privileges.
  • User Interface Privilege Isolation (UIPI) which isolate application running as a full administrator from processes running as an account lower than an administrator on the same interactive desktop.
  • Virtualization which enables redirection for Application read and write to system files and registry key
  • Access Token Change which allow the user to receive one or two access tokens (a filtered access token or standard user access token and a full access token or full administrator access token) based on user account privilege.
Microsoft Windows Installer, Application Compatibility and Deployments

Where is the Windows Installer GUID stored in the machine?

The Installer uses GUIDs to uniquely identify applications, packages, components, etc. The ProductID is the GUID used by the Installer to distinguish one application from another. It doesn’t matter if the package or application names for two different applications are different, if the IDs are the same, the Installer is likely to become confused and you will encounter problems with installation, repair and uninstall.

How should an Installer GUID be represented?

The GUID data type is a text string representing a Class identifier (ID). COM must be able to convert the string to a valid Class ID. All GUIDs must be authored in uppercases. The valid format for a GUID is {XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX} where X is a hex digit (0,1,2,3,4,5,6,7,8,9,A,B,C,D,E,F).

You can use the same ProductID when a package is a newer build of an existing one, but you need to then have different PackageIDs to distinguish the application versions. If you want the packages to be upgrades of each other, then you need them to have the same UpgradeID.

How does GUID get stored?

Windows Installer GUIDS are not written in the registry as they appear in the development tools. The first 8 digits are reversed, the hyphen is dropped, the next 4 digits are reversed, the hyphen is dropped, the next 4 digits are reversed, the hyphen is dropped, the next two digits are reversed, the next two digits are reversed, the hyphen is dropped, then the next two digits are reversed, six times.

So a code such as {D0F23C3F-CA74-460F-9ADB-49CBD57F9688} becomes: F3C32F0D47ACF064A9BD94BC5DF76988

Refer below figure for example.


Microsoft Windows Installer, Application Compatibility and Deployments

Windows Installer 4.5., Available !!!!

Windows Installer 4.5 is now available as a redistributable system component for the following operating systems:

Windows Server 2008, 32-bit editions
Windows Server 2008, 64-bit editions
Windows Server 2008, Itanium-based editions
Windows Vista
Windows Vista Service Pack 1 (SP1)
Windows XP Service Pack 2 (SP2)
Windows XP Service Pack 3 (SP3)
Windows Server 2003 SP1
Windows Server SP2
Refer this link for more details !!!

Windows Installer, Application Compatibility and Deployments

Key Information on Sourcelist of a MSI

The following registry key gives information about the sourcelist for a msi. (Source Resilency)

We can also check for the transforms which were installed along with msi in

General Microsoft

Different Levels of Presentations in Microsoft Public Conferences

Last week it was discussed, that only Level 200 or above presentations will be encouraged in the South Asia MVP Summit 2008. Initially, I was a bit perplexed on the levels of Presentation. That’s when; Abhishek gave me this information which describes on the various levels of presentation.

Level 100 (introductory):
   Overviews of product and technology features, functions and benefits 
   Details of new product features, how will they benefit customers and convince them that they need to buy this product
   The functions of the product and an example of how they are used in a real world environment
   The benefits of the product and any case studies that show how they assisted a customer
   Product requirements and other integration information. 
  Level 200 (intermediate):
   Specific product and technology technical information
   Drilling into architecture, integration and configuration (what makes the feature tick)
   Supportability reviews
   Code samples
   Best practices
   High-level troubleshooting techniques
   Known limitations and issues. 
 Level 300 (experienced):
   Product migration, deployment, architecture, development
   Drilling into how a product and its technology is designed to be deployed, migration, etc and focusing on how it is actually deployed
   Real world examples as appropriate
   Complex coding, known issues and work-arounds (sample code/examples)
   Lessons learned, both positive and negative
   Sample migration plans including sample project plans
   Deployment case studies
   Architecture design best practices and case studies. 
 Level 400 (advanced expert):
   Custom code, scripts, application solution development, architect infrastructure designs and solutions
   Advanced coding considerations and challenges
   Design considerations and challenges
   Architecture considerations and challenges
   Troubleshooting techniques at the debugging level.

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

How good is to use GetVersion function to detect the OS version number?

The internal version number for Windows Vista is 6.0 and Windows 7 is 6.1.  The GetVersion function returns this version number. The problem is, some applications will return a higher version number. 

Symptoms of OS Version 

  1. Applications that check for OS version will get higher version number.
  2. Application installers may prevent themselves from installing the app and apps may prevent themselves from starting.
  3. Applications may warn users and continue to function properly.

Mitigation Techniques for OS Version

  1. For apps and installers that check for OS version, a Compatibility mode is provided in Windows Vista
  2. Users can right right-click the shortcut or the EXE and apply the Windows XP SP2 compatibility mode from the Compatibility tab. This applies multiple shims including “WinXPSP2VersionLie”
  3. Better: Apply the shim “WinXPSP2VersionLie”
  4. In many cases, applications will work the same way that it did in Windows XP and there is no need for changes to the application

Fixes for OS Version

Applications should not perform version checks for equality (== 5.1)

  1. If you need a specific feature, check whether the feature is available.
  2. If you need Windows XP, check for Windows XP or later (>= 5.1).
  3. Exceptions to this occur when there is a very specific business, or legal need to do a version check, such as regulatory body requires you to certify your application for each operating system and version.
General Microsoft

My MVP Letter !!!

I just got my MVP letter today. After reading this.., it makes me feel that I have achieved something really BIG!!!!
I have managed to take a picture of that using my mobile to put it on my blog. Read through it..,


Best Practices Windows Installer, Application Compatibility and Deployments

Best Practices to follow while Packaging Applications

Hard-coding should be avoided

In an MSI, Hard coding should be avoided to the maximum and should be replaced by properties. For e.g. instead of “C:\Program Files\…”, property “ProgramFilesFolder should be used.

Least Use of custom actions involving 3rd party tools

Any changes which are being made to the system during an installation should possibly be made through an MSI involving least use of 3rd party tools. For e.g. If an UI Installation needs to created, it should be done through MSI Dialogues not through Visual Basic exe’s. If a file has to be installed conditionally, same should be done through MSI’s functionality not through VB Scripts.

Deletion and allocation of resources (files, registries) to proper components.

During Setup capture, Wise package Studio, captures lot of junk registries and usually you will find all these registries in a component by name “registryXX”.
This component needs to be carefully looked at since this component will have registries which otherwise should belong to other components. For e.g this component will have registries for e.g HKCR\CLSID\{GUIID} or HKCR\Interface\{GUIID}.If there is a dll in your application and registration of this dll has this GUID, then this registry should be moved from this component to the component having this dll else this registry is categorized as junk registry and needs to be removed.

 Ini Files should be retained as INIFile Table Entries not as Files, to the extent possible.

Ensure that any INI file changes are recorded in the INI file table, rather than just as files in the file table. This will ensure that INI files are edited if they exist already, rather than replaced with the version within the MSI Package.

Shortcuts should be made as “Advertised” shortcuts to the extent possible.

This is to ensure Self Healing.

DLL’s should be registered through Advertising Tables to the extent possible.

This is to ensure Self Healing and minimize registry conflicts.

As soon as you realize that the source installation is an MSI or installs an MSI embedded in it, it should be scripted as Vendor MSI.There should be no empty components in the MSI.

 Only COM Dll’s should be isolated.

If any custom actions are used, “In-Script” options and “Processing Options” need to be set correctly for them.

During Setup Capture

if it’s observed that lot of .INI Files have got captured, it’s better to exclude the INI files from the capture and then a second capture can be taken just with INI files or the INI files can be added as files, else the capture will take several hours and some times may not complete.

it’s possible that .INI Files, .INF Files, .HLP Files or .CHM Files do not get captured properly. To make sure all these files are present in MSI, it’s better to compare the size of the application folder in target machine (where application is installed) with captured folders after Setup Capture.

In some applications, it’s required to do the capture in some specific accounts and Wise can’t be installed in that account. In such cases it’s better to use the Wise as “run as” rather than going for some other capture techniques.  

Note: Run as account should be the account in which Wise is installed.


Lot of CHM files

 When there are lot of CHM files need to be added in the script which might have missed during capture, add it to the components directly rather than adding through Installation Expert. The reason for this is if you add through Installation expert, then the CHM files will be moved to the components, which is already having some CHM files, getting installed in some other folder.


Windows Installer, Application Compatibility and Deployments

How to Slip Stream Application Patches?

There are better methods to handle patches with Windows Installer. However, when this doesn’t work, Slip-Streaming can be a Just in time solution. Slip-Streaming is a process which applies MSP to the MSI where MSI has not been installed on the system. If the Service Pack is in MSP format, then it can be directly installed on the system where the application is present.

In this phenomenon, MSP is automatically added to the MSI file itself and one can directly install the changed MSI. It can be called used by the following command:
msiexec /p abc.msp /a abc.msi

Disadvantages of Slip-Streaming Patches
1. The patch alone can never be un-installed.
If the patch has some problems, we will need to uninstall the entire application and to install the base application again without any patch. This is a very tedious process.
2. The user will not be aware of the patch application on the core MSI.
3. Consecutive patches can’t be applied.

Thanks Sunil and Harsha for this information!