Visual Studio 2019 - Cannot check for updated license

[khamilton2]

I am getting an error when trying to use Visual Studio 2019 community version on our VM/appstacks.

I am able to run VS2019 on our physical machines without having this issue.  This is after a fresh install.

Windows 10 x64 1909

View agent 7.12 & vcenter 7

Appvol agent 2.18.4

I did use the VMware OSOT which disabled NCSI.  I re-enabled that and set the reg keys in HKLM\Software\Policies\Microsoft\Windows\NetworkConnectivityStatusIndicator back to 0.  I thought maybe the issue with Windows thinking it had no internet access was the issue but even with the taskbar icon showing Connect & Internet Access now I still get the same error when trying to update the visual studio license.

I can sign in fine and it recognizes my account, but trying to "update license" always results in the same error "We could download a license, check internet connection and proxy settings"

Has anyone else had this or similar issue?  Is there some other network setting I may need to re-enabled that was turned off using the OSOT?

I have not tried to install it on a fresh plain base image yet but that will be next on the list for tomorrow.

[khamilton2]

A bit of follow up.

I went ahead and installed it on the base Image.  It works fine there.

I also was able to use it without any errors while it was being provisioned on the appprov machine.  As in I updated the appstack, while it was provisioning opened VS2019, signed in and grabed the license without issues.  However when I captured it again and attached it to a pool it was still giving the original error.

That leads me to believe its something related to appvolumes but I am not sure what right now.  We previously had VS2017 working on a appvol 2.15 appstack and windows 1803.

[domdsouza]

Do you have a writable and was there an update to it?

[Ray_handels]

Have not been able to get it working but this has got nothing to do with Appvolumes but with how Visual Studio works in general.

Even if you have a free version (which community is) it will create the license based on a hash of the computer name (or so it seems). We have tried community, professional and enterprise and all have the same issue.

Seems as if Microsoft doesn't want you to use Visual studio in a non persistent environment.

[Douglas42Adams]

So one can use DEdicated Instant clone pools where the pc name remains the same ?... ie not floaters . ?

thx .

[jhol5]

You can regenerate the hash that Ray mentioned by doing the following: https://docs.microsoft.com/en-us/visualstudio/install/automatically-apply-product-keys-when-deployin...

Automatically apply product keys - Visual Studio | Microsoft Docs

We elevated both the StorePID.exe and DDConfigCA.exe with DEM and run a post-import task. This can probably be replaced with an elevated task in DEM 2006.

I can post our script if you need help.

[Ray_handels]

Were you able to get it to work within an Appstack with this reactivation? Or do you still need to install it on the base image?

Because if that is the case for us it is still a no go unfortenately. We do not want Visual Studio within our GI.

[jhol5]

We have it in a AppStack.

Here is the script:

@echo off
if exist "C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\DDConfigCA.exe" (
>%USERPROFILE%\vs2017.txt (
timeout 3 /nobreak >nul
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\DDConfigCA.exe"
"C:\Program Files (x86)\Microsoft Visual Studio\2017\Enterprise\Common7\IDE\StorePID.exe" "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" "08860"
echo error level: %errorlevel%
)
)
if exist "C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\DDConfigCA.exe" (
>%USERPROFILE%\vs2019.txt (
timeout 3 /nobreak >nul
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\DDConfigCA.exe"
"C:\Program Files (x86)\Microsoft Visual Studio\2019\Enterprise\Common7\IDE\StorePID.exe" "XXXXX-XXXXX-XXXXX-XXXXX-XXXXX" "09260"
echo error level: %errorlevel%
)
)

[domdsouza]

What is this path in your install for Visual Studio Community 2019 build?

C:\Users\<userid>\AppData\Local\Microsoft\VisualStudio\16.0_xxxxxxxxx

I may have a fix for this.

[Ray_handels]

Just out of curiosity, is this with the Community edition because for as far as I know it does not have a PID key that I can enter.

Or is it like the KMS key that is freely available online?

My guess is that during packaging you should not activate the product, right?

[jhol5]

Oh right, we are deploying enterprise so the lines containing "StorePID.exe" can be left out.

[pchapman]

Is there anything else beyond running this script and adding those two items to privilege elevation you had to do to get this working?

I added privilege elevation for the two tasks, put the contents of your script in a file and set it to run as a post-import task.  The log file is created showing the ddconfigca.exe running and the error level 0 from storepid.exe, but when I launch VS2019 pro it says pre-release software etc.  If I run the commands manually from an admin command prompt they work as expect.  I'm stumped.

[Ray_handels]

We had the exact same issue that you are seeing. Apparently elevated commands cannot be run post import. What we did is create an elevation for both applications and created a shortcut in the startup menu folder that executed the script, this does work as intended.

Do keep in mind that it could take a while for the appstack to be assigned. I would suggest adding a pause in the script for executing or creating a loop for checking if both files exist.

We are using Visual Studio now as intended.