0

WiXで構築されたMSIを持っています。次のカスタムアクションを実行します。

     <CustomAction Id='StartTray'
                   Directory='INSTALLDIR'
                   ExeCommand='[INSTALLDIR]\myapptray.exe'
                   Return='asyncNoWait'
                   Impersonate='no'
                   Execute='deferred' />

それは次のようにスケジュールされています：

        <Custom Action='StartTray' After='StartServices'>NOT Installed OR (TRAYWASRUNNING AND NOT REMOVE~="ALL")</Custom>

myapptray.exeたまたま偽装を使用して、デスクトップで現在アクティブなユーザーとして、ローカルシステムの開始コンテキスト（MSIコンテキストから実行）から自分自身を再起動します。これは私の管理下にはなく、システムサービスのコンテキストからのアップグレードのためにMSIが呼び出される可能性があるため、Impersonate ='yes'は機能しません。つまり、Impersonate='yes'はアプリをローカルシステムとして実行することになります。

最近、VC9 CRTをMSMとしてこのMSIに含めることから、ブートストラッパーexeに含めることに移行しました。

これを行うと、myapptray.exeカスタムアクションが正常に実行されなくなります。なりすましは失敗し、 .WTSQueryUserTokenを返しますERROR_PRIVILEGE_NOT_HELD。これは、MSMを削除すると、MSIが実行されるユーザーコンテキストが実際に変更されたことを意味しているように見えますが、それはばかげているようです。wxsファイルから削除した行はMSMの<Merge>and<MergeRef>タグだけで、他に何も変更されていません。

私は何が間違っているのですか？

4

2 に答える 2

1

EXEが構築されたCRTのバージョンと、実行対象を示すポリシールールがあるかどうかを詳しく調べます。通常、MSMからEXEの実行に移行してから、MSIを実行することをお勧めします。

ところで、私はかつてこのような本当にハッキングをしました。MSIを使用して、SYSTEMコンテキストでMSIをプッシュする必要がありました。ユーザーがログオンしている場合は、ユーザーのデスクトップログインセッションを使用してアプリケーションを再起動する必要がありました。これを実現するためにインタラクティブユーザーになりすますように構成されたDCOMサーバーをインストールしました。本当に奇妙ですが、正当な理由がありました。

ただし、これはすべてRestartManagerの前でした。

于 2012-06-29T20:38:50.947 に答える
0

私はそれを考え出した。

CRTMSMはALLUSERS=1を設定していましたが、ベースインストーラーに存在しなかったため、インストーラーの動作が変更されました。その結果、MSMのALLUSERSの設定がベースインストーラーに継承されました。

wxsファイルでALLUSERS=1を設定すると、問題が修正されました。

于 2012-07-23T18:48:28.773 に答える