Latest Contributions by ScottFierro2

‎06-06-2017

Did you download the map for offline use?

‎06-06-2017

Are you taking your maps to offline mode? If so, then the first thing you should do is check your server to ensure the 10.5 patch for Sync Update has been applied to the server. Download the patch finder utility here (tells what your system has installed): https://community.esri.com/external-link.jspa?url=http%3A%2F%2Fdownloads2.esri.com%2FSupport%2Fdownloads%2Fother_%2FPatchFinder.exe Download the patch here: http://support.esri.com/Products/Enterprise/arcgis-server/ArcGIS-GIS-Server/10-5#downloads?id=7503 While I can't say this is the messaging we have seen we have found that occasionally the local iPad can keep a previous replica GUID cached and it causes a sync issue because matching replica GUIDs can't be found between the device and server. In these cases we've found doing a hard shut down of the Collector App on the device, re-logging in and syncing has resolved the issue 99% of the time. In some rare cases we've also discovered that updates to the local device causes issues. If working in offline mode and the device has maps downloaded to it ensure there are zero iOS or Collector App updates performed on the device. We've begun training for this now once we figured out it was an issue. Essentially, if the device has a map for offline use on it and the user chooses to perform an iOS update OR chooses to update the Collector App then there's a chance these updates causes issues with the replica on the device (SQLite database on the iPad). These issues would render the local device incapable of performing the sync because the replica no longer matches what the server has. In these cases you have to look into recovery options to get the data off the iPad or if you are lucky some edits might have made it to the server and just not pushed back to your enterprise DB in which case you can try to extract the data from the runtime databases http://desktop.arcgis.com/en/arcmap/latest/tools/conversion-toolbox/copy-runtime-geodatabase-to-file-geodatabase.htm

‎05-30-2017

a.commeford Sounds as though your Feature Service isn't properly configured. If the deletes are working/going through but updates/new features are not check your service to be sure those capabilities have been properly enabled. In the screenshot below have circled the items you need to be sure are checked. Sounds like all your service has checked to be available is "Query" and "Delete". Here is an example:

‎05-30-2017

So something else I forgot about that we did see not to long ago and have identified as an issue. How do you manage/control user ability to update the device OS as well as the Collector App? I can't say that we have seen an issue yet with iOS updated but we have with the Collector App. Since you mentioned some services and devices were working the issue may be specific to a particular user/device. If that is the case the lesson we learned is that if the user has "offline maps" on the device, performs an update of the Collector App, then later tries to sync the data back it will not work. The reason is that during the application update something occurs with the SQLite DB on the device. From error logs and various tests we have tried it comes through as if the replicaID on the device no longer matches what's on the server. Since no match is made the device can't use the replica to sync edits back to the enterprise DB.

‎05-25-2017

To this day this is still unsupported. ESRI's answer for these scenarios for about the last year has been to use Portal or ArcGIS Online to assist with "complex authentication" needs. I built a workaround soon to be published that allows this all to work but ESRI still will state that it is unsupported which is valid because there are 2 somewhat annoying trickle down impacts of implementing this workaround. We have vetted it in 10.2, 10.3.1 and 10.5 and it worked in all of them with the same behaviors. Can also confirm that while it works and can be used if used in conjunction with Collector there are significant performance hits on feature service load times due to the use of Web-Tier authentication over GIS-Tier. The publication is undergoing edits now and is planned to be released by UC. If you'd like a PDF copy sooner send me an email and I can get it over.

‎05-24-2017

Have done this twice now using a GoDaddy wildcard cert same name, etc. and we have done these during off hours, delete existing and import new via Server Admin as well as local server in mmc.exe (we have 1 environment this is necessary on but adopted it for all environments as our own best practice as a fallback in case SSL offloading has an issue). Odds are your root and intermediate certs exp dates are still way far off and you probably only need to do this for the wildcard but always good to check and confirm so that your cert is fully qualified and you don't have a broken path.

‎05-09-2017

I'd reach out to ESRI to not lose valid user collected data. If it's in the runtime gdb it's most likely recoverable and they should be able to assist with the running of that tool. As far as what went askew on this single data set(s) it is hard to say since it sounds like other things are working so then odds of it being a networking or system configs issue is minimal. It does point to some minor piece that is off and may still be able to correct but across 4 pieces of a 5 piece architecture (DB, ArcServer, Web Server, AGOL, Collector App) there are enough possibilities its throwing darts to try and hit. So walking back through from the DB and moving up the architecture piece by piece will be the only way to pinpoint. As for Enterprise its about as Enterprise as anything else from ESRI. It covers and does a lot but probably not all things that many of us want it to do. We architect work arounds and back doors to what ESRI is doing constantly to meet bigger complexities we have or want. I can say we use Collector across 6 data sets to date with another 10-15 on the calendar thus far across 500+ users spread across the state using 400 iPads and its meeting and exceeding most needs from users/business units. That said certainly room to grow and we will keep pushing and punishing it as much as we can.

‎05-09-2017

Interesting so thought I had an idea until you said you have others that are working just fine. Want to be sure that means you have other Feature Services on the exact same ArcServer which you are actively able to edit in AGOL? If the above is true then as much as I hate to say it I'd consider replicating things through as copies from the ground up. By this I mean I'd go back to the DB make a new version of the tables configured for archiving/versioning, etc. build a new MXD, feature template, publish a new service with different name. Eliminate chances for some minor thing that got missed somewhere that's causing this behavior. If the above is false then the possibility for network or system configuration issues is still possible. One last item to consider, launch your AGOL edit session into Chrome, hit F12 and choose the Network tab, make your edit(s) and then save the edits and watch for any message that are not 200 status. That will help to begin troubleshooting if there is some networking/system config issues.

‎05-09-2017

So guess as step 1: Log into Server Manager and confirm the sync service is started and has available instances running. Step 2: Can you make edits in AGOL, save them, close the browser, go back in and see the edits? If not, then your issue is tied to the communications between AGOL and your backend so you'd need to examine what you pushed into AGOL. If yes, then can check next. Step 3: If its allowing you to properly make live edits then all the pieces between AGOL, ArcServer and SQL DB are working correctly so the issue is specific to offline usage. Log into your REST services page and navigate to the Feature Service you are trying to use. At the bottom select the "Replicas" option. (URL looks like this: http://<servername>/arcgis/rest/services/<folder>/<service as FeatureServer>/replicas) Confirm that there are replicas being generated (these are the geodatabases stored on the server that match the SQLite DB's loaded to the users device at time of download or last sync) If this page is blank then there is something wrong with your server configs that isn't actually building the ArcServer pieces necessary to match what the user is taking offline. If there are replicas here you can follow the directions on this site to confirm the edits that were being made in offline mode on the device actually made it back to these replicas. http://desktop.arcgis.com/en/arcmap/10.3/tools/conversion-toolbox/copy-runtime-geodatabase-to-file-geodatabase.htm If they did then it's time to call ESRI or perhaps someone else can assist because if the edits made it that far and simply didn't post back to your SQL DB aside from the Sync service we already checked above I can't say what the issue is. Not knowing your backend configuration I can tell you 1 thing we saw (granted this was 2.5+ years ago) that might fit this. We used the Web Adaptor on an IIS web server VM in our DMZ with our Arc Server on a separate VM server behind the internal firewall. I put 6 testers in a room after they had collected 20 records each with between 1 & 5 pictures per record. I had them all hit sync at the same time. The primary bottleneck was by far the Web Server RAM. We had 2 of the 6 testers fail to sync but all they saw was a message that said something like "failed to sync" on the device and there was no good logs or anything else to determine the issue. Re-conducted the test while watching all servers performance in the environment and was able to identify the RAM spikes. Increased the RAM and re-tested and all users had successful syncs.

‎05-09-2017

So to answer your immediate question I would download the Server Admin Toolkit from this site https://www.arcgis.com/home/item.html?id=12dde73e0e784e47818162b4d41ee340 While that will answer your issue for renaming I am not sure it will correct your issue. Sounds like JQuinn-esristaff‌ is heading down the same path I would so I will let him assist because it sounds as though there is an artifact floating in your directory folders still that is preventing you from publishing with the same name.

‎05-05-2017

This is really 2 different questions: 1 for SQL DB and the other for ArcGIS for Server. With regards to SQL, this is kind of right. So in order to do the initial configurations there is a requirement of being admin however not of the entire server and even the admin that is needed can be altered to further limit you down while boosting IT warm-fuzzy. Not knowing how familiar you are with SQL Server here are some basics. SQL Server is a software install that resides on a server that is probably running Windows Server as its Operating System (OS). The user that is the admin over the entire server (windows) does have control over the SQL Server. However, the SQL Server instance has its own structure of accounts and there is a designated admin user over the entire SQL Database instance and this is most likely controlled by your DBA if you have one (has full admin of the SQL DB configuration and all databases within it but doesn't necessarily have control over anything else out at the OS level). This drills further down and as a simple way to explain this let's use the analogy of the good old Milk Man and his deliveries. He had crates (SQL Server DB instance) and these crates were subdivided down to hold the individual glass milk jars (a SQL database) but there were many milk jars per crate then within the glass milk jars was the milk (the tables, views, feature classes, etc.). So your milk man (SQL DBA) has admin control over the entire crate and all the jars in that crate (individual SQL databases of which many can exist within a single SQL instance) BUT each jar in the crate has its own admin as well. This is where you would finally come I but as I said this can be controlled more. So your SQL DBA builds a brand new empty SQL DB called TEST and assigns the user TESTER as the DBO for the DB. You will need to work together with the SQL DBA because they will have to give you the username and password combo OR they come sit down and enter these credentials to make a connection in ArcCatalog to the TEST DB. At this point we want to get SDE installed and your SQL DBA should know what this means but the statement should be: TESTER IS DBO. This will allow SDE to get installed and now you have an enterprise geodatabase. Depending on the trust/relationship with IT/SQL DBA they may let you continue to manage this new SDE with the TESTER account or may not. If they do, then the SQL DBA would make a change to be: TESTER AS DBO. This still leaves you as admin over the SDE DB without you having ability to change the entire SQL Server or the Windows Server. If they don't go that route because they want to have sole control over TESTER account then they can add a new account, GISADMIN and then make the same statement: GISADMIN AS DBO. Won't get into all the variances but this change from IS DBO to AS DBO does have some differences but none that will likely ever impact you directly, it does help further nest you down into your isolated area to have admin control over just the SDE DB but allows them to retain control of various system files within the SDE and this ability to have some level of admin permissions may come into play for you at times if there is a need to run some of the ESRI driven admin tools. That was more than I expected but ok here goes for the other part which is ArcGIS for Server. Again, this is a software installation that occurs on server also probably having Windows Server as its underlying OS. So same as above, the admin for the ArcGIS for Server install does not have to be (and for security really shouldn't be) the admin of the Windows Server OS. Assuming that the IT staff does the install of ArcGIS for Server for you then there is a required account that will need to setup which is the admin account over the ArcGIS for Server install and they never have to give you this. Now the part of this that again comes down to those relationships and trust will be the configuration of permissions within the ArcGIS for Server install. ArcGIS for Server uses role based permissions that can be tied to an identity store (such as Active Directory) or it has the ability to have its own store that gets manually created. Either way is fine but what you want is to have your user account set to have the role of ADMINISTRATOR. This will grant you full control over the settings and configurations within the ArcGIS for Server install. This does open up doors though which would allow you to inadvertently bring the ArcGIS for Server instance to a screeching halt because you could make changes to things such as directory folders to be used by the installation, or modify clusters, etc. If that trust isn't there then it might be getting our account set to be in the Publisher Role and as things arise that require administrator access and you bug them enough to do things they eventually build the trust etc. and work with you to give you the administrator privileges. At the end of the day when it's not viewed by staff to "be working" it's in most cases going to land at IT's doorstep somewhere so if you are working at the GIS Administrator level but outside of IT the relationships and trust are an inevitable consequence.

‎05-04-2017

As I said above this has been a while back where we hit these (close to 2 years now) but I'll say yes because I honestly can't recall seeing this code anymore and we've had 400+ users collecting in production for a year or so. Our only issues have been a couple sync issues for which we have established some workflows for users to follow and has mitigated that as much as can be done. From what I recall on those issues it was in the early test stages and making this modification along with increasing the RAM on our web server VM's (we use n-tier architecture where the web adaptors are installed to web servers in a DMZ and ArcGIS is installed on an app server behind our internal firewalls so we scale resources different than a single server doing both jobs would) was what it took to eliminate any issues we were seeing with related to attachments. I will add this, although it should have zero impact to seeing these codes from an ESRI standpoint, we have backdoored ESRI on our SQL DB end by implementing FILESTREAM for the management of the attachments. All transparent to ESRI just takes a little work but this does offload the storage of the picture/document from inside the DB onto an NTFS folder location which does change storage/size impacts.

‎05-04-2017

We were using 10.3.1 as well for Collector with iPads for our end users and currently upgrading to 10.5. I can say we have seen similar issues as you. The password change issue unfortunately is something I am not sure will go away anytime soon. The reason behind that is when the users download for offline use a replica GDB is built on the ArcGIS Server which is essentially a snapshot of the SDE at time of download. This replica mirrors the SQLite database that is loaded onto the users device. So the issue seems to lie within the replica on the ArcGIS Server because it stored the credentials at time of creation and expects to be able to pass that between the user and the backend environment. The cases you have where the user can remember old password but still doesn't work would be their credentials working from the local device to the replica but then failing on the server authentication and possibly with your DB authentication if using AD there as well. Unfortunately, would say it sounds like you are doing all you can and we actually include this as part of our initial training event with end users. With regards to the second issue, have you attempted doing a hard app close between the 1st and 2nd user? Can't say we have seen issues with this but again we have a very specific workflow that at training defines to users exactly what steps must be done prior to going out and upon return. We have seen some sync issues in the past where user was logged in and downloaded offline map fine, got back to office went to sync and it fails with log messages tied to error matching replicaID. Having the user double tap the home button to do a full hard close of the app, sign back in and sync seems to resolve the issue. We've only had 1 time this didn't resolve things and as best we can tell it's tied to local caching on the iPads that's outside of ESRI's control because we have worked through a few of these events with the support guys and had zero luck explaining or finding the root cause. Anyways, that's why I'd be curious if the hard close would resolve things in your situation because despite our stringent workflow we have had users forget to sync come back 3 days later after others have used it, logged in and realized they had not sync'd so they sync at that time but there were no issues with others ability to use the device. I'd say you are right with regards to token generation and expiration. Inevitably there will be mistakes and situations and all we've done here has been to stress the importance of the rigorous workflow we have laid out for the users in order to ensure their work doesn't get lost/corrupted and that everyone can use things when they need to.

‎05-03-2017

Short answer is yes. I have a 10.3.1 and 2 different 10.5 LM's serving various needs so you can install the LM software as many places as you need. Regarding a pre-auth I am not sure what this means? With ESRI either it's authorized or its not. Your only limitation here will be the number of licenses you have paid for. If you have an unlimited ELA then it's simple and you grab whatever you need via myESRI site as a .prv (500 advanced desktop, etc.) and load the new LM. If not then it gets more interesting and maybe someone with recent experience can speak to this as I last did this 3 years ago but this is essentially the same workflow if you have an ELA but have limited licensing for extensions such as Data Interoperability. Under individual license scheme (non-ELA) then you had to go into your existing LM, return the licenses to ESRI, wait 24+ hours for myESRI to update and process the licenses have been returned, pull down the licenses for new LM, load new LM. We schedule and plan rollouts ahead based around this due to some limited licenses for various extensions. Our workflow is letting people know that end of business on a Thursday users of the limited licenses will no longer have access to the tools until the following Monday. That means a single Friday where they do something else and ensures a working business day on ESRI end. Over the weekend we push a registry key update to all systems to divert to the new LM server. I come up in early (before most/all users) and pull limited licenses back down then load the new LM. Have occasionally had an issue with licenses not being available again but that has quickly been resolved after a short phone call to ESRI and hasn't impacted work past noon of that following Monday. It may be possible to "pre-load" your new LM with limited licenses but that's certainly going to take a call to ESRI.

‎05-02-2017

Setup the use of DNS aliases. We currently are building out 4 environments with 10.5 (2 are test and 2 are prod for different projects) all of which are using SQL 2016. We have played with mirroring and clustering in SQL and have found reasons/needs for both so just will depend on your need. In both cases we use DNS Aliases and setup all ESRI connections using the DNS. This makes it very easy when we want to do upgrades on single environments and not break existing configurations because we can architect, build and test new SQL releases, OS upgrades or anything else on the DB side we need and once we are ready simply swap the DNS over to the new servers. Here's a quick simple article about 1 guy who used it and wrote blog. Google throws up many references for this if you search for SQL Mirroring using DNS. http://www.allenkinsel.com/archive/2010/01/using-aliases-in-sql-server/

Online Status	Offline
Date Last Visited	‎03-07-2022 02:41 PM

My Ideas

Latest Contributions by ScottFierro2

Re: replicas not listed

Re: I keep getting errors when I try to Sync my Collector map back onto our Server

Re: Collector App not syncing

Re: Collector App not syncing

Re: Allow ArcGIS Server to Authenticate and Authorize users across an Active Directory Forest Trust

Re: Updating SSL Certificate

Re: Collector App not syncing

Re: Collector App not syncing

Re: Collector App not syncing

Re: How to name an AGS service the same name as a previous service???

Re: ArcGIS for Server Permissions vs. Server Permissions

Re: Collector fails to upload all but small attachments

Re: In Collector, if a user downloads a web map containing secure ArcGIS Server services, and then collects some data, could that user encounter problems with synchronizing if their password changes?

Re: moving license manager to different server

Re: How Do I Use SQL Mirroring in ArcGIS?

Re: Bad login problem with database connection in ...

Re: Specific Windows 10 permissions to run .py scr...

Re: Restrict administrative permissions on certain...

Re: Updating SSL Certificate

Re: Restrictive administrative permissions on cert...

Roads and Highways User Group (RHUG)

Ohio GIS