I'm using Tridion 2009 SP1. What I'm trying to do is kick off an event after a component completes a certain workflow process. Intuitively I've tried using the OnProcessInstanceFinishPost event, however, this event only gets triggered when a user (admin) explicitly clicks "Finish Process"; when the process completes normally after having all the activities finished and "reaching the 'Stop' sign end marker (as in the Visio diagram) this event is not triggered.
So I have resorted to using the OnActivityInstanceFinishPost event instead. The issue is that in the OnActivityInstanceFinishPost event I am getting the logger and trying log a simple message, e.g. "Hello World", but the Event Viewer always shows an Error: "An error occured in TCMEventLog.NTEventLog.1:ReportEvent failed." and the event doesn't get executed.
Note, in the OnProcessInstanceFinishPost event the exact same code works without errors.
I've checked to see if this was a problem with the permissions of the identity user, but the user is an admin in Tridion, so this can't be it. I've checked SDLTridionworld forum, but no luck there, and of course, I've simplified the code down to the one logging statement to make sure it's not something in my code.
Here is the code:
public void OnActivityInstanceFinishPost(ActivityInstance ActivityInstance, string finishMessage, string nextActivity, string dynamicAssignee)
{
TDSE tdse = new TDSEClass() as TDSE;
tdse.Impersonate(_identity);
tdse.Initialize();
Logging logger = tdse.GetLogging() as Logging;
logger.LogEvent("Entered event OnActivityInstanceFinishPost. nextActivity="+nextActivity, EnumSeverity.severityInfo, EnumEventCategory.EVENT_CATEGORY_EVENT_SYSTEM);
}
Here is the full error:
Log Name: Tridion Content Manager
Source: Kernel
Date: 4/9/2012 10:14:07 PM
Event ID: 100
Task Category: Logging
Level: Error
Keywords: Classic
User: SYSTEM
Computer: xxxxxxxxxxxxxx
Description:
An error occured in TCMEventLog.NTEventLog.1:
ReportEvent failed.
Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
<System>
<Provider Name="Kernel" />
<EventID Qualifiers="49152">100</EventID>
<Level>2</Level>
<Task>9</Task>
<Keywords>0x80000000000000</Keywords>
<TimeCreated SystemTime="2012-04-10T03:14:07.000Z" />
<EventRecordID>546126</EventRecordID>
<Channel>Tridion Content Manager</Channel>
<Computer>xxxxxxxxxxxxxxxxxxxxxxxxx</Computer>
<Security UserID="S-1-5-18" />
</System>
<EventData>
<Data>An error occured in TCMEventLog.NTEventLog.1: ReportEvent failed.</Data>
</EventData>
</Event>
The error indicates that Tridion has failed to write a logging message. I assume you already have some evidence that this is triggered by the workflow activity finishing.
I don't know what is causing the error, but with logging failures, it is often about permissions.
It will depend on your workflow which user actually triggers the OnActivityInstanceFinishPost event. If the activity is manually finished by a user, then that user will be the Windows identity executing the event (or if Tridion impersonation is configured, the impersonation user). If it's an automatic activity, then it will be being executed by the identity configured for the Workflow agent service. I would suggest checking whether each of these accounts is able to log correctly.
Related
Some of our users are encountering the following error page during the sequence of redirects after authenticating at their IdP.
"Unexpected exception occurred in Response Handling: null"
Partner: ...
Target: ...
This is what I believe is the corresponding info from the the server log.
2015-07-16 07:48:53,458 DEBUG [com.pingidentity.jgroups.MuxInvocationHandler] invocation of saveState on InterReqStateMgmtMapImpl state map size:215 attributes map size4 w/args: [ZkyN3LwNSjurZyfIewu1Kgjbgl7HrB, State(1437050933419){
inMsgCtx=null
outMsgCtx=OutMessageContext
XML: <samlp:AuthnRequest Version="2.0" ID="E6_0yldGrt0iqNKfUpArog6DG8G" IssueInstant="2015-07-16T12:48:53.419Z" xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol">
<saml:Issuer xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion">#issuer%</saml:Issuer>
<samlp:NameIDPolicy AllowCreate="true"/>
</samlp:AuthnRequest>
entityId: <Id> (IDP)
Binding: urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Redirect
relayState: ZkyN3LwNSjurZyfIewu1Kgjbgl7HrB
Endpoint: <endpoint>
SignaturePolicy: DO_NOT_SIGN
parameters=null}] returned null
Is there an obvious place to look for more details? This happens for around 10% of our users and seems to follow them from device to device.
I figured out what the issue was. We are using account linking using the SAML Subject from the IdP. It turned out that a number of accounts at the IdP didn't have the LDAP attribute mapped to the NameID populated. So we were receiving SAML assertions without any data in the Subject.
Understanding where to look is the key. The audit.log file shows a general "failure". Then you look up corresponding activity details in the server.log file. Then you examine the corresponding SAML assertion in the log to determine what the problem was. The difficult part is noticing omissions in the data. That's harder for the eye/brain to catch imho.
It would be useful if we had an option for directing users to a custom page rather than a Ping-specific error page when this occurs.
We're seeing lots of events like these even though we have authentication set to "None":
Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.
Event time: 12/3/2013 12:50:06 PM
Event time (UTC): 12/3/2013 6:50:06 PM
Event ID: 9a0cc0c93a964b1c9bd7126dc367b09b
Event sequence: 163807
Event occurrence: 23853
Event detail code: 50201
Application information:
Application domain: /LM/W3SVC/1/ROOT/BG-4-130305700816025855
Trust level: Full
Application Virtual Path: /BG
Application Path: D:\inetpub\wwwroot\BG\
Machine name: ***
I even double-checked in IIS Manager at the site and server level and the GUI shows Forms Authentication set to Disabled.
This is using asp.net 4.0 running on Server 2008 R2. I tried adding a machineKey to machine.config just to test but it still fails. It doesn't seem like all requests are failing since I only see the error once a minute but I can't isolate which ones are failing. I even tried using Fiddler to send a bogus .ASPXAUTH cookie but I didn't see any new errors in the event log that match up with my request.
Anyone have any ideas?
Thanks,
tim
We have a standard ASP.NET MVC 3 website. From a few days ago some uses cannot login or recover password anymore.
When trying to login they get the following error:
Login failed. Please correct the errors and try again.
•The user name or password provided is incorrect.
When trying to recover password they get the following error:
500 - Internal server error.
There is a problem with the resource you are looking for, and it cannot be displayed.
In the web server event viewer we see:
Event code: 4006
Event message: Membership credential verification failed.
Event time: 4/29/2013 4:22:16 AM
Event time (UTC): 4/29/2013 8:22:16 AM
Event ID: 2b0b4500be674969a5962608df7b18fd
Event sequence: 142
Event occurrence: 2
Event detail code: 0
If we try to register a new user afterward we can login and reset password without problems.
Why only some users get the issue above?
We checked many articles on the internet but explain only to solve this issue for all users, not only for some of them.
Thanks.
For some reason we where not getting the LockedOut exception but simply the "Invalid username or password" error. Now we will investigate on the reason.
Getting 401 errors when trying to use ASP.NET back end in load balanced environment (2 web servers). Windows log says:
Event code: 4005
Event message: Forms authentication failed for the request. Reason: The ticket supplied was invalid.
Event time: 6/6/2012 10:34:27 AM
Event time (UTC): 6/6/2012 5:34:27 PM
Event ID: de68a535d53e4bdfb11ace24a97c63c9
Event sequence: 18
Event occurrence: 7
Event detail code: 50201
Machine key on both IIS applications configured to be same. What else can cause this problem?
As it turned out two web servers had slightly different set of windows patches installed. As soon as we installed all same patches on both of them - problem was solved.
On II7 we host a WCF/asp.net based API. In order to allow users of a classic asp application to connect to the API we had to publish a version we refer to as "transport". This Transport version is written in asp.net too, it points to the same assembly , its just the security layer is different to allow classic asp to authenticate. Transport level security is used as opposed to message based security.
When using a browser to load the service reference i can loading the svcutil.exe ... WDSL page.
When using my test asp page to call a web method from this reference i get the following returned:
Finished calling Web Service.
Status = Internal Server Error
ResponseText = a:InvalidSecurityAn error occurred when verifying security for the message.
This suggests that the authentication is failing. When testing using asp.net or the application WCF storm to contact the normal API everything works well.
The API was recently migrated , it would appear something has not been setup correctly but i am at a loss to explain what.
I can browse to the svcutil.exe ... WDSL service reference, when selecting it via the browser i get the expect XML response.
The USER NAME and password utilised work when using the non-classic asp publicaiton of the API using the message based secuirty.
Would it be possible to post some troubleshooting tip that may help diagnoise the issue please specifically regarding transport level security fault finding and setup ?
Thank you
Scott
EDITED TO ADD THE FOLLOWING UPDATE:
Attempted to use the Default App Pool and a new App Pool but same problem persists.
My test page error: ResponseText = a:InvalidSecurityAn error occurred when verifying security for the message.
IIS LOG shows:
v3/transport/testclassicasptransportwcfservice.asp ( 200 0 0 ) (i.e iis 200)
/V3/Transport/DeviceService.svc/DeviceService (500 0 0) (i.e iis error 500)
note: virtual dir defined on TRANSPORT and V3. V3 works ok using .net as opposed to classic asp to authenticate.
EVENT LOG:
The Template Persistent Cache initialization failed for Application Pool 'transport' because of the following error: Could not create a Disk Cache Sub-directory for the Application Pool. The data may have additional error codes.
This reference appears to suggest a fix but many of the DIR paths and references in "appcmd" dont exist.
_http://theether.net/kb/100127
REF http://theether.net/kb/100127
load cmd prompt
CD to C:\Windows\System32\inetsrv
enter: appcmd list config -section:system.webServer/asp
the following path is displayed: c:\inetpub\conf\temp\ASP compiled templates
check path exists (it does)
Check if the NETWORK SERVICE has permissions to access "ASP compiled templates" If not from appcmd execute;
icacls "c:\inetpub\conf\temp\ASP Compiled Templates" /grant "NETWORK SERVICE:(OI)(CI)(M)"
should read "sucessfully processed 1 files"
restarted app pool.
THE "InvalidSecurityAn error occurred when verifying security for the message" problem still persists but the "COULD NOT CREATE A DISK CACHE SUB-DIRECORY .... " error from the eventlog is no longer occurring.
Sorry another update. The network service permission change DID NOT resolve the issue , changeing to the DEFAULT APP POOL solved the problem.
Got a lead at last. Examined:
ServiceSecurityAudit set in service behaviour. Ref http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/#
IIS logs (simply shows the non-specific error 500.)
Fault tracing enabled( also shows error 500).
Custom errors were off
Friendly IE messages were off
Asp client side and server side debugging on
ProcessMon running , no errors.
Web.config httpErrors errorMode="Detailed" /> +
ServiceSecurityAudit found me an "Object reference not set to an instance of an object" so sounds like our app has a bug.
Follow up (17/08/11):
Service Security Audit documented here:
http://intrepiddeveloper.wordpress.com/2008/08/07/security-event-logging-auditing/
Was the key for us to resolve this issue. Uncovered the Object Reference Error which indicated out Business Objects and Data Access dlls were out of alignment. Using CLASSIC ASP to contact the WCF.NET API using TRANSPORT AUTHENTICATION there was abolutely no indication of this error until Service Security Audit was enavled on the behaviour.config file in the WCF deployment.