So I've been running CF9 on Linux for a while and using CFMail to send email through a client's Exchange 2010 server for quite a while.
We're attempting to migrate to CF10 on Win2008, IIS7.5. Everything is set and ready to go except I can't get CF10 to verify the mail connection? I've got both mail settings (CF9 and CF10) set the exact same way and can view them open side by side and verify they're identical. However, while the CF9 verifies successfully the CF10 system fails??
I tried sending through CFMail tags while specifying the server credentials and see this in the CF10 log:
"javax.mail.AuthenticationFailedException: No authentication mechansims supported by both server and client"
What does this mean? I know my authentication credentials are correct because I'm able to connect in CF9.
I've turned off all firewalls and still nothing. So, I then tried installing CF10 on my Mac laptop. It, too, will not verify the mail connection!
Is there a known problem with CF10 connecting to an Exchange mail server?
Any ideas?
I "solved" this.
I could find little online and received no comments to this thread. No combination of settings I tried would work and I have no access to the client's mail server. The person who runs that server couldn't run a lemonade stand so no help there.
Then I stumbled across this page. Nothing to do with ColdFusion but seemed like a similar issue.
Recent changes in the JavaMail API has changed certain authentication
defaults and sometimes will create an authentication error with some
Exchange Server environments dependent on the configuration.
I'd never put much thought into CFMail because it was always drop dead simple and simply worked. Focusing on this link's Resolution 2 (ie replace the mail.jar with an older version). I wondered if CF used JavaMail and if I could downgrade CFMail? I cracked open CF's mail.jar file and found that CFMail does, indeed, use the JavaMail API. So, I then checked the ColdFusion docs to see if any new features were added to CFMail between CF9 and CF10. None.
So, I swapped out the mail.jar file from my CF9 install to CF10 and restarted. Boom! Everything worked immediately. As far as I can tell I've had no compatibility issues to report.
Swapping the mail.jar did not work for me. However, adding the following to JVM arguments
-Djava.net.preferIPv4Stack=true
worked for me. Please refer to the following article
Java Mail mystery - SMTP blocked?
posted by another user
Related
I know this question has been asked several times but I have a slight variance on it that I have been trying to resolve.
I have crystal reports running on an old web system written in classic asp. All the reports have been running without problems for several years, however recently security was improved so that the system is now accessed over HTTPS. Since this change the reports have all started asking for the database credentials. If SSL is disabled so that it returns to regular HTTP then they start working again.
The system was created by another developer who has since moved on so I am not very familiar with it, but as far as I am aware the reports are all set to use a System DSN set up in the control panel of the server that IIS is running on. The database is located on a separate server.
Does anybody have a suggestion as to why the reports would start asking for database credentials after changing to HTTPS and how to resolve it? I will not be able to make any code changes to the application as the source code is not available but I can modify the reports and play with connection settings etc.
I have figured out the problem. The site was running HTTPS but the button for the report was in a form which submitted to HTTP and then was redirected back to HTTPS. This was causing a loss of the session information or something like that. Fortunately the forms action url was stored in the database so it was a simple matter to resolve.
I have taken over a CTI project for the Avaya IP Office PBX and am trying to resolve a customer issue for a new installation on site which I also have on my test system in the office. Our CTI application uses the Avaya TAPI driver to communicate with the PBX, I have configured the TAPI driver with the IP address of the PBX, enabled third party mode (I need to see data from all extensions), enabled ACD queues and entered the correct password. I've also turned on debug tracing in the driver. I am using Astice TAPI monitor to check that everything is okay before turning on our application but here is where the problem lies: In Windows only the first extension configured on the switch is displaying in Windows, everything works correctly for this extension and I see call details fine but it does not display any other extensions and this is the exact problem that I have on the customer site.
On my test system, IP Office itself seems to be configured correctly (AFAIK there is not much config to do on the PBX anyway) and the CTI Link Pro license is enabled and displayed as valid and set to never expire.
Does anybody have any idea at all why only the first extension should be displayed?
EDIT: I've since found that this issue only occurs on Windows 7, on Windows XP it is fine. This means that it is highly unlikely that the problem is due to any settings on the PBX.
In the (unlikely) case that anybody else has had this issue it was actually due to the Avaya TAPI driver not supporting Windows 7. I procured a newer driver from Avaya which resolved the issue. These drivers are not generally available so you will need a support or partnership contract with Avaya. Presumably if you are looking at a similar issue then that won't be a problem.
In my case I was trying use password "Administrator" for third-party, and there was one extension in "phone.exe" named "Line unnamed", problem was in password: default is "password".
We've managed to get talend MDM UI working fine over SSL, but we've not managed to get the MDM studio talk to the MDM server over SSL. Has anyone managed this? I've not tried the data integration input steps yet over SSL either.
I tried the forums - no joy.
I suspect for some reason it's not possible - And the reason I suspect this is that when you add an MDM server in TOS it prompts for port, hostname, user and password. Nowhere does it prompt for protocol.
One assumes that the EE version must surely support this? But we have a very simple model and wont be using EE as it would be OTT.
Thanks!
Dan
So it turns out this is a bug/unimplemented feature, and has been pencilled in to be fixed in 5.3.0 with luck!
https://jira.talendforge.org/browse/TMDM-4912
I've got SQL Server 2008 with SSIS/SSRS installed on my development box. I followed through the installation notes and everything appeared to install just fine - no errors or anything. I've got it configured using all the defaults for now until I figure out what is what. So the server can be accessed via http://localhost:80/ReportServer and the reports via http://locahost:80/Reports.
I've created a dummy report against the AdventureWorks database to test report creation and deployment and after some initial headaches which were resolved by running BIDS as an administrator, I'm having problems accessing the reports via the web interface and indeed, I'm having the same issue accessing the report server via the web interface.
When I open the URLs in any browser - IE/Firefox/Chrome they all prompt me for credentials. My dev box isn't part of a domain and the credentials I use to log into the machine don't appear to be what it is after as they don't connect successfully. I don't really understand why it's asking for credentials at all due to the fact that the address is an intranet address. In either case, IE is configured to pass through my Windows credentials when logging into machines on the intranet.
Did I configure something incorrectly when I set it up? Does anyone have any decent tutorials for not only installing SSRS, but configuration for development machines.
Try opening your browser with elevated (Administrator) privelages. Did that help?
This may also be related...
http://blogs.msdn.com/b/lukaszp/archive/2008/07/18/reporting-services-http-401-unauthorized-host-headers-require-your-attention.aspx
I have a DNN site (5.06) that I developed on a standalone machine running IIS7. When I copied the site to the production machine running IIS6 and enter the URL, such as www.site.com, I get a generic DNN error page with no additional information. However, if I add the default page, www.site.com/Default.aspx everything works fine.
The Friendly URL settings were never changed and I've verified Default.aspx is entered on the Documents tab in IIS6. The portal event viewer has no entry for the error page I get.
I'm nearly certain it has to do with migrating from IIS7 to II6; clearly I'm missing something here. Any ideas?
DNN has confirmed this is an error in 5.06, and will be addressed in a future update. That doesn't help me today, but I was able to work around the problem by adding the following to the Friendly URLs list:
Look for: .*/
Send To: ~/Default.aspx
I can't find the forum thread I was reading yesterday, but did find this one which also goes into detail on the issue: Error upgrading from 5.5.1 to 5.6.0
Pretty odd...
Double check PortalAlias table in your SQL server. Confirm www.site.com is in there.
Double check host headers in IIS6 has www.site.com
Make sure Default.aspx is in the documents area of IIS6 and set as the top default to run
Recycle your app pool
cross your fingers
Only thing I ever run into from IIS6 and IIS7 is in the app pool running in Integrated mode or classic... but that is usually as issue going from IIS6 to 7, not vice versa.
I was able to fix the issue (for me) by taking the web.config file from a working site with the same version of DotNetNuke and modifying it to have the correct machine key and connection strings. This is my last resort when DotNetNuke is being strange. I am running 10+ DNN sites at version 5.6.0 and I only encountered this issue once.