Latest Contributions by RandallWilliams

Hi Lloyd, Don't fret! I think we can address this. Every machine on a network has a private IP address called a 'loopback address' with the name 'LOCALHOST' that resolves to IP 127.0.0.1. This is why your services are visible on your server - you're telling the browser to look at LOCALHOST for the service resource. Now, because you don't have ArcGIS Server running on every machine on your network, nobody can see your service. Think about it like this: Assume you have a gold bar in your pocket. You send out an email to your office telling them 'you have a gold bar in your pocket'. Everyone gets excited and checks their pockets, but they don't have any gold. Instead, you send out a new email saying 'Lloyd Bronn has a gold bar in his pocket'. Now everyone flocks to you to marvel at your fortune. In this case, we need to do the same thing with how you've referenced your service in ArcGIS.com - we need to tell it to not look at 'LOCALHOST', but instead to your GIS Server name - which I'm betting folks on your network can 'see'. To to this, you can right click on 'My Computer' on the server and go to properties, and get the full computer name. For instance, on my server the full computer name is 'randallsserver.esri.com'. (that's not the real host, I've obfuscated that in the screen cap below). So, instead of adding the service to ArcGIS.com as http://localhost:6080/arcgis/rest/services/myservice/mapserver, you'd add the service as http://yourmachinename.yourdomain.com/arcgis/rest/services/myservice/mapserver. That should fix it. Essentially, instead of telling everyone to look on their own machines for the service, you're now telling them to look at your server for the service. You don't have to have an externally accessible .com domain - mine's not. Hope that helps!! ... View more

I believe that this is an issue with Chrome v 52. I also believe that Chrome has committed to fixing this in the next update. ... View more

To add to Anthony's comment: "My issue is this: I can view the data with attachments on the web app from the web browser on the server. If I view the same page on the web browser on other computers, I can't see the data." My guess is that you're referencing your services using http://localhost/arcgis/rest instead of your server's Fully Qualified Domain name. In any case, the issue is that the other machines on your network can't resolve to the hostname that was used when you added your service as items to 'My Content' on ArcGIS.com. ... View more

Hi Marc, We've done some testing along these lines in house and haven't been able to reproduce this issue. Have you logged a case with Esri Support Services describing your environment? ... View more

I'm surprised by this response as well. I've heard of issues related to IPv6, but not subnets explicitly. I'd update the FlexLM_Timeout environment variable on the clients. Which version LM are you working with? If you haven't updated to the 10.4 version, I'd do so (for security reasons). The LM is backward compatible to previous versions of ArcGIS Desktop software. See also: Error connecting through VPN to Arcgis License Server - Community Contributions - Hermes ... View more

Is Google Earth maybe looking for a URL to the capabilities document? http://localhost:6080/arcgis/services/WIP78Mosaic/ImageServer/WMSServer?request=GetCapabilities&service=WMS ... View more

I'm pretty sure that this is an ArcGIS.com property. I don't have this one my servers, and the example you're pointing to is an ArcGIS.com tile server. ... View more

Hi Joanna, Can you step me through your workflow? ... View more

Are you registering a UNC path or a local path? EG: \\server\share or c:\path\to\data ? ... View more

@Rebecca the 10.2.2 patch is now live ArcGIS for Server Security 2016 Update 2 Patch ... View more

Hi @Karyn Tareen, The DOC team confirmed that there were issues migrating this document and are working on addressing this. Meanwhile, I've pulled the raw content from our KB management system and have posted the details below. Sorry for the inconvenience. Problem: After upgrading to ArcGIS 10.4 for Server, existing services that use data in geodatabases in SQL Server no longer work Description After upgrading ArcGIS for Server to version 10.4, services that consume data in geodatabases in SQL Server 2008 or 2008 R2 no longer function. ArcGIS Server logs show messages indicating "Connection was attempted with an older version of SQL Server client communications software that is not supported." Cause Beginning with ArcGIS 10.4, SQL Server 2008 and 2008 R2 are no longer supported. Solution Upgrade to SQL Server 2012 or SQL Server 2014, which are supported at ArcGIS 10.4 Customers who must continue to have access to their SQL Server 2008 or 2008 R2 geodatabases while planning their upgrade to SQL Server 2012 or SQL Server 2014, can upgrade the SQL Server client on the ArcGIS for Server machine to SQL Server 2012 Native Client or Microsoft ODBC Driver 11, and restart the ArcGIS Server Windows service. ** If a customer has moved to ArcGIS 10.4, but has connections to older geodatabases in SQL Server 2008 and 2008 R2, Esri Support will attempt to reproduce the issue with SQL Server 2012 or SQL Server 2014. If the issue cannot be reproduced on a supported version of SQL Server, the customer will be asked to update their version of SQL Server. Also, customers who move to ArcGIS 10.4 but are still using SQL Server 2008 or 2008 R2 will not be able to create a new geodatabase until they upgrade SQL Server to a supported release. Related Information: Microsoft SQL Server database requirements for ArcGIS 10.4 Connect to Microsoft SQL Server from ArcGIS   Manage connections in SQL Server ... View more

Yes, a lot of links were broken when the support site was recently updated. I'm working with the content team at Esri to find out where this doc went. I'll follow up... ... View more

Whelp, color me schooled! ... View more