Re: What privileg is necessary while CallNtPowerInformation() be c

From: Yu Chen [MS] (yuchen_at_online.microsoft.com)
Date: 03/16/05 

Date: Wed, 16 Mar 2005 10:10:25 -0800

Could you let me know what version of Windows (including SP#) you are
running? And a msi log might be useful in troubleshooting:
http://support.microsoft.com/kb/223300 

-- 
Yu Chen [MS]
This posting is provided "AS IS" with no warranties, and confers no rights.
"Victor Liu" <victor-no_spam@cyberpowersystems.com.tw> wrote in message
news:052A6DED-0D93-4925-A621-7BA4DC015B12@microsoft.com...
> Yu,
> thanks for your reply.
>
> I find the method to change the type of custom commit action via SDK tool
> orca to modify my .msi file, it's action type be modified from 0x612 to
> 0xe12, because this action will to involke a external executable file and
in
> commit action, deffered + no-impersonal (there is your suggestion), so it
be
> combined with
> msidbCustomActionTypeInScript(0x400) +
> msidbCustomActionTypeNoImpersonate(0x800) + msidbCustomActionTypeExe +
> msidbCustomActionTypeSourceFile(0x12) and 0x200(I guess this is means
commit
> action).
>
> but it still not work for hibernate file be enable and
> CallNtPowerInformation() still return 0xc0000061 error code.
>
> "Yu Chen [MS]" wrote:
>
> > I'm new to msi myself. I think you need to set the
> > msidbCustomActionTypeNoImpersonate bit. From MSDN:
> >
> > If the msidbCustomActionTypeNoImpersonate bit is set and a managed
> > application is being installed with administrator permission, the
installer
> > may run the custom action with elevated privileges.
> >
> > -- 
> > Yu Chen [MS]
> > This posting is provided "AS IS" with no warranties, and confers no
rights.
> >
> > "Victor Liu" <victor-no_spam@cyberpowersystems.com.tw> wrote in message
> > news:CF07CECF-9CEA-4712-97FA-05D8AF12B05C@microsoft.com...
> > > I am very appreciate for your help.
> > >
> > > after check the MSDN:
> > >
> > > Custom Action Security / Windows 2000 and later servers
> > >
> > > For Microsoft® Windows® 2000 and later servers, if the
> > > msidbCustomActionTypeNoImpersonate bit is not set for a custom action,
the
> > > installer runs the custom action with user-level privileges.
> > > --
> > >
> > > in my condition, I use the external executable file to be invoke by
> > > installer custom post-action to accomplish enabling hibernate
function,
> > and I
> > > restrict the .msi file only be startup with adminstrator's user, so I
> > think
> > > the post-action,executable file, will be run with adminstrator's
> > authority,
> > > but I don't know why it not work.
> > >
> > > I am not familiar with installer. I try to understand what you said,
and I
> > > take a lot of time to check MSDN and got nothing to sense, so I hope
you
> > can
> > > give me more information and detail and directly solution, if you
could.
> > >
> > > thanks.
> > >
> > >
> > > "Yu Chen [MS]" wrote:
> > >
> > > > I talked to the msi team. Turned out I might be wrong in the first
> > place.
> > > > The msi service is running under local system account which does
have
> > this
> > > > privilege. The solution they suggested is: marking the custom action
as
> > > > deferred + no impersonate.
> > > >
> > > > More details:
> > > > There were some fixes in MSI 3.0 to better support custom actions
that
> > ran
> > > > as the user performing the installation to be able to acquire
> > privileges.
> > > > Prior to MSI 3.0, any privilege that wasn't specifically enabled at
the
> > time
> > > > the installation was invoked would be stripped by DCOM when run as a
> > custom
> > > > action.  With 3.0 that doesn't happen so a custom action can acquire
the
> > > > privilege.
> > > >
> > > > My hypothesis is you have a custom action that is not marked no
> > impersonate
> > > > and therefore runs as the user.  Your customer is using MSI 2.0 and
> > > > therefore is subject to the DCOM permission stripping. That's why it
> > doesn't
> > > > work. In that scenario, marking the custom action as deferred + no
> > > > impersonate should fix the problem.
> > > >
> > > > -- 
> > > > Yu Chen [MS]
> > > > This posting is provided "AS IS" with no warranties, and confers no
> > rights.
> >
> >
> >

Relevant Pages

  • Re: install files in one EXE
    ... about the feasibility of offering MSI installers as wrappers. ... custom action for uninstall. ... You could wrap your installer in an MSI and then handle ...
    (microsoft.public.vb.general.discussion)
  • Re: What privileg is necessary while CallNtPowerInformation() be c
    ... I'm new to msi myself. ... may run the custom action with elevated privileges. ... > installer runs the custom action with user-level privileges. ...
    (microsoft.public.platformsdk.security)
  • Re: Calling c# custom action
    ... Definitive Guide to Windows Installer ... > msi for virtual directory. ... >> rely on the custom action assembly file already being installed. ...
    (microsoft.public.dotnet.framework.setup)
  • Re: Deployment Proj:CustomAction not loaded when path in customactiond
    ... you've used TARGETDIR in the same way as the above documentation. ... Phil Wilson [MVP Windows Installer] ... > The custom action will fail every time with the message: ... > Here's the section from the msi log file: ...
    (microsoft.public.dotnet.framework.setup)
  • installer woes (MSI generated by VS.NET 2003)
    ... have custom actions for Setup that are run within the Installer class. ... The Uninstall custom action in the Installer class isn't always called. ... assemblies within that, but it threw a deserialization exception. ...
    (microsoft.public.vsnet.general)