Exchange Server

Brett · Guest

So, it recently stopped firing completely after a server failover. I've
had problems before, but I think (thought) that I had licked them all
until this.

Servers: Windows Enterprise 2003 (NO SP, all security patches),
Exchange Server 2003 SP1, ScanMail for Exchange, McAffee 8.0i.

We have several four - node clusters. One on of the virtual servers, I
have created an async onsave event sink (on a mail-enabled public
folder). It is registered with the following line:
*********************************************************************************
cscript D:\scripts\EventSinks\regevent.vbs Add "onsave"
ExOleDB.ScriptEventSink.1
"file://./backofficestorage/ourdomain.xxx/public folders/System
Administrator Folders/Virus Notifications/ePO Alerts/ePO WKS Access
Alerts/WksAccessAlertModifier" -m exact -file
d:\scripts\EventSinks\WksAccessAlertModifier.vbs -f "WHERE
$DAV:ishidden$ = FALSE"
*********************************************************************************

This is a mail-enabled public folder. Basically, the script takes
incoming virus notifications, parses the message and changes the
subject line to the affected PC name, and adds a category with the
threat name (for easy sorting). I have 3 other public folders with an
almost identical event on them; when they fail, they all fail at the
same time.

This seems to work fine. However, the cluster recently failed and the
event stopped firing. So I registered the DLL's (exodbesh.dll and
exodbprx.dll) on the server it failed over to, and created the com+
object (I used the script eshmt.vbs). I registered the events again,
but it is not firing. I've stopped and restarted the COM+ app, to no
avail. I've de-registered and re-registered the events, also to no
avail. It was working perfectly (almost) before.

Even before this, when I register the events, and the first messages
come through, I receive the following event log errors - the events
continue to fire after the below 108 & 114 error:

114 is always preceded by 108 - I think it has something to do with
ScanMail for exchange. I always stop the scanmail services prior to
registering the event, then immediately restart it (I have a .cmd to do
it all quickly).

*****************SOURCE: EXOLEDB EVENT ID:
108********************************'
Microsoft Exchange OLEDB was unable to either create an event sink
object or get necessary interface(s) from the sink class specified by
SMEXMA.SmxMailAction, HRESULT = 0x8001010e.
*******************************************************************************

These (114) always occur after 108... they both occur only once after
the first message hits the store immediately following registration.

*****************SOURCE: EXOLEDB EVENT ID:
114********************************
Microsoft Exchange OLEDB has disabled the event binding due to the
problems in the event sink. Binding ID =
{AF313DF4-9EF1-47F4-8347-CEF8A8EED6CC}. You may need to contact the
event sink author and get a fixed or updated copy.
******************************************************************************

I see these several times a day (though it seems to be on severs that
don't even have the event sink, probably not related).
*****************SOURCE: MsExchangeIS EVENT ID:
9646**************************
Mapi session "069e91ec-bb7a-4046-b34d-a75ce1076ccc" exceeded the
maximum of 32 objects of type "session".
******************************************************************************

Occasionlly, I will log onto a server, and see a warning message about
a "Com Surrogate Error". I think it is related to this error.
*****************SOURCE: COM+ Event ID:
4786**********************************
The system has called a custom component and that component has failed
and generated an exception. This indicates a problem with the custom
component. Notify the developer of this component that a failure has
occurred and provide them with the information below.
Component Prog ID:
Server Application ID: {CDE7885C-1C09-4CA7-9608-41C9848E7CBA}
Server Application Instance ID:
{562B7FBA-B2BE-40D6-AC3B-A87E1960BD1A}
Server Application Name: Exoledb Script Handler
The serious nature of this error has caused the process to terminate.
Exception: C0000005
Address: 0x00000100
Call Stack:
+ 0x100
scripto!DllUnregisterServer + 0x1a54
scripto!DllUnregisterServer + 0x46e3
VBScript!DllGetClassObject + 0x167e0
VBScript!DllCanUnloadNow + 0x4a9b
scriptproxy!DllGetClassObject + 0xa83
scripto!DllUnregisterServer + 0x31f3
exodbesh! + 0x47e3
exodbesh! + 0x101f0
exodbesh! + 0x103ff
RPCRT4!NdrServerInitialize + 0x570
RPCRT4!NdrStubCall2 + 0x1d0
RPCRT4!CStdStubBuffer_Invoke + 0x82
ole32!StgGetIFillLockBytesOnFile + 0x1171b
ole32!StgGetIFillLockBytesOnFile + 0x116c5
ole32!CoFreeUnusedLibrariesEx + 0x3d79
*******************************************************************************

Below is the script:
*******************************************************************************
<SCRIPT LANGUAGE="VBScript">

Sub ExStoreEvents_OnSave(pEventInfo, bstrURLItem, lFlags)

Dim i, DispEvtInfo, ADODBRec, strWs, strVirus, colWs, colVirus
Dim RegExpr, strBody, objRegExpr

On Error Resume Next

Set DispEvtInfo = pEventInfo
Set ADODBRec = DispEvtInfo.EventRecord

On Error Resume Next
Const EVT_NEW_ITEM = 1
Const EVT_IS_DELIVERED = 8

If (lFlags And EVT_IS_DELIVERED) Or (lFlags And EVT_NEW_ITEM) Then
If InStr(ADODBrec.Fields("urn:schemas:httpmail:subject"), "Virus
Alert") Then
Set objRegExpr = New regexp
objRegExpr.Global = True
objRegExpr.IgnoreCase = True
strBody = ADODBRec.Fields("urn:schemas:httpmail:textdescription")

'***************Find WS name, assign to strWs, update Subject
objRegExpr.Pattern = "Affected\sComputer\sName:\s+\b.+\b"
Set colWs = objRegExpr.Execute(strBody & " " & Err.Number)
strWs = colWs(0)
objRegExpr.Pattern = "Affected\sComputer\sName:\s"
strWs = Trim(objRegExpr.Replace(strWs, ""))
ADODBrec.Fields("urn:schemas:httpmail:subject") = strWs

'***************Find Virus name, assign to strVirus, update
Category

objRegExpr.Pattern = "Actual\sThreat\sor\srule\sname:\s\b.+\b"
Set colVirus = objRegExpr.Execute(strBody)
strVirus = colVirus(0)
objRegExpr.Pattern = "Actual Threat or rule name: "
strVirus = Trim(objRegExpr.Replace(strVirus, ""))

ADODBrec.Fields("http://schemas.microsoft.com/exchange/keywords-utf8")
= Array(strVirus)
ADODBrec.Fields.Update
Set objRegExpr = nothing

End If

End if

set DispEvtInfo = nothing
Set ADODBRec = nothing
Set colWs = Nothing
Set colVirus = Nothing
strBody = ""
strVirus = ""
objLog.Close
Set objFSO = Nothing

End Sub

</SCRIPT>
*******************************************************************************
It's a fairly high traffic system, however they are hefty servers and
do not seem to be affected by the scripts. I am porting them to vb.net
for better performance, as soon as I can get my head around the
differences.

COM+ settings....

I have the Exoledb Script Handler properties, security set to: Perform
access checks only at the process level. Security property will not be
included on the object context. COM+ security call context will not be
available.

Under the "Queuing" tab of the exoledb Script Handler, I have MSMQ
Message Authentication set to "Do not authenticate messages".
I've also seen a technote stating that "Interactive" need to be added
to the COM+ properties (Default COM Security, Access permissions). Did
that.
The user in the security tab of the Exoldeb Script handler is both a
domain admin, and a full exchange administrator.

I somewhat expect that Scanmail may be a part of this issue, but I
don't know.

So, is there anything special that needs to be done with event sink
registration / COM+ or anything else different in a clustered system? I
saw one article which seemed to indicate that a Distributed Transaction
Coordinator resource had to be set up, but I can't seem to find
verification. Docs seems scanty....

Or, is my script fatally flawed? I hope I haven't rambled too much,
I've just tried to include as much info as I can. Any help would be
greatly appreciated!

Brett · Guest

I think I've found at least a partial solution. I've ensured that the
com+ object is registered (using eshmt.vbs) on each physical server
that the virtual server may fail over to.
That and checking the startup setting of the com+ event system & com+
system application on all of the physical servers is set to auto. Not
sure if it's neccessary, but so far it's failed over and the event
script is faithfully firing.

Brett wrote:

	Exchange Server Forum Index -> Development	All times are GMT
Page 1 of 1