Hi Years ago a programmer from another company wrote a .Net component that could be used in VFP to retrieve a file in XML format from a remote device. This component has worked correctly on previous versions of Windows Server. However, on Windows 2022 Standard it gives an error as shown below. I am not a .Net developer and the programmer who wrote the code has long since moved on. So I wondered if there were any .Net developers who might have a clue about what is wrong and possible steps to fix it. I am assuming something is missing on the Windows 2022 server but I have no idea what. We used the installer supplied with the tool to install it on the Windows 2022 server.
Thanks, Simon
10/18/2024 3:35:06 PM: Retrieve Transaction Error
Server stack trace:
at System.ServiceModel.Security.IssuanceTokenProviderBase`1.DoNegotiation(TimeSpan timeout)
at System.ServiceModel.Security.SspiNegotiationTokenProvider.OnOpen(TimeSpan timeout)
at System.ServiceModel.Security.TlsnegoTokenProvider.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.SymmetricSecurityProtocol.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.Security.SecuritySessionSecurityTokenProvider.DoOperation(SecuritySessionOperation operation, EndpointAddress target, Uri via, SecurityToken currentToken, TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionSecurityTokenProvider.GetTokenCore(TimeSpan timeout)
at System.IdentityModel.Selectors.SecurityTokenProvider.GetToken(TimeSpan timeout)
at System.ServiceModel.Security.SecuritySessionClientSettings`1.ClientSecuritySessionChannel.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.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 System.ServiceModel.ClientBase`1.System.ServiceModel.ICommunicationObject.Open(TimeSpan timeout)
at System.ServiceModel.ClientBase`1.Open()
at WCFClient.TransactionClient.retrieveTransactions(String ipAddress, Int32 startDate, Int32 endDate)
10/18/2024 3:35:06 PM: Retrieve Transaction Error <?xml version="1.0"?><Transaction><Error>SOAP security negotiation failed. See inner exception for more details.</Error></Transaction>

Yeah that's not going to be easy to diagnose. Looks like a WCF Web Service using WS* protocols. And it's failing on a bad security configuration.
These WS* services were always a bitch to get working right to begin with and any number of small configuration tweaks can screw them up. The error message seems to suggest a protocol error likely related to the security configuration or transport.
If I had to guess related to the SSL configuration possibly related to changes in the security protocols (SSL vs. TLS or different TLS version). These services are configured for specific security settings and it's quite possible these are no longer available (like using SSL3 which is no longer supported or available for certificates).
Another possible issue could be that you need to have a client certificate registered on the machine for this to work.
To be honest it's pretty unlikely that anybody but the original programmer will figure this out unless it's something as simple as adding a client certificate to the cert store. These services were so horribly complex to set up and configure even when you knew what you were doing it was difficult to get it right. They are the reason SOAP eventually died out and was mostly replaced by simpler REST services.
+++ Rick ---
Did you register SPN or UPN for this service? Was Windows domain name changed?
Hi
Can you explain by what you mean about registering SPN or UPN?
Simon
Hi. It's not so easy, but I'll try to explain
SPN - Service Principal Name, can be set by setspn command line utility
UPN - User Principal Name, just user name with fully qualified domain name after @ (serviceuser@contoso.local)
Both identify user account of your WCF service, that is used by Domain Controller to authenticate your client and your service during SSPI negotiation if kerberos authentication is used by default.
Easiest way to try to revive service if client machine and service machine belong to the same Windows Domain:
try start it under LocalSystem, LocalService, or NetworkService.
if it doesn't want to work after step 1, look inside *.config files of your client and service, search for userPrincipalName or servicePrincipalName and if they found, ask domain admin to register them
