[FEATURE] Suppress Connect-PnPOnline warning for token cache

[LutzD-pkb]

Is your feature request related to a problem? Please describe.
When connecting using Connect-PnPOnline -PersistLogin, a warning prompt appears that you are using the token cache. It's rather annoying - I purposefuly provided the PersistLogin flag and do not need to be warned - and distracts from real warnings or errors.

Often times I'm working with bulk operations running against thousands of sites, so may see this warning thousands of times flooding the console or logs if I'm redirecting warnings for large operations.

Describe the solution you'd like
Provide a flag, either via an environmental variable or as an additional switch (e.g. SkipTokenCacheWarning) on Connect-PnPOnline itself, to suppress these warnings.

Describe alternatives you've considered
Using -WarningAction would be a band-aid, as it may suppress other (real) warnings. However, this is not possible due (see #5078).

[kachihro]

If you need to use PNP.PowerShell in a loop - it's best to register an AppReg. And - login ONCE - then 'useToken'.
https://pnp.github.io/powershell/articles/registerapplication.html

Here's a good blog - I'd had the same problems in a LOOP ;
https://kachihro.wordpress.com/wp-content/uploads/2025/02/image-2.png

https://kachihro.wordpress.com/2025/02/06/pnp-powershell-in-a-loop/

[LutzD-pkb]

If you need to use PNP.PowerShell in a loop - it's best to register an AppReg. And - login ONCE - then 'useToken'. https://pnp.github.io/powershell/articles/registerapplication.html

Here's a good blog - I'd had the same problems in a LOOP ; https://kachihro.wordpress.com/wp-content/uploads/2025/02/image-2.png

https://kachihro.wordpress.com/2025/02/06/pnp-powershell-in-a-loop/

A few notes:

• AppReg has a time and a place. It has a different risk profile than delegated authentication. While I may make use of it for certain scenarios, there are other scenarios where delegated permissions are a better fit (e.g., a site admin who is not a tenant admin, but administers a hub of sites). Or, perhaps there may be a global admin who would not consent to an AppReg with a broad permission set like Sites.FullControl.All.
• If the PersistLogin functionality is offered by PnP.PowerShell, it should behave in a sensible manner. If PnP.PowerShell with delegated permissions was not designed to handle long-running processes, then what was the point of PersistLogin in the first place?
• Using Get-PnPAccessToken instead of Connect-PnPOnline in a loop does not seem efficient. Access tokens only live for 60-90 minutes with the default Entra configuration, and as I understand it, Connect-PnPOnline internally caches access tokens to not require multiple login prompts automatically, but also re-prompts the user for authentication if needed. Basically, it does what you are trying to accomplish with Get-PnPAccessToken already internally, plus handles more scenarios.

[reshmee011]

Can you please try with latest build as #5078 is fixed.

[gautamdsheth]

Closing this as it has been fixed by @reshmee011 in the latest nightly builds. It will also be available in the next major version when we release it.

[LutzD-pkb]

@reshmee011 @gautamdsheth this feature request is different than #5078, can you please re-open?

That was for the PersistLogin parameter to honor $WarningActionPreference. That means in order to suppress this warning, I must suppress all warnings from the Connect-PnPOnline command.

My feature request is different - it is requesting that this specific warning message does not make sense in many contexts, and instead requests the ability to not generate the warning, rather than having to suppress the entire warning stream.

[reshmee011]

I’m reopening this issue. I understand the requirement, but honestly, I’m not sure how to resolve it yet.

[KoenZomers]

@LutzD-pkb Very valid point. We've moved the message from being a warning to it being a verbose logged message instead.

Code change will be merged through #5219 and available from the next nightly build onward.