Packaging Questions

For more information visit these sites:

www.appdeploy.com
www.wisesolutions.com
www.microsoft.com (search for windows installer)

what is packaging? Why do u do it?

Ans: packaging Is the process of creating a setup.exe with a developed code. Repackaging is
converting this setup.exe to setup.msi by using windows installer technology with a tool like wise
package studio or install shield.
Why we do is?------refer ans 2.

advantages of packaging?
Ans: a) Easy deployment and maintenance
b) Self repair of applications
c) Remote installation
d) Applications will not conflict with each other plus avoiding system crash
e) Web deployment is possible.

Packaging process?
Ans: tech review of given setup.exe- setup capture scripting the wsi file obtained by setup
capturecompiling and generating msi package validating msi and debugging errorsconflict
management and deployment.

What do u do when package is given?

Ans: same as ans 3

use of registries? How many registry hives are their? Explain.

Ans: registries are used to point to the files. They contain path of a file,from where to fetch the file
and compress it into msi. Also registries are called when application is launched.applications reads
the entries in the registries and fetches the files as and when required.
Registry hives: HKCR,HKCU,HKLM, HKUsers
HKCU—user specific registry
HKLM--- Machine specific registry

For detailed info go to start menuruntype regedit.

what is the use of files?

Ans: files are called when the application is running. There are various types of files like .exe, .ico, .ini
etc. they are called associations.

7) What is difference between features, components and files?

Ans: application contains many features, features contain components, and components contain files.
Like this application is gathered.

8) what is ini file? What it does?

1
Ans: ini file is information file or initialization file. It is having some information required by the
application during running. It can contain server name, registries values, path name, device name,
system name anything, which changes frequently.

9) what is dll conflict?

Ans: application tries to install the dll, which is already present in the machine this leads to dll conflict.
To solve this we reference count dll’s by ticking the checkbox in the component. One more solution is
to isolate the components in the application by using wise tool.

10) what is software distribution?

Ans: software distribution is putting applications in central place so that it is available to all users.

11) what are various installations? Explain one with example.

Ans: various installations:
remote installation
on demand installation
wireless installation
server installation
Remote installation: admin sitting on one machine can install to 1000 machines across the
network.

12) what is dependency?

Ans: some applications are depending upon other applications like front end vb calling backend
oracle.
So here for vb application of this kind oracle is dependency.

13) what is custom action? Why we use it?

Ans: custom action is nothing but special vb script or wise script written and called in between the
package to do required task.
Ex: to remove some services or registries etc.

14) what is meant by client standards?

Ans: various clients have various requirements , like we want application name with version and
name without version, we want these shortcuts, we don’t want these files in the package etc.

15) XP features—why we migrate applications from NT to XP?

Ans: XP features which are not present in any other windows:
system restore point
application can’t touch the code kernel of XP-OS
doesn’t need restart after installing most applications
forward and backward compatability

16) what is msi?

Ans: msi file is complete application, which actually contains the resources of the application like
files, registries etc which are needed for the installation.

17) what is mst and use of mst?

Ans: to make any customizations in the application and to implement business rules we create mst’s.
mst is like cap on msi.
2
Ex for customization: u can decide how many shortcuts u want etc

18) what u get after capturing the application?

Ans: capture means--- start wise tool and start capturing before installing the application which is to
be packaged and install the application and again perform the same operation, now all changes to
the system are recorded. this is capturing. After capturing u will get output as .wsi. by compiling
this .wsi u get .msi.

19) what is difference between wsi and msi?

Ans: wsi file ----- this we get immediately after capture, this is output of the capture process. Wsi file
contains the information about from where files are to be taken or fetched and compressed to
produce msi file.
When u compile wsi file u get msi file as output. Msi file will be containing files physically compressed
and put in it.
Wsi is like a root map of application but msi is result of compiling wsi
Ex: after compiling code we get exe file, same way we get msi after compiling wsi.

20) what is rollback? How u will handle it?

Ans: if some problem occurs while installing the application, then instead of stucking in between the
installation process, windows installer will rollback the installation and remove all that is installed.
Means application is either installed fully or it is not installed at all.

21) what is uninstallation ? how u deal with it?

Ans: uninstall is a process of removing everything which is installed. If some files or registries are
remained even after uninstall they are removed by putting them in “remove file table”.

22) what is application repair i.e self healing.

Ans: after installation when user is using application if some file is deleted accidentally windows
installer will take that file and reinstall it to the user. i.e application is repaired automatically. This
process is called self healing or repair.
How does the self repair feature works?
When an MSI entry point is triggered all files marked in the MSI as keypaths are verified to exist
before execution. Each component in a feature contains one or more elements, one of which is
marked as a keypath. When discovered to be missing, an installation is triggered at the feature level
(for repackaged applications, this is often the entire package). Checks to verify if a file is the correct
version, or if the file is corrupt is possible, but is not the default behavior. Such a check must be
specified when the MSI is authored as to perform such a check of all files would be an intensive
process that would affect system performance.

23) what are merge modules?

Ans: These are the files with .msm extension, used by multiple applications. It contains various files,
dll,ocx etc
Ex: MDAC is a merge module.

24) Why do package keep reinstalling?

Ans: If a key file is found to be missing on launch, Windows Installer will trigger a reinstallation of the
parent feature. Having a "clean" package is key.
To find out just what the problem is, look in your Application Event log. Or for more detail, turn on
Windows Installer logging and search for the word "error" in the resulting log file (found in %TEMP%).
3
Some common reasons why this may occur:
Missing Files or Registry Keys
Look closely- some files are deleted by the application itself. If your package contains such a file it will
self-heal in order to restore the file each time.
Temporary Files Included In MSI
If any temporary files left on the system are captured in your package, they may cause self repairs to
occur in order to restore them.
HKEY_CURRENT_USER Keys in Package
HKCU Keys are installed only for the current user. Therefore, the first time the application is run by
each user, the HKCU keys belonging to the package will not exist resulting in a reinstallation of the
containing feature.

25) What operating systems come with Windows Installer?

Ans: Microsoft Windows 2000, Windows Millennium Edition (Windows Me), and Windows XP include
Windows Installer. Windows 2000 includes version 1.1 of Windows Installer, Windows Me includes
version 1.2, and Windows XP includes version 2.0. Windows 2000 SP3 also contains version 2.0 of
Windows Installer. Windows XP SP2 includes version 3.0.

26) How to specify files not be removed after uninstall?

Ans: You may specify what files should not be removed during uninstall at the component level.
However, the terminology differs between the Wise and InstallShield products:
In Wise Package Studio:
In the "Setup Editor" view, locate and right click on the component that contains the file you wish to
have remain on the system after an uninstall operation.
Select "Details" and then check the "Leave installed on uninstall" checkbox.
In InstallShield AdminStudio:
Choose "Components" from the "Organize Your Setup" tree on the left and select the component you
wish to have remain on the system after an uninstall operation.
Change the "Permanent" property of the component to "Yes".

27) How to see what public properties are available?

Ans: Any properties listed in the property table that are written in CAPITOL letters are public
properties that may be set from the command line.

28) How to control the destination directory of the package?

Ans: By default an MSI will place itself on the drive with the most available free space. This can be
controlled via the ROOTDRIVE public property.
The ROOTDRIVE property specifies the default drive for the destination directory of the installation. If
the Directory column of the Directory table indicates the root destination directory by a property name
that is undefined, the installer uses the value of the ROOTDRIVE property to resolve the path to the
destination directory.
The value for this property must end with '\'.

29) Can we install device drivers with msi?

Ans: The ServiceInstall Table allows for the installation and control of services to a limited degree.
Not supported are: SERVICE_KERNEL_DRIVER (a driver service) and
SERVICE_FILE_SYSTEM_DRIVER (a file system driver service.)

4
Repackaging hardware is problematic at best, the consensus seems to be that the creation of a
custom action which performs the hardware installation via an INF file is the way to go.

30) What are the system requirements for install on demand features?
Ans: Self repair only works with the “Desktop Update” from Microsoft, that means the shell32.dll
needs to be version 4.72.3110.0 or higher.
The application must also be launched from the Advertised Icon created by the MSI package- running
the executable from File Manager or creating your own shortcut (.LNK) will bypass the Install-on-
demand or repair process of the Windows Installer.

31) What is windows installer?

Ans: The Windows Installer manages application installation, modification, repair and removal. It is
both a command line utility and a service for the management of application installation on Windows
systems. Windows Installer packages are self-contained database files containing requirements and
instructions that are followed when applications are installed. Among several key benefits gained
include:
 Consistent installation rules
 Better management of shared components
 Dynamic configuration and control

32) How do I install only the features I want?

Ans: The ADDLOCAL, ADDSOURCE, and ADVERTISE properties can be used to install only a
certain number of known features. The following command-line script would be used to install the
"Sports" and "News" features of the example.msi package locally on the machine.
msiexec /i example.msi ADDLOCAL=Sports,News /qb
The following command-line script would advertise the "Sports" feature and install the "News" feature
to run from source.
Msiexec /i example.msi ADVERTISE=Sports ADDSOURCE=News /qb
Another important thing to remember is that feature names are case-sensitive.

33) What is a managed application?

Ans: A managed application is an application where the system administrator exerts some level of
control over the installation and maintenance of the product. Managed applications are often used to
deploy software to large numbers of users or machines. Managed applications are a way for system
administrators to allow users to install authorized software in locked-down environments where users
generally do not have the rights to install software.
An application is considered managed if it is:
• Installed or advertised to a user by a member of the Administrators group.

• Installed or advertised per-machine by a member of the Administrators group.

• Assigned or published on Windows 2000 and later by an Administrator.

• Marked as managed by another software and deployment management system. The exact method
depends on the management system used, but generally requires an administrator's action.

5
An installation package cannot declare itself "managed." Whether or not an application is managed is
controlled by the system administrator.
Note that "managed" is different from "elevated." An elevated application is an application that can
run with system privileges when installing. All managed applications are elevated, but applications
can be elevated without being managed by means of the AlwaysInstallElevated policy. Due to its
security implications, this policy is disabled by default and requires careful consideration before use.

34) What are the differences between a 'deferred' custom action and an 'immediate' custom
action?
Ans: Deferred custom actions can only be sequenced between the InstallInitialize and InstallFinalize
actions in execute sequence tables. Immediate custom actions, on the other hand, can be sequenced
anywhere within any of the sequence tables.
Deferred custom actions cannot access the installation database. In fact, deferred custom actions
have very limited access to the installation session because an installation script can be executed
outside of the installation session that created it. Immediate custom actions have access to the
installation database and can read and set installation properties, modify feature and component
states, and add temporary columns, rows, and tables among other things.
While both deferred and immediate custom actions can run in the context of the user initiating the
installation, only deferred custom actions can run elevated using the system context.
Deferred custom actions are not executed immediately. Instead they are scheduled to run later during
the execution script. The execution script isn't processed until the InstallExecute, InstallExecuteAgain,
or InstallFinalize action is run.

35) When should I use a deferred custom action instead of an immediate custom action?
Ans: Deferred custom actions should be used when the custom action must make a change to the
system or call another system service. Additionally, only deferred custom actions can run in an
elevated context. If your custom action requires elevated privileges in order to run, your custom action
needs to be marked as deferred.
Note: Custom actions marked to run in the system context (msidbCustomActionTypeInScript +
msidbCustomActionTypeNoImpersonate) will only run in the system context if the installation itself is
elevated.
Additionally, when making a change to the system by means of a custom action, you should also
include a rollback custom action that can undo the change.

36) What are the differences between small, minor, and major updates?
Ans: A small update is a product update that changes a few files or possibly adds some new content.
A minor update is a product update that makes enough changes to warrant changing the product
version for the product, whereas a major update is a product update with a large number of changes
that warrants a change in the product code. This table summarizes what changes in each update and
the possible distribution vehicles for each.
It's sometimes easier to think of a small update as a "hotfix" or Quick Fix Engineering (QFE) update, a
minor update as a service pack, and a major update as a product upgrade.
Small and minor updates can be considered almost equal in that the only real difference is that a
minor update has a change to the ProductVersion whereas a small update does not. The rules that
they follow and application of the patch are the same. Application of small and minor update patches
requires explicit reinstallations. Major updates are not subject to that limitation and a reinstallation is
not required for patch application. Additionally small and minor update patches are limited in the
changes that can be made to the feature-component structure for the package. Significant changes
can be made to the feature-component structure in the scope of a major update.
6
37) How can I figure out why my package fails to install?
Ans: There are three good troubleshooting methods for tracking down package installation problems.
The first method is to ensure that your package is valid by running validation. Validation helps catch
common installation authoring problems by identifying errors and warnings. Two tools can be used for
validating an installation package, both are available in the Windows Installer SDK: MsiVal2 and
Orca. MsiVal2 is a command line utility for validating a package. Orca provides a graphical user
interface for validation and will also highlight invalid entries in the package.
The second method is to use the application event log. Windows Installer will record successful and
failed installation information in the application event log.
The final method is to generate a verbose log file, and then analyze the verbose log file looking for
the source of the error. A helpful utility for analyzing verbose log files is the WILogUtl.exe tool
provided in the Windows Installer SDK. Logging can be enabled via Windows Installer logging policy
or by appending "/L*v path to logfile" to your MSIExec command line.

To generate a detailed verbose log file through policy, use the following registry key:

• HKLM\Software\Policies\Microsoft\Windows\Installe
r

• Set: Logging = REG_SZ voicewarmup

• Set: Debug = REG_DWORD 0x7

Log files generated through the policy key will be of the form msiXXXXX.log in the user's %temp%
folder.
Note: Logging through the command line overrides any logging policy settings.

38) Every time I launch my application, Windows Installer performs an installation. How can I
determine the cause of the on-demand installation?
Ans: An easy way to determine the cause of an on-demand installation is to look in the application
event log for MsiInstaller log messages of the form:
Event Type: Warning
Event Source: MsiInstaller
Event ID: 1001
Description:
Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example' failed during
request for component '{00030829-0000-0000-C000-000000000046}'
Event Type: Warning
Event Source: MsiInstaller
Event ID: 1004
Description:
Detection of product '{000C1109-0000-0000-C000-000000000046}', feature 'Example', component

7
'{00030829-0000-0000-C000-000000000046}' failed. The resource 'C:\Progam
Files\example\example.exe' does not exist.
The first message (with event ID 1001) states which component was being installed. The component
listed here is the component named in the Component_ column of the Shortcut table for the particular
shortcut.
The second message (with event ID 1004) indicates which component failed detection. Improved
event logging in Windows Installer 2.0 has updated the message so that in most cases, the message
identifies the actual resource that resulted in the failed detection. The component with the missing or
damaged keypath is the component that is triggering the reinstallation.
In the example above, the reinstallation is triggered because the resource 'c:\Program
Files\example\example.exe' does not exist. You would then need to find out why the keypath does
not exist—in this case, the user deleted it.

39) How can I determine whether Windows Installer installed my feature or component?
Ans: Determining whether Windows Installer installed a particular feature or component is fairly easy.
The answers can be found in a Windows Installer verbose log file. The first thing to look for is the
logging of the InstallValidate action. This action will log the installed, request, and action states of
each feature and component in the installation package.
MSI (s) (5C:F4): Doing action: InstallValidate
Action start 1:51:18: InstallValidate.
MSI (s) (5C:F4): Feature: Example; Installed: Absent; Request: Local; Action: Local
MSI (s) (5C:F4): Component: Example; Installed: Absent; Request: Local; Action: Local
Action ended 1:51:18: InstallValidate. Return value 1.
In the log file snippet shown above, the "Example" feature will be installed locally since its action state
is local. Furthermore, the component "Example" will also be installed locally given its action state.

40) Why are my files not being removed during uninstallation?

Ans: There are four common reasons for why files may not be removed during uninstallation:
• The components to which these files belong are marked as permanent. (This is done through the
Attributes column of the Component table.)

• None of the components to which these files belong have component GUIDs. (The value for the
component in the ComponentId column of the Component table is NULL). Components without
GUIDs are not managed by Windows Installer.

• If the keypath of the component has a shared DLL refcount, then the component will not be
uninstalled.

• If the component is installed in the system folder and at the time of uninstallation there is an
external shared DLL refcount for any one file in the component, then the component will not be
uninstalled.

41) Why are my folders not being removed during uninstallation?

Ans:
Folders are not removed during uninstallation because of one of the following reasons:
• The RemoveFolders action is missing from the execute sequence table when both the

8
 CreateFolder table and CreateFolders action are used.

• The folders were not created by Windows Installer, therefore it will not remove them unless
told to do so.

• Resources still exist in the folder.

42) Why are my registry keys not being removed during uninstallation?
Ans: The most common causes for leaving behind registry keys during uninstallation are:
1 The Registry table contains entries marked with the '+' sign. This directs the installer to leave
. behind those registry keys during uninstallation.

2 In the InstallExecuteSequence table, the RemoveRegistryValues action is sequenced after the

. UnregisterProgIdInfo and UnregisterMIMEInfo actions. The sequence of these actions needs to
be reversed. The presence of some registry values written from the Registry table prevents
certain ProgId, extension, and CLSID keys from being removed.

43) Why is the disk space consumed by the installation so much larger than the actual sizes of
the files I am installing?
Ans: Windows Installer calculates two types of space consumption: the space consumed with
rollback, and the space consumed without rollback. The space consumed without rollback is the
actual disk space consumed by the installation. The space consumed with rollback will include the
space of the backup files necessary for supporting rollback during the installation. Additionally,
Windows Installer calculates some of the overhead required for performing the installation. Included
in the overhead is the space required for the installation script and the space requirements of the
cached package. Furthermore, the installer runs from a temporary copy of the installation package
during the installation. Both the space requirements of the installation script and the space
requirements of the running copy of the package are temporary. These files are cleaned up after
installation. Consider the following example where your installation package is around 80 kilobytes
(KB) in size and you are installing a 4 KB file (Note: your numbers may vary depending on the cluster
size of your hard drive):
89120 bytes (cached MSI, rounded to nearest cluster size of 4 KB)
89120 bytes (temporary working copy of MSI)8192 bytes (estimated script size)
4096 bytes (small file, rounded to disk cluster size of 4 KB)
----------------------
176128 bytes = 172 KB

44) Why is Windows Installer prompting for a reboot?

Ans: Windows Installer may prompt for a reboot if it installs over a file that is in use or the package
explicitly requests that the installer reboot. It is easy to determine if Windows Installer prompts for a
reboot because it installed over a file that is in use. The first step is to generate a verbose log file. In
the verbose log file, look for the presence of the ReplacedInUseFiles property in the property dump. If
this property is present with a value of 1, then the Installer will require a reboot because it overwrote
an in-use file.
To determine which file was in-use, scan the log file for "Info 1603" and "Info 1903" messages. The
1603 message will be logged by the InstallValidate action. For example:

9
MSI (s) (DC:DC): Doing action: InstallValidate
Action start 19:55:42: InstallValidate.
…
Info 1603. The file d:\test\sample.exe is being held in use by the following process: Name:
sample.exe, Id: 4068, Window Title: 'Sample'. Close that application and retry.
Normally, this message coincides with the presentation of the FilesInUse dialog box. In silent UI
cases, this dialog box will not be presented. Additionally, not all files that are in use will show up in the
FilesInUse dialog box. The FilesInUse dialog box may not be displayed if the files in use are not
executables, the process holding the files is the process invoking the installation, or the process
holding those files is one that does not have a window title associated with it.
The FileCopy opcode in the install script can also log the 1603 info message. In the above example,
the log file contains:
MSI (s) (DC:DC): Executing op: FileCopy(SourceName=sample.exe, SourceCabKey=sample.exe,
DestName=sample.exe, Attributes=0, FileSize=2044928, PerTick=32768, , VerifyMedia=1, , , , ,
CheckCRC=0, Version=2.0.2600.0, Language=0, InstallMode=59244544, , , , , , )
…
Info 1603. The file D:\test\sample.exe is being held in use. Close that application and retry.
At the end of the script during cleanup, the following log file message identifies the culprit for the
reboot:
Info 1903. Scheduling reboot operation: Deleting file D:\Config.Msi\12544a31.rbf. Must reboot to
complete operation.
While the file is named 12544a31.rbf, it is the Sample.exe file. In order to install the file, the in-use file
was renamed to the .rbf file and will be deleted upon reboot.

45) What does the ERROR_INSTALL_PACKAGE_VERSION error (1613) mean?

Ans: The error ERROR_INSTALL_PACKAGE_VERSION means that the version of Windows Installer
on the machine does not support the schema of the package. The package schema is indicated by
the PID_PAGECOUNT property in the summary information stream of the package. If the schema
number of the package is greater than the maximum supported schema by Windows Installer, you will
need to update your version of Windows Installer or re-author the package to be compatible with an
earlier schema.
The minimum supported schema for all versions of MSI is 30.
The maximum supported schema for each version of MSI is:
• Windows Installer 1.0:
100

• Windows Installer 1.1:

110

• Windows Installer 1.2:

120

• Windows Installer 2.0:

200

46) When launching an installation from a system account, I receive error 2103. Why?
Ans: Launching an installation from a system account, like the scheduler service, may result in the
2103 error. This can occur if you are initiating a per-user installation. Only per-machine installations
10
are permitted from the system account because the system account does not have all of the
necessary per-user profile folders.

47) Why do I receive error 2755 when launching an installation from a mapped drive letter on a
terminal server?
Ans: Windows 2000 and earlier operating systems do not support passing mapped drive letter
information between terminal server sessions. Since Windows Installer service runs as a service in
the console session, mapped drive letters established in remote sessions are not visible to Windows
Installer service, resulting in this error. This only applies when running the service in Application
Server mode, not Remote Admin mode.
Note that this limitation no longer exists in Windows XP and later operating systems.

48] The product code must be changed if any of the following are true for the update:
 Coexisting installations of both original and updated products on the same system must be
possible.
 The name of the .msi file has been changed.
 The component code of an existing component has changed.
 A component is removed from an existing feature.
 An existing feature has been made into a child of an existing feature.
 An existing child feature has been removed from its parent feature.
 When using a version of the installer prior toversion 2.0, the product code must be changed if a
component has been added to an existing feature. With version 2.0, and later versions, a
component may be added to an existing feature without requiring a product code change.
Note that adding a new child feature, consisting entirely of new components, to an existing feature
does not require changing the product code.

Path Variables View

This view and its subviews do not appear in the following project types:
• MSI Database
• MSM Database
• Transform
• Smart Device
The traditional way to link to source files in an installation project is to create a reference to that file
using a hard-coded path. For example, you might have a source file called Program.exe located at
C:\Work\Files that you want to include in your installation.
11
Using Hard-Coded Paths
If you use hard-coded paths, you have to enter the entire path every time you want to associate a
source file from that directory. If you move the file to another directory, you have to change the hard-
coded path as it appears in your installation project. If your installation consisted of a small number of
source files, this might not be a problem. Unfortunately, some installations contain thousands of files
that all need to be remapped if you change the folder structure or migrate the project to a different
machine.
Using Path Variables
Overview
With path variables, you can define commonly used paths in a central location so that you do not
need to change every source file's path each time you move the project or change the directory
structure. In the previous example, if you keep all of your application's source files in various
subfolders under C:\Work\Files, you could create one variable that points to the Files folder—
<MyFiles>. If you want to include a file that is in C:\Work\Files\Images, you enter <MyFiles>\Images.
If you move your files to D:\Work\Files, you can go to one place, your variable <MyFiles>, and change
the folder that it points to.
Using the Path Variables Explorer
All path variables can be viewed and modified in the Path Variables explorer in the Path Variables
view. You can use path variables in almost any location in InstallShield where you link to source files,
such as in the Dialog Editor, dynamic file links, and the release location. Instead of entering the path
variables yourself, you can have InstallShield recommend them whenever you browse to a path.

NOTE
Path variables are used during the development of your installation project. These paths do not apply
to the target machines where the application is being installed. Rather, they are used to link to source
files for your installation project. When the project is built, those links are evaluated and the files they
point to will be built into the installation.

Path Variables Types

There are four types of path variables that you can use. Each type functions somewhat differently
from the others. Regardless of the path variable type you use, the variable name is provided in the
same manner throughout InstallShield.

Types of Path Variables

Variable Type Description

Predefined Predefined path variables are path variables that point to some of the most commonly
12
 used folders. Unlike other types of path variables, these values cannot be edited in
Path Variables
InstallShield.

See Registry The values of registry-based path variables are derived from the registry keys you
Path Variables created. After creating the registry key, you need to set a path variable to this key.

Environment path variables are based on the values of your system's environment
Environment
variables. You can set an environment path variable to an existing environment
Variables
variable.

Standard, or user-defined, path variables are defined through InstallShield. You can
Standard Path
specify a path variable such as <MyFiles> with a value of C:\Work\Files. These
Variables
variables do not rely on any outside sources, such as the registry or system paths.

MSI (s) (3C:CC) [07:52:18:321]: Feature: CitiAudit; Installed: Absent; Request: Local; Action: Local
MSI (s) (3C:CC) [07:52:18:321]: Feature: Complete; Installed: Absent; Request: Local; Action:
Local

13