Thursday, 30 December 2010

Mastering Configuration Manager 2007 R3

Websites – SMS 2003 homepage – System Center homepage – Configuration Manager News groups – Configuration Manager webcasts – Config Mgr. homepage – Great community – Information about MOF editing – Config Mgr. addons – System Center Config Mgr. team blog – How to virtualize 3D games using the App V. sequencer – List of Configuration Manager log files – ConfigMgr 2007 Antivirus Scan and Exclusion Recommendations
Tools: – Scriptomatic – Config Mgr Client Center – Tool from Mark Cochrane to assist you in creating the correct entries in Configuration.MOF and SMS_def.mof – Extend Config Mgr. 2007 support for other operating systems such a AIX, MAC OS etc. – 1E free tools (package migration tool, WMI tool, Service Window tool and more) – Script and program to assign new site code – Adobe Customization Wizard – Apps for testing Wake On LAN
Config Manager 2007 R2 VHD:
Blogs: – The ConfigMgr. support team – The ConfigMgr. writers team

Tuesday, 12 October 2010

VBScript for SMS " Launch EXE in SMS"

Requirement : To install the Patch EXE(which was repackaged) using VBscript. It should give the status in SMS reports as required by clients and create the log file so the EXE status to be updated so if there is any error we can see the log file and fix the problem.

Below code will execute the EXE with status captured to SMS reports as well.
(EXE should be in same folder)
when we advertise the program, EXE & VBS will in Distribution Point, So VB script will launch the EXE from the same location.
Int1 = ".EXE"
'MsgBox "Copy file location = " & Int1

If objFSO.FileExists(Int1) Then
'status will give the return code in the variable
IntRet = objShell.Exec(Int1).Status

str = " Patch EXE is available and Started Execution, sleeping..."
objTS.WriteLine str
'Till the exe is installed through SMS it will be in Sleep MODE as per requirement
WScript.Sleep 600000
Below code will Creatae Log file if it doesn't exist.
strFileName = objFolder & "\sms\logs\.log"

If objFSO.FileExists(strFileName) Then
'Set objTS = objFSO.OpenTextFile(strFileName,FOR_READING)
'strContents = objTS.ReadAll
Set objTS = objFSO.OpenTextFile(strFileName,FOR_APPEND)
'strContents = objTS.ReadAll
objfso.CreateFolder objfolder & "\SMS"
objfso.CreateFolder objfolder & "\SMS\logs"
'Set objTS = objFSO.OpenTextFile(strFileName,FOR_READING)
'strContents = objTS.ReadAll
Set objTS = objFSO.OpenTextFile(strFileName,FOR_WRITING)
'strContents = objTS.ReadAll
End If

Thursday, 26 August 2010

Tip of the day - Installing PNP drivers within an MSI

To add a PNP driver from within an MSI do the following. Many thanks to the University of Edinburgh Desktop Services Team for originally posting this information.
**Note this will install the driver silently ONLY in the case where the driver is a "signed" driver. Unsigned drivers will require user intervention and possibly admin access to complete the install of the hardware
1. Create a folder and add the driver files to this folder.
2. In the Execute Deferred section sequence create an If Statement custom action after the InstallFiles action. Make the execution of this action only apply on install by giving it the condition "NOT Installed"
3. To this If Statement add a "Call Custom DLL From Destination" custom action with the settings:
DLL File: [SystemFolder]setupapi.dll
Function Name: SetupAddToSourceListA
Parameter: dword, Constant, 00000100
Parameter: string pointer, Constant,[Path to driver.inf file]. (Don't enclose paths in double quotes)
Return Value Type: dword
Return Property: DLLRETURN (Pre creating a property has more consistent results)
4. Add a second "Call Custom DLL From Destination" custom action within the same If\End statement with the settings:
DLL File: [SystemFolder]setupapi.dll
Function Name: SetupCopyOEMInfA
Parameter: string pointer, Constant, ,[Path to driver.inf file](Don't enclose paths in double quotes)
Parameter: long, Constant, NULL
Parameter: dword, Constant, 1
Parameter: long, Constant, NULL
Parameter: long, Constant, NULL
Parameter: dword, Constant, 0
Parameter: long, Constant, NULL
Parameter: long, Constant, NULL
Return Value Type: dword
Return Property: DLLRETURN
That is the install taken care of, now the uninstall...
1. In the Execute Deferred section sequence an If Statement custom action prior to the RemoveFiles action. Make the execution of this action only apply on uninstall by giving it the condition REMOVE~="ALL"
2. To this If Statement add a "Call Custom DLL From Destination" custom action with the settings:
DLL File: [SystemFolder]setupapi.dll
Function Name: SetupRemoveFromSourceListA
Parameter: dword, Constant, 00000100
Parameter: string pointer, Constant, ,[Path to driver.inf file](Don't enclose paths in double quotes)
Return Value Type: dword
Return Property: DLLRETURN

TIP Of the Day : HKCU - Pushing User Profile Settings

HKCU - Pushing User Profile Settings
HKCU (HKEY_CURRENT_USER) settings introduce a different set of problems in deployment. These registry settings are stored in each individual user profile and that makes getting them to everyone a bigger problem than simply installing files and registry settings to a machine. Most well written applications that use HKCU to store user preferences will detect the hive and default values dont exist when first run. The application should then create and populate its HKCU information with defaults automatically. However, some applications that are not written so well may need to have its desired settings present in order to function properly. More often pushing HKCU settings becomes a task for those wishing to deploy a nonstandard set of default user settings with an application. There are two basic ways to complete this task, through a logon script or through system policy settings.
Most networks use a logon script of some kind. If not, a script can still be used in the same way by adding it to the All Users startup group. Either way you do it, you will be sure to want the script to run only once for each user. To do this, the script should first check for a footprint left behind by its initial execution before running, this will prevent it from running over and over again. The footprint can be any change performed by the script that can then be checked for to show the script has been run before. It is a good idea to keep these footprints located in a central area so that they may be checked for later with greater ease. An example:
If $FOOTPRINTS\Change1 = "Complete" Then Goto "End" EndIf
If Exist "$FOOTPRINTS" <> 0 AddKey "$FOOTPRINTS" EndIf
SetValue ("$FOOTPRINTS", "Change1", "Complete", "REG_SZ")
In the above example the script will only run once for each user. The footprint area in the registry will be created if it doesnt exist. The example is written in KixTart, but can be just as easily written as a simple batch file, in Perl or in any other scripting language. Here the Windows NT REG command is used to implement some previously defined registry entries.
The second way to implement user settings, and in some cases the better way, is to use system policies. System policies force registry entries and can do so to all users, or members of specified NT groups. Remember that this method forces settings, so anything set here will always overwrite any settings made by users.
Most think of system policies as what is presented in the default templates provided by Windows NT. However additional settings can be used as well by creating a custom template. For example:
CATEGORY !!MicrosoftIE
CATEGORY !!ConnectionTab
KEYNAME "Software\Policies\Microsoft\Internet Explorer\Control Panel"
POLICY !!ProxyEnable
KEYNAME "Software\Microsoft\Windows\CurrentVersion\Internet Settings"
VALUENAME "ProxyEnable"
A good source of detailed information on creating a custom policy template can be found at: An excellent overview of system policies can be found at:
By default system policies are always implemented if present, this can be controlled by the following registry entry:
UpdateMode is a REG_DWORD with the data values:
0 - A policy file is not downloaded from a server and is not applied.
1 - NTconfig.pol is downloaded (if present) from the NetLogon share of the %LogonServer% and applied.
2 - The UNC path of the policy file is read from NetworkPath and if present, downloaded and applied.
NetworkPath is a REG_SZ value that contains the full UNC path to the policy file. It is only used if UpdateMode is a 2. Example: \\ServerName\ShareName\Policy.pol
The System Policy Editor is not included in the floppy disk version of Windows 95. You can download Policy.exe that contains Poledit.exe. Please see the following article in the Microsoft Knowledge Base for information about downloading Policy.exe: Q135315
One additional thing to keep in mind is what settings are present in the default user profile. Unless these scripts or policies are to remain in place to cover any new users, which is perfectly acceptable, the default user profile should be modified to incorporate any desired changes. Remember there are two default profiles to update, both the local and network default profiles.
The time will come when pushing user settings becomes necessary. If each machine is used by just one user, and packages are pushed in a way that the user actually performs the installation- HKCU settings can be pushed with the installation package itself. This is rarely the case though, and it is only a matter of time before a particular HKCU setting must be implemented.

Monday, 21 June 2010

Tip for the day - Importance of a RunOnce Key in Device Driver Installation.

Well, The Run and RunOnce registry entries help programs to be run automatically. In device driver installations, A RunOnce entry is executed immediately after the driver is installed; These entries are not executed until the user logs on.

For a Client-side installation, all RunOnce entries are executed. No Run, RunEx, or RunOnceEx entries are executed.
For a Server-side installation, Setup looks for RunOnce entries in the INF in the format described on the DDK. The DLLs specified are run in the system context with no UI. Any RunOnce entries that do not follow this format are deferred to a client-side installation and are run in administrator context with UI.

This is the primary reason for special requirements on RunOnce entries.

Addition Information: Run, RunEx, or RunOnceEx entries are executed only in the context of a logged-on user, and are not executed immediately after device is installed. A Service entry can immediately provide functionality for multiple logged-on users, whereas Run entries provide service to them only when the user next logs on, and also run one instance for each user.

For more information on RunOnce and Run Keys, Check these links -

Tip for the day - Redistributing Application Components using Merge Modules.

Redistributing Application Components using Merge Modules.

Most developers understand the benefits of writing reusable code. It makes sense to use that piece again when you need the same functionality. The more pre-tested software you can reuse, the fewer bugs you’re likely to have in the final product. Merge modules extend the notion of reusable components to the software installation process. Once you’ve developed a way to install a reusable component, you can also reuse the installation process!

Merge modules are pre-compiled libraries of components like files, registry, and other system changes which install a discrete portion of the application. This common module can be added to the various applications, instead of adding individual components to different msi files. They cannot be installed alone. they must be merged or added to an msi file to install it.
Merge modules are a mechanism that allows many Application Publishers to prepackage components, sign them and share these standard modules!

A merge module is similar in structure to a simplified Windows Installer .msi file. A merge module(msm file) contains files, DLLs, ActiveX components, registry entries and some system configurations like environment variables that make up these runtimes.

The use of merge modules can eliminate many instances of version conflicts, missing Registry entries, and improperly installed files!

As mentioned before, a merge module cannot be installed alone, it must be merged into an installation package using a merge tool. Developers can also create new merge modules by using many of the same software tools used to create a Windows Installer installation package, such as the database table editor Orca provided with the Windows Installer SDK.
Developers can use this method to merge modules or obtain a merge tool from an independent software vendor like Wise, InstallShield etc.
When a merge module is merged into the .msi file of an application, all the information and resources required to install the components delivered by the merge module are incorporated into the application’s .msi file. The merge module is then no longer required to install these components and the merge module does not need to be accessible to a user.
Merge modules is a tool for the developer, not for the end user!

Summing up, points to remember about the merge modules:
1. All the information required to install a shared file is delivered to the installer in a single, standardized .msm file.
2. Eliminate many instances of version clashing, missing registry entries, and improperly installed files.
3. Traditional installers keep an incremental reference count of the number of applications using a shared file, but not the name of the application. If shared files are installed from .msm files, the Windows installer can keep a correct reference list of applications that use those shared files.
4. Windows can better avoid deleting shared resources used by any application until the last application using them is uninstalled.

Thursday, 10 June 2010

Packaging interview questions HP

Packaging Interview questions HP

1. Disadvantages of lock permission table – find out
Regardless of the tool you're using, Windows Installer has a table called 'LockPermissions', which we expose in the Files and Folders and Registry views of the InstallShield Project file (*.ism).

However, there are some significant limitations associated with this such that Microsoft is rewriting this feature in a future release of Windows Installer. So, there may be some cases where you'll need to end up relying upon the custom action approach that you've used in the past.
Some scenarios that I'm aware of:
--Not natively localizing user groups based on well-known SIDs
--Appending to an existing ACL (it replaces the existing one)
--The following knowledgebase entry:
2. Disadvantages of repackaging legacy setups
3. Update host file using script
4. Diff bet immediate execute and deffered
5. How to identify the application is 16 bit or 32 bit application
Identify a 16-bit Program
To identify a 16-bit program:
1. Use Windows Explorer to open the folder that contains the program's executable (.exe) file.
2. Right-click the .exe file, and then click Properties.
3. A 16-bit program does not have a Version tab in this dialog box.
Back to the top
Identify 16-bit Programs that Are Running
To determine if any 16-bit programs are currently running, and identify any those are:
1. Start Task Manager. To do so, right-click a blank spot on the taskbar, and click Task Manager.
2. On the Processes tab, note the contents of the Image Name column.
3. If any 16-bit programs are running, you see an entry for Ntvdm.exe, which is the virtual DOS machine that is provided by Windows XP. You also see wowexec.exe (the Windows on Windows subsystem), and the executable name of each 16-bit program that is running in that WOW virtual machine. As a helpful visual aid, wowexec.exe and the 16-bit executable file names are indented.

6. Install moniter , adv and more abt
A traditional snapshot captures differences between two machine states - before installation, and after installation.

The smartmonitor tool captures changes as they occur. Here's a quote from Wise:

"SmartMonitor is the only capture technology that records changes as they are executed by the source installation. SmartMonitor captures the replacement of files, overwriting of existing registry keys and more."

If an existing registry key was overwritten with the same value during the installation of a product, a snapshot would not capture this because this would not result in a "change" between snapshots - Smartmonitor should. If you installed your "snapshot" package on a machine where the registry key did not exist, this key would still be missing after you installed your package.
7. VBS, update host file
8. Whether we can open non extension files (VBS)
9. Condition for calling CA during Uninstall
10. Condition for calling CA during only maintaince
11. Where is the options u will go for CA
Standard actions are sufficient to execute an installation in most cases. However, there are situations where the developer of an installation package finds it necessary to write a custom action. For example:
• You want to launch an executable during installation that is installed on the user's machine or that is being installed with the application.
• You want to call special functions during an installation that are defined in a dynamic-link library (DLL).
• You want to use functions written in the development languages Microsoft Visual Basic Scripting Edition or Microsoft JScript literal script text during an installation.
• You want to defer the execution of some actions until the time when the installation script is being executed.
• You want to add time and progress information to a ProgressBar control and a TimeRemaining Text control.

12. When will CA will be executed?
13. How will u debug if application go for self-heal every launch
14. What are the ways the CA can be called?
15. What is the complex application you have done in ue history, why u will call this as complex, what are steps taken to resolve the same
16. Diff between TRAGETDIR and INSTALLDIR
INSTALLDIR represents the main product installation directory for a regular Windows Installer–based (or InstallScript MSI) installation, such as the end user launching Setup.exe or your .msi database.
TARGETDIR represents the installation directory for an InstallScript installation, or for an administrative Windows Installer based installation (when the user runs Setup.exe or MsiExec.exe with the /a command-line switch).
The TARGETDIR property specifies the root destination directory for the installation. TARGETDIR must be the name of one root in the Directory table. There may be only a single root destination directory. During an administrative installation this property specifies the location to copy the installation package. During a non-administrative installation this property specifies the root destination directory.
17. Suppose if i change the TARGETDIR to D:\ but INSTALLDIR passing as c:\pf\VN\APPNAme, where the app will be installed?
18. What are the diff types of properties?
19. Why do u call Pubic property, what is the use of the same
19. What is install on demand and What is adv?
With traditional installation technology, it is necessary to exit an application and rerun setup to perform an installation task. This commonly occurred when a user wanted a feature or product not chosen during the first run of setup. This often made the process of product configuration inefficient because it required the user to anticipate the functionality required before they ever used the product.
Installation-on-demand makes it possible to offer functionality to users and applications in the absence of the files themselves. This notion is known as advertisement. The Windows Installer has the capability of advertising functionality and to make installation-on-demand of application features or entire products possible. When a user or application activates an advertised feature or product, the installer proceeds with installation of the needed components. This shortens the configuration process because additional functionality can be accessed without having to exit and rerun another setup procedure.
When a product uses the installer, a user can choose at setup time which features or applications to install and which to advertise. Then if while running an application the user requests an advertised feature that has not yet been installed, the application calls the installer to enact a just-in-time feature level installation of the necessary files. If the user activates an advertised product that has not yet been installed, the operating system calls the installer to enact a just-in-time product level installation.
Advertisement and installation-on-demand can also facilitate system management by enabling administrators to designate applications as required or optional for different groups of users. There are two types of advertising known as "assigning" and "publishing." If an administrator assigns an application to a group, then these users can install the application on-demand. If, however, the administrator publishes the application to the group, no entry points appear to these users and installation-on-demand is only activated if another application activates the published application.
The Windows Installer can advertise the availability of an application to users or other applications without actually installing the application. If an application is advertised, only the interfaces required for loading and launching the application are presented to the user or other applications. If a user or application activates an advertised interface the installer then proceeds to install the necessary components as described in Installation-On-Demand.
The two types of advertising are assigning and publishing. An application appears installed to a user when that application is assigned to the user. The Start menu contains the appropriate shortcuts, icons are displayed, files are associated with the application, and registry entries reflect the application's installation. When the user tries to open an assigned application it is installed upon demand.
The installer supports the advertisement of applications and features according to the operating system. The installer registers COM class information for assigned applications beginning with the Windows 2000 and Windows XP systems. This enables the installer to install the application upon the creation of an instance of an advertised class. For more information, see Platform Support of Advertisement.
You can publish an application from the server beginning with the Windows 2000 Server. The published application is then installed through its file association or Multipurpose Internet Mail Extension (MIME) type. Publishing does not populate the user interface with any of the application's icons. The client operating system can install a published application beginning with the Windows 2000 and Windows XP systems.

20. Append the log file
21. Steps failed if the app is not functioning
22. What are the diff types of Upgrade?
Patching and Upgrades
Because an installation package can contain the files that make up an application as well the information needed for their installation, Windows Installer can be used to update the application. The installer can update information in the following parts of the installation package:
• The .msi file.
• The files of the application.
• The Windows Installer registration information.
The type of update can be characterized by the changes the update makes to the application's product code, product version, and package code. The application's product version is stored in the ProductVersion property. The application's product code is stored in the ProductCode property. The application's package code is stored in the Revision Number Summary Property.
An update that changes the application into another product is required to change the ProductCode of the application. For more information about which updates require changing the ProductCode see Changing the Product Code. The update can change the ProductVersion and leave the ProductCode unchanged if future versions of the application will need to differentiate between the updated and nonupdated versions of the current product. The Package Code uniquely identifies the installation package and should always be changed whenever update or upgrade changes any information in the installation package.
When deciding whether to change the product version, you should consider If future versions of the application will need to differentiate between the updated and nonupdated versions of the current product. To ensure differentiation in the future, a minor upgrade should be used instead of a small update.
• If an update changes the .msi file and application files, but does not change the ProductCode property or ProductVersion property, it is termed a small update.
• If the update changes the ProductVersion, but does not change the ProductCode, it is termed a minor upgrade.
• If the update changes the installation into an entirely different product, the ProductCode must change and the update is termed a major upgrade.
Note To ensure differentiation of versions of the current product in the future, a minor upgrade should be used instead of a small update.
The following table summarizes the different types of updates.
Type of update Productcode ProductVersion Description
Small Update
No change No change An update to one or two files that is too small to warrant changing the ProductVersion. The package code in the Revision Number Summary Property does change. Can be shipped as a full installation package or as a patch package.

Minor Upgrade
No change Changed A small update making changes significant enough to warrant changing the ProductVersion property. Can be shipped as a full installation package or as a patch package.

Major Upgrades
Changed Changed A comprehensive update of the product warranting a change in the ProductCode property. Shipped as a patch package or as a full product installation package.

23. What is com and y do u do for registering, how u will register manually
In Windows, COM classes, interfaces and type libraries are listed by GUIDs in the registry, under HKEY_CLASSES_ROOT\CLSID for classes and HKEY_CLASSES_ROOT\Interface for interfaces. The COM libraries use the registry to locate either the correct local libraries for each COM object or the network location for a remote service.

What is a COM component?
A COM component is commonly referred to as a COM Object. We can visualize a COM component or Object as simply a "black box" that comprises a set of methods and associated data. Internally, these Objects contain reusable code (Methods), and provide ways for an application to call the object's Methods and read/write its associated data through its Interfaces. Notice that this is the same definition as an object internal to your program. The difference is that COM offers a way to perform this functionality on an object external to your program.
A COM Component is generally known as a COM SERVER, because it serves up information or actions requested by a COM CLIENT. A COM SERVER makes its Methods and Properties public, so that a COM CLIENT can call them as needed.
COM Components usually take the form of an EXE, or DLL/OCX file, but the actual file extension is largely irrelevant. However, DLL/OCX versions of a component are generally referred to as "in-process", since they are loaded into the address space of the calling application. EXE-versions are typically "out-of-process" because they will not share the address space of the calling application.
To summarize, a COM Object (COM Server) is a special form of code library (similar to a standard DLL) that conforms to the COM specification. It provides at least one public interface, and is identified by a globally unique PROGID and CLSID.
Every class is associated with a GUID (a 128-bit number or string) which uniquely identifies this particular class from all others, anywhere in the world. This identifier is called the Class ID, or CLSID. A friendlier version of the CLSID is a shorter text name, which also identifies the Class. This text name is known as the PROGID, though it's possible this PROGID may not be totally unique. As it's a simpler construct, it might be duplicated in another program. These identifiers are stored in the Windows Registry when the COM component is installed and registered. PowerBASIC programmers reference COM components by their PROGID string, and rarely by their CLSID. However, since these two items are stored in pairs, it is straightforward to retrieve the matching PROGID for a known CLSID, and vice versa.
As mentioned earlier, you don't need to know how a television works internally to use it and benefit from it. Likewise, you don't need to know how a COM Object works internally to use it and benefit from it. You only need to know the intended job of the object, and how to communicate with it from the outside. The internal workings are well "hidden", which is called encapsulation. Since we aren't able to "look inside" a COM Object, it's not possible to directly manipulate internal variables or memory. This provides a increased level of security for the internal code and data.
The PowerBASIC Console Compiler can only create internal objects, COM and ActiveX objects can be created with the PowerBASIC For Windows Compiler.

24. No shortcut, no active setup, how to get the keys for the first log-in
25. What does u mean by differed CA, how you will decide what CA to be kept in which mode say differed or execute immediate
The purpose of a deferred execution custom action is to delay the execution of a system change to the time when the installation script is executed. This differs from a regular custom action, or a standard action, in which the installer executes the action immediately upon encountering it in a sequence table or in a call to MsiDoAction. A deferred execution custom action enables a package author to specify system operations at a particular point within the execution of the installation script.
The installer does not execute a deferred execution custom action at the time the installation sequence is processed. Instead the installer writes the custom action into the installation script. The only mode parameter the installer sets in this case is MSIRUNMODE_SCHEDULED. See MsiGetMode for a description of the run mode parameters.
A deferred execution custom action must be scheduled in the execute sequence table within the section that performs script generation. Deferred execution custom actions must come after InstallInitialize and come before InstallFinalize in the action sequence.
Custom actions that set properties, feature states, component states, or target directories, or that schedule system operations by inserting rows into sequence tables, can in many cases use immediate execution safely. However, custom actions that change the system directly, or call another system service, must be deferred to the time when the installation script is executed. See Synchronous and Asynchronous Custom Actions for more information about potential clashes between their custom actions and the main installation thread.
Because the installation script can be executed outside of the installation session in which it was written, the session may no longer exist during execution of the installation script. This means that the original session handle and property data set during the installation sequence is not available to a deferred execution custom action. Deferred custom actions that call dynamic-link libraries (DLLs) pass a handle which can only be used to obtain a very limited amount of information, as described in Obtaining Context Information for Deferred Execution Custom Actions.
Note that deferred custom actions, including rollback custom actions and commit custom actions, are the only types of actions that can run outside the users security context.

26. Response file means, how to call response in command line
Creating the Response File
InstallShield 12
A normal (non-silent) installation receives the necessary input from end users in the form of responses to dialogs. However, a silent installation does not prompt the end user for input. A silent installation must get its end-user input from a different source. That source is the InstallShield Silent response file (.iss file).
A response file contains information similar to that which an end user would enter as responses to dialogs when running a normal installation. InstallShield Silent reads the necessary input from the response file at run time.
The format of response files resembles that of an .ini file, but response files have .iss extensions. A response file is a plain text file consisting of sections containing data entries.
There are two ways in which you can create an InstallShield Silent response file: you can run the installation and have InstallShield record and create the response file for you, or you can write the response file directly.
Recording a Response File
You have the option of letting InstallShield create the response file for you. Simply run your installation with the Setup.exe -r command-line parameter. InstallShield will record all your installation choices in Setup.iss and place the file in the Windows folder.
All InstallShield built-in and Sd dialog functions are designed to write values into the Setup.iss file when InstallShield runs in record mode (Setup -r). If you are creating custom dialogs, you will need to call SdMakeName and SilentWriteData to add sections and dialog data to the response file when the installation runs in record mode. Refer to the Sd dialogs' source code in the \Include folder for examples of using these functions to write to Setup.iss. Read the following section for more information about what data to add to Setup.iss when calling SdMakeName and SilentWriteData.
Manually Creating a Response File
You can also create the response file completely by hand. As mentioned, the Setup.iss file is similar to an .ini file. The sections of an InstallShield response file must be in the following order:
1. Silent Header Section
2. Application Header Section
3. Dialog Sequence Section
4. Dialog Data Sections (one per dialog)
Section names are contained in square brackets, as in [InstallShield Silent].
Data entries follow their section names and consist of pairs, as in the following example:

27. How will make single MST, when we give 5 MST in InstallShield
28. In IRP, whether u can apply std, what r the things can be done in IRP
29. Response iss file can be created for what type of setups

Monday, 7 June 2010

Packaging Interview questions - 1: MP's

1. Briefly explain about your process.
2. What is Dual Run?
3. What tool u r using right now?
4. What is best practices for Quality and as well Microsoft
5. What is difference b/w Publishing and advertised shortcut?
6. What is the difference b/w selfheal and repair?
7. What is /FA?
8. What is schema in wise?
9. What is the use of MSIFile Hash table?(Scenario: suppose MSI has 400 files, but in the MSiFileHash table 50 entries, explain why?)
10. Did u package IE? Adobe applications? What is outcome if do that either MSI/MSP/MST?
11. What is the difference b/w Alluser=1 ,2,0?
12. What is Upgrade? What is the difference b/w Product code and Package code?
13. There two features A and B. there is component C which is having shortcut that under B Feature. When we install the application shortcut is not installing. How will you troubleshoot?
14. What is Lockdown Environment?
15. What is the difference b/w Service and executable service?
16. If you add the advertised shortcut what tables will be effected?
17. What is secure custom properties? Example
18. What is Restricted Public properties? Example
19. Short cuts should not get installed but how will you findout whether its having Advertising shortcut or not?
20. What is patch? How will u implement that?
21. What is Response Transform? How can u create the Response Transform.
22. What is Multithread model ?
23. Explain about the deffered ?
24. What is Windows file protection?
25. What is Dll Hell?
26. What is component Isolation?
27. Do u know about ACT?
28. Why selfreg table should be empty?
29. Signature table.
30. Can we set keypath for ini file?

Monday, 26 April 2010

VMWare 3.0.1 build-227600

Virtual Machine : VMware
Apps Repackaging : VMware 3.0.1 Build - 227600
Issue : VMWare will not install on VMWare virtual machine
Soln : If we install VMWare Silently it will install

1. Extract the Souce file from VMware-player-3.0.1-227600.exe using command
Msiexec /e
2. Taking base MSI as “vmware player.msi” create the transform Using ORCA
3. Apply properties
REBOOT= ReallySuppress

4. Using Install Shield Edit MST to add files “preferences.ini” and Script “Copy_Pref_Users.vbs” to copy files to install directory folder
'On Error Resume next
'Option Explicit
dim path,prog
Set ObjShell = CreateObject("WScript.Shell")
set objFSO = CreateObject("Scripting.FileSystemObject")

path = ObjShell.ExpandEnvironmentStrings("%APPDATA%") & ("\VMware\")

If Not objfso.FolderExists (path) Then


End if

prog = objshell.ExpandEnvironmentStrings("%ProgramFiles%")

objFSO.CopyFile prog & "\VMware\VMware Player\preferences.ini", path

5. Add Active setup to apply setting to all profiles

Friday, 26 February 2010

QA : How can I modify ntuser.dat for base profile

QA :
How can I modify ntuser.dat for base profile "Default User". Regedit is not possible and copying a modified file from an existing user will also copy the users entries.
Modifications are needed for each user logging on for the first time to the machine. System is XP Professional.
Editing the Registry for "other" Users
From an account with Administrator level access
1) Click Start, Run and enter REGEDIT
2) In Regedit, highlight the HKEY_USERS key and go to File, Load Hive.
3) Use the File Open dialog to go to the Documents and Settings\ folder, where is the account you wish to modify.
4) Highlight the NTUSER.DAT file in this folder (usually a hidden file) and select Open.
5) You'll be prompted to enter a "Key name". You can use whatever you wish, but I use the User's logon name.
6) You can now expand the Hive you just loaded and make any needed changes.
7) When finished, highlight this Hive again and go to File, Unload Hive.
NOTE: You MUST unload the Hive prior to logging on to the users account. Otherwise XP may have trouble loading the user's profile.