Skip navigation
All Places > Security > Blog > 2016 > August
2016

The summer of 2016 set new highs for cyber security regulation. In North America, a strengthened version of critical infrastructure protection (CIP) standards for the bulk electric system became enforceable. The Federal Energy Regulatory Commission also issued Order 829 to address supply chain risk management for industrial control systems. In Europe, the strict Network and Information Security (NIS) directive passed parliament and starts the clock for compliance deadlines affecting member states and their critical infrastructure operators.

 

The penalty structure for NERC CIP can be as high as $1m per day per violation. NIS Directive allows for fines of up to €10m.  As a result we observe companies investing in serious cyber security programs. We are especially interested in finding ways to make your security team more effective.

 

Effective incident response is a common theme across these regulatory standards. Perhaps law is following industry hype ‘Be prepared, not scared’ and the FBI’s ‘there are two types of companies: those that have been hacked and those that don't know it yet’. Or perhaps the standards attempt to codify simple wisdom like Ben Franklin’s ‘An ounce of prevention is worth a pound of cure.’

 

In terms of OSIsoft:

  • What incident response triggers are relevant to the PI System? 
  • Are there opportunities for collaboration on incident response activities?

 

These high level questions and others are in scope of a cyber security project with Chevron. Initial findings suggest incident response for industrial control systems is far from trivial - especially amongst large organizations.

Ryan Cheff, Oronite Manufacturing Technical Architect, shares insights on the project in this joint presentation at the OSIsoft User Conference 2016. You can find the presentation here.

 

Aspects of the NIS Directive will be discussed in more detail next month during the EMEA Users Conference 2016 in Berlin.  The session on NIS is part of the Industrial IT track on day 2. Please reach out should your company be interested in exploring partnership on NIS requirements.

 

The summer of cyber bow-ties shows the PI System as part of a kill chain that helps you defend industrial control systems. Working in partnership we can better address your needs for effective incident response.

Bow Tie for Cyber Security Series:

     0x01 - How to Tie a Cyber Bow Tie

     0x02 - Hardcore PI Coresight Hardening

     0x03 - Attack Path of Least Resistance? <-- You are here.

 

In the last installment of this series, we took a look at a Bow Tie diagram of a PI Coresight deployment and walked through some basic evaluation of the coverage.  In this installment, we’ll talk about how Bow Tie diagrams fit into visualizing attack paths and the cyber kill chain concept!

 

For the uninitiated, the cyber kill chain is a concept defined by Lockheed Martin which describes the process that a miscreant must go through in order to achieve their desired effects on a system.  You can check out Lockheed Martin’s dedicated page on the cyber kill chain for a rigorous discussion of the topic.  The SANS Institute published an excellent White Paper [PDF] that discusses the Cyber Kill Chain within the context of ICS.

 

Let’s start with a simple network architecture. We have a business zone with several client machines and a web server, a DMZ with a database server and a single workstation, and finally a control zone with an interface node and our control system (yes, profoundly generic, I know).  We’re going to explore a scenario where a miscreant sabotages the control system to cause physical damage and potential human hazards.

Two possible attack paths traversing our simplified network to the control system are drawn in the figure below.  For each node in the attack path, a miscreant must:

  • Perform Reconnaissance
  • Identify an exploitable vulnerability
  • Exploit the vulnerability to gain a foothold on the system
  • Escalate privileges where necessary
  • Pivot and begin the next attack

 

If we can detect and block these activities, then we can halt their advance before they reach the crown jewels, our precious control system.

 

The first attack path begins with an attack from the outside world to a client machine in the DMZ.  This could result from a firewall configuration issue, stolen VPN credentials or perhaps infected removable media.  Once the client node is compromised, the attacker must then go through the steps in the cyber kill chain in order to pivot and attack the next component in the network.  During reconnaissance the miscreant determines the client is running PI ProcessBook, and from the machine it can connect to the PI Data Archive, which would bring them one step closer to their ultimate goal, the control system.  Once they successfully escalated privilege and pivoted to the PI Data Archive machine, they again must progress through steps in the kill chain to pivot and attack the interface node.  Finally, once the interface node has been compromised, the miscreant can mount an attack on the soft and chewy control system, which is now in striking distance.

In the case of the second attack path, the attacker is not able to compromise a client node in the DMZ.  Perhaps that workstation is properly isolated and the controls with respect to removable media are being followed.  In this case, the attacker has to start with a client in the business network.  The attacker could gain their foothold on one of these clients with any number of methods, including phishing or a watering hole attack.  The next closest node that the business network workstations can communicate with is the web server.  Similar to the previous path, at each node, the miscreant must go through the steps of the cyber kill chain to pivot and mount the next attack deeper in the network.

Hopefully a few things stand out from these example paths: 

  • There is benefit in building a defendable architecture.  If the control system has components connected to the internet or the business network machines can make direct connections to machines on the restricted network, then the work of an attacker is simplified dramatically.
  • Attacking even a fairly simple system can become a complex challenge!  There is a reason that the world doesn’t end when a CVSS 10.0 is discovered.  A single exploit can give you a foothold on a machine, but identifying relative position in the network, escalating privilege, and mounting attacks deeper into the network all while maintaining communication externally and evading detection is another challenge entirely.  Even in this brave new world of APTs, there are still opportunities for defense to win.
  • Lastly, in the second attack path, there was an additional layer that the attacker needed to progress through, the web server.  That layer offers many defenses and impact reductions (highlighted in Hardcore PI Coresight Hardening) that could stop an attacker from completing the steps in the cyber kill chain and progressing.

 

In a few discussions I’ve had with system administrators and security professionals regarding this topic, they’ve indicated that there are plenty of other machines on their network, some of which may be remotely accessible.  Since this approach is modular, this revelation does not interfere from a modeling standpoint.

If there are other machines on the network that are either internet connected or subject to poor controls that could allow compromise through removable media or foreign devices connected to them, these other machines could allow shorter paths to the high value target of the control system.  If we have a Bow Tie for each component, we can use the superposition of Bow Ties in a given path to evaluate the defenses relative to other paths identified.  By looking at the security posture within the context of the full attack paths, we can target weaknesses within the context of the system and prioritize defenses to fortify them.

 

In the next installment of the series, I’ll discuss some of the implications of this path based approach and how we believe it can provide a common language between the opposing sides of the “IT/OT civil war”.  In the meantime:

  • This example centered around a control system as the high impact target.  What other high impact consequences should we reverse off of to generate paths?
  • Are there any other methodologies you use to evaluate the path of least resistance?

 

Update: Replaced broken link for Cyber Kill Chain.

Bow Tie for Cyber Security Series:

     0x01 - How to Tie a Cyber Bow Tie

     0x02 - Hardcore PI Coresight Hardening <-- You are here.

     0x03 - Attack Path of Least Resistance?

 

In my last installment, How to Tie a Cyber Bow Tie, we discussed Bow Tie methodology and how it can apply to software.  As promised, in this installment, I will share an example diagram of a PI Coresight deployment.  Since PI Coresight is a web application hosted in IIS, it is exposed to many of the same challenges, so I started with the enumerated threats and impacts from the web server example in the last edition.  After brainstorming several barriers, I then settled on my four favorite for each threat and impact, displayed in the updated diagram below. 

 

Barriers that were favored for effectiveness, ease of implementation and wide support of configurations.  For example, one threat is "Exploit Vulnerable Product or Service", essentially the risk is that there is a vulnerability present in PI Coresight or the components it depends on and a miscreant determines a way to exploit it.  Selected barriers against this include:

  • Software Updates: using the latest version of the application which has the benefit of bug fixes and defenses implemented through SDL.
  • Windows Server Core: provides reduced surface area to contain exploitable code.  See Coresight Squared by Lubos Mlcoch for a comprehensive guide on setting up a deployment on Windows server core.
  • Firewall Restrictions: a host-based firewall allows a great deal of granularity, not only limiting the accessibility to incoming threats, but also limiting outbound traffic a malicious application might use to call home for a malicious payload or communicate with a C&C server.
  • Application Whitelisting: can offer significant protection since it can prevent both known and unknown malicious software from executing.  For a primer on setting AppLocker rules on a PI Data Archive, see KB00994.  The same concepts can be applied to other PI components such as PI Coresigh as well.

A few honorable mentions that did not make the list for this particular threat are Device Guard due to limited supported configurations presently and Antivirus as it can only protect against known threats.

Looking at the Bow Tie without any barriers in place can be daunting since there are so many ways in which disaster can strike, but hopefully this diagram with barriers in place tells a different story, showing both the breadth and depth of defenses you have at your disposal.  This huge array of security options is encouraging in theory, but if you only have 24 hours in a day, where do you start?  How do you prioritize which measures make it into your deployment?

 

A logical first step is to evaluate what is already in place.  Let’s look at the type of coverage we would have after a basic installation, and for the sake of this post, I’m defining a basic installation as follows:

  • Using the most recent release of PI Coresight
  • Applying Windows updates
  • Host based firewall is enabled allowing inbound connections to port 443
  • Delegation configured for the PI Coresight web application
  • Service account given documented level of access to the PI Server

In the diagram above I’ve highlighted the areas that will be covered in this basic scenario.  While there is significant coverage, the first thing you may notice is that there are no barriers currently in place for the threat “Overload Server Resources”. In the previous edition, we identified four possible barriers for this particular threat:

 

You may also notice that there are several barriers that cover multiple threats and impacts.  These are great candidates to investigate.

  • IIS Role Hardening – 4 (Overload Server Resources, Unauthenticated Access, Authenticated Access, Unauthorized Access to Data)
  • Application Whitelisting – 3 (Client to Another Resource, Spread Malware, Exploit Vulnerable Product/Service)
  • Windows Server Core – 3 (Client to Another Resource, Administrative Access, Exploit Vulnerable Product/Service)
  • Backups – 2 (Tainted Data, Manipulation of Configuration)
  • Credential Theft Defenses – 2 (Administrative Access, Authenticated Access)

 

Given the combination of the coverage that IIS Role Hardening gives, coupled with the fact that it provides a barrier for our most exposed threat, it is probably a good measure to address first.  Incidence of a barrier is just one of many factors we can consider once our options have been enumerated.  If we can effectively consider the relative effort and effectiveness of each barrier, then that can further aid with prioritization as well.

 

Hopefully this piqued your interest!  Now that we’ve drilled into a more detailed example with PI Coresight, the next installment in the series will dive into attack paths and start chaining Bow Ties together to get a closer representation of a full system deployment’s security posture, rather than an isolated component.  Until next time, a few questions for discussion:

  • What are some barriers you use which aren’t represented here? 
  • Do you see other applications for this technique that could be useful in planning or analyzing your deployment?

 

Update: Added links to other parts of the series.

Bow Tie for Cyber Security Series:

     0x01 - How to Tie a Cyber Bow Tie <-- You are here.

     0x02 - Hardcore PI Coresight Hardening

     0x03 - Attack Path of Least Resistance?

 

Welcome to the first installment in our Bow Tie for Cyber Security series, where we will focus on the use of the risk assessment methodology of Bow Tie analysis to examine the attack surface of software installations and discuss how we’ve used the technique at OSIsoft to examine our own software.  The technique aims to improve the reliability and resiliency of a system to threats overall, regardless of attribution.  While I’ll be sharing this material within the context of countering malicious actors, these same measures can protect against insider or incidental threats to the system as well. 

 

To put this approach in context, in the early 90’s Bow Tie methodology was adopted and developed into an industry standard by Shell as a technique to analyze and manage risk.  Traditionally Bow Tie has been used within the realm of safety, but the technique is broadly applicable to any situation where there is the potential for harm.  With the convergence of IT and OT, safety and security are becoming more aligned; it’s time that we apply analysis tools from each area for common goals. 

 

Bow Tie methodology provides a framework to assess risk by identifying the relevant threats, defenses against those threats, impacts and methods to reduce those impacts for any negative event associated with a hazard.  In concept, by placing defenses and reductions in place as barriers, we both reduce the likelihood of the event and lessen the impact of the event should it take place.  The example below is the simplest representation of a Bow Tie diagram.  Within the context of security, we could conceptualize the approach as “keeping the bad guys out” with the measures on the left side of the diagram and “limiting the damage if they get in” with the measures on the right side.

 

Let’s take a look at an example.  To construct a Bow Tie diagram, we must first identify the hazard.  The hazard could be anything with the potential to cause harm, high pressure steam in a pipe, driving a car, etc.  Next we identify the event, which is an occurrence where control is lost over the hazard such as a pipe bursting, or losing control of a vehicle.  In this case, let’s consider running a web server as our hazard and a web server compromise as our event.  With the event identified, on the left side we can enumerate the all of the threats that could potentially cause the event and on the right side we enumerate all of the potential impacts that could result should the event occur.  After taking some time to brainstorm and research, I end up with a diagram like the one below.  Here I’ve chosen to use broader categories of attacks, but depending on the use case, more granularity can be used when enumerating the threats and impacts.  For example, a developer may want to map specific examples of potential exploits to investigate, while an administrator may find categories more actionable since many specific attacks can be blocked by similar defenses.

 

After the threats and impacts are enumerated, we can identify defenses to place as barriers between the threats and the event, as well as impact reductions to act as barriers between the event and the impacts. For this post, I chose to focus on a single threat and one of the associated impacts.  The diagram below provides 4 barriers each for the threat “Overload Server Resources" and the potential impact of “Service Delayed or Unresponsive”. 

 

 

For defenses, to prevent the server from becoming overwhelmed, we can: implement HA, harden IIS, set up Dynamic IP Address Restrictions or throttle the CPU.  In the event the server is overwhelmed, some examples to limit impact include automatically recycling the application pool, or measures which facilitate response such as event logging, diagnostic data like performance counters and a notification system (pardon the shameless plugs) to alert of anomalous behavior.  This list is by no means exhaustive, but reflects a few effective barriers for an IIS based web server.

 

This simplified example provides one threat and impact, but there is not a 1-to-1 correspondence between threats and impacts in general.  One of the main benefits of Bow Tie analysis in cyber security is that it provides a way to visualize multiple facets of the security posture of a software module together. Security is about more than passwords and firewalls, but those are too often the only aspects that get attention.  To get a more thorough picture with the web server Bow Tie, we still need to enumerate the barriers for each of the other threats and impacts, which is precisely what we'll do in the next installment.

 

So, I played it safe this time with a DoS example for a generic IIS web server, but keep an eye out for the next entry in the series where I’ll go into a deeper analysis of PI Coresight with a diagram.  In the meantime, it would be great to hear your comments. In particular:

  • Are you using Bow Tie for your work? 
  • If so, what areas have you applied the methodology? 
  • What are some of your favorite DoS defenses?

 

Update: Added table of contents with links to other posts in the series.

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.

Disclaimer:
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 Core01.it.local machine:

setspn -S HTTP/Core01.it.local OSI\CoresightSVC
setspn -S HTTP/Core01 OSI\CoresightSVC

 

To create SPNs for PI Coresight running under Network Service on Core01.it.local machine:

setspn -S HTTP/Core01.it.local 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

 

 

 

Extras:

 

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:

 

$Computer = "CORESIGHTSERVER"
$Group = "PI Coresight Admins"
$Domain = "IT.local"
$UserOrGroup = "AverageJoe"
([ADSI]"WinNT://$computer/$Group,group").psbase.Invoke("Add",([ADSI]"WinNT://$domain/$userorgroup").path)

 

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.

 

$PI = "PISERVERNAME"
$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!

 

Updates:

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 microsoft-windows-netfx3-ondemand-package.cab 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 microsoft-windows-netfx3-ondemand-package.cab 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!

 

 

 

Updates:

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

lmlcoch

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.