Impersonate the non-privileged token
Take a look at this link. http://blogs.msdn.com/heaths/archive/2006/09/26/Custom-Actions-under-UAC-in-Vista.aspx
As issues are being found, little by little tidbits of information are starting to emerge on what will and what won't work in a MSI installation on Vista. This type of information is something that we need to employ now when we work on a MSI installation rather than waiting 6 months for a plan on how to deploy Vista.
While this article speaks to patches, it is applicable for any MSI installation that employs Custom Actions. This article also talks of Visual Studio 2005. Many Custom Actions were written with VB script which as recommended utilized Impersonate to use the installers credentials to perform an operation. That will cause the installation to fail in Vista unless we utilize some of the work around.
All need to start checking the Custom Actions table to see if any custom actions have been added to the installation. If so they need to be examined to determine if they will work with the default settings found in HKLM\Software\Microsoft\WBEM\Scripting\Default Impersonation Level.
If we start to depend on "Work Arounds" now, we will be poking the first security holes in an Operating System we haven't even deployed.
As issues are being found, little by little tidbits of information are starting to emerge on what will and what won't work in a MSI installation on Vista. This type of information is something that we need to employ now when we work on a MSI installation rather than waiting 6 months for a plan on how to deploy Vista.
While this article speaks to patches, it is applicable for any MSI installation that employs Custom Actions. This article also talks of Visual Studio 2005. Many Custom Actions were written with VB script which as recommended utilized Impersonate to use the installers credentials to perform an operation. That will cause the installation to fail in Vista unless we utilize some of the work around.
All need to start checking the Custom Actions table to see if any custom actions have been added to the installation. If so they need to be examined to determine if they will work with the default settings found in HKLM\Software\Microsoft\WBEM\Scripting\Default Impersonation Level.
If we start to depend on "Work Arounds" now, we will be poking the first security holes in an Operating System we haven't even deployed.
0 Comments
[ + ] Show comments
Answers (0)
Please log in to answer
Be the first to answer this question
Rating comments in this legacy AppDeploy message board thread won't reorder them,so that the conversation will remain readable.
