1

The code I am currently working on runs on Windows Server 2003, but needs to be able to write to EventLogs on multiple machines. I am coding in C#, using VS2008 Pro, and .NET Framework 3.5.

The code itself is relatively simple (thanks to the framework):

using (EventLog remoteEvtLog = new EventLog(LogName, HostName, EventSource))
{
    remoteEvtLog.WriteEntry(Body);
}

"LogName" is a string containing the name of the log to write to - in most cases "Application". "HostName" is a string containing the NetBIOS Name of the machine where the log entry should be written. "EventSource" is a string containing the name of the event sender (this is a utility used by multiple apps, so usually it will have the name of the consuming application). "Body" is a string containing the text to be written to the event log.

In most cases this works fine, but when the machine being written to uses UAC, any write which creates a new EventSource fails. This occurs even though the Security credentials used are members of the Administrators group - and I have not been able to find a way to specify the elevated priviledge level. Apparently, members of the Administrators goroup get two tokens - one limited, and one elevated, but as far as I can tell, the only way to specifiy the elevated token is through the UI - which is obviously a problem when remotely accessing the Logs.

Any ideas out there?

Helen
  • 87,344
  • 17
  • 243
  • 314
DragonsRightWing
  • 58
  • 5

1 Answers1

0

Your code is not supposed to create new event sources (the legacy auto-create behavior is unfortunate, but still wrong). If you need a separate event source for your application, then the installer for that application - which runs with elevated administrative privileges - should create it.

Pavel Minaev
  • 99,783
  • 25
  • 219
  • 289
  • And how would one go about having the installer (from VS Setup Deploy project?) to do that? (sorry for hi-jacking). – Nate Aug 28 '09 at 20:20
  • I do not think you can do this with a VS Setup project - the thing is extremely limited in what it can do. You can of course hand-edit the resulting MSI in Orcas, but that's extremely inconvenient. In general, if you find that you need more than Setup projects offer - which is almost a certainty for any real-world application - you should switch over to WiX. – Pavel Minaev Aug 28 '09 at 22:22
  • 1
    In the Solution Explorer, right-click the default project: choose Add>New Item In the dialog, select the Installer Class template, name it A new class is added - after the call to InitializeCompnent(), add this code: if (!EventLog.SourceExists("MySource") EventLog.CreateEventSource("MySource", "Application"); Add a Setup Project & add Primary Output Right-click on the Setup project, select View>CustomActions Right-Click the Install folder, choose Add Custom Action Select Application Folder, then Primary Output - click OK. Save & Build - the code you added runs at setup – DragonsRightWing Aug 29 '09 at 01:03
  • 1) sorry about the hard-to-read formatting on the last reply ... 2) What is the purpose of EventLog.CreateEventSource - if not to Create Event Sources? In our situation, we may be logging to a physical host on which the application has not been installed, but is being run as a remote application: we want the Events to be written on the client, not the application server. I am not using the auto-create, but specifically testing for, then (if needed) explicitely creating, the EventSource. – DragonsRightWing Aug 29 '09 at 02:00
  • The point is that auto-creating an event source, from security standpoint, is kinda the same as auto-creating a folder under "Program Files". It's not supposed to be done by non-elevated user. – Pavel Minaev Aug 30 '09 at 03:50
  • Oh, and when using WiX, this SO question says how to create an event source from installer without writing your own custom action: http://stackoverflow.com/questions/58538/how-do-you-create-an-event-log-source-using-wix – Pavel Minaev Aug 30 '09 at 03:50
  • Thanks, Pavel. It looks as if I'm going to have to use a single EventSource, then use some alternate means of further identifying the "Inner Source". Again, the problem is that the application is not actually installed on the machine where the Event entries need to be written. You have gotten me interested in WiX, however - I have not looked into it before now. – DragonsRightWing Aug 31 '09 at 21:34