Admin rights on a local session are granted via the default PI Trust as you surmised. To get admin rights from a remote session without PI Trusts, you will need to create a PI Mapping. This should map your Windows credentials (either your individual domain account, or better yet, a security group that you belong to) to a PI Identity that has the required admin access. This could be either the legacy piadmins group, or a custom PI Identity that you have created and granted the necessary permissions to:
Granting required permissions to this identity is done through the Database Security plugin in PI System Management Tools:
You would add this identity to all the databases in this listing. Note that for the PIPOINT database, these permissions will not automatically flow down to existing PI tags, so you would also need to bulk update the security attributes on all your PI tags.
From a practical perspective, mapping your Windows credentials to the piadmins group is easiest, as this group already has permissions to all objects, but it is a legacy security identity. Using the newer PI Identity objects follows the newer preferred security model (as these represent access roles), but require some additional setup and configuration, especially in an existing brownfield PI server.
Have a look at some of the instructional videos in the Configure PI Server Security playlist on OSIsoft's YouTube channel.
Perfect! Many thanks for the help!
Just noticed that a user called "Client" had read/write access to the PIModules database; Client was our normal user access name before we used AD groups. Should it have read/write access to that database??
I guess that would depend on your usage of the Module database. If your system has migrated the MDB to PI AF, then the access by the Client user is somewhat moot, as the MDB should be read-only anyway.