Dim WshShell
Set WshShell = CreateObject("WScript.Shell")
Bits = GetObject("winmgmts:root\cimv2:Win32_Processor='cpu0'").AddressWidth
msgbox Bits
Tuesday, 30 August 2011
VBScript to Check 32bit or 64bit Operating System
VBScript to check if Operating Systems is 32bit or 64bit
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.
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
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
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.
The following command includes a /se command-line switch, which suppresses the display of only the EULA page.
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.
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.
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.
/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
dpinst.exe /q
dpinst.exe /se
dpinst.exe /q /se /f
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:
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
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.
ICE | Brief 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. |
ICE04 | Validates file sequence numbers against the Media table's LastSequence numbers. |
ICE05 | Validates for "required" entries in particular tables. |
ICE06 | Validates for missing column or tables in the database. Any column defined in the _Validation table must be found in the database. |
ICE07 | Validates that fonts are installed to the FontsFolder |
ICE08 | Checks for duplicate GUIDs in the ComponentId column of the Component table. |
ICE09 | Validates that the permanent bit is set for every component marked for installation into the SystemFolder. |
ICE10 | Ensures that advertise feature states among children and parents are compatible. |
ICE11 | ICE11 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). |
ICE12 | Validates type 35 and type 51 custom actions and their locations in the sequence tables. |
ICE13 | Validates that dialogs are not listed as actions in the execute sequence tables. Dialog actions are only allowed in the user interface sequence tables. |
ICE14 | Validates 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. |
ICE15 | Validates that a circular reference exists between every entry in the MIME table and the corresponding extension in the Extension table. |
ICE16 | Validates that the ProductName in the Property table is not greater than 63 characters in length. |
ICE17 | Validates control type dependencies in the Control table. Covers PushButtons, RadioButtonGroups, ListBoxes, ListViews, and ComboBoxes |
ICE18 | Validates the KeyPath column of the Component table when it is NULL. In this case, the key path is a Directory. |
ICE19 | Validates the advertising tables: Class, TypeLib, Extension, PublishComponents, and Shortcut. |
ICE20 | Validates that the required dialogs are in the Dialog table. |
ICE21 | Validates that all components in the Component table map to a feature in the FeatureComponents table. |
ICE22 | Validates that the Feature_ and Component_ columns in the PublishComponent table. |
ICE23 | Validates the tab order of controls in all dialog boxes. |
ICE24 | Validates certain properties in the Property table. |
ICE25 | Verifies merge module dependencies and merge module exclusions. |
ICE26 | Validates required and prohibited actions in the sequence tables. |
ICE27 | Validates the organization and order of the sequence tables. |
ICE28 | Validates actions that must not be separated by ForceReboot. |
ICE29 | Validates that your stream names remain unique if truncated to the 62 character limit. |
ICE30 | Validates that the installation of components containing the same file never installs the file more than once in the same directory. |
ICE31 | Validates the text styles listed in the Text column of the control table. |
ICE32 | Compares the column definitions to validates that keys and foreign keys are of the same size and type. |
ICE33 | Checks for entries in the registry table that belong in other tables. |
ICE34 | Validates that every group of radio buttons has a default. |
ICE35 | Validates that any files from a cabinet file cannot be set to run from source |
ICE36 | Validates that icons listed in the Icon table are used the Class, ProgID, or Shortcut tables. |
ICE38 | Validates that components installed under the user's profile use a registry key under HKCU as their key path. |
ICE39 | Validates the Summary Information stream of the database. |
ICE40 | Performs various miscellaneous checks |
ICE41 | Validates that entries in the Extension and Class tables refer to components belonging to the referenced feature. |
ICE42 | Checks that Class table entries don't have EXEs set as InProc, and that only LocalServer contexts have arguments and DefInProc values. |
ICE43 | Checks that non-advertised shortcuts are in components with HKCU reg keys as the key paths. |
ICE44 | Checks that dialog events in the ControlEvent table (NewDialog, SpawnDialog, SpawnWaitDialog) reference valid Dialogs in the Dialog table. |
ICE45 | Checks for reserved bits that are set. |
ICE46 | Checks for custom properties that only differ from defined properties by their case. |
ICE47 | Checks 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. |
ICE48 | Checks for directories that are hard-coded to local paths. |
ICE49 | Checks for non-REG_SZ default values in the registry table. |
ICE50 | Checks that advertised shortcuts have correct icons and context menus. |
ICE51 | Checks that TTC/TTF fonts do not have titles, but that all other fonts do. |
ICE52 | Checks for non-public properties in the AppSearch table. |
ICE53 | Checks for registry entries that write private installer information or policy values. |
ICE54 | Checks for components using companion files as their key path file. |
ICE55 | Checks that LockPermission objects exist and have valid permissions. |
ICE56 | Validates that the directory structure of the .msi file has a single valid root. |
ICE57 | Validates that individual components do not mix per-machine and per-user data. |
ICE58 | Checks that your Media table does not have more than 80 rows. |
ICE59 | Checks that advertised shortcuts belong to components that are installed by the target feature of the shortcut. |
ICE60 | Checks that if a file in the File table is not a font and has a version, then it also has a language. |
ICE61 | Checks the Upgrade table. |
ICE62 | Performs extensive checks on the IsolatedComponent table for data that may cause unexpected behavior. |
ICE63 | Checks for proper sequencing of the RemoveExistingProducts action. |
ICE64 | Checks that new directories in the user profile are removed in roaming scenarios |
ICE65 | Checks that the Environment table does not have invalid prefix or append values. |
ICE66 | Uses the tables in the database to determine which schema your database should use. |
ICE67 | Checks 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. |
ICE68 | Checks that all custom action types needed for an installation are valid. |
ICE69 | Checks that all substrings of the form [$componentkey] within a Formatted string do not cross-reference components. |
ICE70 | Verifies that integer values for registry entries are specified correctly |
ICE71 | ICE71 verifies that the Media table contains an entry with DiskId equal to 1. |
ICE72 | ICE72 ensures that the only custom actions used in the AdvtExecuteSequence table are type 19, type 35, and type 51 custom actions |
ICE73 | ICE73 verifies that your package does not reuse package codes or product codes of the Windows Installer SDK samples. See Package Codes and Product Codes. |
ICE74 | ICE74 verifies that the FASTOEM property has not been authored into the Property Table. |
ICE75 | ICE75 verifies that all custom action types that use an installed file as their source are sequenced after the CostFinalize action. |
ICE76 | ICE76 verifies that no files in the BindImage table reference SFP (WFP) catalogs. |
ICE77 | ICE77 verifies that in-script custom actions are sequenced after the InstallInitialize action and before the InstallFinalize action. |
ICE78 | ICE78 verifies that that the AdvtUISequence table either does not exist or is empty. |
ICE79 | ICE79 validates references to components and features entered in the database fields using the Condition data type. |
ICE80 | ICE80 validates that Template Summary Property and Page Count Summary Property correctly specify the presence of 64-bit components or custom action scripts. |
ICE81 | Validates the MsiDigitalCertificate table and MsiDigitalSignature table. |
ICE82 | Validates the InstallExecuteSequence table. |
ICE83 | Validates the MsiAssembly table. |
ICE84 | Checks the sequence tables to verify that required standard actions have not been set with conditions. |
ICE85 | Validates that the SourceName column of the MoveFile table is a valid long file name. |
ICE86 | Issues a warning if the package uses the AdminUser property in database column of the Condition type. |
ICE87 | Validates that the following properties have not been authored in the Property Table. |
ICE89 | Validates that the value in the Progid_Parent column in ProgId table is a valid foreign key into the ProgId column in ProgId table. |
ICE90 | Posts a warning if it finds that a shortcut's directory has been specified as a public property. |
ICE91 | Posts 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. |
ICE92 | Verifies that a component without a Component Id GUID is not also specified as a permanent component. |
ICE93 | Issues a warning if a custom action uses the same name as a standard action. |
ICE94 | Issues a warning if there are any unadvertised shortcuts pointing to an assembly file in the global assembly cache. |
ICE95 | Checks the Control table and BBControl table to verify that the billboard controls fit onto all the billboards. |
ICE96 | Verifies 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:
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.
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
For training details please visit www.AppRepack.in
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.
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 entriesIf 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.
- Action run only during Install
Condition: NOT Installed - Action only runs during removal of MSI
Condition: REMOVE="ALL" - 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
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
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.
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.
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.
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
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.
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
For training details please visit www.AppRepack.in
Subscribe to:
Posts (Atom)