tags:

views:

36

answers:

1

I've been developing a C# (WinForms) application that uses the Office 2007 PIAs to integrate with Outlook 2007. In my dev environment, UAC is disabled and all of my functionality works, but my test environment is Vista 32-bit with UAC enabled.

In the test environment, Outlook runs at medium integrity level by default (when started by the user). My application requires high integrity level (i.e. it presents a UAC prompt on startup). In this scenario, instantiating the Microsoft.Office.Interop.Outlook.Application class from my application fails with a CO_E_SERVER_EXEC_FAILURE (COMException, HRESULT=0x80080005).

I can get around this problem in 2 ways:

  1. Ensure Outlook is not running when my application instantiates Application - this forces Outlook to run in high integrity mode, since the process that starts it is also running at high integrity.
  2. Instruct Outlook to always run as Administrator (Compatibility tab).

It is worthwhile to note that the Word and Excel PIAs do not exhibit this problem.

Is there any way around this problem? My application cannot run at low integrity, but there is a chance that it could be adapted to run at medium integrity level - however, I can't work out how to do this. Can .NET executables even run in this mode?

Alternatively, is there some way to communicate with Outlook even while there are mismatched integrity levels? As i've said, Word and Excel seem to have no problem with this.

+2  A: 

Can .NET executables even run in this mode?

.NET applications can run at any UAC integrity level (including system and low).

But one process has only one integrity level (add the integrity column to Process Explorer to see the distribution of processes across integrity levels).

If you try and run a second instance of Outlook, it will just bring the existing instance into view, it actively prevents two instances running. Word and Excel do not.

Together these explain what you are seeing. When you instantiate a Word or Excel application object a new Work or Excel process is run with matching integrity level. If you do this with Outlook and Outlook is already running then it will try to attach to that existing process. But this will fail unless Outlook is already running at high integrity. You should be able to validate this by running Outlook as administrator (i.e. high integrity) and then running your application to attach to it.

Requiring users to run Outlook as administrator is a poor idea (due to risks of attachments to email from unknown parties, running Outlook at high integrity is just inviting malware infection).

The best approach (and this is how Explorer etc. do it) is to split your process into two parts, using COM monikers to elevate only the parts of your application that really need elevation. See this SO question on how to do this: http://stackoverflow.com/questions/127042/how-to-uac-elevate-a-com-component-with-net

Richard
So, if I infer your answer correctly, I can only interact with Outlook using an unelevated process (or COM object, in this case)? My application requires admin privileges more than not, so it would make sense to separate the Outlook code out into a separate component. Can a high-integrity process spawn a low-integrity COM component? (Wishful thinking, hehe)
Bradley Smith
Yes, an elevated process can launch a non elevated one. http://www.gregcons.com/KateBlog/LaunchingANonElevatedProcessFromAnElevatedOne.aspx
Kate Gregory
@Bandly: or rather a medium process can (with the correct API) launch a high process. So run your application as medium, with just the bits that need to be high running in their own high process.
Richard