What I suggest you to do is to solve PI Web API first and then check if PI Coresight works properly.
There are lot of issues when customers try to crawl new databases because although PI Web API works with Anonymous, Basic and Kerberos authentication methods, you must be using Kerberos only in order to crawl or rebuild an AF database or PI Data Archive. Once the database has been crawled, you do not need Kerberos in order to be able to search. Anonymous and Basic Authentication methods can also be used to search.
Therefore, the first step is to open PI System Explorer and go to the Configuration database. Find the System Configuration element of your PI Web API instance. It should be under OSIsoft\PI WebAPI. Check the value of the AuthenticationMethods and make sure “Kerberos” is the only option available. Make sure to check in your changes.
You can use the link below in order to make sure that PI Web API has picked up the changes:
Make sure that Kerberos is well configured on the domain controller including delegation. Also, check if PI Web API and PI Web API Search crawler services have privileges to access the PI System resources. Before trying to rebuild the crawler, make sure the core services of PI Web API are running properly with Kerberos only.
The next step is to check the SSL certificate. Is it a valid one? Is it a self-signed certificate? Have you trusted the certificate in the client?
Another ideas is to check the logs:
- PI Web API logs through Windows Event Viewer on the web server running PI Web API
- PI Message Log on the PI Data Archive you are trying to crawl
- AF logs on the Windows Event Viewer on the PI AF Server whose AF database you are trying to crawl
Hope this helps!
This is awesome good advice.. Thank you so much so far...
We will check out all your recommendations tomorrow when IT is back.
So far we are at the point to make sure that delegation works and the proper user is forwarded to the PI data server.
As far as I understand: It is the user that has been authenticated that is been forwarded and the serviceaccount the pi web api crawler runs on forwards (delegates) it to the pi server?!
In our case the situation is really complicated: Pi server is in domain A, web api there too. But user comes from another (B) domain and that one has no trust relationship.. thus the server the pi web api runs on can not authenticate the user... or the user has to provide credentials for a Domain A user.
(You see where this is going, especially when the server we are building our web app on is even on another Domain.. so we we have Domain A,B,C.. so after Kerberos-Crawl has run we go back to anoynmous for a while.)
3 of 3 people found this helpful
Without a domain trust, Kerberos won't work. You will have to use Basic but as I told you, you cannot crawl a database using Basic authentication.
Here is what I suggest you to do:
- Change the AuthenticationMethods to Kerberos
- Set up Kerberos properly within domain A
- Crawl all the databases you want, using any client from domain A
- Change the AuthenticationMethods back to Basic so all client from the other domains can access PI Web API
All of your clients will be able to use the search using Basic authentication. But if you need to crawl a new database or rebuild an existing one, you will have to follow this procedure again.
Hopefully, on upcoming releases of PI Web API, we will have a better solution for your use case.
Thank you so much for these straight forward instructions.
One final question: What if we set to anonymous authentication instead of basic? Would that work?
My question then is, which user account is delegated by the PI web api service to the PI server?
.. and with Basic authentication, is then username/password forwarded and we have to configure this as an extra user on the PI server?