September 28, 2006 at 12:45 pm
We're fairly new to reporting services.
We have a SQLServer 2005 Enterprise installation as an instance on a Windows 2003 server that is also running SQLServer 2000. Our Development area has a straight install of SQL2005, and we have no problems with report subscriptions by email from that environment. Unfortunately, the instanced production environment gives the following error on the Subscriptions page for a report. Settings between the two servers are as exact as I can make them.
The error is: Failure sending mail: Retrieving the COM class factory for component with CLSID {CD000001-8B95-11D1-82DB-00C04FB1625D} failed due to the following error: 8007007e.
This error shows under the "Status" field on the subscriptions page of the report. We encounter the error for all users in all reports.
I'm assuming it has to do with the registration (or lack thereof) of a particular COM object, but I've had no luck with searches and whatnot attempting to figure out what the object might be or where it is. I'm not seeing anything that looks related in any of the event logs.
Any help would be greatly appreciated. Thanks!
September 28, 2006 at 2:02 pm
Sounds like you have not configured the Exchange or SMTP properties properly within RS. Sorry I can't be more specific but I do not currently have a copy of 2005 running. I am shooting from memory.
Thank-you,
David Russell
Any Cloud, Any Database, Oracle since 1982
September 28, 2006 at 2:45 pm
That was the first thing I looked at. The settings were exactly the same as on the development server - which is working fine.
I'm currently looking at the possibility that some windows features that are on the dev server weren't installed on the non-working prod server and am attempting to add the missing features that may relate to emailing from an IIS site.
I did manage to trace the object that the error is talking about to a DCOM object called CDOMessage. I don't see that it is registered in the component manager on the dev machine either though.
September 29, 2006 at 11:18 am
Resolution:
Alright, after my last post, I went to the dev server to look at the keys related to CDOMessage. These keys are in the registry under (HKEY_CLASSES_ROOT\CLSID\). CDOMessage keys are labeled under: {CD0000xx-8B95-11D1-82DB-00C04FB1625D}, where xx is a number from 01-12. I noticed that on the Dev server, I had the numbers 01-12, where on the production server, I only had 02-12. From our error above, we know that the Reporting Services 2005 subscription mail send service is looking for {CD000001-8B95-11D1-82DB-00C04FB1625D}. This key was missing. I looked at the InprocServer32 keyvalue, and determined that on the working dev server, the DLL responsible for these keys was c:\windows\system32\CDOsys.dll. On the production server, it was c:\program files\common files\microsoft shared\CDO\CDOex.dll.
After doing some more Googling (how did we ever survive before Google?!?), I determined that some service packs and other windows programs (in our case, Exchange Server Manager) were known for damaging or otherwise changing the CDO object responsible for these keys. In our case, it looked like Exchange Server Manager had been installed, and our prod server was using CDOex.dll, which apparently didn't have the key we needed in it.
The suggested resolution on Google was to unregister CDOex.dll, and register CDOsys.dll. Using Regsvr32, I attempted to unregister CDOex.dll. I got a funky hex error. Using the full path, I got "module not found" or somesuch. I attempted to register CDOsys.dll, and got another hex error. After trying a ton of things, including safe mode, I still couldn't get it to register or unregister any combination of CDOsys or CDOex. More Googling - some people were reinstalling operating systems. Not good.
Looking in c:\program files\common files\microsoft shared\CDO\, I noticed that CDOex.dll didn't exist at all in that folder. Ok, so the registry has a registered DLL in it that doesn't actuall exist on the server. I went to http://www.webzila.com/?wz=dllc, downloaded CDOex.dll from it, and placed it into c:\program files\common files\microsoft shared\CDO\. I attempted to unregister it. Got another hex error. So I tried to register CDOex.dll and got a success! Now I unregistered it and got another success. I then registered CDOsys.dll from c:\windows\system32, and again...success.
Just to be safe, I restarted the ReportingServices service, and went to check on my subscription email I had set up to run every 2 minutes during trouble shooting. It's now working great.
So, sorry for the long writeup, but I want to make sure if anyone else runs into this they have a nice set of instructions and places to look to establish the problem and get a good resolution, or at least a resolution better than "reinstall your OS".
Viewing 4 posts - 1 through 3 (of 3 total)
You must be logged in to reply to this topic. Login to reply