Categories
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.

Categories
General Microsoft

Mis-understood Features of Windows Vista

This is a very good article to understand Windows Vista better. There are lot more to talk about. Once you go through that article, I believe your complains would be reduced for sure !!!!

You can obtain the article from here

Categories
How-to Microsoft

How to register a File Extension in Windows?

If your application uses special file extensions, you might want to register them so that the application gets started when the icon associated with the file gets double-clicked.

There are special tables for this in the MSI structure (Extension and ProgId). The contents of these tables are used for advertising. You can also make your own registry entries to create application-to-file-extension relations. This example shows how to register the .dvi extensions to be opened with the yap.exe program.

Link the extension .dvi to the DVI.Document class:

Key: HKLM\SOFTWARE\Classes\.dvi
Value: <default> = “DVI.Document”

Describe the DVI.Document class:

Key: HKLM\SOFTWARE\Classes\DVI.Document
Value: <default> = “DVI Document”

Select Icon #0 from yap.exe which is in the MSI:

Key: HKLM\SOFTWARE\Classes\DVI.Document\DefaultIcon
Value: <default> = “[!yap.exe],0”

How to open the .dvi file if it is double clicked in the Explorer:

Key: HKLM\SOFTWARE\Classes\DVI.Document\shell\open\command
Value: <default> = “[!yap.exe]” “%1”

Categories
Best Practices Microsoft Windows Installer, Application Compatibility and Deployments

Microsoft Best Practices & Standards: Application Packaging

Here are a few tips I picked up from Microsoft about how to “color inside the lines” when using any tool (including Wise Package Studio) to create an MSI.

  1. Match components in previous versions of the MSI:
    Key path resource matches a resource in previous .MSI list
    Match component layout of previous .MSI
    Set component key to match previous version.
  2. Add all executable files to their own components
  3. Create new component for the resource
  4. Add all .TLB files to their own components
  5. Group matching .HLP and .CNT files together
  6. Group matching .CHM and .CHI files together
  7. Put registry keys associated with files or components in matching components.
  8. Put current user registry keys in their own component
  9. Put non-current user registry keys in their own component.
  10. Group all non-executable files to their own component
  11. Name new non-advertised shortcuts by destination directory.
  12. Group non-key path resources by resource type
  13. Create new components for resources not matching other criteria.
  14. Set component key to table name of key path or the first resource.

Hope these little guidelines helps!

Categories
Microsoft Windows Installer, Application Compatibility and Deployments

How to check an Executable for Manifests and Digital Signing?

To avoid UAC prompts for applications on launch, there exists a manifest file which contains key information on the privileges. Many times, these manifest files are present along with the executable in the same directory. For example: Altair.exe will have a manifest file called Altair.exe.manifest in the same directory. There can also be cases where the manifest is embedded in the exe itself. In this case, identifying the launch condition for this exe involves a lot of research.

Here is a simple executable which will help research those launch conditions.

Sigcheck.exe is an executable from the Sysinternals team that enables you to check whether a file has been digitally signed. The -m switch allows you to view any manifest within the file. All we need to do is run this sigcheck.exe with -m switch along with the executable, the full manifest will be displayed on the command prompt window.

If the XML manifest is going to prompt an elevation then there will be a tag “requiredExecutionLevel” set to “requireAdministrator”.

You can then re-create a manifest on these 3 categories:

  • Runasinvoker
  • Runasadmin
  • Runwithleastprivilages

Its advised to use Run as Invoker for manifests (Launch condition).

Signcheck.exe can be downloaded here.

Categories
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.

 

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

Understand the Windows Installer Logs

Here’s a fantastic document by Richard on “how to interpret Windows Installer logs”. This is a very essential and a noteworthy bookmark for every packager and administrator. Especially, Don’t miss the Annotated Verbose Installer Log section; it has a pdf file, which contains a log file generated on Vista.

Special Thanks to Richard Mc Donald for this wonderful Document!

Click here to Download the Annotated Verbose Log 

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

How to Troubleshoot an error using Windows Installer Logs

When you need to troubleshoot a failing install, it is often useful to use the policy hive rather than the command line to catch things like repairs and multi-package installs. The Windows Installer Log comes in very handy in this case. The log can be generated 2 ways (Other than the usual Msiexec <misname> /l*v c:\testlog.log).

1. Registry Key
Start Registry Editor (Regedt32.exe), and then create the following path and keys in the registry:
HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\Installer

Create keys:
Logging : voicewarmupx
Debug”=dword:00000007

The letters in the value field are the options that are available to use with Windows Installer logging. You can use the options in any order. Each option turns on a specific logging mode. The function of each option is as follows:

v – Verbose output
o – Out-of-disk-space messages
i – Status messages
c – Initial UI parameters
e – All error messages
w – Non-fatal warnings
a – Start up of actions
r – Action-specific records
m – Out-of-memory or fatal exit information
u – User requests
p – Terminal properties
x – Extra debugging information.
+ – Append to existing file
! – Flush each line to the log

* – Wildcard, to log all information except for the v option. To include the v option, specify *v.

It is recommended that you use this service only for troubleshooting. Leaving the service turned on creates a new Msi*.log file every time you use the Add/Remove Programs tool in Control Panel. This activity adversely affects system performance and disk space.

2. Modifying Group Policy
You can use Group Policy to enable logging by modifying the appropriate organizational unit (OU) or Active Directory Group Policy:
Click Start, and then click Run.

In the Open box, type gpedit.msc to start the Group Policy Editor.
Expand Computer Configuration, expand Administrative Templates, expand Windows Components, and then click Windows Installer.
Double-click Logging, and then click Enabled.
In the Logging box, specify the options for what you want to log.
After the installation\UnInstallation of the package check in %temp% for log files starting with MSI (eg.MSI8758d.LOG).

Categories
How-to Windows Installer, Application Compatibility and Deployments

Troubleshoot MSI Installation Issues and Functional Errors

If the application does not work after the install, there could be several possible reasons for this. I’ve tried to outline a few of the troubleshooting steps I take when I run into these types of errors. Read on to learn more. 

The application does not work in user context ie., locked-down environment. 
  • To test this, install the package and run the application under a local administrator account for the workstation.
  • If the application works under this account but not under a normal user account, then the following problems might be present.
  • Unable to write to drives/folders such as R:, C:\Program Files, C:\Windows, etc. which are read-only for normal users. If this is suspected then make the drives read/write for the user to test this. Check whether R:\ and other shared directories are mapped properly before installation.
  • Unable to write to registry keys. With the exception of HKCU and HKLM\SOFTWARE, all other hives are read-only for normal users. If this is suspected then make the hive read/write for the user to test this (use REGEDT32.EXE in W2000 and regedit in XP and Vista).
    In either case if such problems are encountered then the resolution of the problem should be to give the read/write access required for folders on the workstation or hives in the registry.

The application does not work because of missing component!

  • To test this, run the source or native install on a clean machine, and run the application.
    Note that this test can also be done, after the initial application capture. If it does not work, then it is reasonable to assume that the application install is missing some components for it to work or the application will never work on this environment.
  • If it seems as if a component is missing then it can be added.

Not everything has been captured.

  • To test this, install the source, compile the captured .wsi or .wse file and execute the resulting .msi or .exe on the machine, and run the application. If it works then this indicates that all was captured but perhaps too much was removed whilst creating the package or wrong versions of components were used from the originals.
  • In either case a reasonable next step is to perform a “gap capture” on the workstation on which the package has been installed and tested.
    To do this, run WfWI or WI on this workstation and perform a capture of the original native install on top of the Packages install. This will give a “gap capture” indicating the differences, or what has been left out.
    Look at the files and registry entries in the resulting .wsi or .wse.

This post outlined some actions to be taken in the event of a completed package not working when installed. Further it also provided some details of the most common problems and actions.

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

MSI Packaging Guidelines and Best Practices for Windows 7 / Vista

Here are few points which would prove handy while re-packaging an application for Vista / Windows 7.

1. If you must make a change on the system via a custom action, ensure that the custom action is deferred and the msidbCustomActionTypeNoImpersonate bit is set. This will ensure that the custom action inherits elevated privileges from the installed

2. Place all your custom actions in the Execute Sequence to ensure that they are invoked during silent mode and use appropriate conditions on the custom actions to only run when intended

3. Test your application for a locked down user. If necessary, give the user permissions to access folders and registry keys that the application tries to write to via the Locked Permissions table. Do not open higher level folders such as C:\Program Files, C:\Windows or C:\Windows\System32 for locked down users. Instead, set permissions on the exact sub-directory that the application needs access to:

4. AdminUser property commonly used to check for admin rights will not work in UAC. Microsoft has decided to set this to TRUE by default for Application Compatibility reasons. Use MSIUSEREALADMINDETECTION property instead.

5. Add installation logic that was not captured by SetupCapture. Example: Launch conditions that check for system requirements.

6. Turn off Virtualization feature. This will ensure that, duplicate files and registries are not created. This mainly happens to the applications which need a launch. The keys which are virtualized can be removed from the package as well.

7. Add support for Vista-specific features 🙁 This can be found in the “Windows Installer Options” dialog of Installation expert in WPS 7.0)

a. Disable the User Account Control (UAC) prompting for standard user installations.

b. Set options for Restart Manager.

8. Set Windows Installer logging options to provide verbose output. The installation log can provide valuable information about why an installation fails.

9. Remove 16-bit features from packages that will run on the 64-bit version of Windows Vista, if they are not part of the application’s primary functionality.

10. Remove all WRP components from the MSI package. If the installation installs a file that would otherwise be installed to an area that is protected by Windows Resource Protection (WRP), you can do one of the following:

a. Delete it from the installation and test the application with the version that is on the destination computer. However, if you do this, your application can fail if the protected file is updated or changed in the future.

b. Isolate the protected file so it is installed to a different location.

11. Fix installation-related errors that you find while performing installation and functionality tests.

12. Make other changes that are not related to Vista but are required as Customers standards.

13. Resolve CA’s which involved Nested Installation. This will throw an error while deployment.

14. Impersonation should not be used when running setups on Windows Vista. Edit the custom action and change its In-Script Options property to Deferred Execution – System Context. Test to verify that the custom action runs in this context.

15. Edit the custom action to add a description. The Windows Installer Editor documentation contains information you can use to document Wise custom actions

16. Any property beginning with MSI cannot be used. Hence avoid using the same.

17. Components cannot have a dummy GUID; it’s a best practice to generate one.