Beginning in PowerShell 7 Preview 3, PowerShell will be sending some additional data points to Microsoft. This data will allow us to better understand usage of PowerShell and enable us to prioritize our future investments. These additional points of data were reviewed with the PowerShell community and approved by the PowerShell Committee through the PowerShell RFC process.
What we added
We will continue to use Application Insights to collect the following new telemetry points:
- Count of PowerShell starts by type (API vs console)
- Count of unique PowerShell usage
- Count of the following execution types:
- Application (native commands)
- ExternalScript
- Script
- Function
- Cmdlet
- Enabled Microsoft experimental features or experimental features shipped with PowerShell
- Count of hosted sessions
- Microsoft owned modules loaded (based on white list)
This data will include the OS name, OS version, the PowerShell version, and the distribution channel when provided.
We will continue to share portions of our aggregated data with the PowerShell community through the Public PowerBi report.
Why we added it
We want to make PowerShell better and believe this can be achieved by better understanding how PowerShell is being used. Through these additional data points we will get answers backed by data to the following questions:
- Is the PowerShell Core user-base growing?
- How is PowerShell being used? What is the usage distribution across command types and session type?
- How can we encourage PowerShell Core usage growth?
- What are issues that customers are hitting in PowerShell Core?
- What versions of PowerShell tools and services should Microsoft continue to support?
- Which experimental features are being used and tested? Which experimental features should we invest in?
- How can we optimize the engine size and efficiency of PowerShell for cloud scenarios?
To ensure we are getting an accurate picture of how everyone uses PowerShell, not just those most vocal/involved in the community, we made improvements in our telemetry. PowerShell usage telemetry will allow us to better prioritize testing, support, and investments.
Performance testing
When implementing this telemetry we took special care to ensure that there would not be a discernible performance impact. The telemetry is collected through Application Insights and is batched and sent on a separate thread in order to reduce impact. We also conducted tests to verify that there would not be a noticeable difference in PowerShell performance.
In order to test the performance impact of the telemetry we ran our test suite 5 times with and 5 times without the telemetry changes and compared the average time for test completion. The tests had a 1% difference in average completion time with the telemetry-enabled test runs actually having the faster average completion. The difference in average completion time, however, was not statistically significant.
We also tested the impact of collecting telemetry on startup time for both cold starts (first start-up of PowerShell) and warm starts (all future starts). We found that on average cold starups were .028 seconds slower with the additional telemetry while warm startups were, on average, .027 slower. The average performance impact was around 4% and all start-ups during the test runs performed faster than .6023 seconds.
How to disable
The telemetry reporting can be disabled by setting the environment variable POWERSHELL_TELEMETRY_OPTOUT to true, yes, or 1. This should not be done in your profile, as PowerShell reads this value from your system before executing your profile.
Feedback and issues
If you encounter any issues with PowerShell telemetry, the best place to get support is through our GitHub page.
In times with growing data privacy protection needs and laws, I think big enterprise environments will report nothing.
Please take care about an shifted view to Home use cases …..
enough with the spying alread, really, in all future products too (GDPR issues come to mind)?
POWERSHELL_TELEMETRY_OPTOUT to true, yes, or 1 is my new fav setting
Can you define ‘hosted’ session please? Is that so that you can detect the integrated terminal of the PS extension in VS Code or can you also detect a ‘normal’ terminal of PSCore in VS Code? Can you generally detect whether PowerShell is being run interactively or non-interactively (which would be an indicator for usage in an automation platform)? Not concerned, just curious.
Hosted sessions refer to any sort of remote sessions opened...we check for this data point here: https://github.com/JamesWTruher/PowerShell-1/blob/21ebb3e216dd5cc2e880e9914f1954c82ccf934e/src/System.Management.Automation/engine/remoting/client/RemoteRunspacePoolInternal.cs#L859
We plan to use the "distribution channel" data point to help us better track targeted/known tools that are hosting PowerShell, with the most obvious example being the PS extension in VsCode.
Currently we cannot detect whether a PowerShell session is interactive or non-interactive...although that is a question we are interested in and have been exploring (could show up...