By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
424,851 Members | 1,131 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 424,851 IT Pros & Developers. It's quick & easy.

Managed OnSave Event Sink Errors on x64

P: n/a
Don
Getting errors after following the MSDN article on using VB.NET (and VS2005)
for "Implementing a Managed OnSave Event Sink" for Exchange Server 2007. Not
sure, but part of the problem may be that it's the 64-bit version of
Exchange 2007 installed on Windows Server 2003 Enterprise x64, while the
Exchange 2007 SDK samples seem mostly geared toward 32-bit. Even at that, I
was able to build the TLB and install it into COM+ Component Services, then
use Exchange Explorer to register the event in a Public Folder. The event
fired when I saved a message to the Folder, but the following two errors
were logged. Permissions seem to be okay in Component Services, DCOM Config,
and on the Folder. I even tried installing VS2005 on the Server, but no
change in results. I also made sure that I followed the steps in the
prerequisite article "Building Managed Event Sink DLLs". Has anyone been
able to get the OnSave example to work on an all-64-bit setup?
Event Type: Error
Event Source: EXOLEDB
Event Category: Events
Event ID: 108
Date: 2/8/2007
Time: 7:46:21 AM
User: N/A
Computer: ENGNT3
Description:
Microsoft Exchange OLEDB was unable to either create
an event sink object or get necessary interface(s)
from the sink class specified by
SampleEvtSinkVB.AsyncEvents, HRESULT = 0x80004002.

Event Type: Error
Event Source: EXOLEDB
Event Category: Events
Event ID: 114
Date: 2/8/2007
Time: 7:46:21 AM
User: N/A
Computer: ENGNT3
Description:
Microsoft Exchange OLEDB has disabled the event binding
due to the problems in the event sink.
Binding ID = {D180271E-0F75-48AD-A402-FDDE9156398E}.
You may need to contact the event sink author and get a
fixed or updated copy.

Feb 9 '07 #1
Share this Question
Share on Google+
7 Replies


P: n/a
Don,

Have you already looked what the debug options can do for you.

On some places the throwing of a break is off, maybe can you set that more
on.

Cor

"Don" <do***@newsgroup.nospamschreef in bericht
news:uN*************@TK2MSFTNGP05.phx.gbl...
Getting errors after following the MSDN article on using VB.NET (and
VS2005)
for "Implementing a Managed OnSave Event Sink" for Exchange Server 2007.
Not
sure, but part of the problem may be that it's the 64-bit version of
Exchange 2007 installed on Windows Server 2003 Enterprise x64, while the
Exchange 2007 SDK samples seem mostly geared toward 32-bit. Even at that,
I
was able to build the TLB and install it into COM+ Component Services,
then
use Exchange Explorer to register the event in a Public Folder. The event
fired when I saved a message to the Folder, but the following two errors
were logged. Permissions seem to be okay in Component Services, DCOM
Config,
and on the Folder. I even tried installing VS2005 on the Server, but no
change in results. I also made sure that I followed the steps in the
prerequisite article "Building Managed Event Sink DLLs". Has anyone been
able to get the OnSave example to work on an all-64-bit setup?
Event Type: Error
Event Source: EXOLEDB
Event Category: Events
Event ID: 108
Date: 2/8/2007
Time: 7:46:21 AM
User: N/A
Computer: ENGNT3
Description:
Microsoft Exchange OLEDB was unable to either create
an event sink object or get necessary interface(s)
from the sink class specified by
SampleEvtSinkVB.AsyncEvents, HRESULT = 0x80004002.

Event Type: Error
Event Source: EXOLEDB
Event Category: Events
Event ID: 114
Date: 2/8/2007
Time: 7:46:21 AM
User: N/A
Computer: ENGNT3
Description:
Microsoft Exchange OLEDB has disabled the event binding
due to the problems in the event sink.
Binding ID = {D180271E-0F75-48AD-A402-FDDE9156398E}.
You may need to contact the event sink author and get a
fixed or updated copy.

Feb 9 '07 #2

P: n/a
Hi Don,

In order to resolve such issue (Exchange development issue) more quickly,
we would like to suggest you may post in
"microsoft.public.exchange.development", because to special Exchange
Development issue, the people in those groups will be more likely to be
able to help and familiar in such field.

Have a great day.
Sincerely,
Wen Yuan

Feb 9 '07 #3

P: n/a
Don
Hi Cor,
Tried it, but couldn't get the "Launch in debugger" option of the component
to work. Getting errors about not registering with DCOM within the timeout
period, and Event ID 4096 for the VsJITDebugger where "The request is not
supported". I'm using the default entry for the "Launch", which is
"C:\Windows\system32\VSJitDebugger.exe" C:\Windows\SysWOW64\dllhost.exe
/ProcessID:{ID#}

Don
"Cor Ligthert [MVP]" <no************@planet.nlwrote in message
news:uz**************@TK2MSFTNGP03.phx.gbl...
Don,

Have you already looked what the debug options can do for you.

On some places the throwing of a break is off, maybe can you set that more
on.

Cor

Feb 9 '07 #4

P: n/a
Don
Hi Wen Yang,

Thank you for the suggestion. I've posted this now to
"microsoft.public.exchange.development"

Don

""WenYuan Wang"" <v-******@online.microsoft.comwrote in message
news:bX*************@TK2MSFTNGHUB02.phx.gbl...
Hi Don,

In order to resolve such issue (Exchange development issue) more quickly,
we would like to suggest you may post in
"microsoft.public.exchange.development", because to special Exchange
Development issue, the people in those groups will be more likely to be
able to help and familiar in such field.

Have a great day.
Sincerely,
Wen Yuan

Feb 9 '07 #5

P: n/a
Don

Finally got the MSDN "Implementing a Managed OnSave Event Sink" working for
Exchange Server 2007 x64 on Windows Server 2003 Enerprise x64 Edition. Could
be because of one or all of the following reasons (Note: these items were
just the result of my own tests, so may or may not work for you):

1. clean up some of the items in the VB.NET code: change "Imports
ExevtsnkLib = SignedExevtsnk" to "Imports ExevtsnkLib = Interop.Exevtsnk",
and avoid warnings by setting the objects = Nothing when Dim'ing rec and
conn.

2. For Component Services, use the "Install new component(s)" button instead
of "Import component(s)". This will permit you to review the interfaces and
methods to make sure you've got IExStoreAsyncEvents on the list.

3. For Component Services select the DLL file, not the TLB file, when
installing the component. Using the TLB file appears to work, but the
Exchange Explorer Registration Wizard may believe that your component is not
properly registered. It also seems that in one of my attempts, using the TLB
file resulted in IExStoreAsyncEvents missing from the component's list of
interfaces.

4. COM Security: For Default Access and Default Launch and Activation: Be
sure that the list includes SYSTEM, INTERACTIVE, and the "run under" account
you selected on the Identity Tab of the Component Properties.
Feb 13 '07 #6

P: n/a

Thanks, Don.:)
We greatly appreciate for your post back.

Have a great day!
Wen Yuan

Feb 14 '07 #7

P: n/a
Don
Here's a problem I had on my x64 machines, and a suggested fix:

Problem:
I deployed the OnSave Event Sink by simply copying the project Release
folder files to the destination Server, added it manually to Component
Services, then created an Event Registration on a Public Folder using
Exchange Explorer. All seemed to go well, but the Sink didn't work.

Cause:
When I saw "Imports ADODB" in the MSDN sample code for "Implementing a
Managed OnSave Event Sink", I selected adodb" from the list of .NET
References. This points to the file at "C:\Program Files
(x86)\Microsoft.NET\Primary Interop Assemblies\adodb.dll" on my Development
Server. Unfortunately, this file did not exist on the destination Server
because VB.NET was not installed, so the Event Sink failed.

Solution:
Delete the .NET ADODB Reference and add a Reference instead in one of the
following two ways: 1) browse to and select the Interop.msado28.dll file in
the "C:\Program Files\Microsoft\Exchange Server\Bin" folder. Then revise the
line in the project code to read "Imports ADODB = Interop.msado28", or 2)
select "Microsoft ActiveX Data Objects 2.8 Library" from the list of COM
References. For solution 2 you don't even need to change the code since the
CDO Reference appears on the list using the same "ADODB" name as the .NET
version.

Hope this helps,
Don
Mar 8 '07 #8

This discussion thread is closed

Replies have been disabled for this discussion.