One of the most helpful error messages (sad very sarcastically) in Business Objects XI is “destination DLL disabled. CrystalEnterprise.Smtp:”. You get this one usually after recently configuring a new job server or setting up your first scheduled job in a Business Objects XI environment. This error exists in XI R2 and it is definitely present in XI 3. So what does it mean and how do you fix it?
What is the “destination DLL disabled. CrystalEnterprise.Smtp:” Error?
This error essentially means that you do not have an SMTP/Email destination configured on the job server that your job or action is attempting to use. In some cases, your job may not even being trying to send email to anyone and you will still get this error if you have not configured an SMTP/Email destination for the job server being used. In XI R2 you need to be sure that the destination is enabled as well as configured. In XI 3 your will need to add it as it is not there by default and this will also enable it. Don’t forget the “Destination Job Server” as well as this one handles non-scheduled job, such as distributions straight from InfoView (I think). Also since jobs are assigned seemingly on a random basis, if your cluster has multiple job servers check them (or the specific job error) to pinpoint to trouble-maker.
How do I fix this error?
Easy, just configure an SMTP or Email destination on the job server (CMC > Servers > Job Server > Destinations). I highly recommend that you configure the SMTP/Email destination on all reporting job server (WebI, DeskI, Crystal), adaptive jobs servers (XI 3), and destination job servers. The only information that you must enter is domain, server name and port; however, your email admins might require the user id and password fields as well. Make certain that in XI R2 the destination is enabled too. This should stop the error; however, you might want to add more default information for the From/To email fields to prevent errors caused by users who will accept the defaults. I usually use the variable for the users email ID in both fields.
I just moved my organization from Exchange 2003 to Exchange 2007. We were getting regularly emailed reports from our BusinessObjects XI 3.1 server until the move to 2007. I went into the Central Management Console > Servers > .CrystalReportsJobServer and edited the Destination to include the new name of my Exchange 2007 server. Ive restarted all BOXI services, and also rebooted the BOXI server. Still no scheduled emails arrive. I have also forced a report to be emailed and the Instance Manager reports the job successful, but there still is no email. I have checked the Relay settings in my Exchange 2007 box, and mail from the BOXI server is explicitly allowed. I also checked message tracking on Exchange and it does not show any emails from the BOXI server arriving (and getting kicked back). So, it seems the emails never even leave the BOXI server.
I have upped the attachment size limit in Exchange, but the report Ive tested with is under 1Mb.
I have gone to Server and right-clicked every single one, and every one that had a Destination property, I have changed to the name of the 2007 server.
Any thoughts?
This is a head-scratcher… I would expect an error from the behavior you describe. The only thing that would not produce an error, in my experience, would be that your job was not actually configured to send an email using the new info. You might try creating a server group and setting a new scheduled job to use that server group only. Start with just a notification email or an email without an attachment and if you can get that to work try with an attachment…
I wish I had a better suggestion. Hopefully someone else does.
Found the answer to my problem. The problem was that my BOXI server has two nics, and the 2nd nic’s IP was not allowed in the Relay list on Exchange 2007.
How I found it:
When I logged onto BOXI server and telnet’d to port 25 of my 2007 exchange server, I got a response. But, the response was from AVG – our antivirus. I disabled the anti-virus figuring AVG was eating the emails, and then tested access to port 25 again. My exchange 2007 server would not accept a port 25 connection from my BOXI box at all then. (I also then tested emailing a report from BOXI, and it actually finally gave an SMTP error.)
So, I went back to my relay list on Exchange 2007 (Hub Transport > Default Receive Connector > Network > “Receive mail from remote servers….” and added the machine’s 2nd nic’s IP address.
Retested emailing from BOXI, and all is well.
Thanks Maria for posting your solution!
It seems logical now, BO was reporting no problems, Exchange was receiving no emails, and so the problem had to be between in the layer between BO and Exchange.
This is not the first time that I have heard multiple NICs as being the source of problems experienced by BO implementations. Even high-level BO support engineers commonly suspect dual NICs of causing/contributing to BO issues.
I’m a first timer at this site and I think you can help. Actually already have some; I just need some clarification.
We are running BOXI R3. I need to be able to schedule some reports to run automatically daily (which I can do) and have them emailed automatically.
I’m a little confused on which servers need the destination information provisioned in them. I see from your original post that it’s more than just the DestinationJobServer (which is all I tried so far). By the way, I found this thread because I saw the same error code mentioned at the beginning.
My BOXI system is running on an 8 node cluster of linux servers so I have 8 of each type of server.
If you could clarify which servers need this info provisioned that would help me greatly. There seems to be 29 servers (for each node). I’m definitely a novice using BOXI so far.
A related question – when I schedule a report to be emailed can it have more than one email destination? Would I have to schedule it separately for each email destination?
Thanks in advance for your help.
Jeff
Hi Jeff,
The most important place for you to setup your destinations is on all reporting job server (WebI, DeskI, or Crystal, depending on which ones you use). Scheduled jobs will always use the destination configured on their specific corresponding reporting job servers.
For example, a WebI report will use the “Web Intelligence Job Server”. If you have many in your cluster then you better setup the destination on each and every one of them.
By the way, if I am not mistaken you may be able to see the server’s name that the job attempted to use in the error.
Now, I would be curious to understand better you architecture. If I understand you correctly, I could offer some tips on how to better configure your cluster/environment. Please email me if interested.
hi julian,
well, iam using bo xi r3.0 edge series in windows vista.
i want to schedule a deski with the instance copied to my desktop as destination.
I have added the filesystem from the drop down in both destination job server and also the program job seerver. but still get the same error ” destination DLL disabled. [CrystalEnterprise.DiskUnmanaged]: [] “
julian,,
you can ignore. this got resolved by adding from deski job server as well.
Hi Shravee, I think your problem is that neither of those job servers are the job server that is running your DeskI job. Does your system have a “Desktop Intelligence Job Server” or an “Adaptive Job Server”? Those are the ones that run reports refreshes. Program Job Servers are for running scripts or Java code, nor reports. Destination Job Server are for small requests submitted in the User Interface (InfoView) for sending a document to a destination, again, nor for refreshing a document.
Oops, I see you figured it out! Excellent work.
Good Morning All, i have changed the settings as per your helpful suggestions and that sorts the e-mail out. My users still get the same error message though when they try to save the output to a predifined location on the application server. The idea being that they can use the output from one query to provide input variables for a subsequent one. There is also a need to save output straight to SharePoint. I don’t know whether that is all part of the same settings or whether that needs to be set up differently again. Any help gratefully received, Christiaan de Haes