Pages

Tuesday 30 August 2011

VBScript to Check 32bit or 64bit Operating System

VBScript to check if Operating Systems is 32bit or 64bit


Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
Bits = GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth
msgbox Bits

Hide ARP entry of an MSI

VBScript to hide ARP entry of an MSI. In place of [ProductCode] give the product code of the msi for which you want to hide the ARP entry.


Dim WSHShell,strRegKey 
Set WSHShell = WScript.CreateObject("WScript.Shell") 
WSHShell.Regwrite "HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\[ProductCode]\SystemComponent","1","REG_DWORD"

VBScript to find MAC Address of a machine

VBScript to find the MAC Address of Network Adaptors attached to a computer.
On Error Resume Next

Dim strComputer
Dim objWMIService
Dim colItems

strComputer = "."

Set objWMIService = GetObject("winmgmts:" _ 
	& "{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2")

Set colItems = objWMIService.ExecQuery _
    ("Select * from Win32_NetworkAdapterConfiguration")

For Each objItem in colItems
    Wscript.Echo "MAC Address: " & objItem.MACAddress
Next

VBScript to Check Free Disk Space

Following script helps to find free disk space available on C-Drive, change the Drive letter in the script if you want to find free disk space of any other drive.


strComputer = "." 
Set objWMIService = GetObject("winmgmts:\\" & strComputer & "\root\CIMV2") 
Set colItems = objWMIService.ExecQuery( _
    "SELECT * FROM Win32_LogicalDisk WHERE DeviceID = 'C:'",,48) 
For Each objItem in colItems 
    Bytes = objItem.FreeSpace

If Bytes >= 1073741824 Then
	SetBytes = Round(FormatNumber(Bytes / 1024 / 1024 / 1024, 2), 0) & " GB"
ElseIf Bytes >= 1048576 Then
	SetBytes = Round(FormatNumber(Bytes / 1024 / 1024, 2), 0) & " MB"
ElseIf Bytes >= 1024 Then
	SetBytes = Round(FormatNumber(Bytes / 1024, 2), 0) & " KB"
ElseIf Bytes < 1024 Then
	SetBytes = Bytes & " Bytes"
Else
	SetBytes = "0 Bytes"
End If

Wscript.Echo "OUTPUT = " & SetBytes

Next

SendKeys using VBScript

Following script is an example of how to use SendKeys function available in VBScript to pass automated clicks to an application.


Application Window Name should be changed in the script according to application that you are working on.


On Error Resume Next

Set WshShell = CreateObject("WScript.Shell")
strWindowNameEN = "Application Window Name"

successEN = False
Do

successEN = WshShell.AppActivate(strWindowNameEN)
Loop Until (successEN = True)

If (successEN) Then
WshShell.AppActivate strWindowNameEN
End IF

WshShell.SendKeys "{TAB}"
WshShell.SendKeys "{ENTER}"

Add entries to Hosts File

Following script can be used to append entries in HOSTS file. A text file containing the entry to be appended should be placed in INPUT location as in below script


 Const ForReading = 1, ForWriting = 2, ForAppending = 8
Dim TargetFile,objWshShell,objFSO, Input, ProgramFiles, WinDir
Dim objTextFile, Target
Set objWshShell = CreateObject("WScript.Shell")
Set objFSO = CreateObject("Scripting.FileSystemObject")
ProgramFiles = ObjWshShell.ExpandEnvironmentStrings("%ProgramFiles%")
WinDir = ObjWshShell.ExpandEnvironmentStrings("%WinDir%")
Set Targetfile = objFSO.GetFile(WinDir & "\system32\drivers\etc\hosts")
Set Input = objFSO.GetFile(ProgramFiles & "\Input.txt")

Set objTextFile = objFSO.OpenTextFile (Input, ForReading)
Set Target = CreateObject("Scripting.FileSystemObject")
Set TargetFile = Target.OpenTextFile (TargetFile, ForAppending, True)
Do Until objTextFile.AtEndOfStream
Input = objTextFile.ReadLine
TargetFile.WriteLine(Input)
Loop
TargetFile.Close
ObjTextFile.Close
objFSO.DeleteFile(ProgramFiles & "\Input.txt")

How to Package Drive Applications using DPInst.exe

DPInst supports the following command-line switches that set the DPInst configuration flags that are described in Setting DPInst Configuration Flags and additional switches that further modify DPInst operation:

 /a
Sets the installAllOrNone flag to ON, which configures DPInst to install drivers in a driver package only if all of the drivers in the installation package can be installed.

/c
Configures DPInst, if DPInst is called at a command prompt, to display the text of log messages in the Command Prompt window.

/d
Sets the deleteBinaries flag to ON, which configures DPInst to delete the binary files that were copied to a system when a driver package was installed.

Note   Starting with Windows 7, the /d switch is ignored by the operating system. Binary files, which were copied to a system when a driver package was installed, can no longer be deleted by using DPInst.

/el
Sets the enableNotListedLanguages flag to ON, which configures DPInst to enable all of the supported languages that are not explicitly enabled by language XML elements in a DPInst descriptor file.

/f
Sets the forceIfDriverIsNotBetter flag to ON, which configures DPInst to install a driver on a device even if the driver that is currently installed on the device is a better match than the new driver.

/h/?, or /help
Configures DPInst to display help information about DPInst command-line options. If DPInst was called at a command prompt, DPInst displays the help text in the Command Prompt window; otherwise, DPInst displays the help text in a message box.

/l language-ID
Configures DPInst to display the text, bitmaps, and icon for the language that is specified by a language-ID value. The language-ID value can be specified in either hexadecimal or decimal format. For a list of the languages and corresponding language identifiers, see DPInst Localization Support.

If DPInst supports the specified language and runs on a Windows operating system in which the language is installed, DPInst will use the specified language. For more information about how to use the /L switch, see Testing Language Customization.

/lm
Sets the legacyMode flag to ON. In legacy mode, DPInst accepts unsigned driver packages without performing signature verification. However, be aware that Windows driver signing requirements apply to the installation of a driver package from the DIFx driver store. These requirements depend on the Windows version, the signature type, the driver package type, and the driver signing options that are set for a computer.

/q or /s
Sets the quietInstall flag to ON, which suppresses the display of wizard pages, user dialog boxes, and other user messages that DPInst and Windows generate. ThequietInstall flag works with the presence of an end-user license agreement (EULA) page and the suppressEulaPage flag.

/p
Sets the promptIfDriverIsNotBetter flag to ON, which configures DPInst to display a user dialog box if a new driver is not a better match to a device than a driver that is currently installed on the device. The user dialog box informs a user of this situation and provides an option to replace the driver that is currently installed on the device with the new driver.

/path DPInst-working-directory
Sets the DPInst working directory to DPInst-working-directory. DPInst searches for driver packages in the DPInst working directory and in subdirectories under the working directory that are specified by subDirectory XML elements in a DPInst descriptor file. For more information about how to set the DPInst working directory and specifying subdirectories under the working directory, see Specifying the Location of a Driver Package.

/sa
Sets the suppressAddRemovePrograms flag to ON, which configures DPInst to suppress the addition of entries to Programs and Features in Control Panel. These entries represent the driver packages and driver package groups that DPInst installs.

Note  In versions of Windows earlier than Windows Vista, DPInst added the entry for the driver package or driver package group to Add or Remove Programs in Control Panel.

/se
Sets the suppressEulaPage flag to ON, which configures DPinst to suppress the display of a EULA page. The suppressEulaPage flag works with the quietInstall flag and the suppressWizard flag.

/sh
Sets the scanHardware flag to ON, which configures DPInst to install a driver package for a Plug and Play (PnP) function driver only if the driver package matches a device that is currently configured in a computer and if the driver package is a better match for the device than the driver package that is currently installed on the device.

/sw
Sets the suppressWizard flag to ON, which suppresses the display of wizard pages and other user messages that DPInst generates. The suppressWizard flag works with the presence of a EULA page and the suppressEulaPage flag.

/u inf-file-path
Configures DPInst to uninstall a driver package whose INF file is specified by inf-file-path. The path that is specified by inf-file-path is relative to the directory that containsDPInst.exe.


Examples

The following command includes the /q and /se command-line switches, which configure DPInst to operate in quiet-install mode, whether a eula XML element is included in a DPInst descriptor file. This command suppresses all of the wizard pages, user dialog boxes, and other user messages that DPInst and Windows generate.

dpinst.exe /q /se

The following command includes the /q command-line switch, which configure DPInst to operate in quiet-install mode. However, DPInst will operate in quiet-install mode only if aeula XML element is not included in a DPInst descriptor file. If a eula element is included, DPInst does not operate in quiet-install mode.


dpinst.exe /q

The following command includes a /se command-line switch, which suppresses the display of only the EULA page.

dpinst.exe /se

The following command includes the /q and /se command-line switches, which configure DPInst to operate in quiet-install mode, including suppressing the EULA page. The command also includes the /f command-line switch, which forces the installation of a new driver package for a device that is configured in a computer, even if the driver package that is currently installed on the device is a better match for the device than the new driver package.

dpinst.exe /q /se /f

The following command includes the /sh command-line switch, which configures DPInst to install a driver package on a device that is configured in a computer only if the new driver package is a better match for the device than the driver package that is currently installed on the device. This command facilitates using an installation package to batchinstall driver packages for devices that are configured in a computer. Although the installation package might contain a large number of driver packages, DPInst will install only driver packages that are better matches for the devices than the driver packages that are currently installed on the devices.


dpinst.exe /sh

The following command includes the /u command-line switch, followed by the Abc.inf INF file, and the /d command-line switch. The /u command-line switch uninstalls the driver package that is associated with the Abc.inf INF file from all of the devices on which the package is installed. The /d command-line switch deletes the binaries that were copied to the system when the package was installed and deletes the package from the DIFx driver store. If the driver package is signed, the corresponding catalog file must be present in the same directory in which Abc.inf is located.

dpinst.exe /u abc.inf /d

Difference between Execute Immediate and Execute Deferred



Immediate Execution
You use this option if the custom action should be executed during Windows Installer’s first pass through the installation database, which executes before any scripts. Custom actions run in Immediate Execution mode can change properties, feature states, component states, target directories, or schedule system operations. They can also be placed in the UI Sequence or in the Execute Sequence. If your custom action requires install files or registry keys, then it should be executed after the InstallFinalize sequence.

Deferred Execution
You use this option if the custom action should be executed later, during the install script installation. This is the best option if your custom action depends on a file that is installed with the installation and if the custom action changes the system directly. Deferred custom actions cannot change properties in the Property table, call another system service, or change the system directly. A custom action using Deferred Execution can only be placed in the Execute Sequence after the InstallInitialize sequence and before the InstallFinalize sequence. When using a custom action set to Deferred Execution, the session handle and the property data set during the installation sequence are not available


VMWare ThinApp 4.6.2 released

VMWare ThinApp 4.6.2 is released and can be download at VMWare ThinApp


The ThinApp 4.6.2 release adds the following features to improve usability, performance, and provide updates:

  • Multiple enhancements have been made in the ThinDirect component, and outstanding known issues addressed, to improve performance and reliability.

  • ThinDirect now supports the redirection of all browser pages except a specified list of URLs, instead of only supporting the redirection of only a list of specified URLs.
    Example:
    [VirtIE6.exe]
    -www.vmware.com
    *

  • New parameters have been added to the thinreg utility to enhance search and exclude functionality. See New Parameters in thinreg.exe.

  • The thinreg utility can now uninstall applications without dependence on .vbs file association to run the uninstall script.

  • Microsoft Office 2007 application startup times have been improved by approximately 30%.

  • The IgnoreDDEMessages parameter has been added to the Package.ini file. This parameter, which is automatically set for virtualized Internet Explorer 6 packages, causes an application to ignore any DDE messages that it receives, meaning that it can be used to ensure Document Open operations always launch in the native application and not an open virtual application.












Monday 29 August 2011

How To Register DLL

Following Command can be used to register DLL/OCX Files


regsvr32 /s <Path to DLL file to be registered>


Use, regsvr32 /? on command line to see more options available to register DLLs

ICE Errors Reference

The following list provides links to each individual ICE. These ICEs are used to validate installation packages.


ICEBrief description of ICE
ICE01:Simple test of ICE mechanism.
ICE02:Circular reference test for File-Component, Registry-Component KeyPaths.
ICE03:Basic data and foreign key validation.
ICE04Validates file sequence numbers against the Media table's LastSequence numbers.
ICE05Validates for "required" entries in particular tables.
ICE06Validates for missing column or tables in the database. Any column defined in the _Validation table must be found in the database.
ICE07Validates that fonts are installed to the FontsFolder
ICE08Checks for duplicate GUIDs in the ComponentId column of the Component table.
ICE09Validates that the permanent bit is set for every component marked for installation into the SystemFolder.
ICE10Ensures that advertise feature states among children and parents are compatible.
ICE11ICE11 validates the Source column of the Custom Action table for Nested Installation custom actions. The Source column must contain a valid GUID (MSI product code).
ICE12Validates type 35 and type 51 custom actions and their locations in the sequence tables.
ICE13Validates that dialogs are not listed as actions in the execute sequence tables. Dialog actions are only allowed in the user interface sequence tables.
ICE14Validates that feature parents do not have msidbFeatureAttributesFollowParent bit set. Also validates that the entries in the Feature and Feature_Parent columns are not the same in the same record.
ICE15Validates that a circular reference exists between every entry in the MIME table and the corresponding extension in the Extension table.
ICE16Validates that the ProductName in the Property table is not greater than 63 characters in length.
ICE17Validates control type dependencies in the Control table. Covers PushButtons, RadioButtonGroups, ListBoxes, ListViews, and ComboBoxes
ICE18Validates the KeyPath column of the Component table when it is NULL. In this case, the key path is a Directory.
ICE19Validates the advertising tables: Class, TypeLib, Extension, PublishComponents, and Shortcut.
ICE20Validates that the required dialogs are in the Dialog table.
ICE21Validates that all components in the Component table map to a feature in the FeatureComponents table.
ICE22Validates that the Feature_ and Component_ columns in the PublishComponent table.
ICE23Validates the tab order of controls in all dialog boxes.
ICE24Validates certain properties in the Property table.
ICE25Verifies merge module dependencies and merge module exclusions.
ICE26Validates required and prohibited actions in the sequence tables.
ICE27Validates the organization and order of the sequence tables.
ICE28Validates actions that must not be separated by ForceReboot.
ICE29Validates that your stream names remain unique if truncated to the 62 character limit.
ICE30Validates that the installation of components containing the same file never installs the file more than once in the same directory.
ICE31Validates the text styles listed in the Text column of the control table.
ICE32Compares the column definitions to validates that keys and foreign keys are of the same size and type.
ICE33Checks for entries in the registry table that belong in other tables.
ICE34Validates that every group of radio buttons has a default.
ICE35Validates that any files from a cabinet file cannot be set to run from source
ICE36Validates that icons listed in the Icon table are used the Class, ProgID, or Shortcut tables.
ICE38Validates that components installed under the user's profile use a registry key under HKCU as their key path.
ICE39Validates the Summary Information stream of the database.
ICE40Performs various miscellaneous checks
ICE41Validates that entries in the Extension and Class tables refer to components belonging to the referenced feature.
ICE42Checks that Class table entries don't have EXEs set as InProc, and that only LocalServer contexts have arguments and DefInProc values.
ICE43Checks that non-advertised shortcuts are in components with HKCU reg keys as the key paths.
ICE44Checks that dialog events in the ControlEvent table (NewDialog, SpawnDialog, SpawnWaitDialog) reference valid Dialogs in the Dialog table.
ICE45Checks for reserved bits that are set.
ICE46Checks for custom properties that only differ from defined properties by their case.
ICE47Checks for features with more than 1600 components per feature on Windows NT/Windows 2000 and more than 800 components per feature on Windows 95 and Windows 98.
ICE48Checks for directories that are hard-coded to local paths.
ICE49Checks for non-REG_SZ default values in the registry table.
ICE50Checks that advertised shortcuts have correct icons and context menus.
ICE51Checks that TTC/TTF fonts do not have titles, but that all other fonts do.
ICE52Checks for non-public properties in the AppSearch table.
ICE53Checks for registry entries that write private installer information or policy values.
ICE54Checks for components using companion files as their key path file.
ICE55Checks that LockPermission objects exist and have valid permissions.
ICE56Validates that the directory structure of the .msi file has a single valid root.
ICE57Validates that individual components do not mix per-machine and per-user data.
ICE58Checks that your Media table does not have more than 80 rows.
ICE59Checks that advertised shortcuts belong to components that are installed by the target feature of the shortcut.
ICE60Checks that if a file in the File table is not a font and has a version, then it also has a language.
ICE61Checks the Upgrade table.
ICE62Performs extensive checks on the IsolatedComponent table for data that may cause unexpected behavior.
ICE63Checks for proper sequencing of the RemoveExistingProducts action.
ICE64Checks that new directories in the user profile are removed in roaming scenarios
ICE65Checks that the Environment table does not have invalid prefix or append values.
ICE66Uses the tables in the database to determine which schema your database should use.
ICE67Checks that the target of a non-advertised shortcut belongs to the same component as the shortcut itself, or that the attributes of the target component ensure that it does not change installation locations.
ICE68Checks that all custom action types needed for an installation are valid.
ICE69Checks that all substrings of the form [$componentkey] within a Formatted string do not cross-reference components.
ICE70Verifies that integer values for registry entries are specified correctly
ICE71ICE71 verifies that the Media table contains an entry with DiskId equal to 1.
ICE72ICE72 ensures that the only custom actions used in the AdvtExecuteSequence table are type 19, type 35, and type 51 custom actions
ICE73ICE73 verifies that your package does not reuse package codes or product codes of the Windows Installer SDK samples. See Package Codes and Product Codes.
ICE74ICE74 verifies that the FASTOEM property has not been authored into the Property Table.
ICE75ICE75 verifies that all custom action types that use an installed file as their source are sequenced after the CostFinalize action.
ICE76ICE76 verifies that no files in the BindImage table reference SFP (WFP) catalogs.
ICE77ICE77 verifies that in-script custom actions are sequenced after the InstallInitialize action and before the InstallFinalize action.
ICE78ICE78 verifies that that the AdvtUISequence table either does not exist or is empty.
ICE79ICE79 validates references to components and features entered in the database fields using the Condition data type.
ICE80ICE80 validates that Template Summary Property and Page Count Summary Property correctly specify the presence of 64-bit components or custom action scripts.
ICE81Validates the MsiDigitalCertificate table and MsiDigitalSignature table.
ICE82Validates the InstallExecuteSequence table.
ICE83Validates the MsiAssembly table.
ICE84Checks the sequence tables to verify that required standard actions have not been set with conditions.
ICE85Validates that the SourceName column of the MoveFile table is a valid long file name.
ICE86Issues a warning if the package uses the AdminUser property in database column of the Condition type.
ICE87Validates that the following properties have not been authored in the Property Table.
ICE89Validates that the value in the Progid_Parent column in ProgId table is a valid foreign key into the ProgId column in ProgId table.
ICE90Posts a warning if it finds that a shortcut's directory has been specified as a public property.
ICE91Posts a warning if a file, .ini file, or shortcut file is installed into a per-user profile directory that does not vary based on the ALLUSERS property.
ICE92Verifies that a component without a Component Id GUID is not also specified as a permanent component.
ICE93Issues a warning if a custom action uses the same name as a standard action.
ICE94Issues a warning if there are any unadvertised shortcuts pointing to an assembly file in the global assembly cache.
ICE95Checks the Control table and BBControl table to verify that the billboard controls fit onto all the billboards.
ICE96Verifies that the PublishFeatures action and the PublishProduct action are entered in the AdvtExecuteSequence table.


VBScript to Delete File/Folder from User Profiles

Following VBScript can be used to delete files/folders from Each and every User profile
Dim FSfolder
Dim subfolder
Dim i 

set objshell = CreateObject("Wscript.shell")
Set FSO = CreateObject("Scripting.FileSystemObject")
Profile = strSysDrive & "C:\Documents and Settings"
Set FSfolder = FSO.GetFolder(Profile) 'getting the user profile folders

For Each subfolder In FSfolder.SubFolders

   If (subfolder.Name <> "All Users" And  subfolder.Name <> "Default User"_
   and subfolder.Name <> "LocalService" and subfolder.Name <> "NetworkService") Then

	folder1=Profile & "\" & subfolder.Name & "\Application Data\Sample"

		DeleteThisFolder(folder1)

   end if

Next 

'*******************************************************************************************************

Function DeleteThisFolder(FolderName)

    If FSO.FolderExists(FolderName) Then
	     objshell.Run "CMD.EXE /C RD /S /Q """ & FolderName & """",0,True
    End If

End Function

Logoff Windows using VBScript

Following VBScript can be used to Logoff machine. Test it and Enjoy
  
Set WshShell=WScript.CreateObject("WScript.Shell")  
  
 WshShell.run "shutdown.exe -L -F"  
 

Get ComputerName + VBScript

Set oNetwork = CreateObject("WScript.Network")
sComputerName = oNetwork.ComputerName
MsgBox("ComputerName = " & sComputername)

Active Setup Registry Keys

Following Registries are to be included in package to load User settings(either registries/files) so that by the time User
logs in his current user settings will be available on the machine.

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Active Setup\Installed Components\[ProductCode]]
"StubPath"="msiexec /fup {9A346205-EA92-4406-B1AB-50379DA3F057} /qn"
"Version"="1,0"

Set Working Directory to Shortcut Using VBScript

Set objShell = WScript.CreateObject("WScript.Shell")
Set objShtCut = objShell.Createshortcut("C:\Documents and Settings\All Users\Start Menu\Programs\ShortcutName.lnk")
objShtCut.WorkingDirectory = "C:\PROGRA~1\MKSTOO~1\Demonstrations\bin"
objShtCut.Save
'WScript.Echo objShtCut.WorkingDirectory

VBScript to Terminate Process

Option Explicit
Dim objWMIService, objProcess, colProcess
Dim strComputer, strProcessKill 
strProcessKill = "'ProcessName.exe'" 
Set objWMIService = GetObject("winmgmts:root\cimv2") 
Set colProcess = objWMIService.ExecQuery _
("Select * from Win32_Process Where Name = " & strProcessKill )
For Each objProcess in colProcess
objProcess.Terminate()
Next 
WScript.Quit

Ger CurrentDirectory using VBScript

on Error Resume Next

	Set objWshShell = CreateObject("WScript.Shell")
	Set objFileSystem = CreateObject("Scripting.FileSystemObject")

	sScriptDir=objFileSystem.GetParentFolderName(WScript.ScriptFullName)

msgbox sscriptdir

Installshield 2012 Released

Installshield 2012 is the latest version best installation development solution which can be downloaded from flexera Software website

MsiLockPermissionsEx table



MsiLockPermissionsEx Table in Windows 7 enhances the functionality over LockPermissions Table. With MsiLockPermissionsEx table, users now have the ability to set access permissions on objects impacted by the application install that previously required using custom actions or other methods outside of Windows Installer


Expanding the set of permissions that can be applied to a resource by incorporating the Security Descriptor Definition Language(SDDL) in Windows Installer. This allows the security settings for an object to be more flexible, including;


o Ability to apply Deny ACLs to objects
o Indicate inheritance properties for permissions
o Expand the set of well-known SIDs
o Ability to set Owner, Group, and SACLs to the objects in addition to the regular access permissions


Security settings can be applied to services as well in addition to Files, Folders, Registry keys


Ability to apply permissions specific to user accounts – including accounts that are newly created on the system during the course of installation
Read more about this in Windows installer team blog

Whats new in Installshield 2012

Introducing InstallShield 2012 - used by over 70,000 software producers on more than 500 million desktops, InstallShield 2012 is the only installation solution capable of supporting the needs of today’s sophisticated software producers for packaging both standalone offerings and complex suites. InstallShield 2012, has been updated for a new generation of app-savvy users, delivering a fresh, positive and friendly experience to the exacting standards of today’s sophisticated users. And – it’s the only solution providing automated tools that empower software producers to productize, package and install their products in both traditional MSI and virtual formats. Understanding the needs of today’s decentralized agile teams, means that Flexera Software can design a world-class installation solution that supports the installation authoring, building and bundling requirements of these teams.


Register for this “What’s New with InstallShield 2012” Webinar and learn more about our new features including:

  • Suite Installations: With the new InstallShield Suite Project type, multiple products can be easily bundled together into a single, unified suite installation eliminating the need to develop a complex custom launcher or bootstrapper application. This new functionality offers advantages over MSI chaining, InstallShield prerequisite support, and the user interface functionality that is provided by Windows Installer.

  • Installation Streaming: Installation Streaming reduces the downloading wait time required before installation can begin. End users need only download a small file to quickly start the installation giving a more immediate interaction with the product installation. Based on the selected install options, only the required packages are downloaded from the web or extracted from the installation, reducing the overall time it takes to install the application and providing an “app store-like” experience for the user.

  • Installation Collaboration: The InstallShield 2012 Collaboration add-on has been significantly enhanced to better support distributed, collaborative installation development allowing product developers and technical writers to more efficiently create and manage their portion of the installation.

  • 64-Bit Enhancements: Comprehensive support for 64-bit installation development including updated dependency scanners to identify 64-bit dependencies of the 64-bit files in a project; support for setting permissions for files, folders and registry keys in 64-bit locations; and a prerequisite that installs the 64-bit version of the Microsoft VSTO 2010 Runtime.

  • Application Tagging: InstallShield 2012 is the only strategic installation development solution that creates ISO 19770-2 software identification tags as part of the installation development process. This enables software producers to help their customers by delivering better visibility into their installed software estate in order to facilitate software compliance efforts.

What is Application Packaging

Application Packaging is all about customizing applications according to best practices and User requirements.


Application packaging can help enterprises manage growing volumes of software for desktop and server systems efficiently. By streamlining software
configuration and deployment, application packaging can help reduce application management costs.

MDOP 2011 R2

MDOP 2011 R2 is available and can be downloaded from theMicrosoft Volume Licensing website, MSDN and TechNet. This version of MDOP includes Microsoft BitLocker Administration and Monitoring (MBAM) which is brand new to MDOP, and updates to the Microsoft Diagnostic and Recovery Toolkit (DaRT) 7.0, and Microsoft Asset Inventory Service 2.0.

Difference between Run, Run Once, Active Setup

Active Setup:



It is used when your application requires installation of components such as files or registry keys on a per-user basis, but application has no advertised entry points or other triggers to initiate the installation process.


Run:



The Run key is processed after every logon, either by the Explorer shell, if it is present, or by First Boot Agent (FBA), if a custom shell, Command shell, or Task Manager Shell is used. If FBA processes this key, it does so after every logon, not during first boot as it normally would. Typically, this flag is used to load Systray applications, launch services in executables, hide autostart applications, or hide background processes


Run Once:



The RunOnce key is processed only once, by FBA, after Plug and Play device enumeration and DLL registration processing have completed. The values of this registry key are deleted from the registry after it is processed, so that it will not run again. Typically, this flag is used when a reboot is required, such as for a DLL or OCX registration, or for cleaning up a setup or an uninstall.

AdminStudio Installshield Online Training Training

New batch of Application Packaging Classroom training using Installshield/Wise Packaging Studio is starting at Hyderabad on3rd September. If you are interested contact me at 91-9963678795 or Virtual.App.Packager@gmail.com


For training details please visit www.AppRepack.in

Application Packaging Video



http://www.youtube.com/watch?v=quY_a7Ye_WQ

Sunday 28 August 2011

What is Active Setup

Active setup provides a solution when the aim is to deliver user based components when no advertised entry points exist in an MSI package.


Most packages will contain some kind on entry point; commonly an advertised shortcut. When launching this kind of shortcut Windows Installer will check the keypath of the component the shortcut belongs to and verifies that the component is installed. If it is found to be missing Windows Install will kick off a repair.


This provides a great solution for installing current user data when the package is not installed in the user context. It is also a very good reason why you should never mix machine and user data in the same feature.

On logon the following registry keys are compared:


HKLM\Software\Microsoft\Active Setup\Installed Components\<UID>
HKCU\Software\Microsoft\Active Setup\Installed Components\<UID>


<UID> has to unique; it is good practise to use a GUID.


If the HKCU key is not found the contents of the string value StubPath is executed. The HKLM key is then copied to HKCU.


The executable in StubPath can be anything (a VBS script, a regsvr32.exe call, etc), but our aim, in this example, is to deliver missing current user data from a previously installed MSI. To do this we need to force the package to repair so Msiexec.exe will be used:


Msiexec.exe /fpu /qn


/f - Repair
/p - only if file is missing
/u - all required user-specific registry entries
If you choose to, the entire installation can be repaired:



Msiexec.exe /fomus /qn


[HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components\{44CCA842-CC51-11CF-AAFA-00AA00B6015B}]
"Version"="1"
"StubPath"="Msiexec.exe /fpu {44CCA842-CC51-11CF-AAFA-00AA00B6015B}"


Where a version is included; StubPath will only execute if the version of HKCU is less than the version of HKLM.


When a new user logs on Windows will find the HKCU active setup key missing, run Msiexec.exe with the repair arguments from StubPath and copy the HKLM key to HKCU. Next time this user logs in the repair won't run as the key already exists in HKCU.

Advantages of MSI Application Packaging


  • Customize Applications to suit the user needs.
  • Simplify the Installation and Un-installation Procedures.
  • Saves Time in both Installation and Un-installation.
  • Once packaged, applications can be quickly installed on a range of desktops in multiple locations, saving administrative costs, simplifying the manage of licensing fees and minimizing support and repair expenditures.
  • Saves Space of the product by doing apt modifications to applications.
  • Has a great flexibility of obtaining the lost files through a phenomenon called Self Heal, this reduces the down time of application. If a critical file (a .DLL or .EXE file, for example) that is part of the distribution is corrupt or is deleted, the user can be prompted to repair the installation by presenting the original .MSI distribution. Additionally, if the installation media is available (for example, on a network share), the repair simply happens automatically.
  • Can be advertised. So that on demand installation could take place.
  • Upgrading of the application can be done with ease.
  • Clean installation and Un-Installation is achieved by a process called Roll-Back.
  • Simplifies management of new user set-up along with the revision and distribution of software repairs and new applications to existing users. Application recovery can also be improved.
  • Helps eliminate uncontrolled software downloads and installation, enables applications to be safely removed and reduces non-business traffic on a corporate network.
  • Using .MSI format, can automate software distribution process and ensure that the installation doesn't break other applications that have already been installed.
  • Application is installed via an OS service.
  • State management is maintained. In the past, it's been difficult to know whether an application is installed on a machine. You would have to query for a .DLL with a specific version number or determine whether an .EXE file with a specific name was present. Windows Installer provides an application programming interface (API) that lets programmers and administrators see whether a specific application is installed on a machine.
  • Scriptable API. This whips together a VBScript to help us with the MSI file manipulations. The API to manipulate MSI files is so powerful that it can create, validate and update packages, trigger installs and uninstalls, examine the MSI repository data on computers, and perform some custom actions.
  • Served installs. Because MSI files can be housed in a share point and delivered via a server, we can keep our installation files all in one place or move them around -- closer to the users if necessary.

Custom Action Conditions in MSI

You can execute a custom action or make the component install using conditions as per the requirement.

  1. Action run only during Install
    Condition: NOT Installed

  2. Action only runs during removal of MSI
    Condition: REMOVE="ALL"

  3. Action runs during Install and repair
    Condition: NOT REMOVE

Difference Between Self Heal and Repair

Self Heal and Repair are two different concepts in Windows Installer which people many times consider to be the same thing, however there is difference in these two.

Self Heal is triggered by advertised shortcuts, or other advertising information in the package which eventually Repairs the application.

When the application is launched by advertised shortcut, it checks for all the key paths of the Current Feature, if any of the key paths is missing it will launch Repair.

Note that if there are multiple features then it will not check the missing key paths of the other features, but only the feature of which the advertised shortcut is launched.

Repair of an MSI can be triggered by
  • Repair from  Add/Remove programs
  • Command -     msiexec /f{other option} {MSI path}
  • Self Heal by advertised shortcut or other advertising information.
  • Active setup
Once the repair of the package is triggered then the whole of the MSI is reinstalled by which I mean, all its features are reinstalled.

A Guide to MSI Healing

This describes several methods of MSI healing (repair) techniques to populate HKCU keys for other users.


The best methods are documented first with other alternative ways following later.


Method I



Active Setup Method:


This is one of the best practices in MSI Packaging which uses the native Active Setup behavior of Windows XP and Windows Installer HKCU keys repair techniques.


One should follow these specific steps while using this method:


Make sure all HKCU keys in the MSI Package that we are creating are under structured component names like CurrentUser, CurrentUser1, etc.
The Package author should be able to judge and set the key path for that Component properly.


As per Microsoft Component guidelines, make sure the components containing HKCU keys are as few in count as possible, for example only one component (CurrentUser) with all HKCU keys with best key path set is the best practice.
Create the following registry keys under the main hive:
HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID of the MSI}
ComponentID=PackageName_ComponentName
StubPath=[SystemFolder]msiexec.exe /fu {Product Code of the MSI} /q
Version=ProductVersion


The principle of Active Setup behavior is when a new user logs on for the first time, then the Active Setup will perform a checksum between HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID of the MSI} and 
HKCU\Software\Microsoft\Active Setup\Installed Components\{GUID of the MSI}; 


and if the GUID is not present under HKCU, then it performs all actions which are under that main hive (StubPath, Version) and populates the GUID under HKCU. The main Advantage of Active Setup is it performs an action only once per User with the Checksum behavior by matching the entries under HKLM and HKCU.


Method II



Active Setup Method:


This method can be used for both MSIs and Non-MSIs (SMS or WSE Script executables).


Create a silent SMS script or Wise Script (for eg:-Script.exe) which will create the needed HKCU registry entries for the application. Then place that EXE in the Application [INSTALLDIR] in your MSI Pkg or Executable binary memory.


Then create the following additional registry entries in the MSI Package or within the Script whichever is applicable:


HKLM\Software\Microsoft\Active Setup\Installed Components\{GUID or AppName}
ComponentID=PackageName_ComponentName
StubPath="[INSTALLDIR]Script.exe"
Version=ProductVersion


The Active Setup performs the regular checksum (comparison of entries under) HKLM and HKCU and if the respective unique GUID or AppName is not present under HKCU hive, then it will perform all actions (StubPath, Version) and populates the GUID or AppName under HKCU hive too. This is only once per user -- for the first time -- to populate HKCU hive.


Method I and method II use the Active Setup feature, and One should understand the advantages of one over the other. Method I requires source resiliency to populate HKCU keys, where as method II does not require this as the Script.exe does everything.


Method I and method II can be used in any scenarios like if Advertised entry points are present or NOT present.


Method III



Windows Installer repair method with SMS or Wise Script:


Typically the body of the script will be;


Check for the existence of a Flag key under
HKCU\Software\Company Name\Applications\{ProductName][productversion]
Installed=True


If the key exists then quit else initiate the Windows Installer repair to populate HKCU keys:


Msiexec /fu {Product Code of the MSI} /q


And edit and create registry key (Basically a Flag Key which can be any key which your firm adopts)
HKCU\Software\XYZ*\Applications\{ProductName][productversion]
Installed=True
End
* XYZ= Name of the organization \ Company
And keep this script exe in HKLM\Software\Microsoft\Windows\CurrentVersion\Run.


One should keep in mind that the /p switch can also be used to repair files (populate) user-specific data (Profile data) with the following syntax:


Msiexec /fup {Product Code Of the MSI) /q




Method IV



Silent empty exe with valid shortcut:


Create a silent empty exe and its Advertised shortcut and place both of them in the Application [INSTALLDIR]. And use them as entry points to trigger healing to populate HKCU keys.

Tuesday 9 August 2011

Application Packaging Training - September Batch

New batch of Application Packaging Classroom training is starting at Hyderabad on 3rd September. If you are interested contact me at 91-9963678795 or Virtual.App.Packager@gmail.com


For training details please visit www.AppRepack.in