Skip to main content

Items To Consider

info

When commencing your journey with Pia, it is important to consider if any of the following items are applicable to your company internally, or any of your clients. These items can impact a smooth implementation of Pia and should be taken into consideration before your 90 minute “Core Implementation Training” session.

IP Whitelisting​

Do you have IP whitelisting configured on your Ticketing System or IT Glue for inbound connections? These restrictions can also apply to incoming API calls and may block communication with Pia. If this is applicable to you, please advise the Pia PMO Team ASAP so we can discuss what you have in place and make the required arrangements. We can provide you with the public IP addresses for your Pia Tenant to whitelist if needed.

IP/Geo-Filtering​

Do you or any of your clients have IP/Geo-Filtering in place? If so, you will likely need to modify the Pia Agent install script/module provided as by default, the agent is downloaded from an Azure Storage Blob located in Microsoft’s Sydney, Australia Data Centre. We also have an Azure Storage Blob in the United States which the script can be modified to utilise by simply replacing the URL. If this is applicable to you or your clients, please see Pia Agent Installation, select your RMM and review the instructions for your RMM on how to replace the URL in the scripts.

HTTPS Proxy and Web Caching Solutions​

All traffic communicated via the Pia Agent is over HTTPS on Port 443. We have observed that some HTTPS Proxy and Web Caching solutions try to intercept the agents outgoing communications to your Pia Tenant and attempt to retrieve the result from it’s cache instead. This causes communication issues and can lead to the device showing offline in your Pia Portal. If you do have one of these solutions in place, please advise the Pia PMO Team ASAP so we can discuss what FQDNs/URLs you need to whitelist.

MITM/SSL Inspection Solutions​

The Pia Agent utilises a public key/private key pair for communication with your Pia Tenant. MITM/SSL inspection solutions can break the SSL chain trust, causing the communication to fail. If you do have one of these solutions in place, please advise the Pia PMO Team ASAP so we can discuss what FQDNs/URLs you need to whitelist.

Inbound/Outbound HTTPS restrictions​

As mentioned above, the Pia Agent communicates all traffic over HTTPS on Port 443. If you have Inbound/Outbound HTTPS restrictions in place, they may cause issues with the agent’s communication. If you do have one of these solutions in place, please advise the Pia PMO Team ASAP so we can discuss what FQDNs/URLs you need to whitelist.

Anti-Virus/Security Applications​

We have observed some anti-viruses and other security applications(such as ThreatLocker) block the installation of the Pia Agent or even the PowerShell in Pia’s Automation Packages from running on devices. Please keep this in mind as part of your deployment that whitelisting in these solutions may be required. The Pia Agent is installed to the following location “C:\Program Files (x86)\OrchestratorAgent” and runs under a service named “OrchestratorAgent” for which the associated .exe file resides in the same, directory.

What email address do I want Pia’s email notifications sent from?​

Your Pia Portal will send email notifications to your Engineers, an example of this is when you schedule a package to run in the future. When Pia runs the package as per the schedule, the Engineer who scheduled the package will receive an email notification confirming the execution. For the Mail Send functionality for these notifications, Pia must be delegated “Send.As” permissions from a user with a licensed mailbox(i.e. Exchange Online Plan 1/2). The user who has delegated the permissions will appear as the sender of the email. Some of our Partners choose to utilise the Pia Admin O365 account they created for their tenant provisioning for this purpose, so it is obvious from the name on the account that the email came from Pia.

As part of configuring Pia in each of your Client’s Microsoft 365 environments, a Delegate Consent is required from a Global Admin account to allow Pia to reset user passwords. This consent must be granted by a Global Admin who perpetually maintains the role, the consent will fail if the Global Admin role was elevated/provided via Just-In Time Access from Azure Privileged Identity Management (PIM). If you only have Global Admin rights granted via PIM, you may need to consider creating a dedicated Global Admin account for Pia. The Delegate Consent can also expire in the future if any of the following scenarios should occur:

  • The Global Admin role is removed from the account
  • The Global Admin account is disabled/deleted
  • The Global Admin account has it’s password changed
  • The Global Admin account has it’s MFA methods reset