You are viewing limited content. For full access, please sign in.

Question

Question

Laserfiche.HttpClient.HttpException: Error sending HTTP request to server

asked on December 7, 2021 Show version history

Hi everyone,

 

We're trying to set up a script that will export pages from a document in Laserfiche Cloud when certain conditions are met. The script we're using is the following:
 

	public class ExportarPagina
	{
		public static Task<IDictionary<string, object>> MyScript(IDictionary<string, object> inputsFromRule)
		{
			//Initialize a Dictionary to store your outputs
			var outputsFromScript = new Dictionary<string, object>();


			int EntryID = Int32.Parse(inputsFromRule["EntryID"].ToString());
			string Ruta = inputsFromRule["Ruta"].ToString(); //path to save exported pages or doc
			string numPags = inputsFromRule["NumeroPagina"].ToString(); //values: number between 1 and n; word:Completo

			try
			{
				// Session login
				CloudTicketRequestSettings cloudTicketSettings = new CloudTicketRequestSettings();
				cloudTicketSettings.AccountId = "xxxxxxxxx";
				cloudTicketSettings.UserName = "xxxxxxxxxx";
				cloudTicketSettings.Password = "xxxxxxxxxx";
				cloudTicketSettings.CustomEndpoint = new Uri("https://acs.laserfiche.com/ACS");
				
				string repositoryHost = "r-abcde123.laserfiche.com";
										 
				CloudTicket cloudTicket = CloudTicket.GetTicket(cloudTicketSettings);
				Session cloudSession = Session.Create(repositoryHost, cloudTicket);

                                //Actions here
				
				
				cloudSession.LogOut();
				return Task.FromResult<IDictionary<string, object>>(outputsFromScript);
			}

			catch (Exception e)
			{
				outputsFromScript["Mensaje"] = e.ToString();
				return Task.FromResult<IDictionary<string, object>>(outputsFromScript);
			}	
		}
	}

The script works as expected in the dev environment with our server. However, once we move it to production, we get the following error:

Laserfiche.HttpClient.HttpException: Error sending HTTP request to server. ---> System.ComponentModel.Win32Exception: Unknown error (0x2efd)

   --- Fin del seguimiento de la pila de la excepción interna ---

   en Laserfiche.HttpClient.HttpRequest.DoSendRequest()

   en Laserfiche.HttpClient.HttpRequest.SendRequestWithCredentials(Boolean useKerberos, Boolean negotiateAuth)

   en Laserfiche.HttpClient.HttpRequest.SendRequest()

   en Laserfiche.RepositoryAccess.CloudTicket.GetTicket(CloudTicketRequestSettings requestSettings)

   en LF_Cloud_ExportarPaginas.ExportarPagina.MyScript(IDictionary`2 inputsFromRule)

 

Technically, both servers have been set up the same way. There are different AV in both, but rules have been set in place to allow the URLs. If we ping from the prod server to the repository URL and we can get to it without issues. We can also log in to Cloud from that server using the browser. The Remote Agent has been updated to the latest available version in cloud and connection is established with the repository. 

Searching on answers and online I find that this issue is most likely related to a network problem, but like I said, technically the connections are enabled. Has anyone else come across this issue with LF Cloud?

0 0

Replies

replied on December 7, 2021

Hi Edgar,

While I haven't run into this exact issue before, your description did remind me of another network-related case where a user could access a certain URL in a browser on the server while a service on the same machine couldn't reach it.

The culprit ended up being Windows proxy settings (Internet Options -> Connections -> LAN Settings). The user's account was configured to use a proxy that enabled outbound internet access to the URL, while the service's account wasn't.

I wrote more about this and what to do about the general issue here: Do the HTTP activities respect the proxy configuration in the HKCU of the Workflow service account?

1 0
replied on December 7, 2021

Hi Samuel,

 

That's an interesting take. I reviewed the settings and, at least on a server level, I'm not running on a proxy. I will pass this along to the network team to have a different take at this problem. Now, it's worth mentioning that the LFPALocalAgent service is running with local system account, and that Import Agent is also installed on the same server and also running as local system account and it works properly with Cloud. 

 

Thanks for the guidance!

0 0
replied on December 9, 2021

Well, I stand corrected: Import Agent WAS working in the past. As we've been troubleshooting with IT, it seems ImportAgent is returning this error when trying to process a document:

Error al ejecutar el perfil Perfil Prueba mientras se importaba el archivo "\\ServerPath\20211012160851545_0027.pdf". (Método no encontrado: 'Void Laserfiche.RepositoryAccess.EntryInfo.LockWithCheck(Laserfiche.RepositoryAccess.LockType, System.Nullable`1<System.TimeSpan>, System.String, Laserfiche.RepositoryAccess.LockExtent)'.)
 
Error Code: 
 
StackTrace:    en Laserfiche.ImportAgent.Service.ExecuteProfileElectFile.ImportFile(ExecutionContext context)
   en Laserfiche.ImportAgent.Service.ExecuteProfileFile.Execute(ExecutionContext context)

And whenever I try to edit a profile, I get prompted to sign in and get the following error after typing the credentials:

 

From the server itself, I still have access via browser to Cloud. I can even ping and tracert the URL to the repository:

Taking your advise, I changed the login of the services to use my account instead of local system, but we got the same result. 

IT is telling me that on the firewall and AV side, all rules and exceptions have been applied. I'm drawing a blank.

0 0
replied on December 9, 2021

One note is that ping (and by extension tracert which uses ping under the hood) is an unreliable test here and doesn't tell you anything beyond the most basic outbound connectivity check. ICMP (ping) messages are often treated differently than TCP/HTTP requests by firewalls and proxies.

Instead, try in PowerShell:

Test-NetConnection r-######.laserfiche.com -port 443

You can also use "tnc" as an alias for Test-NetConnection. That will make a TCP request on the same port the service is trying to use.

Then try:

Invoke-WebRequest -Uri 'https://r-######.laserfiche.com' -Method GET

I'm not sure exactly what that's supposed to return normally, but it's definitely something other than "Error sending HTTP request to server."

Use psexec to run PowerShell as the System account.

Let me know the results of the tests above.

1 0
replied on December 13, 2021

Hi Samuel,

 

This has proved to be a difficult task. Long story short: I've had to run these tests on both PS 5.1 and 7.2, and I get mixed results:

I had to update PS to version 5.1 to try and get the Test-NetConnection cmdlet, but ultimately I failed due to PS not allowing me import the module. I had to run that test instead on PS 7.2 and it (somewhat) succeeded:

 

The interesting part comes with the second test. On PS 5.1 it failed:

However, on PS7 it succeeds:

 

Any thoughts?

0 0
replied on December 13, 2021

Well that is certainly interesting. I don't know enough about PowerShell internals to be able to say why that is, or if it's even relevant to the issue at hand.

The next troubleshooting step would be to take a Wireshark trace of the connection attempt. Use "nslookup r-#####.laserfiche.com" to get the IP(s) and apply a Wireshark capture filter for those. If you take a trace, please open a support case, link to this post, attach the trace to the case, and reply here with the case number. I'll follow up on it. You seem like you know what you're doing on the IT side; let me know if Wireshark instructions would be helpful though.

Are you able to connect to the Prod repository endpoint from your working Dev environment?

You said in the original post "There are different AV in both [servers]." I personally would try setting up a new server with the same AV and configuration as your working Dev one.

The error you're getting is a low-level and generic Windows networking error. There aren't that many hits for it. Here are all the ones I've found:

 

The Wireshark trace might tell us more.

1 0
replied on December 14, 2021

Hi Samuel,

I had opened a support case for a different issue regarding Import Agent. Long story short, the issue was that TLS 1.2 had not been enabled in this server. After following the KB from microsoft provided by support, both the issue with Import Agent and this one were resolved:
https://support.microsoft.com/en-us/topic/update-to-enable-tls-1-1-and-tls-1-2-as-default-secure-protocols-in-winhttp-in-windows-c4bd73d2-31d7-761e-0178-11268bb10392

 

Thank you so much for your help and guidance! 

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.