I am using a network charge to import files PST in Office 365 follow this link:
https://support.office.com/es-es/article/Usar-la-carga-en-la-red-para-importar-archivos-PST-en-Office-365-103f940c-0468-4e1a-b527-cc8ad13a5ea6?ui=es-ES&rs=es-ES&ad=ES
The transfer start, but in the end display (for the detail in every mailbox) the next:
"The transfer failed: Unable to connect to the remote server"
"The transfer failed: Unable to write data to the transport
connection: An existing connection was forcibly closed by the remote
host"
I have a user administrator and a file shared with all Access: to read and write, i don`t know if i need something special permission or disable something service?
Please your help!
Best Regards,
Verónica Muentes
"The transfer failed: Unable to write data to the transport connection: An existing connection was forcibly closed by the remote host"
The error is often caused by following 2 reasons.
Azure storage request either using http or https. That means it send requests through ports 80 or 443. So you need to make sure these ports are open to the internet.
Please double check whether you used a proxy on your machine. If yes, you need to disable the proxy or create a configuration file named 'AzCopy.exe.config' to the following location 'C:\Program Files (x86)\Microsoft SDKs\Azure\AzCopy\'.
In this file you will need to add the following XML:
<configuration>
<system.net>
<defaultProxy>
<!--PROXY_ADDRESS: Is the proxy address used to connect to the internet, e.g. myproxy.company.com
PORT_NUMBER: Is the port number used to connect to the proxy, e.g. 8080-->
<proxy proxyaddress="http://PROXY_ADDRESS:PORT_NUMBER" bypassonlocal="true" />
</defaultProxy>
</system.net>
</configuration>
Related
I have a Mule 4 application [App1] created on CloudHub. I tried to deploy the application's jar file onto CloudHub. This application has a Static IP [eg. 100.101.102.103] assigned to it in Runtime Manager. This IP address is whitelisted by customer to allow communication with their SFTP sites and APIs. My Mule application has APIs and some SFTP flows. When I try to deploy my mule application [App1], the deployment fails with below error:
Connectivity test failed for config 'SFTP_Config'. Application deployment will continue. Error was: Could not establish SFTP connection with host: 'sftp.hostname' at port: '22' - Error during login to 'sftpuser#sftp.hostname'.
The SFTP Config is:
<sftp:config name="SFTP_Config" doc:name="SFTP Config" doc:id="5d626288-5181-41d5-807d-2786ea4292d8" >
<sftp:connection host="${sftp.host}" port="${sftp.port}" username="${secure::sftp.username}" password="${secure::sftp.password}" connectionTimeoutUnit="MINUTES" connectionTimeout="2" responseTimeoutUnit="MINUTES" responseTimeout="2" workingDir="${sftp.peoplePosition.directory}">
<reconnection failsDeployment="false" >
<reconnect frequency="${sftp.retryInterval}" count="${sftp.retryAttempts}" />
</reconnection>
</sftp:connection>
</sftp:config>
I also tried using failsDeployment="false" in the SFTP configuration as recommended in this KB article
but it didn't work either.
The log shows:
[2023-02-16 05:59:00.754] ERROR
org.mule.extension.sftp.internal.connection.SftpConnectionProvider
[qtp1351434790-36]: Auth fail
com.jcraft.jsch.JSchException: Auth fail
[2023-02-16 05:59:00.824] WARN
org.mule.runtime.core.internal.connection.
PoolingConnectionManagementStrategy
[qtp1351434790-36]: Failed to create a connection while
applying the pool initialization policy.
org.mule.runtime.api.connection.ConnectionException:
Could not establish SFTP connection with host: 'sftphost' at port: '22'
- Error during login to sftpuser#sftphost
at
org.mule.runtime.core.internal.connection.ErrorTypeHandler
ConnectionProviderWrapper.lambda$connect$0(ErrorTypeHandler
ConnectionProviderWrapper.java:70)
at java.util.Optional.map(Optional.java:215)
I have verified the SFTP credentials, they are working fine with Winscp.
Is there any way a CloudHub worker can complete the deployment successfully or validate the SFTP configuration using Static IP instead of it's own IP address?
I am trying to create a SAP RFC connection to a new system.
AFAIK the firewall (in this case to port 3321) is open.
I get this message at the client:
RFC_COMMUNICATION_FAILURE (rc=1): key=RFC_COMMUNICATION_FAILURE, message=
LOCATION SAP-Gateway on host ax-swb-q06.prod.lokal / sapgw21
ERROR timeout during allocate
TIME Thu Jul 26 16:45:48 2018
RELEASE 753
COMPONENT SAP-Gateway
VERSION 2
RC 242
MODULE /bas/753_REL/src/krn/si/gw/gwr3cpic.c
LINE 2210
DETAIL no connect of TP sapdp21 from host 10.190.10.32 after 20 sec
COUNTER 3
[MSG: class=, type=, number=, v1-4:=;;;]
And this message on the SAP server
Any clue what needs to be done, to get RFC working?
With this little info no one can know what the issue is here.
But it is something related to your network and SAP system configuration.
I guess your firewall does some network address translation (NAT) and the new IP behind the firewall does not match anymore with the known one. SAP is doing some own IP / host name security checks.
If not already done, check with opening the ports 3221, 3321 and 4821 in the firewall. Also check the SAP gateway configuration which IP addresses and host names are configured to be valid ones for it (look at what is traced in the beginning of the gateway trace file dev_rd at ABAP side).
Also consider if maybe the usage of a SAProuter would be the better option for your needs.
it works in my case if ashost is the host name, and not an IP address!
Do not ask me why, but this fails:
Connection(user='x', passwd='...', ashost='10.190.10.32', sysnr='21', client='494')
But this works:
Connection(user='x', passwd='...', ashost='ax-swb-q06.prod.lokal', sysnr='21', client='494')
This is strange, since DNS resolution happens before TCP communication.
It seems that the ashost value gets used inside the connection. Strange. For most normal protocols (http, ftp, pop3, ...) this does not matter. Or you get at least a better error message.
As far as my knowledge of Endeca goes, any time you want to add a new dgraph definition in your Endeca configuration, you have to run initializeServices.sh to set the updated configuration on EAC.
I was wondering if there is any way I can do that without running initalizeServices.sh (since it does a lot more than just update the list of Dgraph registered in EAC, and I want to prevent that).
I found the command ./runcommand.sh --update-definition allows you to do configuration changes to a Dgraph, which has already been registered with EAC, but if I add a new dgraph in config and run the command it fails with below error:
[11.17.16 16:00:07] INFO: Setting definition for host 'MDEXLiveHost2'.
[11.17.16 16:00:07] SEVERE: Caught an exception while checking provisioning
Caused by com.endeca.soleng.eac.toolkit.exception.EacCommunicationException
com.endeca.soleng.eac.toolkit.host.Host setDefinition - Caught exception while setting host definition.
Caused by com.endeca.eac.client.ProvisioningFault
sun.reflect.NativeConstructorAccessorImpl newInstance0 - null
I can't find any detailed logs of this error being generated anywhere in PlatformServices logs to further debug.
I could, however see in request log that /eac/ProvisioningService gave a HTTP code of 500, which leads me to believe that the script is trying to find current configuration of MDEXLiveHost2 and is unable to find it.
EDITED TO ADD Configuration for:
New host:
<host id="MDEXLiveHost2" hostName="${mdexLive.host2}" port="${mdexLive.eac.port}" useSsl="false" />
New Dgraph:
<dgraph id="DgraphLive2" host-id="MDEXLiveHost2" port="${dgraphLive1.port}"
post-startup-script="LiveDgraphPostStartup">
<properties>
<property name="restartGroup" value="A" />
<property name="updateGroup" value="a" />
<property name="DgraphContentGroup" value="Live" />
</properties>
<log-dir>./logs/dgraphs/DgraphLive</log-dir>
<input-dir>./data/dgraphs/DgraphLive/dgraph_input</input-dir>
<update-dir>./data/dgraphs/DgraphLive/dgraph_input/updates</update-dir>
</dgraph>
EDITED TO ADD errors after manually adding host using eaccmd.sh
Host definition file:
<host host-id="MDEXLiveHost2" host-name="172.18.0.7" port="9999" useSsl="false"/>
The host is added successfully (validated via describe-app)
$./eaccmd.sh describe-app --app myapp | grep MDEXLiveHost2
<host host-name="172.18.0.7" port="9999" host-id="MDEXLiveHost2" useSsl="false">
But, running any command I get this error:
[11.18.16 11:00:58] INFO: Updating provisioning for host 'MDEXLiveHost2'.
[11.18.16 11:00:58] INFO: Host name of host 'MDEXLiveHost2' has changed from 172.18.0.7 to 172.18.0.7 . Components on this host will be re-provisioned.
[11.18.16 11:00:58] INFO: Updating definition for host 'MDEXLiveHost2'.
[11.18.16 11:00:58] SEVERE: Caught an exception while checking provisioning.
Caused by com.endeca.soleng.eac.toolkit.exception.EacCommunicationException
com.endeca.soleng.eac.toolkit.host.Host updateEacDefinition - Caught exception while updating host definition.
Caused by com.endeca.eac.client.ProvisioningFault
sun.reflect.NativeConstructorAccessorImpl newInstance0 - null
If only this error could be made more verbose, that might give some help.
You do not have to run initializeServices.sh for every configuration change you make. When you execute other scripts in the control folder, they first check if there are any configuration changes and apply these changes.
As far as the error is concerned, I suspect you either didn't specify the MDEXLiveHost2 in your LiveDGraphCluster.xml or the host that you did specify is not reachable. Verify your configuration.
Lastly your approach to dynamically add more DGraphs into the cluster is not standard practice. When you configure your environment you should do a load test using ENEPerf to simulate the load and then create as many DGraphs and hosts as required. If you are adding more hosts and DGraphs dynamically, you also need to ensure that you add them, dynamically, into your load balancer configuration as well.
My first guess was that maybe the mdex host 2 didn't have Platform services/Mdex installed and Platform services running but it may be that the port you specified is incorrect.
<host host-id="MDEXLiveHost2" host-name="172.18.0.7" port="9999" useSsl="false"/>
Is your eac port 9999 and not 8888 (OOB value)? If it is 9999 on your ITL server, you want to make sure that it is also set to 9999 on your new Dgraph server.
I have a plone installation (4.2.5) with plone.app.ldap add-on. There is a site with plone-ldap enabled and our ldap server was changed to another domain/IP. So on, zope server downs on plone-ldap retrieving ldap information. Nothing more works even root ZMI.
Any request to server doesn't load anything few seconds after plone restart. Therefore I can't reconfigure our new ldap server neither by our site or ZMI interface.
In such case, How can I proceed to reconfigure the new ldap server on plone-ldap component? Is there some script application similar to ZMI to do this? Is it a known bug?
Some logs:
1) Zeoserver.log
2016-06-06T15:52:04 new connection ('127.0.0.1', 40051): <ManagedServerConnection ('127.0.0.1', 40051)>
2016-06-06T15:52:04 (127.0.0.1:40049) received handshake 'Z3101'
2016-06-06T15:52:04 (unconnected) disconnected
2016-06-06T15:52:04 (unconnected) disconnected
2016-06-06T15:52:08 new connection ('127.0.0.1', 40052): <ManagedServerConnection ('127.0.0.1', 40052)>
2016-06-06T15:52:08 new connection ('127.0.0.1', 40053): <ManagedServerConnection ('127.0.0.1', 40053)>
2016-06-06T15:52:08 new connection ('127.0.0.1', 40054): **<ManagedServerConnection ('127.0.0.1', 40054)>
2016-06-06T15:52:08 (127.0.0.1:40052) received handshake 'Z3101'
2016-06-06T15:52:08 (unconnected) disconnected
2016-06-06T15:52:08 (unconnected) disconnected**
2) client1/event.log
2016-06-06T15:53:12 ERROR event.LDAPDelegate {'desc': "Can't contact LDAP server"}
Traceback (most recent call last):
File "/usr/local/Plone/buildout-cache/eggs/Products.LDAPUserFolder-2.26-py2.7.egg/Products/LDAPUserFolder/LDAPDelegate.py", line 366, in search
connection = self.connect(bind_dn=bind_dn, bind_pwd=bind_pwd)
File "/usr/local/Plone/buildout-cache/eggs/Products.LDAPUserFolder-2.26-py2.7.egg/Products/LDAPUserFolder/LDAPDelegate.py", line 265, in connect
raise e
**SERVER_DOWN: {'desc': "Can't contact LDAP server"}**
Backup first
Disclaimer - I never seen before an LDAP configuration that freeze also the root-level admin ZMI access to the Plone site.
What I can quickly suggest you is to delete the ldap plugin from the site's acl_users and starts from scratch.
As ZMI is not usable you must use the console access.
For doing this run a zope instance as follow:
$ bin/instance debug
(where "instance" is one of your instances)
The you can delete the ldap plugin:
del app.Plone.acl_users['ldap-plugin-id']
Where Plone is the is of your site and ldap-plugin-id the is of the LDAP plugin.
If you don't remember it, look for it in this set:
app.Plone.acl_users.objectValues()
Finally you must persist your changes:
import transaction;transaction.commit()
...then exit using CTRL+D
Now you must be able to access ZMI and you must create and reconfigure a new plugin.
Please note: when configuring an LDAP or AD plugin always set a "Connection timout" and an "Operation timeout". This is probably why your access attempt totally freeze the instance.
I'm trying to get PingAccess set up as a proxy (let's call the PA host
pagateway) for a couple of applications that share a Web Session. I want all access to come via the PA pagateway and use HTTPS, but the back end systems are not HTTPS.
I have two sites defined, app1:8080 and app2:8080. Both are set to "secure" = no and "use target host header" = yes.
I have listeners defined on ports 5000 and 5001 that are both set to "secure" = yes.
The first problem I found is that when I access either app in this way (e.g. going to https://pagateway:5000), after successfully authenticating with PingFederate I end up getting redirected to the actual underlying host name (e.g. http://app1:8080), meaning any subsequent interactions with the app are not via PingAccess. For users outside the network they wouldn't even be able to do that because the app1 host wouldn't even be visible or accessible.
I thought maybe I needed to turn off "Use target host header" to false but Chrome prompts me to download a file that contains NAK, ETX, ETX, NUL, STX, STX codes, and in the PA logs I get an SSL error:
2015-11-20 11:13:33,718 DEBUG [6a5KYac2dnnY0ZpIl-3GNA] com.pingidentity.pa.core.transport.http.HttpServerHandler:180 - IOException reading sourceSocket
javax.net.ssl.SSLException: Unrecognized SSL message, plaintext connection?
at sun.security.ssl.InputRecord.handleUnknownRecord(InputRecord.java:710)
...
I'm unsure exactly which part of the process the SSL error is coming from (between browser and pagateway, or pagateway and app1). I'm guessing maybe app1 is having trouble with the unexpected host header...
In another variation I turned off SSL on the PA listener (I also had to change the PingAccess call-back URL in the PingFederate client settings to be http). But when I accessed it via http://pagateway:5000 I got a generic PingFederate error message in the browser and a different error in the PA logs:
2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:148 - Invoking request handler: Scheme Validation for Request to [pagateway:5000] [/]
2015-11-20 11:37:25,764 DEBUG [DBxHnFjViCgLYgYb-IrfqQ] com.pingidentity.pa.core.interceptor.flow.InterceptorFlowController:200 - Exception caught. Invoking abort handlers
com.pingidentity.pa.sdk.policy.AccessException: Invalid request protocol.
at com.pingidentity.pa.core.interceptor.SchemeValidationInterceptor.handleRequest(SchemeValidationInterceptor.java:61)
Does anyone have any idea what I'm doing wrong? I'm kind of surprised about the redirection to the actual server name, to be honest, but after that I'm stumped about where to go from here.
Any help would be appreciated.
Have you contacted our support on this? It's sounding like something that will need to be dug into a bit deeper - but some high level suggestions I can make:
Take a look at a browser trace to determine when the redirect is happening to the backend site. Usually this is because there's a Location header in a redirect from the backend web server that (by nature) is an absolute URL but pointing to it instead of the externally facing hostname.
A common solution to this is setting Target Host Header to False - so it will receive the request unmodified from the browser, and the backend server should know to represent itself as that (if it behaves nicely behind a proxy).
If the backend server can't do that (which it sounds like it can't) - you should look at assigning rewriting rules to that application. More details on them are available here: https://support.pingidentity.com/s/document-item?bundleId=pingaccess-52&topicId=reference%2Fui%2Fpa_c_Rewrite_Rules_Overview.html. The "Rewrite Response Header Rule" in particular will rewrite Location headers in HTTP redirects.
FYI - The "Invalid request protocol." error you're seeing at bottom of your description could be due to a "Require HTTPS" flag on your defined Application.
Do you have the same issue if you add a trailing slash at the end (https://pagateway:5000/webapp/)? Your application server will rewrite the URL based on what it thinks is the true host. This is to get around some security related issues around directory listing.
Which application server are you using? All app servers are unique, but I'll provide instructions on how to resolve this with Tomcat.
Add a global rule that forces the application server to use the external facing host name. Here is a sample Groovy script:
def header = exc?.request?.header;
header?.setHost("pf.pingdemo.com:443");
anything();
In Tomcat's server.xml, add scheme="https" to the connection:
<Connector port="8080" protocol="HTTP/1.1"
connectionTimeout="20000"
redirectPort="443" scheme="https" />
Cheers,
Tam