There is requirement from client that install and configure PI WebAPI 2015 R3 (because same version in test environment) on a workgroup machine.

 

I will share the challenges faced during this process of running PI WebAPI successfully , so it will be helpful in future (reference to me only ).

 

Architecture:

Note: This all machines are individual workgroup.

 

Things to take care before installation:

  • Kindly create windows user with same password, for example user U, on both machines : the PI WebAPI Server-Machine A, and the AF Server - Machine B.
  • Add User U in administrator group of AF Server on Machine B, so that it can access configuration database on AF Server, and add PI WebAPI database into it.

    I haven't followed this, so getting error at the end of PI WebAPI installation wizard like as follows:
  • Give an administrative privilege to User U on WebAPI machine, machine A, to run services on this name.

 

Things to note during configuration via PI WebAPI Admin Utility:

  • On the 2nd step of configuration, add machine B as AF Server and appropriate name for database to create.
    While connection if it requires credentials then use machine B/user U as username.
  • On the Port # step, please check that you have no other application running on port 443 (chosen by default by setup), and on precaution note chose port # except 80 and 443.

  • On the user name step, chose custom user and add user U with credentials.
    Here, add username as machine A/user U not just ./user U. Because my workgroup machine unable to get the user name untill I put it as domain\username.

 

Things to look out for after configuration:

  • After installation and configuration completed successfully, check your PI WebAPI database under configuration db, that is created on machine B.

  • Check the authentication method, and change it to Kerberos if you want to add PI Data Archive / AF Server in PI WebAPI and crawl through it.

    
     Sample snap-shot of PI WebAPI database.


     The problem I faced here, I was unable to add PI Data Archive, machine C, in PI WebAPI due to some authentication error. So I changed authentication method in PI WebAPI db to Basic      and added machine C in PI WebAPI.

  • Create trust on your PI Data Archive / AF Server to allow data access to PI Web API.
    Trust should has OSIsoft.Search.Crawler.exe as application name, and IP of machine A as IP Address.
  • After adding PI Data Archive/AF Server name in PI WebAPI, click on Build Index, to start crawling through the entity.

 

Here I faced major hurdle. The problem mentioned in last point popup once again .
I found some useful links regarding same error message on PI Square, and tried following:

- Check if username via which PI WebAPI services are running, is added in PI Web API Admins.
   In our case user U is already added in the group.
- Add WebAPI end url in Trusted Sites.
   Done but no success .

 

When checking eventviewer found some error logs under OSIsoft-PISystemSearch->Operational :

Error System.AggregateException: One or more errors occurred. ---> System.Net.Http.HttpRequestException: An error occurred while sending the request. ---> System.Net.WebException: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel. ---> System.Security.Authentication.AuthenticationException: The remote certificate is invalid according to the validation procedure.

Here we, i.e. techsupport and me, thought this issue is because of certificate, and one known issue is there KB01318 - Self-signed certificate created by PI Web API 2015 R3 admin utility may fail for FQDN . Tried creating new certificate via IIS as well as PowerShell and mapping it into PI WebAPI via running PI WebAPI Admin Utility. But issue was still there.


Digged logs once again, and found below information log doubtful:

Gone to the configuration file of PI WebAPI via C:\ProgramData\OSIsoft\WebAPI\Search\Config path.
In file, the CrawlerHost name was machineA.clientname.com. As per above log, changed it to machineA only, and to our surprise crawling has been started for machine C .

 

Eventually problem is solved by modifying the crawler config file:

  • Deleted the FQDN part so that only the hostname remained.
  • Restarted WebAPI and crawler service, to take the new parameter into account.

 

 

That's it from my experience. Thanks for reading .

 

Happy Saturday !!!