2

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.

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 would like to avoid using "New-Object -ComObject 'Outlook.Application'" because i don't want to create a new 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 is stored locally to a log text file.

Martijn Pieters
  • 1,048,767
  • 296
  • 4,058
  • 3,343
  • in the project I am wondering if you need to change it from `AnyCPU` to x86 or vice versa` this sounds like an OS issue in regards to 32bit OS vs 64bit OS – MethodMan Apr 27 '17 at 17:19
  • All of our machines are 64bit OS, we don't deploy 32bit machines. Thanks – powershellFan83 Apr 27 '17 at 17:40
  • what about checking if the `CopyLocal =` property for the DLL make sure it's set to true when deploying.. – MethodMan Apr 27 '17 at 17:43
  • MethodMan, thanks for your reply. Not familiar with this "copylocal=" property for the DLL. Can you elaborate a little on how i'm supposed to make sure it's set to "true" please? – powershellFan83 Apr 27 '17 at 17:48
  • in your `references` node in the project, if you are using any 3rd party assembly's / dll, just click on the dll in the reference node and change that property from `CopyLocal=false` to `CopyLocal=true` this will copy the dll over to the Bin Directory of your project and not rely on the `GAC` when looking up / and or Referencing the dll.. – MethodMan Apr 27 '17 at 17:51
  • Thank you again, but i'm not using any 3rd party assemblies/dll files. Just simply compiling the .ps1 powershell script into a .exe executable file and pushing it out with SCCM. Appreciate your assistance sir. – powershellFan83 Apr 27 '17 at 17:57

2 Answers2

1

Make sure Outlook and your app are running in the same security context - either both apps are running with elevated privileges ("Run As Administrator") or neither app is running as an admin.

Dmitry Streblechenko
  • 62,942
  • 4
  • 53
  • 78
  • Appreciate your input Dmitry but as I mentioned in my original post, i'm pushing this successfully against Windows 7 workstations, and it's being "installed as user" via SCCM. But for some reason it fails for Windows 8/10 (same exact application) when it's also pushed via SCCM as "install as user". I'm thinking a change in the WMF for Win 8/10 that's causing this. – powershellFan83 May 10 '17 at 00:48
  • If SCCM is not running in the same security context (even if the user identity is the same), you will see that error. – Dmitry Streblechenko May 10 '17 at 16:12
0

I was experiencing similar symptoms. I don't know if this is your exact problem, but maybe my solution will help someone else who stumbles across this issue.

The following MS KB article mentions that Office applications do not register themselves in the ROT until the application loses focus (which is apparently "behavior by design"). If the application is not registered in the ROT, GetActiveObject will return the error you indicated.

In my case, the script was working reliably on Windows 7, but it only sometimes worked on Windows 8. For some reason, perhaps related to the versions of Office installed, different versions of Internet Explorer (which I used to launch the Office apps) or maybe changes to Windows itself, I experienced different default window focusing behavior on Windows 8. As soon as I manually clicked on the Office app in my Windows 8 tests, the script started working.

To solve the problem, I just inserted a call to focus the Office application window before making the GetActiveObject call, which made the operation completely reliable on Windows 8.

Scott Dudley
  • 3,256
  • 1
  • 18
  • 30