Highlighted
Contributor
Contributor

Visual Studio 2019 - Cannot check for updated license

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.

pastedImage_2.png

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.

12 Replies
Highlighted
Contributor
Contributor

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.

0 Kudos
Highlighted
Enthusiast
Enthusiast

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

0 Kudos
Highlighted
Virtuoso
Virtuoso

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.

0 Kudos
Highlighted
Enthusiast
Enthusiast

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

thx .

0 Kudos
Highlighted
Enthusiast
Enthusiast

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.

Highlighted
Virtuoso
Virtuoso

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.

0 Kudos
Highlighted
Enthusiast
Enthusiast

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%

)

)

Highlighted
Enthusiast
Enthusiast

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.

0 Kudos
Highlighted
Virtuoso
Virtuoso

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?

0 Kudos
Highlighted
Enthusiast
Enthusiast

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

0 Kudos
Highlighted
Hot Shot
Hot Shot

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.

0 Kudos
Highlighted
Virtuoso
Virtuoso

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.

0 Kudos