Skip navigation
All Places > Learn PI > Blog

Learn PI

2 posts

What is the OSIsoft Training Cloud Environment?

Simply put, OSIsoft's Training Cloud Environment (formerly known as VLE) is a PI System sandbox that allows you to learn new skills, to expand your knowledge through hands-on labs or with online courses, to check out new products, or to try things that you cannot easily do in your production environment.


Find out more about our Training Cloud Environment (formerly VLE) in this 3 min YouTube video:



What is included in the Training Cloud Environment?

Training Cloud Environment subscriptions include two types of environments: Hands-on Labs and Online Course


  • Hands-on Labs Cloud Environments contains various 2-3 hour self-guided labs that have been presented at the latest OSIsoft conferences and regional seminars. Since these labs are designed to be completed in a 2-3 hour time frame, each virtual machine included in the Hands-on Lab Cloud Environment subscriptions is designed to shut down and to reset every 8 hours. If you are interested in learning a large array of topics with the latest PI System technologies, this training environment is for you. To see the latest list of the hands-on labs included in the Hands-on Labs Cloud Environment subscriptions, visit the Training Cloud Environment pages below.
  • Online Course Cloud Environments are typically designed and developed specifically for different online courses. Most of our online courses are designed so that learners can follow the content while practising on their own system. If you purchase an administrative online course, you will be automatically granted access to the course-specific cloud environment. If you are taking a non-administrative online course and need the PI System to practice with, you can subscribe to a Training Cloud Environment.

To Subscribe to the Training Cloud Environment

Have More Questions About the Training Cloud Environment?

Please visit the OSIsoft Learning FAQ page, and scroll down to "Training Cloud Environment"

André Åsheim

PI Security

Posted by André Åsheim Champion Dec 11, 2014

Setup security on a new PI environment. As simple as this might sound it's absolutely not straight forward.


First of all, plan what you are doing.

Secondly, Do not take any shortcuts during the installation and testing. The cleanup afterwards takes more time than you would have used to set it up correctly the first time.


Preparation tasks

Who should have access to what

PI Administrators, should have administrative access to everything

PI Users, should only work as a base group, logon only

Site X Read/Write, should be provide access to it's site and it's site only.


Service Accounts

AF_Service (AF server and Analysis service)

PINO_Service (PI Notifications Scheduler Service)

PIWebAPI_Servcie (PI WebAPI service)

PIBuffer_Service (runs the PI Buffer Subsystem service on all servers that sends data to PI)

Interface_XXX_Service (one service account for each interface)


Create AD groups

We started up with creating the two main AD groups that will be the base of the security model.

PI Administrators

PI Users

Site 1 Read/Write

Site 2 Read/Write


The PI Administrator group should give full administrative access to any PI component in the network. Local Administrators (and local users on the PI Data Archive) should NOT get access to the PI Environment.

PI Users group is a base group that should only provide a valid login to the PI environment. On the AF server this would mean that they can connect, and read the top level structure (which does not contain any data). On the Data Archive server this should only provide login, not able to read any tag/data etc.


The "Site X Read/Write" groups should only give access to the sites PI tags and AF structure. They should not be able to read data from ANY other site or data source, including other AF Databases, elements in the same database that's not part of it's site.


Asset Framework Security

What we discovered in the AF security model is that it somehow uses "and" security for both read and write operations.

We couldn't just give access to create element (write) directly on the parent element, the group needed to have access to write on the database level as well.


The AF security by default is poor. When would you ever give "Everyone" access to read your production data?

I'd like if AF did the same thing as Coresight on a new installation. Create a local group "PI AF Users" which is mapped into AF, replacing the existing default security where Everyone have access.

What would been even better is that they also created a "AF Administrator" group replacing the existing "Local Administrator". Why should the IT maintenance have full access, shouldn't this be restricted to only the users that absolutely need it?



PI Data Archive Security

The PI Data Archive security is not exactly simple.


Disable API trusts.....

Sorry we couldn’t do this. We tried and failed. We are importing most of our data using self-developed interfaces that only uses windows authentication, and we are using OSIsoft interfaces to backfill older data.

I thought that we could be able to disable the API trusts when the backfilling was completed but what we discovered surprised me.

PI Notifications was the major party pooper (if I'm allowed to say). It turn out that PI Notifications is able to create it's tags with Windows authentications (SDK) and the notifications starts and runs as normal, it even sends the notifications as expected. But what it didn't do was to save the history. It turs out that PI Notifications uses API to write data to PI. So we had to enable API trusts again and create a trust for PI notifications (application name "PIAnE")

PI Backup also requires PI trust due to it's use of PI Diag. This we could have worked around by running a third party backup solution, but when we first needed to enable the API trusts again we figured out that the best way was to use the built-in backup solution.


Yeah, I disabled !Proxy_127! trust, still working, still running and most important, People that logon to the server don't get access to the PI server. As a backup I created a local group and mapped that to piadmin.


PIPOINT database access

In order to list tags the user needs access to the top level PIPOINT database. This is easier said than done.

As I mentioned earlier, we have different sites which shouldn't have access to each other’s data. So what we ended up doing is not removing "PIWorld" from the default security, because the users should have access to list the tags.

We are now creating tags that PIWorld has access to and then we are replacing PIWorld with the sites user-groups.


Kerberos authentication

In order to use Kerberos authentication we did the following configuration changes on the service/computer account

PI Server

Server name: PI_Server01$  - Allow Computer for delegation to any service

SPN "PIServer/PI_Server01" and "PIServer/" (FQDN)


AF Server

Service account: AF_Service - Allow User for delegation to any service

Server: AF_Server01

SPN "AFServer/AF_Server01" and "AFServer/"



Service account: PIWebAPI_Service - Allow User for delegation to any service

Server: AF_Server01

SPN "HTTPS/AF_Server01" and "HTTPS/"



  1. Well.. We entered the planning stage on this step but figured out that it might was a bit overkill

But if you're interested in configuring IPsec, send me a message! Andre Johnsen


Nice to have

AF: Not use Everyone and local administrator as default security on new/clean installations

PI Notifications: Write data with SDK!

PI Buffer Subsystem: Impersonated buffer writes

PI Data Archive: Backup that does not require API trust