Hello,
How can we check whether elevated privileges are enabled on a system?
Steve
This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Elevated privileges?
Started by
Steve55
, Oct 26 2005 20:03
2 replies to this topic
Posted 26 October 2005 - 20:16
More questions.
How to check if Rollback has been disabled on the target computer?
What type of actions on the target computer can be categorized into Deferred Execution in System Context? Can anyone give some examples?
Why do we need Deferred Execution in System Context custom actions?
Steve
How to check if Rollback has been disabled on the target computer?
What type of actions on the target computer can be categorized into Deferred Execution in System Context? Can anyone give some examples?
Why do we need Deferred Execution in System Context custom actions?
Steve
Posted 26 October 2005 - 20:33
First, the elevated privilige is only effective when both the user and the machine policy are set. During an install:
Priviliged AND NOT AdminUser
Otherwise, read the registry keys in HKLM\Policies and HKCU\Policies (Try the Windows Resource Kit for better info)
Rollbacks: Note this can also be set on the commandline. A property will be set.
Typically you run CAs in system context if the CA requires priviliges that the installing user may not have, for instance writing in HKLM or Windows folder. Actually those are bad examples, you should use the designated tables for this. Better examples are creation of local accounts for services, creating file shares, installing device drivers...
In such CAs you should not access user-specific areas, like the HKCU registry, the My Documents folder etc. Beware of access to other computers too.
Priviliged AND NOT AdminUser
Otherwise, read the registry keys in HKLM\Policies and HKCU\Policies (Try the Windows Resource Kit for better info)
Rollbacks: Note this can also be set on the commandline. A property will be set.
Typically you run CAs in system context if the CA requires priviliges that the installing user may not have, for instance writing in HKLM or Windows folder. Actually those are bad examples, you should use the designated tables for this. Better examples are creation of local accounts for services, creating file shares, installing device drivers...
In such CAs you should not access user-specific areas, like the HKCU registry, the My Documents folder etc. Beware of access to other computers too.