getactiveObject works for Windows 7, not for Windows 8/10

PowerShell Help
1

I have the following Powershell code below that i’ve compiled into an executable (.exe) file and have packaged it into SCCM to push against several 100 users. I have setup the SCCM package to run as “Install as user” and not as an Administrator. The package successfully captures the data for users with Windows 7, but any user that has Windows 8/10 installed fails to capture the data I need. A user who is on Windows 7 and has Powershell 5.0 installed is able to successfully run the package and output data, so not a PS version 5.0 issue.

I did a try/catch statement and get this error - "Exception calling “GetActiveObject” with “1” argument(s): “Operation unavailable (Exception from HRESULT: 0x800401E3 (MK_E_UNAVAILABLE))”

I’m trying to understand why the same exact code works perfectly on Windows 7 machines, but does not work on Windows 8/10. Is there a fix? I’m thinking this is likely an issue with the context of how the code is being executed due to the change in WMF for Windows 8/10. I would like to avoid using “New-Object -ComObject ‘Outlook.Application’” because i don’t want to create a new (additional) Outlook process in the background (fear of corrupting user’s running Outlook session). I need to run the Powershell code to capture the active running Outlook process. Please help. Thank you

$mail = [Runtime.Interopservices.Marshal]::GetActiveObject('Outlook.Application')

$name = $mail.Application.DefaultProfileName

output of $name value is stored locally to a log text file.

2

On my Windows 10 box, if Outlook is not open, the error is produced. You can do something like this to attempt to connect to an active Outlook.Application, but if it fails connect with the standard New-Object:

try {
    $mail = [Runtime.Interopservices.Marshal]::GetActiveObject('Outlook.Application')
}
catch {
    "Outlook isn't open, attempt to start new session. {0}" -f $_
    try {
        $mail = New-Object -ComObject 'Outlook.Application'
    }
    catch {
        "Unable to start new Outlook.Application. {0}" -f $_
    }
}


if ($mail) {
    #Do stuff
    $mail.Application.DefaultProfileName
}
else {
    "Unable to open Outlook.Application"
}
3

Hey thanks for your response Rob. I did have something similar (if (Outlook process non-existent) {EXIT}) to what you wrote above in my test lab, but I still was hoping to understand why the failure happens. As an fyi, i sit next to several guys who have Windows 8/10 and i can see that they have Outlook 2016 open and pulling mail as my package is pushed to their machines via SCCM, but unfortunately still fails with the same error exception. So from our side, we can definitely see that the failure is not due to Outlook being closed (non-existent processes) but likely something that’s different in WMF for Windows 8/10. Any insight how to bypass this would be much appreciated. Thanks again.

4

My first thought is if there is anyway to avoid using the COM Object to get the data you need, you should investigate that route. COM Objects are painful.

It’s possible it’s a DCOM-related issue similar to this:

http://stackoverflow.com/questions/3750605/getting-creating-an-outlook-application-in-windows-7

This talks about some of the ways to change DCOM settings or permissions:

http://stackoverflow.com/questions/11363342/change-dcom-config-security-settings-using-powershell

Again, you’ll see in most of these posts that users are trying to mess with old COM objects with scheduled tasks and have to jump through hoops to get it to work consistently.