Unable to create Event Source in Windows Server 2008

http://social.msdn.microsoft.com/forums/en-US/windowsgeneraldevelopmentissues/thread/00a043ae-9ea1-4a55-8b7c-d088a4b08f09/ has some information on this issue.

Reassigned due to new project ownership.

Adam, 13/08/2010

"Appears to be a permissions issue.
Once service was run as admin, it functioned correctly.

According to *1 the user running the process should be given read access to HKLM\SYSTEM\CurrentControlSet\services\eventlog\Security; and full access to HKLM\SYSTEM\CurrentControlSet\services\eventlog\Application.

*1:
http://www.azpc.net/Blog/archive/2010/02/07/eventlog.writeentry-issues.aspx

*2:
http://msdn.microsoft.com/en-us/library/fc682h09.aspx

*3:
http://msdn.microsoft.com/en-us/library/8b25b3ee.aspx"

One solution was raised by Shane Day on the old HelpDesk system:

"In the product installer, add functionality to add Windows Event Log source.

This will get around permissions issues on systems that do not give elevated permissions to Identity Broker Service. Ie Identity Broker cannot create the source without the correct permissions."

According to http://social.msdn.microsoft.com/Forums/en/netfx64bit/thread/b7d8e3c6-3607-4a5c-aca2-f828000d25be and some other comments on EventLog related classes on MSDN, you can receive a "The parameter is incorrect" error when the log you are attempting to write exceeds a certain character limit.

(from duplicate issue ACGCEO-53 ...)
Instead of logging a meaningful exception, a "System.ComponentModel.Win32Exception: The parameter is incorrect" exception is raised instead (Application Event Log) against the "Logging" source whenever the adapter XML is incorrectly configured (incomplete).

A few instances of invalid XML configuration have been identified so far:
1. omitting a name attribute value (e.g. "ChainList") from an adapterEntityTransformationFactory node;
2. omitting a GroupTarget attribute value for a Relation.Group.dn adapter
3. including the <image> tag for an adapter at the wrong level (e.g. as a child node of adapterEntityTransformationFactory instead of AdapterConfiguration)

The above problem masks the information required to make troubleshooting straight-forward.

Upon looking at this, it looks like we may have two different problems here:

• First is the issue of the account not having sufficient permissions to log to the Event Viewer (as seen above). This looks to be best be addressed by causing the installer to add the Windows Event Log source, based on prior research.
• Second is the issue of the "parameter being incorrect". This is likely due to the error message according to my research, and could be addressed by limiting the amount that can be written to the Event Viewer.

Assigned to Adam due to log fix

Installers can optionally set log sources, will need to add to future versions of IdB and test.

The problem with this concept is that the current logging system uses random sources - ie. the generator of the log item can choose their own log source.

There is a lot more that needs to go into this than just adjusting installers.

Assigned to Tony.

Please check what is used for the source in Identity Broker. If it does not vary it will be easy to account for, if it varies, we may have to change how it works. Spend some time reading through the comments and investigate if there could be another way to solve other than creating the source on install.

Thanks.

Although this may not be the root cause of the problem, the way in which IdentityBroker determines the source to be written to the EventLog will need to be updated.

Currently there are invalid sources written such as:

• "Change detection engine import all items started."
• "Change detection engine import all items failed."
• "Get all entities from connector failed."

The logging mechanisms of IdentityBroker will need to be decorated in a similar fashion to the *EngineLoggingDecorators in EventBroker.

With the exception of an incorrectly configured Source being logged on failed service startup, the EventBroker method of preventing this behaviour has been confirmed successful in an environment that otherwise exhibits the described behaviour in Identity Broker.

What is the status of this issue for Identity Broker v4?

The method used by EventBroker has been confirmed correct/sufficient to prevent the described behaviour of this issue; with that in mind and with regards to IdentityBroker v4.0, every single log entry that would otherwise be logged needs to decorated to ensure that the source is correct.

Resolved.

Please confirm that this conforms to your original expectation.

Thanks.

The source has been correctly updated for log entries, as per the notification message service itself being updated to require branded log entries.

The source is correctly registered through the Identity Broker installer, demonstrated in the below code snippet:

if (EventLog.SourceExists("UNIFY Identity Broker Service"))
{
     EventLog.DeleteEventSource("UNIFY Identity Broker Service");
     Console.WriteLine("Removed");
}
else
{
     Console.WriteLine("Doesn't exist.");
}

Whereby prior to installation the output is "Doesn't exit" and after Installation the input is "Removed".