Outlookを使用するCOMクラスコンポーネントが管理者権限でのみ失敗する

Question

現在のOutlookセッションを照会するPowerShellスクリプトがあります。予想されるようにちょうどunelevated PowerShellウィンドウでそれを実行

は動作しますが、私は昇格プロンプトにいるとき、以下に示すように、それは失敗します。

「通常」のセッション：

PS> New-Object -Com Outlook.Application 


Application  : System.__ComObject 
Class    : 0 
Session   : System.__ComObject 
Parent    : 
Assistant   : 
Name    : Outlook 
Version   : 15.0.0.4903 
COMAddIns   : System.__ComObject 
Explorers   : System.__ComObject 
Inspectors   : System.__ComObject 
LanguageSettings : System.__ComObject 
ProductCode  : {90150000-000F-0000-0000-0000000FF1CE} 
AnswerWizard  : 
FeatureInstall  : 1 
Reminders   : System.__ComObject 
DefaultProfileName : Outlook 
IsTrusted   : False 
Assistance   : System.__ComObject 
TimeZones   : System.__ComObject 
PickerDialog  : System.__ComObject 

上昇1：

PS> New-Object -Com Outlook.Application 
New-Object : Retrieving the COM class factory for component with CLSID {0006F03A-0000-0000-C000-000000000046} failed 
due to the following error: 80080005 Server execution failed (Exception from HRESULT: 0x80080005 
(CO_E_SERVER_EXEC_FAILURE)). 
At line:1 char:1 
+ New-Object -Com Outlook.Application 
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
    + CategoryInfo   : ResourceUnavailable: (:) [New-Object], COMException 
    + FullyQualifiedErrorId : NoCOMClassIdentified,Microsoft.PowerShell.Commands.NewObjectCommand 

エレベーションは、管理者グループ内の同じユーザーアカウントを使用します。なぜこれが起こるのですか？それを修正する方法は？私が知っているように、昇格していないアプリケーションは高位のアプリケーションと直接通信することはできませんが、それ以外の方法ではうまくいくはずです。私はまた、管理者としてOutlookを起動しようとしましたが、期待どおりの違いはありません。

EDIT：

C:/WINDOWS/system32> $PSVersionTable 

Name       Value 
----       ----- 
PSVersion      5.1.14393.693 
PSEdition      Desktop 
PSCompatibleVersions   {1.0, 2.0, 3.0, 4.0...} 
BuildVersion     10.0.14393.693 
CLRVersion      4.0.30319.42000 
WSManStackVersion    3.0 
PSRemotingProtocolVersion  2.3 
SerializationVersion   1.1.0.1 

それはこの問題を調査私を助けに@Lievenへ

Answer 1

おかげでオフィス2013ホーム&ビジネスでの勝利10の5 POSHです。誰かが来て、これについての解決策を見つけたら、私はこれを開いたままにしたかったのです。 @Lievenと自分自身にいくつかの現在進行中の研究によって述べたように、このには「解決策は、」ありません：

OutlookとPowerShellが同時に共有メモリを使用して、同じOutlookセッションを使用することができます。異なる高度レベルのプロセスはメモリを共有できません（参照が必要です）ので、2番目のプロセス（私の場合はPowerShellの昇格）はPST（新しいOutlookセッション）を単独で開く必要があります。 （私の場合は不安定なOutlook）。

私の回避策は、Outlookセッションを保持する下位レベルのプロセスを作成し、上位レベルのプロセス（および同じレベルも同様）と接続するためにproviding a pipelineを作成することです。不均衡なプロセスが昇格したパイプラインに接続することが許可されていないため、その逆もうまくいきません。

これは、PowerShellのOutlookセッションでの作業が非常に基本的なので、私の仕事です。ただし、これはまだ回避策です。