Latest Contributions by MichaelJenkins

As for REST services, it is just the standard protocol that web applications use to access data.  Whenever you publish a feature layer item in ArcGIS Online, you are creating a REST service.   ArcGIS creates them for you. When you create an ArcGIS Enterprise site, you are hosting a mini-version of ArcGIS Online on your own equipment.  The main advantage of having ArcGIS Enterprise is that it can connect to resources you have on-prem.   Resources like imagery that you have on a file system, File Geodatabases, and most importantly Enterprise Geodatabases (SQL Server, Oracle, etc). There used to be a lot of other things you could only do in ArcGIS Enterprise and not in ArcGIS Online, like hosting imagery services, using a GeoEvent Server and more.   Esri has made many of those features available Online for an additional fee.  You can upload File Geodatabases to AGO, but you cannot connect to an EGDB from ArcGIS Online, so that is one of the key advanatages. There are also aspects of security that can be considered, but that is a pretty big topic on its own.  The main pioint there would be you can put ArcGIS Enterprise behind a firewall for additional security.   ... View more

Looking forward to these updates! ... View more

Yes, perfectly OK if the service is already deleted.    Delete from one level above what you ahve highlighted i.e. the folder that is named with the service name. ... View more

If you have an active pool of users who are currently using ArcGIS built-in accounts, you will have to migrate all their content and group memberships to their new accounts.    If you implement SSO, it will require new ArcGIS Enterprise accounts for your users.   You cannot convert an existing built-in account to an SSO account.  That is the part that you should plan for ahead of time.  You will also have to train / inform you users to click on the correct login button to use SSO rather than selecting the "ArcGIS login" and filling out a username and password. Just enabling SSO is quick and easy, and you can run both SSO and built-in accounts at the same time, so nothing needs to break when you enable SSO.       ... View more

I got a low disk space warning not too long ago and found over 150,000 temp files from ArcGIS Server going back over 3 years.   I was able to delete many of them and freed up about 100GB of space on the C drive. This article was helpful:  How To: Delete ArcGIS Enterprise Temporary Files (esri.com) It has info that applies to stand-along ArcGIS Server as well as other Enterprise components. For example, it shows this as one location where temp files can accumulate. C:\Users\<user>\AppData\Local\Temp Where <user> is the account that runs the ArcGIS Server service. Also very helpful in these situations is a little program called "TreeSize Free" which you can install on your server and run it to see the names and size of all the folders in your drive tree, including hidden folders that you don't normally see in File Explorer.   Another time we got a low disk space warning I used TreeSize Free and found another user had downloaded dozens of GBs of installation files into their "Downloads" folder, which is in their user profile directory and not one I would normally see or think to check.     ... View more

They will need to access more than just the specific map service URL, because they will need to be able to log in and that involves a couple of other URLs on the server. At a minimum they also need to be able to access https://myname.mydomain/arcgis/rest/login If by "Portal account" you mean ArcGIS Enterprise Portal, then that won't work for services on an unfederated server.  But if you just mean a built in account on the unfederated server, then yes I think that would work.  You can create a group, using ArcGIS Server Manager, add that user to the group, then secure the service, specifiying that group has access.   Then, any user account in that group can see/access the service (plus all admin accounts), even if it is just one user. No other changes to ArcGIS server related to the VPN/Firewall as far as I know.  No token needed since they will generate their own when they log in.         ... View more

You don't need to supply the 3rd part app with both username/pw and a token.  The token alone authorizes them to access services, and it is tied to the username that was used to generate the token, so that is how the server knows which content a user can access. Think of it this way - if you just go to the URL to the secured map service, the server will prompt you for a username and password.  Same thing if you go to https://myname.mydomain/arcgis/rest/login.  When you log in, it generates a token for you and stores it in a cookie for your browser.  Then each time you make a request to the server, it automatically includes that token in the header.  You can't see it unless you look for it, but it is sending that token with every request to the server.   So, the purpose of providing a token to another application is so that the appliation's user doesn't have to provide a username and password. You could just provide the username and password to the user of that application and when that 3rd party application tries to use the map service, it will prompt them to log in, then they log in and carry on their merry way.   It depends on what this 3rd party application can do and how many people are going to use it.  If you provide just the token, that application will need to know how to use it.  End users can't log in with the token directly. Also, since your server is behind the firewall,  you could just leave it as an unsecured service (anonymous access) and then no username, password or token would be needed by the 3rd party app.  That is as long as it is ok for people on your network to be able to see that service if they know where it is.  Since you have services directory turned off, the URL to the service can't be found by accident. That  may have been long winded, but I like to dig into the details. 🙂       ... View more

Hi Cody.   We have Enterprise set up in a very similar way to what you are describing in your OP.   We put all of the web adaptors on one web server in the DMZ and all the other servers for the multi-machine site are inside our firewall.  No VPN required for regular web access, but it is required for actually remoting into the servers for maintenance and updates. Having all of the web adaptors on one server is nice because you have the same root URL for all of the Enterprise component servers, and only one SSL cert is needed for all of them. ... View more