3 of 3 people found this helpful
What you can do is adjust a data archive mapping via piconfig. Open an admininstrative command prompt and navigate to %piserver%\adm
Copy and paste the following lines into a .txt file and save this in the adm directory:
Then, on command prompt, type piconfig.exe < txtfilename
In command prompt you will see outputs of the mappings on your data archive. Find one of windows users/groups (it will be the first field) that you would like to change the identity of and right click + mark and highlight this one (you should have 4 comma separated fields). Paste this in notepad and make sure it is one single line.
Then copy and paste the following lines into another .txt file in the adm directory as well.
what you pasted from command prompt goes here (be sure to change the PI Identity: 3rd field to piadmin or something with more permissions)
Then type piconfig.exe < secondfilename
This should update the identity of the windows user or group to what you specified as the new identity
Note that the @select principaldisp=*d should be @select principaldisp=*
That was a typo
1 of 1 people found this helpful
It sounds like to me that you were previously using the loopback trust to connect to the PI Data Archive, since by default the loopback trust grants piadmin access to local connections. However, by creating this new trust, you inadvertently configured it in such a way that this new trust now takes precedence over the loopback trust. Please see KB00964 on how trusts are scored and precedence is determined. Since you configured the new trust for a domain and user, this would have given it a higher score than the default loopback trust - thus your new connections are using the new trust and no the loopback trust.
As Mark pointed out, you should still be able to use the piconfig utility to create a mapping. After you create the mapping, you may need to change the authentication protocol order in the SDK Utility Connections Options to put Windows > Trust. Once this is done, you should be able to authenticate using the newly created mapping. Alternatively, you could also use piconfig to simply delete the new trust that you created, which should revert you to using the loopback trust:
@tabl pitrust @mode delete @istr trust <new trust name>
By the way, we do recommend PI Mappings and Windows security over PI Trusts. Is there any reason why you are configuring your Windows group with a PI Trust rather than with a PI Mapping?
I was testing/using the UFL connector for the first time. I would run the connector and it would process the text file yet my test PI Point would not update. I tried many revisions without success. The last thing I tried was creating a trust assuming that the connection was getting blocked. As it turned out the data was actually going into PI archive all along. The UFL connector created a new PI point equal to what I specified and added the UFL. prefix to it. I need to do a bit more reading on this behavior. So, normally I would not use a trust but since it was a dev system I wanted to rule that out as an issue.
Mark and Gavin if PI SQ had a "You Rock" award I would be clicking on that now. Ultimately both solutions were used to fix the problem.
Here's how the fix went down. I implemented Mark's solution but ran into a problem early on. I need to replace the PIGuys Identity with a new identity that had higher permissions. Unfortunately I had not created any so I used the default "PI Supervisors" so my second text file looked like this:
@table piidentmap @mode edit @istr principaldisp,principal,piident,identmap PI Connector Administrators,S-1-5-21-1590910984-1880753989-3888108208-1010,PISupervisors,Windows_S-1-5-21-1590910984-1880753989-3888108208-1010 @ends @exit
Unfortunately this did not elevate my permissions any but it did remove the associations of PIGuys with the Windows user group.
The interesting part of losing your admin rights is that you no longer are able to view the Trust in SMT. In Gavin's solution to delete the trust, you need to know the trust name. Needless to say, I did not write the trust down anywhere but I was out of options so I tried several guesses and got lucky (another good reason for using strict conventions). On the second attempt I was able to delete the trust with this code:
@tabl pitrust @mode delete @istr trust <Trust Name>
Once the trust was deleted I was back in business with full admin rights. I was then able delete the PIGuys Identity as it was no longer mapped to anything. and finally deleted the PI Supervisor mapping.
Thanks Mark and Gavin for posting this.
Lessons learned for Dev PI Servers:
1. Always add a second admin to your admin group.
2. Avoid using Identities and trusts.