Latest Contributions by RyanUthoff

The ArcGIS Data Store is completely independent of your database servers (MSSQL, PostgreSQL, etc.). So it is certainly not mandatory for them to be installed on the same machine. In fact, it's best practice for them to be installed on separate machines for workload separation purposes (so the Data Store and DBMS don't have to share resources). The ArcGIS Architecture Center can provide some good resources on how to architect your ArcGIS Enterprise deployment. https://architecture.arcgis.com/en/framework/architecture-practices/introduction.html ... View more

Perhaps "working as designed" per Esri's documentation might be a better way to put it.  I'm not disagreeing with you, because it's misleading and easy to misunderstand unless you read Esri's documentation to get an understanding of how it works. I believe others have been in this situation, which is why some ArcGIS Ideas that David linked above have already been submitted for Esri to improve this. If the map image and feature layer truly are dependent on each other, then I think it would make sense for the permissions to be "linked" to each other. Meaning that if you change permissions to one, it forces you to change permissions to the other (perhaps giving you a pop-up message stating that). Otherwise, as you've encountered, it's misleading when the permissions in Portal state one thing, but in practice, are actually something else. ... View more

There might be more elegant ways of doing it, but you could just modify the script you linked to export all 25 attachment tables at once. Just copy and paste lines 5-17 over and over again, and just modify your inTable and fileLocation variables. Notice how I changed inTable1 = arcpy.GetParameterAsText(0) in line 5 to inTable2 = arcpy.GetParameterAsText(3) in line 19. You'll also need to change the corresponding variables that are referenced in the code as well. And then when you create your tool, you'll just create 25 user inputs. If your output location is going to be the same for every attachment table, you would just create that variable once and wouldn't have to create a copy of it for each attachment table. import arcpy from arcpy import da import os inTable1 = arcpy.GetParameterAsText(0) fileLocation1 = arcpy.GetParameterAsText(1) with da.SearchCursor(inTable1, ['DATA', 'ATT_NAME', 'ATTACHMENTID']) as cursor: for item in cursor: attachment = item[0] filenum = "ATT" + str(item[2]) + "_" filename = filenum + str(item[1]) open(fileLocation1 + os.sep + filename, 'wb').write(attachment.tobytes()) del item del filenum del filename del attachment inTable2 = arcpy.GetParameterAsText(2) fileLocation2 = arcpy.GetParameterAsText(3) with da.SearchCursor(inTable2, ['DATA', 'ATT_NAME', 'ATTACHMENTID']) as cursor: for item in cursor: attachment = item[0] filenum = "ATT" + str(item[2]) + "_" filename = filenum + str(item[1]) open(fileLocation2 + os.sep + filename, 'wb').write(attachment.tobytes()) del item del filenum del filename del attachment   ... View more

I'd recommend using Esri's System Log Parser to get some more granular results than what ArcGIS Monitor provides. There are a lot of rabbit holes you can go down when trying to figure out what to do next. I'm of the opinion that adding resources should be the last option to do after we've explored all other options first.  You didn't include your DB servers (assuming you're using some type of DBMS and not solely using ArcGIS Data Store). Your DB server will absolutely have an impact on your Enterprise performance. If it is maxed out on resources, then that's probably your problem. But it might not be your entire DB server, it could be some inefficient DBs and/or tables. That is the beauty of System Log Parser. It will give you statistics down to the individual layer level on the average response time, number of requests, etc. Hypothetically, for a feature service, you might see 1-2 second response times for all layers except for one, which takes 15 seconds. With that information, you can target that layer (and underlying table in the DB) for optimization. Also, at the feature service level, it will also give you wait time, which is the amount of time is spent waiting for a feature service instance to become available to process requests because the max number of instances has been reached. You can also use wait time to potentially increase the maximum number of instances allocated to a feature service. You also didn't include your server resource usage. Are all your servers resources alright (like CPU/RAM)? Or are they maxing out when your issues are happening? If resources are maxed out, that could be a sign that that is where you're hitting your limit and you need to increase your resources on the server machines. There's definitely a lot of things to check. But in my experience, adding resources is often not the "correct" solution, and instead, it's poorly optimized DBs, tables, etc. ... View more

I might not be fully understanding your question, but if you're trying to share S123 forms with a distributed collaboration, then it's not supported. https://enterprise.arcgis.com/en/portal/11.3/administer/windows/share-content-with-collaboration-participants.htm But I still don't think I'm fully understanding. Are you trying to share forms between AGOL and Enterprise? ... View more

I'm also not a full-fledged DBA, but you can check and see if an index is fragmented. If it's fragmented, then that means it's not going to function as efficient as it could be. This site has information about how to find fragmented indexes in SSMS. You can also follow some best practices and rebuild your indexes on a regular basis, which you can do either through Esri or SSMS. ... View more

The biggest gotcha I can think of right off (which might not necessarily be a gotcha, but something to be aware of) is you'll need to work through your hostname resolution dealing with your public URLs. If your original environment is going to stay online during the migration, you might need to do some hostname resolution stuff until you're ready to make the cutover to your new environment. Of course, this all depends on how your current environment is configured. This blog post does a great job of explaining what you need to do when using WebGISDR to restore to a new environment. https://www.esri.com/arcgis-blog/products/arcgis-enterprise/administration/migrate-to-a-new-machine-in-arcgis-enterprise-two I'm not 100% sure on your last question. I want to say that you could use Enterprise/Cloud builder and then do a WebGISDR restore to it. I mean, using those builders shouldn't prevent you from doing a WebGISDR, so I'm thinking it would be fine, but I've also never been in that specific situation before. Edit: To add on, the WebGISDR is at the software level, not server/cloud level. So I can't imagine there being any issues or gotchas when using WebGISDR to go from AWS to Azure. I'd imagine it would be more configuration related things at the server/cloud level and not the Esri level. ... View more

I've never had the need to try it because of how long the lifespan of certificates are at the moment. It's more time efficient to do it manually than to create a Python script to do it. I just did a quick search and found that and thought it might be helpful for you (and possibly me in the future as well). ... View more

Thanks for posting that information! I was not aware this was happening. Would this meet your requirements? https://support.esri.com/en-us/knowledge-base/how-to-import-certificates-to-arcgis-server-and-portal--000029033 ... View more

Awesome, thank you! And I appreciate you taking the time to clarify that information for me. I've been looking forward to a tool like that for a long time. We collect a lot of photos in S123 but even after deleting them, the space isn't released back to the OS and it's not sustainable to keep on adding and adding HDD space. We're able to connect to the data store PostgreSQL DB directly and do the vacuum in PGAdmin, but we'd prefer to do things in the more "Esri approved way" and it's good to know there is now an official tool that will do it for us. Thank you! ... View more

Hmm, I'm not sure if that is related to your issue or not. What I'd recommend doing is try and correlate this error message when receiving the error in S123. So if you can, try and submit a S123 form that will result in an error, and then check the log again and see if you see this same error message at the same time you submitted the S123 form. If you receive the same log message at the same time you submitted the S123 form, then that error is probably related. Unfortunately even if it is related, I'm not sure what that means as far as fixing it, but at least it would give you a little more information to work with. ... View more

I do not believe it is possible to export shapefiles in Experience Builder. I just looked and do not see any options to export to shapefile, nor do I see anything in their documentation. Someone already created this idea for Esri to implement as well. https://community.esri.com/t5/arcgis-experience-builder-ideas/extract-data-widget-in-experience-builder-for/idi-p/1404337 Of course there are workarounds to that, but if that's not what you're looking for, then it's not possible. ... View more

This might be a long shot, but what about the underlying PostgreSQL logs? The ArcGIS Server logs will only show log entries from the ArcGIS Data Store service, but not the underlying PostgreSQL database the data store runs off of. I've found and resolved multiple S123 issues by looking at the PostgreSQL logs directly. The location should be here: C:\arcgisdatastore\logs\machine name\database ... View more