In this video, we will cover an issue that you might face wherein you see an error in
connecting to the PI Analysis Service from within PI System Explorer.
Along with this error, you will also notice that you cannot view the runtime status of
your analyses, but instead, you will only see a gray question mark.
On the “Analyses” tab of any element, you will see a red status indicator along
with the message “Could not connect to the PI Analysis Service” in the lower right.
You will also see only the Enabled / Disabled status of your analyses in both the “Analyses”
tab of elements as well as “Management”.
Before looking into fixes for this issue, we first need to note an important piece of
information.
Hovering over the “Could not connect to the PI Analysis Service” message shows the
server name where PSE is attempting to contact the PI Analysis Service.
The tooltip shown could indicate one of 3 possibilities: either the server name is correct
for where you expect PI Analysis Service to be installed, the server name is incorrect
for where you expect PI Analysis Service to be installed, or the tooltip is entirely blank.
Depending on how your system arrived at this state, there are several different resolutions
to this issue.
Some of the more frequent ones will be covered in turn.
For the first case, if we hover over the “Could not connect to the PI Analysis Service”
message, we see the expected machine name for where the PI Analysis Service should be
installed--pisrv01 is in fact expected.
So the first thing we’ll do is go to that machine and verify if the PI Analysis Service
is in fact running.
We see that it is not, so we’ll start it up, and head back to our client machine to
verify.
We will close and reopen PSE to force a fresh connection, and navigate back to the “Analyses”
tab.
And we see a “Connected to the PI Analysis Service” message.
If we find that the service is running and we see the correct server name shown in the
tooltip, the next step is to check that the port to access the PI Analysis Service is
open.
We can check this by running a command in PowerShell.
This command will attempt a TCP connection to the specified machine while using the specified
port.
You can find this command in the article shown on the screen.
Note that this command might take a bit of time to return.
Notice that the result is an error stating that the connected host has failed to respond.
This leads us to think that maybe there is a network issue, likely a firewall, blocking
our connection.
So we’ll go to the PI Analysis Service machine and investigate a possible firewall blocking
us.
Here we see that the firewall is turned on, and if we check the inbound rules, we can
see that there is a rule blocking the PI Analysis Service on port 5463.
If we disable this rule, and go back to our client machine, and attempt a reconnection,
we can see if this worked.
Here we see that we are again connected to the PI Analysis Service.
Note that if you have a network firewall, you might have to get your IT department involved
to investigate a possible firewall which is not directly on the machine.
If we hover over the “Could not connect to the PI Analysis Service” message and
notice an incorrect machine name, this implies that PSE is attempting to reach the analysis
service on the wrong machine.
Hovering over the message, we notice that the server listed is piclient01.
We know from previous cases that this is incorrect.
The analysis service is in fact installed on the pisrv01 machine.
We can change this in the Configuration database of the AF server.
Here we have the Configuration database open for the AF server.
We simply need to drill down from OSIsoft to PIANO, AnalysisService, and to the ServiceConfiguration
element.
Clicking the 3 dots next to the value will open a text visualizer which will allow us
to make changes to this attribute.
Finding the hostname attribute, we see the name of the machine where the analysis service
registered to this AF server is located.
We can use a dot symbol in order to represent that the analysis service is on the same machine
as the AF server.
However, we can also be explicit and actually write the machine name or fully qualified
name of the analysis service.
Let’s hit OK and check in our change.
The fact that our actual analysis service was not registered to any AF server actually
made the service stop.
So we also have to double check that the service is running.
Now if we return to our client machine, we can check whether or not this change worked.
Let’s close and reopen PSE to start a fresh connection.
And now we’re back connected to the analysis service.
In this case, we have already verified that the PI Analysis Service is running and that
there is not a network issue preventing our connection.
If we hover over the “Could not connect to the PI Analysis Service” message, we
see that the tooltip is entirely blank.
This indicates that we are missing an AF permission needed to read the name of the PI Analysis
Service machine from the Configuration database.
Checking my current permissions, I see that I have “World” permissions on this AF
server.
If I give this information to my admin, they can determine if I am missing the required
permissions.
The admin could open the Configuration database and go down to the PIANO > AnalysisService
> ServiceConfiguration element, right click “Security” and see if I have the required
permissions.
“World” is not present in this list indicating that I do not have the required permission.
Let’s take away all permissions except Read and hit OK.
Back on the client, I can close and reopen PSE to see if this worked.
And again we see that we are connected to the PI Analysis Service.
Note that you will need permissions in the entire pathway from the “OSIsoft” element,
down to the “ServiceConfiguration” element in order for this to work.
Another situation that you might see is that when clicking on the “Analyses” tab of
an element or on the “Management” tab, you are presented with a login prompt in PSE.
Here we see that login prompt.
When clicking on the “Analyses” tab, PSE attempted to pass the credential used to open
PSE to the analysis service.
But for some reason, analysis service rejected the credentials, and is asking you to provide
another set of credentials to login before failing to connect entirely.
Let’s enter our credentials.
Now we see that we are connected.
This implies that PSE passed bad credentials for some reason.
One reason that PSE might have passed an invalid credential is that there is an invalid credential
saved in Windows Credential Manager.
Under Control Panel > User Accounts > Credential Manager > Windows Credentials, we can check
if this is true.
Here we see that there is a saved credential that will be passed whenever a connection
is made to the pisrv01.pischool.int machine.
Rather than the current user credential being passed, Windows will instead pass the student01
username and password shown here.
This credential however is likely invalid.
Let’s remove it and see if this fixes the issue.
And reopen PSE to see if we still get a login prompt.
And we see that we do not get a login prompt, and we are connected to the PI Analysis Service.
Let’s go through one more reason why you might get a login prompt to the PI Analysis
Service when clicking on the “Analyses” or “Management” tabs of PSE.
Here again, we get a login prompt.
Let’s enter our credentials and see if it works.
We see that entering in our credentials still doesn’t work.
This must mean that the PI Analysis Service is blocking our connection even though we
are providing correct credentials.
The PI Analysis Service employs NTLM authentication.
Let’s ensure that there aren’t any settings which could be blocking this authentication.
Under Local Security Policy > Local Policies > Security Settings, we see there are various
settings for NTLM authentication.
We also see that there is a setting which will block all incoming NTLM traffic.
Let’s change this to “Allow All”, hit OK, and double check that the change worked.
Back on our client, let’s close and reopen PSE.
We see no login prompt, and we are connected to the PI Analysis Service.
If you see an issue with any Local Security Policy setting, or you want to make a change
to them, then we recommend that you involve your IT department before changing them as
these settings may have been put in place for a specific purpose.
They may also be controlled by group policy.
In addition, if you would like to increase logging for NTLM authentication, then you
can control NTLM auditing from this location as well.