Openpdc service missing

GPA Products openPDC
1

Hello,

I am currently trying to install openPDC on a windows server 2008 R2 and I am facing a problem with the openPDC service; it is not created during the installation. The only error message that is popping up during the installation (from the installers) is that I don’t have enough privileges for the installation. However, when I ignore this message the installation continues normally, I set up the openpdc database etc., the connection tester is also working properly, but there is no openpdc service created hence I cannot use the openPDC manager.
Any ideas what is wrong?

Thanks in advance.

Best regards,
Eva

2

Hello Eva,

Do you have administrator privileges on the Server 2008 system? Also, what do you enter into the fields on the step shown in the following screenshot?

Thanks,
Stephen

3

Hello Stephen,

yes I have administrator privileges. I enter nothing as service password. I tried also to enter a password, but both don’t work…
I have also tried openpdc version 2.1 but i get the same error…

Best regards,
Eva

4

In the Synchrophasor.Installs.zip archive, there should be a folder called Installers which contains a file called openPDCSetup.msi. If you open a command prompt, navigate to the Installers folder, and type the following command, and then run through the installation, Windows will produce a log file from the installation.

msiexec /i openPDCSetup.msi /l*v openPDCSetup.log

If you send that log file to support@gridprotectionalliance.org, I will have a look and see if I can figure out what’s going on.

Thanks,
Stephen

5

I took a look at the log, but I’m not seeing anything obvious. A Google search on the error message suggests that it is a generic error message, the root cause of which could be a variety of things.

  • You do not have sufficient privileges to install services.
  • A service called openPDC already exists on the system.
  • The account used to install the service is invalid or doesn’t have permissions to log on as a service.

This leads to a few generic suggestions. Hopefully one of these will help make some progress.

  • Try opening the command prompt as administrator and running msiexec /i openPDCSetup.msi
  • It certainly doesn’t sound like this is the case based on prior information, but I guess you can double-check that there is not already a service called openPDC that exists on the system.
  • On the step shown in the screenshot I provided in an earlier reply, try changing the username to LocalSystem or NT AUTHORITY\SYSTEM.

Also worthy of note, I just tested the installer on a Windows Server 2008 R2 system and did not encounter the issue so we can rule out the OS.

Thanks,
Stephen

6

Hi Stephen,
I’d like to follow up on this. Both, Local System and NT AUTHORITY\SYSTEM work for starting the service - thanks for your hints. The service now starts up but refuses to communicate. When starting the openPDC console it outputs the following error message:

Connecting to tcp://localhost:8500…
Exception during connection attempt: Unable to authenticate connection to server
: Authentication failed because the remote party has closed the transport stream.
Disconnected from tcp://localhost:8500:
Client state: Disconnected
Connection time: 0 seconds
Receive buffer: 8192
Transport protocol: Tcp
Text encoding used: US-ASCII

Any idea what’s going wrong? I have verified that openPDC listens on port 8500 TCP (netstat). Windows firewall is turned off, AV uninstalled. I even tried to revert to TLS 1.1 but nothing helped. What else can be the reason for this behavior?
As side-note we had troubles with the MySQL net connector, the installer being unable to remove/repair/re-install, all actions resulting in error messages and nothing being changed (according to the reports on the net we’re not the only ones trapped by this behavior). We managed to get around by various manual tweaks, now anything works as expected. However, even a clean re-install (including full uninstall and delete of all openPDC directories) did not help.

I guess that some guidance wrt the following topics could be very helpful also for other users (part of the FAQ?):

  • Recommended account type and name (minimum rights) for setting up and for running OpenPDC as service. Is it sufficient/recommended to have an own openPDC account with administrator rights? Should we create one or prefer the administrator account?
  • List of software requirements and -dependencies, recommended software versions (known to work or to not work). Our setup: Windows Server 2008 R2, MySQL Server Community Ed. 5.6, MySQL Connector .Net 6.9.9, .Net 4.6, all updates. A similar setup on a laptop with other OS (Windows 7) works like a charm.
  • A “big picture” drawing - a sketch of all openPDC modules, components, databases, PMUs, and their interaction/relations - could be an enormous help for newbies. To be more specific, one could think about a block diagram that shows the openPDC service, openPDC manager, openPDC console, (my)sql database, one PMU along with their connections (protocol including default port numbers) that openPDC uses in a (typical) default setup. As an improvement, one could extend this to three use cases: local installation with openPDC historian, local installation with SQL database, remote operation (POSIX with openPDC Manager on a remote computer).

Any hint of what can be done to debug our very specific communication problem?

Thanks,
Joachim

7

This may help a little:

http://gridprotectionalliance.org/docs/products/gsf/tsl-components-2015.pdf

8

Hi Joachim,

The openPDC Console has two levels of authentication to get through before it will be able to interact with the service. The first is the TLS authentication which is mainly used to establish an encryption mechanism for the data over the channel. The second is called “Integrated Security” which uses NTLM to authenticate the user using their Windows credentials. The error you’ve shown is a generic client-side message that indicates that the server disconnected from the client during one of the two authentication processes. Typically, this means the server encountered an error during the authentication process.

To get more details about the error, you can check the ErrorLog.txt file in the openPDC’s installation directory to see if you can identify the error that caused it to disconnect during authentication. If I were take a wild guess, I would say the most likely explanation would be that the LocalSystem account is unable to access the domain in order to authenticate your domain credentials. In some systems, it may be necessary to run the openPDC as a domain user (such as a managed service account) so that the user will have access to the domain. It’s also possible to disable one or both of the authentication processes if it becomes too much of a headache.

Thanks very much for the FAQ suggestions! Would you be willing to build a diagram like the one you described? We don’t have an official process yet for accepting user contributions to our project documentation, but if you can provide the diagram, I’ll make sure to get it up on the GitHub openPDC wiki.

Thanks,
Stephen

9

Ritchie: thanks, to some extent this is what I meant - it’s definitely useful as a starting point. Coming back to Stephen’s question: first priority is for now to bring the system to work. If there is some spare time during the next weeks I’ll think about how to condense the various scenarios into some drawings.

Thanks,
Joachim

10

Hi Stephen,

today I spent again some time in debugging and noticed some strange behavior. As a side note: we’re using a stand-alone Windows system, so no Active Directory or similar.
After managing to trace the loopback interface I couldn’t find any suspicious traffic. However the openPDC service, whenever started, continuously queries (in parallel using Netbios and DNS Multicast) for the name “SYSTEM”. It’s strange as I didn’t configure the name SYSTEM anywhere (at least not knowingly). Moreover, openPDC uses the wrong interface - and this brings me to the next question: have you tested openPDC with multiple interfaces on the same host? Our host has two active v4 interfaces, one private (192.168.x.x) and one having a public v4. I’ve switched off IPv6 on all interfaces, including the automatically created tunnels. openPDC broadcasts the queries on the private interface (used for connecting some other sensors) but ignores the public one, that is used for contacting the PMU and marked as default (same network as default gateway).

Does anyone have an idea what could be the reason for the SYSTEM lookup? And can someone shed some light onto the IP address prioritization of openPDC? Or is this a strategy hard-coded into the .net binaries?

Thanks for your support,
kind regards
Joachim

11

Hi Joachim,

This is mostly conjecture, but I suspect that query may be the service attempting to find the domain controller to do an Active Directory search. Since you stated that the system is not using Active Directory, that search is likely destined to fail so the interface it chooses is probably insignificant, but in this case it would be an implementation detail of the Active Directory searcher and not something you would have configured. Since the service is trying to authenticate your Windows credentials, the service would naturally make the query every time you attempt to connect to the service using the openPDC Console or openPDC Manager, which would be something like every 5 seconds.

As for IP address prioritization for network connections to other devices and the openPDC Console, that is indeed handled by the .NET Framework libraries. However, the IP address used to bind to an endpoint can be overridden through configuration. The method for doing so varies, but generally involves adding “Interface=x.x.x.x” to a connection string somewhere.

Did you find anything in the ErrorLog.txt file?

Thanks,
Stephen

12

Hi,

yes, but the content is rather general - please find it below.

thanks
Joachim

---- Stack Trace ----

[10/12/2016 11:02:33 PM] (Inner Exception)
Date and Time: 10/12/2016 11:02:33 PM
Machine Name: WIN-XXXXX
Machine IP: a.b.c.d
Machine OS: Microsoft Windows NT 6.0.6002 Service Pack 2

Application Domain: openPDC.exe
Assembly Codebase: C:/Program Files/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.2.70.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.2.70.0
Assembly Build Date: 6/21/2016 12:19:08 AM
.Net Runtime Version: 4.0.30319.42000

Exception Source: System
Exception Type: System.ComponentModel.Win32Exception
Exception Message: The credentials supplied to the package were not recognized
Exception Target Site: InternalEndProcessAuthentication

---- Stack Trace ----
System.Net.Security.SslState.InternalEndProcessAuthentication(lazyResult As LazyAsyncResult)
openPDC.exe: N 8121733
System.Net.Security.SslState.EndProcessAuthentication(result As IAsyncResult)
openPDC.exe: N 00076
GSF.Communication.TlsServer.ProcessTlsAuthentication(asyncResult As IAsyncResult)
openPDC.exe: N 00146

(Outer Exception)
Date and Time: 10/12/2016 11:02:33 PM
Machine Name: WIN-XXXXX
Machine IP: a.b.c.d
Machine OS: Microsoft Windows NT 6.0.6002 Service Pack 2

Application Domain: openPDC.exe
Assembly Codebase: C:/Program Files/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.2.70.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.2.70.0
Assembly Build Date: 6/21/2016 12:19:08 AM
.Net Runtime Version: 4.0.30319.42000

Exception Source:
Exception Type: System.Exception
Exception Message: Unable to authenticate connection to client [127.0.0.1]: The credentials supplied to the package were not recognized

---- Stack Trace ----

13

That tells me the error occurs during TLS authentication. Google search indicates that the service user may not have access to the private key, which sounds plausible because it may have placed the private key in the NT SERVICE\openPDC user’s certificate store. Try this:

  • Stop the openPDC service.
  • Delete openPDC.cer in the openPDC installation folder.
  • Start the openPDC service.

This will force it to recreate the server’s certificate and generate a new private key. After following these steps, verify that the openPDC.cer file was automatically recreated. Also, if this doesn’t fix the problem, verify that the error message in the log hasn’t changed.

Thanks,
Stephen

14

Nope, unfortunately no change. I spent again many hours today and tried everything I could think of, including: uninstall and install of openPDC as another user, configuring database authentication instead of Windows Authentication, openPDC config file tweaking (including Tls, Tls11 and Tls12 as config options in openpdc.exe.config and openpdcconsole.exe.config, entering authentication information, n-times-reinstall and re-configuration), and many, many others. The certificate appeared as untrusted, so I even tried to store it import it into the Trusted Root Authorities Store. Still same behavior and same output in the error log for both, openPDCManager and openPDCConsole.

The current/last setup uses the WIN-XXX\Administrator account to run the openPDC service (tried WIN-XXX\openPDC and LocalSystem, too). The service starts successfully but communication between the openPDC service and manager/console fail). Any other solutions that I can try? (like debugging options to get more verbose output)?

thanks
Joachim

---- Stack Trace ----

[10/14/2016 1:22:21 PM] (Inner Exception)
Date and Time: 10/14/2016 1:22:21 PM
Machine Name: WIN-XXX
Machine IP: a.b.c.d
Machine OS: Microsoft Windows NT 6.0.6002 Service Pack 2

Application Domain: openPDC.exe
Assembly Codebase: C:/Program Files/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.2.70.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.2.70.0
Assembly Build Date: 6/21/2016 12:19:08 AM
.Net Runtime Version: 4.0.30319.42000

Exception Source: System
Exception Type: System.ComponentModel.Win32Exception
Exception Message: The credentials supplied to the package were not recognized
Exception Target Site: InternalEndProcessAuthentication

---- Stack Trace ----
System.Net.Security.SslState.InternalEndProcessAuthentication(lazyResult As LazyAsyncResult)
openPDC.exe: N 8121733
System.Net.Security.SslState.EndProcessAuthentication(result As IAsyncResult)
openPDC.exe: N 00076
GSF.Communication.TlsServer.ProcessTlsAuthentication(asyncResult As IAsyncResult)
openPDC.exe: N 00146

(Outer Exception)
Date and Time: 10/14/2016 1:22:21 PM
Machine Name: WIN-XXX
Machine IP: a.b.c.d
Machine OS: Microsoft Windows NT 6.0.6002 Service Pack 2

Application Domain: openPDC.exe
Assembly Codebase: C:/Program Files/openPDC/openPDC.exe
Assembly Full Name: openPDC, Version=2.2.70.0, Culture=neutral, PublicKeyToken=null
Assembly Version: 2.2.70.0
Assembly Build Date: 6/21/2016 12:19:08 AM
.Net Runtime Version: 4.0.30319.42000

Exception Source:
Exception Type: System.Exception
Exception Message: Unable to authenticate connection to client [127.0.0.1]: The credentials supplied to the package were not recognized

---- Stack Trace ----

15

Rather than continuing to fight a losing battle, it may be best to go ahead and disable the TLS authentication. Try stopping the openPDC service and then changing the value of the following setting to None in openPDC.exe.config.

<configuration>
    <categorizedSettings>
        <remotingServer>
            <add name="EnabledSslProtocols" value="None" description="The set of SSL protocols that are enabled for this server." encrypted="false" scope="Application" />
        </remotingServer>
    </categorizedSettings>
</configuration>

After restarting the service, go into openPDCConsole.exe.config and change the following setting.

<configuration>
    <categorizedSettings>
        <remotingClient>
            <add name="EnabledSslProtocols" value="None" description="The set of SSL protocols that are enabled for this client." encrypted="false" />
        </remotingClient>
    </categorizedSettings>
</configuration>

Now run the openPDC Console. If that gets it working, launch openPDC Manager and navigate to System > Manage Nodes in the menu. In the text box labeled Settings, modify the RemoteStatusServerConnectionString property to add enabledSslProtocols=None. For example:

RemoteStatusServerConnectionString={server=localhost:8500; integratedSecurity=true; enabledSslProtocols=None}; dataPublisherPort=6165; AlarmServiceUrl=http://localhost:5018/alarmservices

Thanks,
Stephen

16

Yes, this works! When disabling security, everything works as it should and such a functional setup helps enormously for testing various setups. After this experience I suspect some legacy software (in particular .net 3.5) to cause interference - but I can’t install it as other software on the server depends on it.
So next week I’ll try several alternatives: setup a clean 2008R2 and test openPDC on it, test openPDC on Linux. Let’s see if I can figure out the root cause.

Many thanks again for your help and patience,
kind regards
Joachim

17

I’m glad we got it working! Regarding your testing next week, anything you can do to help identify and document potential issues will be very much appreciated, so thanks in advance for that.