Latest Contributions by ScottFierro2

So a Google search on that error message shows multiple instances where people report the error and it always is a python coding issue. Since you haven't indicated the use of anything you built in python I'd assume you are just using ESRI out-of-the-box tools to handle tiling. That makes it a little odd but I'd say step 1 would be to start at the basics. 1) Launch MS Certificate Manager (certmgr.msc) and ensure the self signed certificate has been added at least to the personal folder. Once added open the certificate and ensure the last tab on right "Certification Path" that the "Certificate Status:" box at bottom states "This certificate is OK.". If this message isn't here you need to provide any missing pieces in the path from the top box. 2) Go to http://gisserver.domain.com:6080/arcgis/admin or the appropriate path you configured for ArcGIS Server Administrator Directory. Follow the path in below image for each machine and ensure the certificate is available and correct If the selfsignedcert is missing it can be added from this page using the "importExistingServerCertificate" operation. If both of these are fine and correct then maybe the next step is to walk through the permissions levels of your user across the steps. Ensure all the NTFS permissions are established at both the Read data location and the write location of the tiles. Ensure the user has appropriate permissions to generate the token the process is attempting to use by doing a manual token generation at http://gisserver.domain.com:6080/arcgis/tokens ... View more

Interesting and good to know. So from your original post we have an identical architecture to what you are running with a SQL2012 DB on the backend. The only variation is that we stuck with GIS tier. We saw a similar issue with non-displaying layers to what you initially described but I can't recall which of 3 possible issues was tied to resolving it. 1) We have a BigIP in play where we assign the VIP to load balance onto our IIS Web Servers in the DMZ. The BigIP had some caching turned on that we had to tweak at one point. We also have found that making significant web adaptor or ArcServer configuration changes requires us to turn off all the BigIP caching and then turn it back on. 2) The certificates while maybe not necessary we fully deployed to 3 locations: a) within Windows Certificate Manager on both the IIS Web Server ensure the Root, Intermediate and Personal Certificates are installed; b) do the same thing in A but on the servers hosting ArcGIS Server; c) from the Admin Directory http://<server_name>.<domain>:6080/arcgis/admin/login add all 3 certs to each machine 3) We have a need to allow Collector Access over our wifi network which is different from our hard line network. This was tied to networking and BigIP items but we had to create some specific iRules to allow proper access and once that was done we had to exclude the VIP we are using from the BigIP list for SSL offloading (i.e. we wanted our servers to handle it rather than the BigIP handling it). Side item, in a recent convo with ESRI we were able to establish that it is their understanding that there is no scenario which will offer an SSO experience other than using Portal instead of AGO. Essentially, they stated that because the user Enterprise login is derived from ADFS in AGO and either the Web Server or ArcServer is hitting AD directly it gets handled as a mismatch. By that, ESRI stated the returns from ADFS if they were passed to the servers on backend even though username/password are identical it's a different format so the backend servers will always cause a prompt. We are going to investigate a work around to this which would involve using a service account as the controlling factor for securing the REST service but then during publishing to AGO choose to store the username/password combo into AGO and then it's just managing control to that REST service in AGO products that use it via group controls, etc. ... View more

Couldn't agree more. Drives us nuts with some web apps we had tried to enforce a NO NULL scenario which is impossible since it writes a geometry only record and the DB kicks it out. Hadn't considered these as a workaround to that but will have to look at it now. ... View more

Been reviewing these but thus far we haven't pursued using them. In part we haven't done a backend version upgrade to make use of them and in part because our experience has shown the DB will always process far faster if it can do things natively. We have some instances where we set a Windows Task to call a python script that performs tasks, submits call to DB stored procedure, gets returns and performs final tasks back within python just because of the performance gains from letting the DB do what it's designed to do. Again, lots of variables and all depends on need, architecture, expertise, etc. etc. but it does sound like an SOI could handle the task. ... View more

Right, our use of triggers has been great and we use archiving on all our editable tables within Collector. Only hiccups we hit was trying to use triggers to perform system calls for things like pulling the system time. ... View more

Ahhh ok you are referring to the actual Collector app from the initialization through to the login. Sadly, I'd say right now the answer is no there isn't any better streamlined workflow. Once the user performs the initial sign on, unless they sign out of the app or kill it I can say from iOS devices they should be auto logged in. Unfortunately, step 1 choice for enterprise is how they drive the click stream for the domain that is needed so that ESRI can point to the right organization instead of ArcGIS.com and then with the app pointing to the right domain site it's re-asking if the user wants to use an AGO side account or Enterprise account option with the final login piece. Probably would make for a great idea forum post. Suggest something where ESRI can add a configuration option into the local device app under the existing settings option. Allow the user to choose to store the current login details as some sort of a template saved to the local device and on launch the app will load the user to the organizations domain based page (your step 3) so all they have to do is select which login AGO or Enterprise and login. Obviously ESRI would have to build in some sort of escape function as an embedded piece of the template that would allow a user to get back to the current initial page for ArcGIS.com. ... View more

Depending on your SQL abilities this should resolve it for you and not be overly difficult to accomplish and done as a trigger or stored procedure depending on your needs and performance speeds. I'd lean toward a trigger but we have seen mixed results with those in conjunction with Collector usage. In the trigger scenario build it as an on insert so as soon as the user commits the record to the DB the actions are performed eliminating batch processing concerns. https://msdn.microsoft.com/en-us/library/ms189799.aspx For the trigger action to resolve use the centroid piece STCentroid https://msdn.microsoft.com/en-us/library/bb933847.aspx and then seems like you'd want to use STIntersect() for the rest and that solves #2 and #3. https://msdn.microsoft.com/en-us/library/bb933899.aspx #4 is just an IF statement and perform a check on the field. Assuming the user is unable to enter a blank space (field should use a numeric, integer, etc. data type and not varchar) then you can assume any entry you will accept so all you are actually needing is to do a check for IS NULL and if that = true then perform STArea https://msdn.microsoft.com/en-us/library/bb933923.aspx ... View more

We use it via an ADFS federation with AGO and roughly 700+ users of the app in the field right now. We brought this issue up about 18 months ago in monthly meetings we were doing with the ESRI Apps Dev Team and it was due to the limitation then that Web Tier authentication wasn't supported it is all token based. So, essentially, users are having to login to AGO (Windows integrated auth supported here and works) but then once the user selects the map to use must provide login information again to authenticate with your backend (ArcServers specified identity store). Believe it was 2 AGO updates back (June/July roughly) when they provided an option within AGO to add "Trusted Servers". The intention with this is to mimic a federation and in theory when your backend is entered into here it's supposed to create the SSO experience for the user by allowing AGO to pass the credentials provided by the user to your backend and handle that authentication in the background thus eliminating the second prompt. We plan to do some testing of this capability in the next few months. It was placed on hold while we have had to work some very extensive testing to establish the ability to use 2 separate AD forests where a 1 way trust exists (ESRI claims a non-supported scenario due to configurations within ArcServer to only read a single identity store) and we are in the last phase with just 1 workflow scenario to resolve before we can show it can/does work. ... View more

Looked at some of our servers and yes I'd say that is correct. Seems that we only have 1 GP that's utilizing the space and all the rest I've done the published service modifications to, etc. It appears though that while it does use the space it's only partially cleaning things out or has a very long period it retains the temp job folders and contents. ... View more

See this with all of our GP's and based off what you have said I can make some observations. 1) You configured your servers to use the basic service account named ArcGIS during installation and when running the GP it's through anonymous authentication so the service account is being used, hence C:\Users\ArcGIS. Also curious, for your cluster, did you configure your config-store and directory folders to use a folder on the C:\ of the first server you installed ArcServer onto and then made that an available share folder? If so, this might present issues because unless you replicate the same local pathway other servers in the cluster can't find the folder (doubt you did this) OR if you used the shared path (UNC) \\<server_name>\arcgisserver\... then you are creating load strain on any work done to that original server (more likely what most people do). It's best to have network storage or at least a server not used within the cluster to establish the shared location for the config-store and directories. 2) Within your GP you are using the inline variable call for %scratchWorkspace% or %scratchGDB% and while this works great from desktop it seems something doesn't quite convert over during the "packaging" of the services. Doesn't seem to be from server not recognizing the inline variables because the services will publish and run. I've dug into the published services from within the directory folders and ensured the variables are not be miss translated during publishing. In cases I have just gone in and built out a FGDB within the published service called it Scratch.gdb then modified the published service by hardcoding in the new Scratch.gdb. Far less than ideal especially with regards to cleanup, etc. but ensures certain GP's don't inadvertently overload any local server drives and built a simple python script scheduled via Windows Task Scheduler to nightly go through and clean out the FGDB. Sorry I can't give you a clearer or better answer just what we've encountered thus far but it will be interesting to see if any ESRI staff chimes in with better details. ... View more

Yes, that is all true and correct. To make matters even worse if the user travels to an area and loses cell connectivity with the device locked then the user can't do anything and must travel back to an area with signal, get logged in, map pulled up, etc. and then keep the device active through the "no signal" area in order to go perform the collection. Once the collection(s) are done then the user can let it lock again and the data collected in the "offline" mode will auto-sync once the device has signal again. It was due to these issues we had to setup all of our workflows as permanent offline only use scenarios and this prevents users from such headaches but requires more user training and more work on the GIS team to prepare everything for offline use at all times. ... View more

We use SMTP as well and as a government agency can say we have had this same error occur several times before. So I have seen 2 scenarios for us that triggered this: 1) Network spikes/lag issues - we have created a centralized IT agency here in Ohio and rather than each agency managing their own exchange servers, etc. it's all handled by the new IT agency. Being that we are not co-located and due to some extensive networking that had to be done so the central IT could sit between the web and all agencies under it we have seen some minor oddities at times with things that have to be routed between agencies (essentially, having to define agency to agency traffic as external despite the fact that everything appears to be internal since all agencies are tucked behind the IT firewall). 2) Permissions at the SMTP end - The centralized IT office of course doesn't allow open ended admin rights to the exchange servers, etc. So they had to build in permissions to explicitly allow the service accounts (running the .py scripts) and sender accounts (FROM field of e-mail) [had them do both to cover our bases and alleviate further wait times on 2 separate tickets] in order to allow the e-mails to be sent. ... View more

If you have Data Reviewer the "Find Dangles" tool is one of my favorite tools and used it extensively while cleaning up 360,000 road line segments for the city of Baghdad. http://desktop.arcgis.com/en/arcmap/latest/extensions/data-reviewer/finding-dangles-on-line-features.htm ... View more

OK, so this may be a multi-step process just have to see. So in your original data were there any unique ID fields other than the ObjectID? The easiest scenario would be, for example, if you were gathering light poles and maintained a data field of unique values for each record. An example of this might be a 3 letter county abbreviation code along with a unique 5 digit number (i.e. Franklin county = FRA and it's the 1st pole collected so it's value is FRA00001). If you have some unique value for each record like this then the process would involve appending just the new records to <your_FC> and then adding gloablID's to <your_FC> Next, you'd let ESRI create the <your_FC>__ATTACH table by doing the simple right-click in ArcCatalog on <your_FC> and "Create Attachments". This means you have your total record set of existing and appended new values in <your_FC> and an empty <your_FC>_attach. Add a new field to the <your_FC>__ATTACH call it anything you want but ensure it has the same data type as <your_FC> for the unique ID column (discussed above). From here it's either an Append or Insert of all your unique values into the new field on <your_FC>__ATTACH. The issue now is that <your_FC>__ATTACH will generate a bunch of globalID and rel_globalID values for all these new records. This is where your database skills need to kick in and these steps should be nearly the same regardless of if you are using Oracle or SQL or something else. From your database tools perform a join of <your_FC> and <your_FC>__ATTACH based on the uniqueID field. Using the join overwrite the rel_globalID field values in <your_FC>__ATTACH with the globalID values from <your_FC>. This step fulfills the needs of the ESRI relationship class and properly associates the record from <your_FC> to the record with the attachment. Next, map the data to populate the fields in <your_FC>__ATTACH and remember your pictures get mapped into the "DATA" field but it may also become necessary for you to script or do manual entry of several of the other data fields (content_type, att_name or data_size) if the information isn't available from what was pulled down out of AGOL. Once done perform a delete of the column added to <your_FC>__ATTACH with the uniqueID values and you end up with a fully functioning and related source table with related ATTACH table and pictures. ***In the event you did not have a uniqueID field prior to doing all the work it gets trickier because there is no consistent value that exists in your original sde <your_FC> and the new copy of <your_FC> pulled down out of AGOL. This uniqueID value is essentially the 1 constant as the data was moved around and therefor the only piece that really allows you to build the necessary joins to relate the 2 versions of data you have along with doing the 1 to Many style table split you are attempting to perform. I'd provide you with some screenshots and PDF export of the model builder I used for similar functions but it'd require several and lots of explanation for the workflow. ... View more

Just want to be sure I am building this scenario correctly. Within your sde you have an existing feature class (<your_FC>). This feature class currently has no <your_FC>__ATTACH table built for it as well as it has no relationship class defining the relationship of the <your_FC> __ATTACH back to the <your_FC>. Now, you have pulled down your data from AGOL and want to extract just the attachments and apply them against this existing FC in your sde? This is doable via an ETL using ModelBuilder it's just a matter of understanding what pieces you have and are working with. I am going under the assumption that your existing FC in the sde has records in it already and what was up in AGOL is a mirrored copy so the need is to now provide attachments inside your sde as they exist in AGOL? OR is the need to add new records to the existing FC in sde along with the associated attachments? ... View more