ArcGIS Pro Named User Licenses and computer labs

[MarkWinek]

Is there a way to deploy ArcGIS Pro in a shared computer environment, such as a computer lab, and have users rely on their Named User Licenses from ArcGIS Online? I don't have access to a license server, so I can't use Concurrent Use licensing.

[AmnoyAm]

Mark,

You can run the install silently using the following syntax:  

msiexec.exe /i <Path to msi> /qb ALLUSERS=1 SOFTWARE_CLASS=Professional AUTHORIZATION_TYPE=NAMED_USER License_URL="www.arcgis.com"

You can find addition information concerning silent install in the following document:

Localized and silent install options—ArcGIS Pro | Documentation 

[PeterKnoop]

Below is an example of the silent install options we use in many of our computer labs. Since you are using Named User licensing, you can point to your organization's ArcGIS Online instance, rather than the generic www.arcgis.com, to potentially save users steps logging in. This is especially handy if you have configured your instance to use Enterprise Logins for users, and configured Enterprise logins as your only login option. Then your users are sent straight to your single-sign-on dialog when they start-up Pro, rather than having to fill out Esri's generic login dialog and find their way to your organization.

msiexec.exe /i <path to installer>\ArcGISPro.msi \

ALLUSERS=1 \

SOFTWARE_CLASS=Professional \

AUTHORIZATION_TYPE=NAMED_USER \

License_URL="https://<your org>.maps.arcgis.com" \

Portal_List="https://<your org>.maps.arcgis.com" \

CHECKFORUPDATESATSTARTUP=0 \

LOCK_AUTH_SETTINGS=TRUE

One important note: make sure you specify the parameters in the order presented above!

(The installer for ArcGIS for 2.4.2, and maybe any 2.4.x, introduced a bug whereby it does not properly parse the command line arguments, so re-arranging them can cause unexpected failures. For example, if you construct your command line in the order in which the parameters are explained in the documentation, then the installer will report success, however, the settings you specified will not be applied correctly, and you will get errors or unexpected behaviors when you try to login to Pro.)

[MarkWinek]

Hi Peter,

Thank you! Forgive the ignorant questions, but do you have any problems with Pro remaining logged in for a specific user after they're done with using the shared computer?

[PeterKnoop]

Hi Mark,

Not in an unexpected way. Pro caches the info from a successful login, so a user doesn’t have to login every time they start Pro. Once the authorization times out, however, they will have to login again.

That auth info is cached in the user’s profile, so if you’re not deleting it from the profile — or deleting that user’s profile itself —after the user logs out of the shared machine, then it will still be there the next time they login to use that machine. 

[MarkWinek]

Peter,

That's very helpful. It makes sense that if the user's login is cached, they won't have to log in again on that computer while the authorization is current. The concern our folks had was that a user might sign in to Pro, then log out of the shared machine. When another user logs in to the shared machine, Pro would still recognize the previous user.

So in your lab instances, when a user opens Pro for the first time, they still have to navigate to the right place in the application to log on, correct? Or does it automatically pop up upon initial program start with your Enterprise login? 

[PeterKnoop]

Hi Mark,

As long as each user using the shared machine is logging into the machine with their own Windows account, then there should not be any problem.

The ALLUSERS=1 parameter in the installer options shared above, installs ArcGIS Pro in a single location, and makes it available to all users on that machine. When each user runs ArcGIS Pro, their user-specific settings for Pro -- such as their cached authorization info -- is stored in that user's Windows profile, so that only that user's Windows account has access to it. 

If the users of your shared machine are all logging in using the same Windows account, then it would be a problem. They would be accessing the same Windows profile, so whomever last logged into to Pro on that machine would have their Pro authorization cached in that Windows accounts' profile.

-peter

[AmnoyAm]

Mark,

Each user on a single machine will have his/her own profile.  User A's login detail will not affect User B.  In your scenario, let's assume User A opened Pro using a specific account from AGOL.  Without shutting down Pro, another user logs in on the same machine and starts Pro.  The user will be prompt for an AGOL login account.  The user can then log into Pro using another AGOL account that was previously granted Pro licenses.  In this situation, User A started Pro using one account and User B started Pro using another AGOL account.  

Hope that cleared up any confusion.