GetNamespace("MAPI") error with Outlook

[UlrichDemlehner]

My simple 2 lines code:

$outlook = New-Object -ComObject Outlook.Application
$namespace = $outlook.GetNamespace(“MAPI”)

The GetNamespace(“MAPI”) command leads to the error message:

Ausnahme beim Aufrufen von “GetNamespace” mit 1 Argument(en): “Das COM-Objekt des Typs “Microsoft.Office.Interop.Outlook.ApplicationClass” kann nicht in den Schnittstellentyp
“Microsoft.Office.Interop.Outlook._Application” umgewandelt werden. Dieser Vorgang konnte nicht durchgeführt werden, da der QueryInterface-Aufruf an die COM-Komponente für die Schnittstelle
mit der IID “{00063001-0000-0000-C000-000000000046}” aufgrund des folgenden Fehlers nicht durchgeführt werden konnte: Element nicht gefunden. (Ausnahme von HRESULT: 0x8002802B
(TYPE_E_ELEMENTNOTFOUND)).”
In Zeile:2 Zeichen:1

• $namespace = $outlook.GetNamespace(“MAPI”)

•   + CategoryInfo          : NotSpecified: (:) [], MethodInvocationException
    + FullyQualifiedErrorId : InvalidCastException
  
  

This happens with both a 32 and a 64 bit version of Powershell. The equivalent good old 32 bit VBScript code

Dim outlookApp: Set outlookApp = CreateObject(“Outlook.Application”)
Dim namespace: Set namespace = outlookApp.GetNamespace(“MAPI”)

has no problems at all. I’m running Outlook 2016 32 bit on Win10 64 bit.

Thanks for your comments!

Ulrich

[Olaf]

Ulrich,
Servus & Welcome to the forum.

Since this is an English forum error messages in foreign languages are problematic. I’d recommend to ask the question in a German forum or translate the German parts of the error message.

Regardless of that - what do you actually want to do? But I should admit in advance that I don’t have any experiences automating office.
Automating MSFT Office is AFAIK best done with the office internal scripting language VBA. It might be a good idea as well to find a particularily Office related forum.

[UlrichDemlehner]

@UlrichDemlehner

Ausnahme beim Aufrufen von “GetNamespace” mit 1 Argument(en): “Das COM-Objekt des Typs “Microsoft.Office.Interop.Outlook.ApplicationClass” kann nicht in den Schnittstellentyp
“Microsoft.Office.Interop.Outlook._Application” umgewandelt werden. Dieser Vorgang konnte nicht durchgeführt werden, da der QueryInterface-Aufruf an die COM-Komponente für die Schnittstelle
mit der IID “{00063001-0000-0000-C000-000000000046}” aufgrund des folgenden Fehlers nicht durchgeführt werden konnte: Element nicht gefunden. (Ausnahme von HRESULT: 0x8002802B
(TYPE_E_ELEMENTNOTFOUND)).”

Sorry, but my assumption was that somebody who has expertise with those COM problems will be able to identify the error message even if it is in mixed German/English. Google translates as

Exception when calling “GetNamespace” with 1 argument(s): “The COM object of type “Microsoft.Office.Interop.Outlook.ApplicationClass” cannot be included in the interface type
“Microsoft.Office.Interop.Outlook._Application” can be converted. This operation could not be performed because the QueryInterface call went to the COM component for the interface
with the IID “{00063001-0000-0000-C000-000000000046}” could not be performed due to the following error: Element not found. (Exception from HRESULT: 0x8002802B
(TYPE_E_ELEMENTNOTFOUND)).”

and this translation appears to match the original English error message quite well.

@Olaf

Regardless of that - what do you actually want to do? But I should admit in advance that I don’t have any experiences automating office.

Exactly that: automating office, in particular Outlook. The problem is that this GetNamespace call is basically the key to all Outlook objects and if that key does not fit, there is no way to work with the other Outlook objects.

@Olaf

Automating MSFT Office is AFAIK best done with the office internal scripting language VBA. It might be a good idea as well to find a particularily Office related forum.

Sure, that has been my work around. But I’m simply curious if somebody has a solution for PowerShell.

[Olaf]

@UlrichDemlehner

Sorry, but my assumption was that somebody who has expertise with those COM problems will be able to identify the error message even if it is in mixed German/English.

OK, but wouldn’t you agree that it is a kind of nice and polite when you make it as easy as possible for someone to help you?

@UlrichDemlehner

and this translation appears to match the original English error message quite well.

Great. You may add some more info about your environment. The error might be related to a particular version.

@UlrichDemlehner

Sure, that has been my work around. But I’m simply curious if somebody has a solution for PowerShell.

OK, let’s wait if there is someone able to help.
Good luck.

[UlrichDemlehner]

@Olaf

OK, but wouldn’t you agree that it is a kind of nice and polite when you make it as easy as possible for someone to help you?

I see your point …

[matt-bloomfield]

I can’t replicate this error although my version of Office is 64-bit, not sure if that’s relevant.

Google search results for the error suggest that repairing the Office installation might resolve the problem (at least temporarily). Worth a try?

[UlrichDemlehner]

At keast it’s interesting that you found something which I did not. This alone is a bit strange according to my experience. So it appears that I probably have a very strange mixture of COM objects on my machine that leads to the problem. I’m not really sure if it’s worth a repair or complete re-build of the machine since the work-around with VBA or VBScript works quite well.

Thanks for your comment.

Ulrich

[Olaf]

@UlrichDemlehner

At keast it’s interesting that you found something which I did not.

In the meantime I tested the two lines of code as well on my work PC and couldn’t reproduce your error neither.

[UlrichDemlehner]

I installed the latest version of PowerShell and the problem has disappeared though I use the 64 bit PowerShell with my 32 bit Outlook. Jumping to a conclusion that may be completely wrong, but the problem obviously were not my Outlook COM objects but the way PowerShell worked with those. Confusing stuff …