We get this error when attempting to run arccatalog and arcmap (see image attachment) on a virtual machine.
We are pointing to a machine that houses the concurrent use license manager.
The odd thing is that when running ArcGIS for desktop (Standard) 10.2 from a different VM that is pointing to the same license manager, we receive no errors. We can't figure out how to address the errors on the VM that has 10.3 installed.
We have another machine (not a VM - but a standard laptop) that has 10.3 installed and is pointing to the same concurrent use license manager and it runs just fine.
Any ideas?
Ben, *
We'll assume you have the ArcGIS Administrator -> Desktop panel radio buttons pointing to the correct flavor of concurrent ArcGIS as supported by your license pool, e.g. Basic (ArcView), Standard (ArcEditor), Advanced (ArcInfo). And that the License Manager field is populated with at least the FQDN for the license server, but better the port@FQDN
On the client Is the FQDN resolving to IPv4 or IPv6 DNS?
Any improvement if you disable the IPv6 service on the VM client?
Done with regedit in the:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\TCPIP6\Parameters key by setting a DisabledComponents DWORD (32-bit) value. And assigning a hex value "ff". This will force the client to work across IPv4 connections and should make the license exchanges with the server behave.
Simple to revert to allowing full IPv6 by deleting the new key.
Stuart
In case what Stuart mentioned doesn't help......if you are using Citrix XenDesktop, make sure you have a supported version. We ran into an issue since we were using an older version and had to keep those machines on 10.2.x until our network staff approves and installs the newer version (which is in progress for us).
full list can be found ArcGIS 10.3.x for Desktop system requirements—Help | ArcGIS for Desktop
Thank you for the helpful comments. Turned out it was a subnet issue that our IT people were able to resolve.
Ben, make sure to mark this thread as answered so it can be closed. you can mark it assumed answered if non of the responces answered it completely, typically you do not want to mark your own response as the answer....but if you elaborated with more details on the subnet solution, it may work for this thread.