Hi @ben-spiller,

Thank you for reaching this out!

GitHub hosts Linux and Windows runners on Standard_DS2_v2 virtual machines in Microsoft Azure (doc here). The configuration including port is consistent.

checked on Github:

image751×255 9.21 KB

Checked with Azure ‘windows-2019’ machine:

image881×229 13.8 KB

Thanks

Thanks for looking into this!

I just created a win2019 machine myself in azure (“Windows Server 2019 Datacenter”)
and it’s using the standard IANA range:

Protocol tcp Dynamic Port Range

Start Port : 49152
Number of Ports : 16384

The MS docs for dynamicport are a bit sketchy but https://support.microsoft.com/en-gb/help/929851/the-default-dynamic-port-range-for-tcp-ip-has-changed-in-windows-vista seems to indicate the same IANA port range (dynamicport for 19152+) for modern windows versions (see the “applies to” which includes 2019).

I wonder why you’re seeing something different. How exactly did you create your win2019 Azure machine where you saw the 1024+ dynamic port range? Did you tick any non-default options? I did: “create a virtual machine”, selected my region (UK South), image=2019 gen1, size=DS1_v2 (DS2 option was not available), inbound port rules=allow selected (RDP i.e. the default). But I doubt any of those would make a difference to this.

I don’t suppose anyone reading this knows someone in the Azure or Windows Server teams who might be able to shed light on why some machines seem to have a different out-of-the-box dynamicport configuration?

Hi @ben-spiller,

Thanks for your reply!

No special setting on my azure pipeline, just select windows-2019 and use a powershell script to get the info, this will use hosted vm for checking. (didn’t create VM)

image983×388 13.9 KB

Powershell script:

netsh int ipv4 show dynamicport tcp
echo ------------------
systeminfo | findstr /B /C:"OS Name" /C:"OS Version"

Could you please check on your side?

Thanks

Hi, @ben-spiller
We generate images for GitHub and Azure Pipelines using the https://github.com/actions/virtual-environments repository.

After installing VS via script https://github.com/actions/virtual-environments/blob/2602d388778a3626a5cba3f332bbf4283b4a5fa2/images/win/scripts/Installers/Install-VS.ps1 the dynamic port range is changed to:

Protocol tcp Dynamic Port Range
    vhd: ---------------------------------
    vhd: Start Port      : 1024
    vhd: Number of Ports : 64511

Example https://github.visualstudio.com/virtual-environments/_build/results?buildId=78654&view=logs&j=011e1ec8-6569-5e69-4f06-baf193d1351e&t=486c0909-f67d-5748-80b3-bb1d531e7b43 :

Before Visual Studio installation [703]:

==> vhd: Provisioning with powershell script: C:\agent\_work\9\s\images\win/scripts/Installers/Install-VS.ps1
    vhd: Display ports
    vhd:
    vhd: Protocol tcp Dynamic Port Range
    vhd: ---------------------------------
    vhd: Start Port      : 49152
    vhd: Number of Ports : 16384

After [825]:

    vhd: Display ports
    vhd:
    vhd: Protocol tcp Dynamic Port Range
    vhd: ---------------------------------
    vhd: Start Port      : 1024
    vhd: Number of Ports : 64511
    vhd:

We are currently discussing to revert ports to the default values or update the documentation (https://github.com/actions/virtual-environments/blob/2602d388778a3626a5cba3f332bbf4283b4a5fa2/images/win/Windows2019-Readme.md) about that moment.

Great thanks for doing that analysis!

Wow this is quite surprising that installating Visual Studio 2019 seems to have changed the machine’s dynamicport TCP configuration. I couldn’t find any VS documentation about that, it smells like possibly an unintentional change/bug?

Either way I guess the https://github.com/actions/virtual-environments/blob/9110b389998666dc0c6a8e9abd9400248bad8dba/images/win/scripts/Installers/Install-VS.ps1 could perhaps revert back to the default Windows configuration to avoid surprising people with this more limited TCP configuration that’s not good for server processes.

Anyway thanks for looking into it, I look forward to hearing what you come up with :slight_smile:

@ben-spiller, I have prepared the actions/runner-images#1442 PR to revert the default value.

Awesome thanks, I’ve removed my workaround and now it’s working as expected. Thanks for the quick turnaround :slight_smile:

Seems quite dodgy that Visual Studio is changing the machine’s TCP config in this radical way (without any documentation I’m aware of to let user’s know) but I guess that’s a problem for someone else to solve