windows - Brug af udsigter COM-klasse komponent mislykkes kun med administratorrettigheder

Indlæg af Hanne Mølgaard Plasc

Problem



Jeg har et PowerShell script, der spørger om den aktuelle Outlook-session.


At køre det bare i et unelevated PowerShell vindue virker som forventet, men når jeg er i en forhøjet prompte, fejler det som vist nedenfor:


'normal' session:


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


Forhøjet en:


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


Elevation bruger den samme brugerkonto, som er i administratorgruppen. Hvorfor sker dette? Og hvordan man retter det? Som jeg ved, er ikke-forhøjede applikationer ikke tilladt at kommunikere direkte med forhøjede, men omvendt skulle det fungere, burde det ikke? Jeg forsøgte også at starte Outlook som administrator, men som forventet gør det ikke nogen forskel .


REDIGERE:


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


Det er PoSh 5 på Win 10 med Office 2013 Home &Business

Bedste reference


Tak til @Lieven om at hjælpe mig med at undersøge dette problem. Jeg ønskede at lade dette være åben, hvis nogen kommer rundt og finder en løsning på dette. Som det fremgår af @Lieven og nogle igangværende undersøgelser om mig selv, er der ingen løsning til dette :


Outlook og PowerShell kan samtidigt bruge den samme Outlook-session ved hjælp af delt hukommelse. Da processer med forskellige forhøjelsesniveauer ikke kan dele hukommelse (reference nødvendig), skal den anden proces (forhøjet PowerShell i mit tilfælde) åbne PST (en ny outlook-session) i sig selv, hvilket mislykkes, fordi den udelukkende åbnes af første (uovervåget Outlook i mit tilfælde).


Min løsning er at lave en lavproces, der holder Outlook-sessionen og give en pipeline til processer på højere niveau (og på samme niveau) for at oprette forbindelse til. Omvendt vandt det ikke, da uelevede processer ikke må forbinde til forhøjede rørledninger. [6]


Dette virker for mig, da opgaverne med Outlook-sessionen fra PowerShell er meget grundlæggende. Men det er stadig en løsning.