Update check stills runs on startup despite disabling

[MrSoxAndShoes]

Prerequisites

• Write a descriptive title.
• Make sure you are able to repro it on the latest released version
• Search the existing issues.
• Refer to the FAQ.
• Refer to Differences between Windows PowerShell 5.1 and PowerShell.

Steps to reproduce

I have 7.2.6 installed on a Windows 2019 Server with no Internet connection and even after adding the UPDATE and OPTOUT system environment variables, PS7 still attempts to contact ctldl.windowsupdate.com upon startup, delaying the command prompt anywhere from 3-10 seconds.

COMPlus_EnableDiagnostics=0
DOTNET_CLI_TELEMETRY_OPTOUT=1
DOTNET_TELEMETRY_OPTOUT=1
POWERSHELL_CLI_TELEMETRY_OPTOUT=1
POWERSHELL_DISTRIBUTION_CHANNEL=MSI:Windows Server 2019 Standard
POWERSHELL_TELEMETRY_OPTOUT=1
POWERSHELL_UPDATECHECK=Off
POWERSHELL_UPDATECHECK_OPTOUT=1

Expected behavior

Immediate access to the command prompt after starting PowerShell.

Actual behavior

Upon startup, a delay of 3 - 10 seconds after the logo info is displayed until the command prompt becomes accessible.

Error details

No errors.

Environment data

Name                           Value
----                           -----
PSVersion                      7.2.6
PSEdition                      Core
GitCommitId                    7.2.6
OS                             Microsoft Windows 10.0.17763
Platform                       Win32NT
PSCompatibleVersions           {1.0, 2.0, 3.0, 4.0…}
PSRemotingProtocolVersion      2.3
SerializationVersion           1.1.0.1
WSManStackVersion              3.0

Visuals

No response

[dkaszews]

Are you sure this is caused by the update check? Startup delays can be caused by a lot of things, like a heavy $PROFILE you can check by running pwsh with -NoProfile.

[MrSoxAndShoes]

Good questions. No, I'm not sure but it's my suspicion. I also don't have a $PROFILE.

I just tried this on two other servers (let's call them B & C) without an Internet connection but their behavior is inline with what we would expect. Before setting the opt-out variables, they both contacted aka.ms upon launching. After I added in the opt-out variables, they don't.

Note this attempt to connect "aka.ms" on servers B & C is different from server A which is trying to connect to "ctldl.windowsupdate.com" and that may be the source of the problem.

I don't know how or why they're different – except I created B & C from scratch whereas A was created by another SA. I wonder if they're setting up Windows Update differently and maybe that bypasses the PWSH update check?

[breakwaterlabs]

I can confirm that this happens, with a clean profile, on Server 2022 VM with pwsh 7.3.4

pwsh -nop             # takes 3-5 seconds to load; dns pings to ctldl.windowsupdate.com
pwsh -nop -noni       # loads instantly with no dns queries

This issue has been reported in the past and there is even a microsoft article on this.

TL;DR this appears to be related to certificate checks on signed powershell modules. In my case I have only the default RSAT modules available but that appears to be enough to trigger the calls to ctldl.windowsupdate.com. Changing the recommended GPO setting (Windows Settings / Public Key Policies / Certificate Path Validation Settings / Network Retrieval) to suit our environment did prevent those calls, and substantially resolved the slow startup.

The question remains why the loading of pwsh itself is delayed while these checks for modules are performed. It seems to me that correct behavior would be for pwsh to load what it needs to return an interactive prompt, and then if it needs to check modules and their metadata it can do that in the background.