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 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 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.
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.
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. Custom actions marked to run in the system context (msidbCustomActionTypeInScript + msidbCustomActionTypeNoImpersonate) will only run in the system context if the installation itself is elevated.
Best Practice: When making a change to the system by means of a custom action, its always a better to include a rollback custom action that can undo the change.
You can look at the below link, to understand more on accessing the MSI database Property in deffered context.
Hope this Helps..!!!
Microsoft MVP [Setup-Deploy]