Post Install - Application Services Registration Fails
I have installed activated Geocortex Essentials 3.4.2 on Windows 7 32 bit. Geocortex Agent is up and running 3 components (Authentication and User Management services, Storage Services and Token Security Services all show running). I am going through the Post Install and at the very end I get a window pop titled "Application Services Registration" showing an error and requesting login information.
In this window it states:
An unknown error was encountered. For more information, review the details of the error.
When I click View Details, I get the following information.
System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:02.7680000'. ---> System.IO.IOException: The write operation failed, see inner exception. ---> System.ServiceModel.CommunicationException: The socket connection was aborted. This could be caused by an error processing your message or a receive timeout being exceeded by the remote host, or an underlying network resource issue. Local socket timeout was '00:00:02.7680000'. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host
at System.Net.Sockets.Socket.Send(Byte[] buffer, Int32 offset, Int32 size, SocketFlags socketFlags)
at System.ServiceModel.Channels.SocketConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
--- End of inner exception stack trace ---
at System.ServiceModel.Channels.SocketConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
at System.ServiceModel.Channels.BufferedConnection.WriteNow(Byte[] buffer, Int32 offset, Int32 size, TimeSpan timeout, BufferManager bufferManager)
at System.ServiceModel.Channels.BufferedConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
at System.ServiceModel.Channels.ConnectionStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.Net.Security._SslStream.StartWriting(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security._SslStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
--- End of inner exception stack trace ---
at System.Net.Security._SslStream.ProcessWrite(Byte[] buffer, Int32 offset, Int32 count, AsyncProtocolRequest asyncRequest)
at System.Net.Security.SslStream.Write(Byte[] buffer, Int32 offset, Int32 count)
at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
--- End of inner exception stack trace ---
Server stack trace:
at System.ServiceModel.Channels.StreamConnection.Write(Byte[] buffer, Int32 offset, Int32 size, Boolean immediate, TimeSpan timeout)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.SendPreamble(IConnection connection, ArraySegment`1 preamble, TimeoutHelper& timeoutHelper)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.DuplexConnectionPoolHelper.AcceptPooledConnection(IConnection connection, TimeoutHelper& timeoutHelper)
at System.ServiceModel.Channels.ConnectionPoolHelper.EstablishConnection(TimeSpan timeout)
at System.ServiceModel.Channels.ClientFramingDuplexSessionChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
Exception rethrown at [0]:
at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
at System.ServiceModel.Security.SspiNegotiationTokenProvider.OnOpen(TimeSpan timeout)
at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Security.CommunicationObjectSecurityTokenProvider.Open(TimeSpan timeout)
at System.ServiceModel.Security.SecurityProtocol.OnOpen(TimeSpan timeout)
at System.ServiceModel.Security.WrapperSecurityCommunicationObject.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.SecurityChannelFactory`1.ClientSecurityChannel`1.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.Channels.ServiceChannel.OnOpen(TimeSpan timeout)
at System.ServiceModel.Channels.CommunicationObject.Open(TimeSpan timeout)
Exception rethrown at [1]:
at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
at System.ServiceModel.ICommunicationObject.Open(TimeSpan timeout)
at Geocortex.ApplicationServices.Common.SecureServiceHelper.EstablishTrust(TrustContext context, X509Certificate2 cert)
at Geocortex.ApplicationServices.Common.SecureServiceHelper.EstablishTrust(TrustContext context)
at Geocortex.Essentials.PostInstall.AppServicesConfigPanel.EstablishTrust()
Anyone have any ideas what is wrong?
-
Also, the Agent Log file, Application Log File and event logs are not showing an errors or information related to the issue.
0 -
Kevin,
I had a problem earlier this week with the app services registration. This article got me started in identifying the problem: http://support.geocortex.com/Forums/Thread.aspx?pageid=0&mid=2&ItemID=2&thread=45255&postid=131379
But ultimately, Latitude support determined that the Georcortex certificates didn't install properly. After we fixed that the registration succeeded.
Hope this helps point you in the right direction.
0 -
Thanks for the info Eric. I actually came across that forum post and from what I can tell both ports 723 and 724 are open and working.
If it is certificates....well I guess I will have to talk to Latitude (still waiting for them to get back to me on the question).
One way around it was to not install the Application Services. This doesn't help though if you want to make use of it though.
0 -
It appears my problem was also Certificate related. I had three certs located under Personal\Certificates in the Certificates MMC snap-in. I did not have the certs located in the file system here though:
C:\Users\All Users\Latitude Geographics\Certificates
or
C:\ProgramData\Latitude Geographics\Certificates
Actually there was not certificates folder in either location. After talking with Latitude about it, I ended up deleting the certificates from the Certificates MMC snap-in. When I re-ran the post-install and registered with Application Services, the certificates were re-created and placed in both the snap-in and the two file locations above.
Everything seems to be working now.
0 -
Kevin,
That is exactly what I had to do to solve the problem. However, this issue has occurred twice since then. Things will be working fine one day, then the next morning I login to the REST Manager and attempt to make changes to existing sites or create a new one and I'm met with the "No connection could be made because the target machine actively refused it myhostname.com:724" error. It's easily solved by repeating the steps you described in your post above, but it does not do much for my level of confidence in maintaining high availability web services.
Anyone have any ideas?
-Eric
0 -
I'm still having this problem. I ran the fix on Friday (delete Geocortex certificates > restart Agent > rerun Post-Install), which fixed the problem. Then this morning when I got to work the site had crashed again. Surely there is someone else out there who is experiencing this problem in the same way that we are. Can someone please help?
Environment:
Windows Server 2008 R1
ArcGIS Server 9.3.1
Geocortex Essentials 3.3
IIS 70 -
I have had a problem with the 'Application Services Registration' multiple times and have tried all the suggestions given. Here is what seems to have solved it for me (running Windows Server 2003 and Essentials 3.5):
In the Windows Event Viewer under application an error with source 'crypt32' always displayed when I've had this problem. Microsoft have a kb article on this which basically explains how to disable 'Update Root Certificates' under Windows Components (Add/Remove programs) - details here:
http://support.microsoft.com/kb/317541
Hopefully this will solve it for others.
Josh
0 -
Lets add another solution to this problem.
So today we came up with the same error just a different reason for it. Long story short is we found that the "System" account had lost permissions to the following folder
C:\ProgramData\Microsoft\Crypto\RSA\S-1-5-18
We applied the same permissions as were on the parent folder which was Full Control.
PLEASE READ:
We were working on a web farm and had one node working while the other was throwing the above error. We discovered that permissions were missing on the node that was not working. What is really strange though is while we were checking permissions on the working node, the "System" account lost its permissions to that folder. There were two of us watching the process and we know we canceled out of the screens and didn't apply any changes. We can only say that this was some strange Microsoft glitch that removed the permissions. We can only guess that sometime in the past we had checked the permissions on that folder on the machine which was not working. This put the nodes out of sync and resulted in one working and one not.
0 -
Kevin,
I'm glad to hear you found a solution for your implementation. Unfortunately, we have not. I ran through all the permissions and everything is as it should be. I upgraded to Essentials 3.6 in hopes that a new version of the application services would fix the problem, but to no avail. We are at the point now where we're ready to give up on Essentials, which is a shame given all the effort put into it.
Eric
0 -
Eric I work with Kevin and was the one that found the permissions issue. Something I can suggest is get a tool from MS (free tool and used to be from Sysinternals) called Process Monitor (procmon). Get the version for your server and run it while you run the post install and see if you see an access denied somewhere. You can then get the properties of the process/thread that is running and see what account is having problems as yours could be an account you might not expect (past experience speaking here).
Later
0
Du måste logga in om du vill lämna en kommentar.
Kommentarer
10 kommentarer