I would like to see increased level of logging to identify potential issues with the operation of PICC especially since the alarms page is deprecated.

As a customer I want to be notified when there are issues with PICC instead of having to actively query the health of PICC, so that I can be aware of issues immediately.

As a customer I want an easy way to validate that all the data from publisher side went to the subscriber side, so I know if there are any issues.

This will make the website faster and more secure.

HTTP/2 will make the website load faster. OSIsoft's other websites use it.

HTTP/2 check:
https://http2.pro/check?url=https%3A//www.picloudservices.com/

As a PI Cloud Connect Subscriber, I would like annotations from the Publisher to be replicated so that I can have all of the information associated to the PI Tags

Prior to be able to adopt PI Cloud Connect, many of our customer cybersecurity teams request OSIsoft to provide SSAE SOC2 cybersecurity audit reports. Currently OSIsoft does cybersecurity audits, but these are not specifically SOC2 audits. This is a request to provide these audits that better fit into the industry trend seen at our customer base.

I am a subscriber who receives data from multiple organizations in different (>15) subscriptions. Due to needing the data to be located in different Data Archives as each is for a different business area, one instance of PI Cloud Connect should be able to write to multiple Data Archives, instead of just to the default data server on its node.

PI Cloud Connect currently scores an A from Security Headers. However, this can be improved to an A+ by addressing the issues in the link below.
https://securityheaders.com/?q=www.picloudservices.com&followRedirects=on

To help ensure that no insecure HTTP requests are attempted against picloudservices.com, please consider submitting it for HSTS preloading.
https://hstspreload.org/?domain=picloudservices.com

Before that can happen, some redirects must be set up. http://picloudservices.com should redirect to https://picloudservices.com, and https://picloudservices.com should redirect to https://www.picloudservices.com.

Since picloudservices.com is used for a much narrower purpose than osisoft.com, the barrier to submission for HSTS preloading should be much lower.

As an administrator, if I were to move my PI Cloud Connect nodes to new machines, I would like the ability to clean up my tenant portal by removing old system names that are still present.

When setting up PI Cloud Connect subscriptions it would be nice to specify the PI Data Archive tags get created on along with the AF Server and Database to create elements. In our case, we have multiple AF Servers that are linked to different PI Data Archives. Additionally, I don't really like that the default PI Data Archive gets used. What if a user were to accidentally change that?

Problems as:
- PI Cloud Connect node cannot connect to PI Data Archive,
- Account/Password has been expired (service not running properly),
- Publications not sending data,
and so on. Would be reported to administrators automaticky.

As a PI Cloud Connect user, I would like to screen receiving Vendors via their account, but by also by limiting connections to a specific IP or IP range for connections.

Allow history recovery for PI Cloud Connect to be longer than the current max of 30 days

Allow administrators the ability to configure the PI Cloud Connect agent on-prem to configure a group managed service account (gMSA) for the Windows Service account.

Use of a gMSA reduces IT burden since the rotation of credentials with strong credentials is handled automatically. Furthermore, gMSAs generally improve security as they are hardened by default.

As a PI Cloud Connect subscriber, I would like for PI tags that have been edited or deleted on the publisher end to be marked (renamed or otherwise) on my PI Server, so that I can tell when tags are no longer needed. This way, I can also determine if a tag is not updating because it has been edited/deleted, OR if the tag isn't updating because of a different issue.

PI Connect should auto-resolve the proxy settings, but then allow the administrator to either set them manually or update them.