As the title says, I am trying to send files from local directory to a SharePoint online site with BizTalk. I am unable to do so for days and days... read tons of topic about it but nothing is working, I am a bit discouraged to be honest at the moment...
Here is how my send port is currently configured :
The account used has full access granted on the SharePoint site. I can log in with it using a browser without any issue, I can upload files as well.
Here is the error I encounter when trying to send a file :
I am using BizTalk 2016 with SharePoint Online.
If someone has an idea on how I could resolve this, I would be very very grateful.
BizTalk, or rather the .Net layer defaults to using older TLS protocols, namely TLS 1.0, and doesn't then negotiate up.
To address this you need make sure you have CU5 for BizTalk Server 2016 or later (currently CU8) and then follow the steps in "Option 1: Switch to the TLS 1.2 protocol" section of the following article in the Microsoft Knowledge Base:" as per the article Support for TLS 1.2 protocol in BizTalk Server
3155464 MS16-065: Description of the TLS/SSL protocol information disclosure vulnerability (CVE-2016-0149): May 10, 2016
or
Use the scripts from the following Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2
Note: You will have to test to make sure no other system BizTalk connects to still uses TLS 1.0 or 1.1, and if so not to disable those, but to try to default to 1.2.
Related
It is quite easy do enable HTTP/2 on Azure App Service. However, it is still disabled for existing components and also for new ones. Why is that?
Unsecured requests are still served by HTTP 1.1 if I enable the feature. Can enabling HTTP/2 have any negative impact for my site? Our apps run on .NET, ranging from .NET Framework 4.6.2 to .NET 5.0.
After enabled HTTP 2.0 in your webapp, you need clear cookies and sessions, then you will find your webapp is works fine with HTTP/2 . Or wait a little longer.
1. You can open a new inprivate window, it works for me.
2. The second question is that enabling HTTP 2.0 will not have a negative impact on your application.
Related Posts：
① Will HTTP/2 in Azure App Service auto fallback to HTTP/1.1 for legacy browsers
3. The third point, there are also considerations about the correct version of .Net Framework, 4.6.2 and above all support HTTP 2.0.
The above results are given through the test.
I have tested that HTTP Version is supported in .NET Framework 4.6.2 and above. So your first question, you can open the privacy window and try again.
My team has taken over some applications that were developed around 10 years ago. We are mainly for sustainment; however, there is also some development going on, primarily for security issues. On our Cognos server, we were required to upgrade from 10.2 to 11. Our server administrator installed Cognos 11; however, our previously working Single Sign-On (SSO) stopped working. We submitted a ticket to our IT services who said that it was out of their hands and asked us to fix it. This was months ago and there has been no progress. Our IT dept. put a ticket in with IBM and they asked the following:
1. For 441 (Cognos SSO Errors) errors, have you added pass through error in the bottom of the gateway configuration document?
2. What have the 441 errors resolved to?
3. What pass through method are you using to send authentication from "another site"? Service provider shibboleth, openid connect, etc.?
Does anyone know where I can find the gateway configuration document and where the pass through errors would be?
Also, how can I tell what they resolve to? I monitored my network traffic from my browser when trying to login but only see the 441, I guess the "resolving happens on the server" but I'm not sure where to find it.
Does anyone know how I can find the service provider they mention in question 3?
Thanks in advance for any help.
To use IIS as a Cognos gateway for Single Sign On for IBM Cognos 11.0.4 and later, use this document from IBM
http://www.ibm.com/support/knowledgecenter/SSEP7J_11.0.0/com.ibm.swg.ba.cognos.inst_cr_winux.doc/t_gateway_iis.html#t_sso_actdirserver
I have been trying to figure out how to use the Acumatica mobile app. I can log on without any problems but when I click on Expense Claims for example, I get a error 500. On a test store that we have in the same installation, it gives error 404. Is there any configuration that has to be done before the app can work? I have Acumatica version 5.1. I've looked at the results in the Request profiler but do not see any thing that could help. I have also been looking for any documentation on the mobile app, is there a framework development guide?
error 505 usually means difference between version on Acumatica site and mobile app.
Please verify that you have installed LATEST version from store and use Latest version of Acumatica.
Please provide version of your mob App (android or iOS) and version of Acumatica site.
Just installed latest version of Android app from http://play.google.com/ and connected to one of our test sites on 5.2 https://external.acumatica.com/Acumatica5/ to Demo company without any issues, i can open Expense Claims UI without issues.
Well, looks like it somehow related to network connection, first of all try to use HTTPS protocol instead of HTTPS
Also will be helpful if you provide url and credentials to your site.
Also, you can use some proxy to capture http traffic to figure out the reason, i'm using Fiddler for example
In this technote from IBM you can find the following answers:
Q1: Can I import the SHA-2 cert on a Domino 9.x server and then use that keyring on a Domino 8.5.x server? No. Domino 8.5.x lacks the
cryptographic infrastructure for SHA-2. This means if you import the
cert using 9.x and the Interim Fix and and KYRTool described above,
you can use that keyring on a Domino 9.0 or above server, but not on a
Domino server pre-Domino 9.0.
Q2: Can I get a hotfix on 8.5.x or earlier to support SHA-2? No. This
is not possible since releases prior to Domino 9.0 lack the
cryptographic infrastructure for SHA-2.
Is an update to Domino 9.x the only way the handle this issue? If so, how long it's time, before the relevant web browsers (ie, firefox and chrome) will cancel the support for SHA-1?
Yes, for long-term, upgrade to Domino 9 is the only solution. As a workaround you could use a reverse-proxy solution, (e.g. using Apache Web Server, NGINX or HAProxy), see https://frostillic.us/blog/posts/6AF303DE836BA02D85257D570058B1CA as an example.
Regarding browsers support of SHA-1:
Microsoft:
http://blogs.technet.com/b/pki/archive/2013/11/12/sha1-deprecation-policy.aspx
Google:
http://googleonlinesecurity.blogspot.co.uk/2014/09/gradually-sunsetting-sha-1.html
Mozilla:
https://blog.mozilla.org/security/2014/09/23/phasing-out-certificates-with-sha-1-based-signature-algorithms/
In order to be able to get SHA-2 certificates with Domino 8.5.3 you could install a reverse- proxy in front of domino and let that one handle encryption. But of course then you have two machines and two different software- environments to maintain. And you still have a "very old" software running.
As of this Link the first to abandon SHA-1 Support will be Microsoft in January 2016. Chrome will show warnings long before that but still accept them.
Firefox will not accept SHA-1 after January 2017.
From that point Chrome will also treat them as "affirmatively insecure".
Best advice: update your servers to 9.0.1 as fast as possible. The effort is minimal and then you can natively handle TLS 1.2
We have a single server inside the firewall used for all of our production apps. The server and clients are 8.5.3.
We have a single 'portal' server outside the firewall used by a small set of our customers for read-only access to a few apps via a browser. This server is currently at 8.5.3. Mail isn't implemented on this server; customers log in, see dbs, view docs, and leave. The only admin tasks I perform on this server are to add new users and push new replicas onto the external box (which I do from my Notes client, not the admin client)
Because of POODLE, we're going to be upgrading our portal server to 9.0.1. We have no plan to upgrade our internal server (or clients).
I'm the developer and admin for both servers.
I don't intend to install the 9.0.x designer client on my system.
Do I need to install the 9.0.x admin client or can I just keep using my 8.5.3 version?
Any risks with either scenario?
Thanks for any tips or suggestions.
Mixed versions of domino server and clients can be used and actually have been used for a long time. Certainly only the intersection set of features of these versions can be used.
I'm using Domino servers 9 (including cluster), we are TLS because af Poodle (see question). Most of our Client / Designer are 8.53. I recommand: do not install Client/Designer on the server (especially outside).
We had months a "last server" to upgrade (8.5) and this also didn't made problem. But I suggest to upgrade also the internal server.