Skip navigation
All Places > Security > Blog > Authors lmlcoch


6 Posts authored by: lmlcoch Employee

Hall of Thanks

Posted by lmlcoch Employee Mar 22, 2019

OSIsoft thanks all individuals ethically reporting security issues in our products or services. Contact us - Report a Security Vulnerability.




Each name represents an individual or organization who has privately reported one or more security vulnerabilities in OSIsoft's products or services (since 01-Jan-2019).



Security researcher
Name: Mohammed Israil | Twitter handle: mdisrail2468
Name: Serge LaCroute | Twitter handle: fakessh

Although introduced in Windows Server 2012, the Group Managed Service Account (gMSA) still has low adoption within our customer base. This blog post aims to highlight benefits of gMSAs, discuss how to deploy and use them, and offer some tips & tricks.


Built-in accounts such as NetworkService or LocalSystem have decent password management, are simple to use, and can easily run a service or an Application Pool. However, outside the machine boundary, they take on the identity of their host machine (COMPUTERNAME$). This limits their usefulness outside the machine itself, as granting access to a computer object inevitably gives access to all other built-in identities on the computer (and all the services they're running!).

Many companies use standard domain accounts instead, but these accounts suffer from very poor password management (entropy, expiration/resetting, maintenance). Moreover, standard domain accounts' passwords are inevitably exposed to both users (who need to regularly interact with the passwords - typing or copy/pasting) and computers (passwords are stored locally).


gMSAs combine the best of both worlds: automatic password management with secure & centralized storage, while maintaining uniqueness outside the machine boundary. gMSA's password is calculated on-demand by Domain Controller (KDC) and automatic password changes are done periodically. In contrast to passwords used by standard domain user accounts, gMSA passwords are not stored locally on computers nor exposed to users.




gMSA vs. Standard Domain User - Practical Password Play


Sticky notes are awesome! Right?




gMSA password consists of 256 bytes of data, interpreted as 128 UF-16 characters. It is a constructed attribute calculated by the Domain Controller (KDC) on-demand.


Let's take a look using PowerShell:
# Download the DSInternals module

Save-Module DSInternals -Path C:\share


# Import the required modules

Import-Module ActiveDirectory

Import-Module C:\share\DSInternals\2.22\DSInternals.psd1


# Get the password blob – need to explicitly ask for the msDS-ManagedPassword attribute

$gmsa = Get-ADServiceAccount -Identity PVizgMSA -Properties msDS-ManagedPassword

$mp = $gmsa.'msDS-ManagedPassword'


# Convert the blob to Unicode string

$pw = ConvertFrom-ADManagedPasswordBlob $mp



This yields the actual Unicode string representation:



For more details, check out DSInternals’ post on retrieving cleartext gMSA passwords.



As an example, let's take a look at the two IIS Application Pools shown below - one is running under a standard domain user, while the other runs under a gMSA (an easy way to spot a gMSA is by the trailing $ character, much like a computer object).

Since the password of the standard domain user is stored locally on the server, a local administrator can obtain the password in plain text, which means there is no role separation between the service administrator and the local computer administrator! The gMSA password, on the other hand, is not stored locally on the server and therefore can't be retrieved.



In this case, we’ve read the standard domain user password from applicationHost.config file.


But it’s the same story with Windows services. The only difference is that the passwords are stored in the registry (within HKEY_LOCAL_MACHINE\SECURITY hive) rather than in a .config file:




While we’re on the topic of passwords, I would be remiss if I didn't mention mimikatz - the Swiss Army Knife of Windows Authentication. We’ll cover mimikatz and attacks on credentials (pass-the-hash, pass-the-ticket, plus mitigation and detection strategies) in a future blog post.


gMSA Passwords – main takeaways:

  • Incredibly high entropy making brute force attacks impossible
  • gMSA is denied interactive logon, so even with the raw data for the password, capabilities for using it are limited

  • Obscure characters in the gMSA password natively protect against mismanagement or accidental leakage


While gMSAs provide some hardening and additional security against credential theft, they do not address all threats. Deploy gMSAs to complement other security best practices such as least privilege.




gMSA – Provisioning and deployment



  • Windows Server 2012+ on at least one Domain Controller.
    • Functional Level of the domain must be at least 2003, but 2008 R2+ is recommended.
  • Windows Server 2012+ OS installed on the machines hosting services that will use the gMSA.
  • Key Distribution Service (KDS) Root Key must exist to enable gMSA creation.
    • Microsoft strongly recommends using a single KDS Root Key. See the documentation for more details.


To create the KDS Root Key, run PowerShell command:
If (-Not (Get-KdsRootKey)) {




By default, it takes 10 hours until the KDS Root Key is in effect (this is to provide sufficient time to replicate the key in large domains). However, in a test environment, we can force it to come into play immediately:

If (-Not (Get-KdsRootKey)) {

Add-KdsRootKey -effectivetime ((get-date).addhours(-10))



Next, use New-ADServiceAccount PowerShell cmdlet and specify (at least):
Name gMSA account name (must be fewer than 15 characters)
DNSHostName gMSA DNS account name (FQDN of the gMSA)
PrincipalsAllowedToRetrieveManagedPassword Principals allowed to obtain gMSA’s password. For manageability, it’s best practice to create a Domain Group (type: Security) and add the machines hosting services the that will run under the gMSA. However, it’s also possible to specify the computer(s) directly.


Optionally, specify other parameters such as ServicePrincipalNames and PrincipalsAllowedToDelegateToAccount, to configure Kerberos Authentication (SPNs) and Kerberos Delegation upon gMSA creation. To change the default password reset period (30 days), use ManagedPasswordIntervalInDays parameter.

Recommendation: Read the official New-ADServiceAccount cmdlet documentation before proceeding further.


Example 1:

The steps outlined below create a gMSA called PIVizgMSA, designed to run PI Vision Application Pools on two servers (piviz1 and piviz2). The appropriate Service Principal Names are created as well.


1. Create a domain group called PI Vision Servers and add piviz1 and piviz2 computers into the group.


2. Create the gMSA: (execute the command in an elevated PowerShell console on your Domain Controller)

New-ADServiceAccount -Name PIVizgMSA -DNSHostName PIVizgMSA.domain.local -PrincipalsAllowedToRetrieveManagedPassword "PI Vision Servers" -ServicePrincipalNames http/piviz1, http/piviz1.domain.local, http/piviz2, http/piviz2.domain.local


3. Remove all Kerberos Tickets from LocalSystem session on piviz1 and piviz2 computers by running klist -li 0x3e7 purge command in an elevated Command Prompt (alternatively, restart both computers). This is only required because a Domain Group was specified as the value for the PrincipalsAllowedToRetrieveManagedPassword parameter. If the machines were specified directly (i.e. -PrincipalsAllowedToRetrieveManagedPassword piviz01$, piviz02$), there’s no need to update Kerberos tickets (restart the machines).


4. Optional: Allow the account to write its own Service Principal Names – useful for services that support automatic SPN registrations such as PI Data Archive, PI AF Server or MS SQL Server.

(execute the command in an elevated PowerShell console on your Domain Controller)

$gMSA = Get-ADServiceAccount -Identity PIVizgMSA

dsacls $gMSA.DistinguishedName /G "SELF:RPWP;servicePrincipalName"


5. Use the gMSA to run PI Vision AppPools on the target machines (piviz1 and piviz2). Use it in the same way as a standard Domain User, just don’t specify the password (make sure the Password box is empty) and let the computer retrieve the password.



Example 2:

The steps outlined below create gMSA called AFgMSA, designed to run AF Server service on machine piaf01. Included are the appropriate SPNs and configuration of Kerberos Constrained Delegation (Resource Based Kerberos Delegation in this case) – where the PI Vision gMSA created in Example 1 (PIVisionGMSA) will be allowed to delegate to the AF Server piaf01 running under AFgMSA$.


1. Create the gMSA:

New-ADServiceAccount -Name AFgMSA -DNSHostName AFgMSA.domain.local -PrincipalsAllowedToRetrieveManagedPassword piaf01$ -ServicePrincipalNames afserver/piaf01, afserver/piaf01.domain.local -PrincipalsAllowedToDelegateToAccount PIVisionGMSA$



2. Allow the account to write its own Service Principal Names – AF Server supports automatic SPN registration:

$gMSA = Get-ADServiceAccount -Identity AFgMSA

dsacls $gMSA.DistinguishedName /G "SELF:RPWP;servicePrincipalName"


3. Use the gMSA on the target machine.



Example 3:

The steps outlined below create a gMSA designed for PI Web API service running on machine piweb01, including appropriate SPNs and configuration of Kerberos Constrained Delegation (traditional Kerberos Constrained Delegation in this case) – where the newly created PI Web API gMSA will be allowed to delegate to PI Server pi01.


1. Create the gMSA:

BackendSPNs = 'PIServer/pi01', 'PIServer/pi01.domain.local'

New-ADServiceAccount -Name PIWebAPIgMSA -DNSHostName PIWebAPIgMSA.domain.local -PrincipalsAllowedToRetrieveManagedPassword piweb01$ -ServicePrincipalNames http/piweb01, http/piweb01.domain.local -OtherAttributes @{'msDS-AllowedToDelegateTo'=$BackendSPNs}



2. Allow the account to write its own Service Principal Names – in case the AF machine name changes, for example.

$gMSA = Get-ADServiceAccount -Identity PIWebAPIgMSA

dsacls $gMSA.DistinguishedName /G "SELF:RPWP;servicePrincipalName"


3. Use the gMSA on the target machine.




If any modifications are required after the gMSA is created, use the Set-ADServiceAccount cmdlet. See the official documentation for details.




gMSA in PI Environment

When specifying gMSA identity in Services.msc snap in or in IIS Manager, simply type in the name of the account and leave the password box blank:



Tip: After the Log On account of a Service is set to a gMSA, the Log On tab will be permanently unavailable (grayed out). To fix this, open an elevated Command Prompt and execute sc managedaccount <serviceName> false.


PowerShell can be used to use gMSA for IIS Application Pools and Services.


IIS Application Pools:
# Define gMSA and AppPool name

# Change the two variables below as needed

$gMSA = "DEN\PISQgmsa$"

$AppPoolName = "PIVisionServiceAppPool"


# Import WebAdmin module

Import-Module WebAdministration


# Set AppPools to use gMSA

$AppPool = Get-Item IIS:\AppPools\$AppPoolName

$AppPool.processModel.identityType = 3

$AppPool.processModel.userName = $gMSA

$AppPool.processModel.password = ''

$AppPool | Set-Item



# Define gMSA and Service name

# Change the two variables below as needed

$serviceName = 'PIOLEDBENTAgent'

$gMSA = "DEN\PISQgmsa$"


$service = Get-WmiObject -Class Win32_Service -Filter "Name='$serviceName'"

$service.Change($null, $null, $null, $null, $null, $null, $gMSA, $null, $null, $null, $null)



PI Data Server 2017 R2+

  • Use Services.msc or PowerShell to switch PI Network Manager service (pinetmgr) to run under the gMSA.
  • Older PI Data Servers do not support custom accounts.


PI AF Server

  • Use Services.msc or PowerShell to switch the AF Server service (afservice) to run under the gMSA.

PI Vision

  • From Command Prompt, execute aspnet_regiis.exe -ga domain\gMSA$ to give the account access to Microsoft .NET Temporary folder and IIS meta database.
  • Use IIS Manager or PowerShell to switch PI Vision Application Pools to run under the gMSA.


PI Web API 2017+

  • Run through PI Web API Admin Tool and select the default NT Service accounts.
  • Use Services.msc or PowerShell to switch PI Web API and PI Crawler services to run under the gMSA.
  • Re-run PI Web API Admin Tool and make no changes. The tool will automatically grant all required permissions to the gMSA.


PI Connectors

  • Add the gMSA to PI Connector Administrators local group as this group is automatically granted all the required permissions.
  • Use Services.msc or PowerShell to switch PI Connector to run under the gMSA.



  • Install kit supports gMSA and sets permissions appropriately.




Resource-based Kerberos Constrained Delegation (RBCD)


Configuring RBCD is not limited to gMSAs, but the requirements are similar – if you can use gMSAs, you can also use RBCD. OSIsoft has good documentation on the requirements and configuring RBCD.


One of the big advantages of RBCD is that service administrators can configure it themselves (no need to contact Domain Administrators).





1. Open elevated Command Prompt on the machine with the gMSA-run back-end service (PI or AF Server).


2. Use Windows Sysinternals’ PsExec to open a PowerShell console under the gMSA identity:
PsExec.exe -u DOMAIN\gMSAname$ -p ~ powershell.exe


3. Domain users, including gMSAs, possess the required permission (write account restrictions) by default, so we can configure RBKCD as needed:

Set-ADServiceAccount -Identity gMSAname -PrincipalsAllowedToDelegateToAccount Account1, Account2 ..

For example, to allow Kerberos Delegation from PI Web API service running under PIWebAPIgSMA$ account to AF Server service running under AFgMSA$ account, execute:

Set-ADServiceAccount -Identity AFgMSA -PrincipalsAllowedToDelegateToAccount PIWebAPIgMSA$



4. Assuming the gMSA has been granted to write to its SPN attribute (as recommended and shown above), SPNs can now be set using SetSPN.exe:
setspn -s SPNClass/MachineHostName gMSAname$
setspn -s SPNClass/MachineFQDN gMSAname$


For example, to create HTTP SPNs for a PI Vision Service, execute:

setspn -s HTTP/piviz01 PIVizgMSA$

setspn -s HTTP/piviz01.domain.local PIVizgMSA$



References and recommended reading


Securing Privileged Access

Group Managed Service Accounts Overview

Getting Started with Group Managed Service Accounts

Windows Server 2012: Group Managed Service Accounts

CQURE: How To Use Group Managed Service Accounts (gMSA) vs. Service Accounts

DSInternals’ post on retrieving cleartext gMSA passwords

OSIsoft documentation: Resource Based Kerberos Constrained Delegation

Coresight Squared


This series consists of three parts:
1. Server Core Installation and Configuration
2. PI Coresight Installation

3. Extras: Kerberos and more << you're here!



At this point, Coresight Squared is ready to rock. But what’s next? Surely we can’t end here!


Meet everyone’s favorite three headed friend – Kerberos.

We will not go into technical details about how the Kerberos protocol works, nor will we cover Kerberos troubleshooting. Maybe next time!

Instead, we’ll look into how to leverage Kerberos authentication and Kerberos delegation to enhance security configuration of the PI System.




Coresight - IIS Settings


Before configuring Kerberos, make sure Kerberos Authentication with PI Coresight is possible:


1. Enable Windows Authentication

Select Coresight Web Application > Authentication Settings:



2. Enable Kernel-mode Authentication
Right-click Windows Authentication > Advanced Settings... > make sure Kernel Mode is enabled:


As per the description above, Microsoft recommends keeping Kernel-mode Authentication enabled. Some hard data on performance benefits of Kernel-mode Authentication can be found here.


If Kernel-mode authentication is Enabled, Kerberos tickets are decrypted using the password hash of the computer where the service we're accessing is running (i.e. the Coresight Web Server in this case). As such, if the Coresight AppPools run under:


  • Virtual or Machine account (such as Network Service) - no further action required


  • Custom Domain Account - In IIS Manager, select the Coresight Web Application > Configuration Editor > navigate to system.webServer/security/authentication/windowsAuthentication > set useAppPoolCredentials to True. This ensures that the password hash of the Coresight AppPool account is used to decrypt incoming Kerberos tickets, allowing Kerberos Authentication to work properly.


3. Make Kerberos Authentication possible

Right-click Windows Authentication > Providers... > make sure the Negotiate provider is listed as the first option. For example:






Kerberos Simplified: The Three Heads


To simplify as much as possible, let's consider the three main points of interest:

1. Front-end Service Principal Name  - Coresight end-users need to be able to use Kerberos Authentication to log in to Coresight (the front-end service)

2. Back-end Service Principal NamePI or AF Server (the back-end service) needs to be able to receive Kerberos requests (delegated credentials)

3. Kerberos Delegation - Coresight service account (the front-end service identity) needs to be allowed to delegate end users' credentials to the back-end service (PI or AF Server)



The First Head: Front-end Service Principal Name

A Service Principal Name (SPN) is a unique identifier of a service instance. SPNs are used by Kerberos authentication to associate a service instance with a service account.

SPN can be broken down into two parts (I am purposefully leaving out the port number and service name as they’re not relevant to our context):


ServiceClass/TargetHost, which is assigned to the appropriate ServiceAccount.


ServiceClass – a string indicating the general class of a service. Well-known service classes pertaining to the PI System include:

PI Data Archive – PIServer

PI AF Server – AFServer

PI Coresight – HTTP

Regardless of whether SSL is enabled for Coresight, the ServiceClass is always HTTP!


TargetHost- Hostname and Fully Qualified Domain Name of the computer on which the service is running. Always create one SPN for the hostname and one more for the FQDN of the Coresight server!


ServiceAccount – The account running the service. In case of:

Domain Account - the SPN is assigned to the actual domain account running the service

Virtual or Machine accounts (Network Service, NT Service\Service etc.) – the SPN is assigned to the computer object (on which the service is running)


SPNs can be created using the setSPN.exe tool (available from the Command Prmompt). In most environments, a Domain Admin access is needed to create new SPNs.


To create SPNs for PI Coresight running under OSI\CoresightSVC on machine:

setspn -S HTTP/ OSI\CoresightSVC
setspn -S HTTP/Core01 OSI\CoresightSVC


To create SPNs for PI Coresight running under Network Service on machine:

setspn -S HTTP/ Core01
setspn -S HTTP/Core01 Core01




Use setSPN.exe to verify whether the SPNs are created and assigned correctly.


To list all SPNs assigned to a particular domain\account:

setspn -L domain\account
Example: setspn -L OSI\CoresightSVC


To check whether a particular SPN exists:

setspn -Q SPN
Example: setspn -Q HTTP/Core01




The Second Head: Back-end Service Principal Name


The same principles applied to front-end Service Principal Names apply to the back-end Service Principal Names as well. Make sure the appropriate (PIServer/TargetHost and AFServer/TargetHost, respectively) SPNs are assigned to the correct service account (PI Network Manager ServiceAccount for Data Archive; PI AF Application Service ServiceAccount for PI AF Server).





The Third Head: Kerberos Delegation


Once Kerberos Delegation is enabled, the front-end service (PI Coresight) can delegate end users’ credentials to the back-end service (PI Data Archive or PI AF Server) and thus ensure that end users access resources (data) of the back-end service in a secure way.


In our case, the Coresight service account needs to be allowed to delegate end-users’ credentials to PI Data Archive. Starting with PI Coresight 2016, Keberos Delegation to AF Server is required for annotating Event Frames.


There are three main types of Kerberos delegation:


  • General (Unconstrained) Delegation
  • Constrained Delegation
  • Resource Based Delegation


For additional details, please consult KB01222 - Types of Kerberos Delegation. We’ll go for the cutting edge option – Resource Based Delegation.


There are several benefits to Resource Based delegation. Most notably:

  • Permission to delegate associated with back end instead of front end identity
  • Domain administrator privileges are not required
  • Functions across domain and forest boundaries


This is excellent news for non-IT administrator users as it allows for the administrator of the back end resource, such as PI Administrators for the PI Data Archive and PI AF Server, to control whether or not these resources receive delegated credentials.


However, there are also some requirements for resource based constrained delegation to work.

  • Both the front and back end account domains must have Server 2012 level or higher Kerberos Distribution Centers
  • The front end server must be running on Server 2012 or later OS


To configure resource based constrained delegation, use the Active Directory cmdlets in PowerShell.

The example below is for a PI Coresight web server running under a domain account picoresight and AF Server PIAF01 running under the default virtual account NT Service\AFService.


Step-by-step guide:


1. Get the front-end and back-end service identities. If the service is running under a domain account use Get-ADUser. If it is running under a machine account such as Network Service or a virtual account, use Get-ADComputer.


$frontendidentity = Get-ADUser -Identity picoresight
$backendidentity = Get-ADComputer -Identity PIAF01



2. Assign the front-end identity to the PrincipalsAllowedToDelegateToAccount property of the back-end identity:

Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity



3. View the updated PrincipalsAllowedToDelegateToAccount property for the back-end identity to verify that it is set properly:

Get-ADComputer $backendidentity -Properties PrincipalsAllowedToDelegateToAccount






To allow multiple principals to delegate to the same back end, set the PrincipalsAllowedToDelegateToAccount with all the desired identities, separated by a comma:

Set-ADComputer $backendidentity -PrincipalsAllowedToDelegateToAccount $frontendidentity1, $frontendidentity2


If there are multiple domains involved, specify more criteria when executing the Get-ADUser cmdlet. The example below includes the -Server parameter to specify a DC of the domain where the identity resides:

$frontendidentity = Get-ADUser -Identity picoresight -Server piDC01.pidoge.local





Recommended Kerberos reading (and you guessed it, it’s three links ):

OSIsoft: Kerberos Authentication and web browsers

How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 1

How Windows Server 2012 Eases the Pain of Kerberos Constrained Delegation, Part 2



What's next? Look into Coresight High-Availability!



Since you've made it all the way here, chances are you're interested in assessing the security posture of your entire PI System, not just Coresight, so please do check out the PI Security Audit Tools on GitHub!

Coresight Squared


This series consists of three parts:
1. Server Core Installation and Configuration
2. PI Coresight Installation << you're here!

3. Extras: Kerberos and more



Service Accounts


Before movng on to PI Coresight installation, get the proper Service Accounts in place. To follow the principle of least privilege, use 3 separate accounts:


  1. Service Account to run both Coresight AppPools

  2. Service Account to run PI WebAPI Service

  3. Service Account to run PI Crawler Service


Required permissions:


PI Coresight service account

- Read access to everything in PI Data Archive and PI AF that will be accessed in PI Coresight

- Read access to any import folders with PI ProcessBook displays


PI Crawler service account

- Read access to PIUSER, PIDBSEC, PIPOINT, PIMAPPINGS tables in PI Data Archive

- Read access to everything in PI Data Archive and PI AF that PI Coresight users would like to search for


PI Web API service account

- Access to connect to any PI or AF Server that’s used in PI Coresight (required for successful registration of the source for indexing by PI Crawler)




PI Coresight Installation


The attached setup.ini file (or get it from pastebin) is the key that opens the door to Server Core for PI Coresight. The setup file is modified so that the Server Roles and Features check is skipped, and PI Buffer Subsystem module is removed as it’s not required by PI Coresight.


Important note regarding .NET Framework 4.6 (skip this note if Windows Server 2016 is used - it comes with .NET Framework 4.6 installed by default):

Considering the high number of reported .NET Framework 4.6 installation issues due to missing prerequisites, it’s good to install it via Windows Update before proceeding with PI Coresight installation.


There are two ways of doing this:

1) Slow: Wait for the updates to be installed automatically

Windows Update is running in Automatic mode (as we configured it in the preparation phase), so all required updates will be installed eventually.


2) Quick: Force a Manual update on a Server Core

To speed up the process, switch Windows Update to Manual mode and installed all available Updates immediately:

a) Open up sconfig > select Option 5 – Windows Update Settings > type m to switch Windows Update to Manual mode.


b) From the main sconfig menu, select Option 6 – Download and Install Updates > type a to search for all updates > type a again to install all updates.

Restart may be required to finish the installation of some of the Updates. This procedure may have to be repeated couple of times to get .NET Framework 4.6 installed.


c) Switch Windows Update back to Automatic mode (sconfig > select Option 5 – Windows Update Settings > type a to switch Windows Update to Automatic mode).


If you decide to go for a manual installation, the /q switch (silent installation) needs to be used when installing .NET Framework 4.6 on a Server Core.
The installation would be initiated by running: NDP46-KB3045557-x86-x64-AllOS-ENU.exe /q. As such, the /q switch is included in the modified setup.ini just in case.



Steps to follow:


1. Replace setup.ini


i. On any computer, run PI Coresight installation kit and unzip it to a folder (let’s call it installsrc), then cancel out of the installation before any components are installed.

ii. Go to installsrc and delete the original setup.ini file and copy & paste in the modified setup.ini .



2. Copy the installsrc folder to the Server Core machine and install PI Coresight


Use the Robocopy (available from the Command Prompt) or copy&paste feature in Windows Explorer.


For example, to copy Coresight 2016 install folder from C:\Temp on the local drive to C:\Temp on a remote machine called CORE:

robocopy "C:\Temp\Coresight2016" "\\CORES\c$\Coresight2016" /e



Using Command Prompt, run Setup.exe located in installsrc on the Server Core machine and click through install wizard answering prompts. PI System Explorer can be deselected as a feature during the AF Client installation since it’s not required, although it does make adding new PI and/or AF Servers much easier. In any case, PI Coresight is installed at this point.



3. Reboot the machine using shutdown /r /t 0 command


4. Configure PI Coresight Application Pools to run under a service account


If the Remote Administration step has been completed (as per the previous part of this series), configuring the AppPools to run under a custom service account is that much more convenient as it can be done remotely via IIS Manager.


Alternatively, use Powershell. For example, to configure Coresight AppPools to run under OSI\CoresightSVC:


Import-Module WebAdministration;
Set-ItemProperty iis:\apppools\coresightserviceapppool -name processModel -value @{userName="OSI\CoresightSVC";password="password";identitytype=3}
Set-ItemProperty iis:\apppools\coresightadminapppool -name processModel -value @{userName="OSI\CoresightSVC";password="password";identitytype=3}



5. Recycle both Coresight AppPools – run iisreset in Command Prompt or recycle the AppPools remotely via IIS Manager






PI Coresight - Finishing touches


1. Grant users access to the PI Coresight and/or PI Coresight Administration page


PI Coresight Application - Local Windows group PI Coresight Users on the PI Coresight server controls access to the PI Coresight application. By default, Authenticated Users group is a member

PI Coresight Administration – Local Windows group PI Coresight Admins on the PI Coresight server controls access to the PI Coresight Administration. In addition, a PI Coresight Administrator needs to be in an additional local group PI Web API Admins group in order to be able to allow/disallow PI and AF sources for PI Coresight. Only the user who runs the installation is added to these groups by default.


Local Users and groups can be accessed from Server Manager on a workstation of your choice.


Alternatively, Poweshell can be used to add Users or Groups to the Local Group. For example, to add user IT.local\AverageJoe to PI Coresight Admins local group on CORESIGHTSERVER machine, run:


$Group = "PI Coresight Admins"
$Domain = "IT.local"
$UserOrGroup = "AverageJoe"


Coresight can be configured to use any domain or local group instead of the default ones. I won’t go into the details, but if you’re interested, here’s a link to our documentation.



2. Manually create PI Coresight SQL Database


Copy over all files from %pihome64%\Coresight\Admin\SQL folder to a SQL Server machine.


Use robocopy (or copy&paste feature in Windows Explorer):

robocopy "C:\Program Files\PIPC\Coresight\Admin\SQL" "\\SQLSERVER\c$\Coresight-SQL" /e


b) Go to the SQL Server, open up the Command Prompt, navigate to the folder with the Coresight SQL files and execute:

GO.BAT DBSERVER DBNAME CoresightAppPoolAccount output.log


For example, to create a SQL database PICoresight in SQL Server MYSQLSERVER assuming OSI\CoresightSVC is the domain account running Coresight AppPools:

GO.BAT MYSQLSERVER PICoresight OSI\CoresightSVC output.log


For additional details, please see our online documentation.



Finally, link the Coresight application needs to the Coresight SQL Database. In a web browser, navigate to the Coresight Admin page > Configuration > PI Coresight Database and select the appropriate SQL Server and Coresight SQL Database.


Note: Due to Known Issue, the Admin page may indicate that the connection to the Coresight SQL Database is not healthy. To verify whether this is a false positive, navigate to the Coresight homepage, create a New Display and save it. If that works, all’s good.



3. Configure allowed PI and AF data sources in PI Coresight Admin page


Additional PI Data Archive Servers and PI AF Servers need to be added to the KST first unless only the defaults specified during the install are used.


Option 1) Use PI System Explorer (PSE)


If PSE was installed during the AF Client installation, use it to add additional PI and/or AF Servers. On the Server Core machine, use the Command Prompt to navigate to %pihome64%\AF (cd /d %pihome64%\AF) and then run AFExplorer.exe.

PSE will open normally and the File > Connections menu does the trick.


Option 2) PSE is not available - Manually add PI  / AF Servers


AF Servers information is stored in the AFSDK.config file (located in %programdata%\OSIsoft\AF). Navigate to the location in Command Prompt and open the file:

cd /d  %programdata%\OSIsoft\AF
notepad  AFSDK.config


Add a new AF Server into the PISystems collection: <PISystem name="AFSERVERNAME" host="AFSERVERHOST" protocol="Tcp" port="5457" accountName="" timeout="300" />. The Unique ID for the server is automatically populated upon the first connection.


For example: <PISystem name="CSAFBUILD" host="CSAFBUILD" protocol="Tcp" port="5457" accountName="" timeout="300" /> will get adjusted to: <PISystem name="CSAFBUILD" id="638f25d4-21ed-44ea-92bb-84305d373578" host="CSAFBUILD" protocol="Tcp" port="5457" accountName="" timeout="300" /> after the first connection.



PI Servers information is stored in the Registry under HKLM\SOFTWARE\PISystem\PI-SDK\1.0\ServerHandles hive.

Use Powershell to add a new PI Data Archive - set the value of the $PI variable as needed.


$Key = "HKLM:\SOFTWARE\PISystem\PI-SDK\1.0\ServerHandles\" + $PI
If ( -Not ( Test-Path $Key)){New-Item -Path $Key -ItemType RegistryKey -Force}
Set-ItemProperty -path $Key -Name "configString" -Type "String" -Value ""
Set-ItemProperty -path $Key -Name "confirmed" -Type "String" -Value "0"
Set-ItemProperty -path $Key -Name "defaultServer" -Type "String" -Value "0"
Set-ItemProperty -path $Key -Name "defaultUser" -Type "String" -Value "pidemo"
Set-ItemProperty -path $Key -Name "path" -Type "String" -Value $PI
Set-ItemProperty -path $Key -Name "port" -Type "String" -Value "5450"
Set-ItemProperty -path $Key -Name "serverID" -Type "String" -Value ""



Alternatively, create the necessary registry keys using Registry Editor.


In any case, upon the first connection to the PI Data Archive, the value of the ServerID property is added automatically.




At this point, PI Coresight + Server Core configuration should be fully functional. Next, configure Kerberos!



Update 22-Aug-2016:

-Added a small note on Windows Server 2016 and .NET Framework 4.6.

-Clarified the required PI WebAPI permissions

Coresight Squared


This series consists of three parts:
1. Server Core Installation and Configuration << you're here!
2. PI Coresight Installation

3. Extras: Kerberos and more




Server Core - Install and Configure


Server Core is the default option when installing Windows Server 2012 R2 and Windows Server 2016:




Log in to your Server Core machine for the first time - only the Command Prompt shows up for the welcome party!



Use the Server Configuration tool (sconfig) to rename the machine, configure DNS settings, join a Windows Domain, enable Windows Updates, enable Remote Management and more.

To access the tool, execute sconfig in the Command Prompt. Using sconfig is straightforward, but I recommend proceeding in the following way:


1. Configure DNS Settings

Select Option 8 > select index of the Ethernet card > select Option 2 (Set DNS Servers) > set preferred (and alternate) DNS server(s)




2. Join the computer to a Windows Domain

Select Option 1 > select D for Domain > enter Domain Name > confirm and finish



3. Rename the computer - this option automatically pops up when joining the computer to a Windows Domain.


4. Reboot - Use Option 13 in sconfig.



5. Enable Windows Update

Select Option 5 > Select A for Automatic



6. Configure inbound Firewall rules

Using Powershell, enable File and Printer Sharing inbound rule in order to copy PI Coresight installation kit to the machine. This rule can be disabled after PI Coresight installation.


Enable-NetFirewallRule -DisplayGroup "File And Printer Sharing"


For proper Remote management, enable additional Firewall rules:

Enable-NetFirewallRule -DisplayGroup "Remote Event Log Management"
Enable-NetFirewallRule -DisplayGroup "Remote Service Management"
Enable-NetFirewallRule -DisplayGroup "Remote Volume Management"



7. Activate all Roles and Features required by PI Coresight


a) If Windows Server 2016 Core is used, the location of file needs to be specified in order to install features related to .NET Framework 3.5. Mount the Windows Server 2016 installation .ISO file, go to sources folder, and copy sxs folder (this is where resides) to C: drive on the Server Core machine. Then use CSRolesFeatures2016.ps1 (attached to this post and available at pastebin) PowerShell script in the next step - it uses the C:\sxs folder as source for feature activation. For Windows Server 2008 or 2012 Core, use the original CSRolesFeatures.ps1 (attached to this post and available at pastebin).


b) In any case, copy the appropriate script to the Server Core machine using robocopy (available from the Command Prompt) or copy&paste feature in Windows Explorer.


For example, to copy CSRolesFeatures.ps1 from local D:\Downloads folder to C:\Temp on CORESQUARED using robocopy:

robocopy "D:\Downloads" "\\CORESQUARED\C$\Temp" CSRolesFeatures.ps1



c) Open PowerShell console on the Server Core machine (execute powershell command in the Command Prompt) allow execution of the script for the current session, and run the script:

Set-Executionpolicy RemoteSigned -Scope Process
.\CSRolesFeatures.ps1 -Mode Install -IsCore $true



d) Once the script does its magic, reboot the machine by running shutdown /r /t 0 in the Command Prompt.




Server Core – Enable Remote Administration


Use sconfig > select Option 4 > select option 1 to enable Remote Management.


Use Remote Management to add/remove Windows features, maintain Local Users and Groups, inspect Event Logs and more.



Web Server Management Service is required for remote IIS Management. Use PowerShell to install the service and set the related registry setting:

Install-WindowsFeature Web-Mgmt-Service
Set-ItemProperty -Path HKLM:\SOFTWARE\Microsoft\WebManagement\Server -Name EnableRemoteManagement -Value 1


Finally, start the Web Management service by running net start WMSVC in the Command Prompt. Optionally, configure the service to start automatically: sc config wmsvc start=auto.




Server Core can now be fully managed from a remote workstation (Server Manager for general server management, IIS Manager for IIS management)!


To connect to the Server Core IIS remotely, open up IIS Manager on any Server with GUI, right click on Start Page and select the Connect to a Server... option:


Server Core is ready for PI Coresight. Let's install it!





Update 22-Aug-2016: Added a couple of small notes regarding installing .NET Framework-related features on Windows Server 2016 Core.


Coresight Squared

Posted by lmlcoch Employee Aug 1, 2016

PI Coresight is not officially supported on Windows Server Core, but with a couple of tweaks and a bit of effort, Coresight Squared is possible.


What is Server Core and why use it?

Server Core is a minimal installation option for Windows Server and its main benefit is reduced footprint. However, this is not just to reduce the number of potentially vulnerable components (thus reducing the attack surface area), but also serves to reduce the amount of patching and maintenance required. Last but not least, Server Core consumes less resources.


Server Core References:

Benefits of Server Core

Server Core in Windows Server 2012 – Improved Taste, Less Filling, More Uptime



We strive to officially support Server Core in a future PI Coresight release (please up-vote the related UserVoice item), but for now, this guide will have to do.


Side note: It’s possible to install Windows Server with the Full UI capability, install PI Coresight, configure it, and remove the GUI components to get Server Core. In Windows Server 2012, the GUI can be added or removed as needed via PowerShell.

To remove the GUI:

Remove-WindowsFeature -name Server-Gui-Mgmt-Infra
Remove-WindowsFeature -name Server-Gui-Shell


To add the GUI:

Install-WindowsFeature -name Server-Gui-Mgmt-Infra
Install-WindowsFeature -name Server-Gui-Shell




But where’s the Fun in that? 



If you are an experienced Server Core user, please feel free to dive right into PI Coresight installation and Kerberos Configuration for PI Coresight.


If you're new to Server Core, please go through the Coresight Squared series in the following order:


1. Server Core Installation and Configuration

2. PI Coresight Installation

3. Kerberos Configuration for PI Coresight



A big thanks goes to Harry Paul for useful advice and guidance throughout the entire process of putting this series together.