Latest Contributions by PaulDavidson1

‎04-21-2016

In Portal 10.4, this error can also be related to the Display Field of the mxd or the schema setup of a zipped up file geodatabase. I have just posted a complete analysis of this situation here: Packaging succeeded, but publishing failed. ERROR 001369: - One Solution

‎04-21-2016

Apparently, the 1369 error can have a lot of causes and potential solutions. Some other reported solutions are here: https://community.esri.com/thread/137218?q=Publishing I recently encountered this error when trying to publish the OutageDetails mxd from the Esri Water Solutions for the Isolation Trace (comes from WaterWebIsolationA4W.zip) This is an mxd that is referencing an empty schema. I was however able to publish the mxd up to AGOL. I tried to publish this in a variety of ways, from ArcMap 10.2.2, 10.4, from my desktop, directly from the Portal server, etc… all with no luck. Esri provided the following explanation and solution: “The problem is the layer ‘Outage Area’ uses the 'length' field as the display field. You wouldn’t be able to publish the map in 10.4. To get around the problem you could change the display field to something else in the mxd. In AGOL the publishing implementation is a bit different.” The Display Expression Field is found in your mxd’s Layer Properties on the Display Tab. If I looked in there, this was originally set to: SHAPE_Length. For this mxd, I set the Display Field to OutageType and was then able to publish the mxd successfully to our 10.4 Portal. I am guessing that this was a bug introduced in 10.4 otherwise the Esri Water Solutions folks would have caught it under Portal 10.3.1? When I first searched the Server log files, I came across some error messages that were very familiar looking: "Failed to create the service.: ERROR: code:500, Failed to create the service 'Hosted/OutageDetails.FeatureServer'. The submitted field 'st_length(shape)' does not exist in the table” It’s that last line that caught my attention because I had seen it before when trying to publish zipped file geodatabases with certain polygons. Some polygons would fail to publish to Portal while others would publish fine. All would publish to AGOL. I had put in a ticket with Esri and level 1 support found a workaround, export the polygon to a shapefile and then import it back into the Feature Class. It's a usable work around but didn’t define the underlying problem. When I look at the problematic polygons, I see the same issue, Default Display field is set to SHAPE_LEN. When we do the export/import, a new field is created in the schema: SHAPE_Leng which then had the display field set to it. SHAPE_Length was still there but was no longer the default display field. This explains why the export/import works. As a note to others, changing the display field only works for a layer in an mxd. You then publish the mxd to Portal. In order to make the change permanent in the Feature Class (in a file.gdb or an egdb) you probably have to modify your schema so that the field used for the default display field is not the 'length' field. The following information lists out how the default display field is chosen (at least from one source, I think back about 9.3) & was taken from: http://gis.stackexchange.com/questions/16934/how-is-the-default-label-field-chosen-by-arcmap ----------------------------------------- The default display field is chosen according to the following priorities: First field of type Text whose name contains the word "name" (case-insensitive) First field of type Text First field of an integer type (Long or Short, presumably) First field of any type I don't think there is any way to specify the primary display field without using a layer or layer file, other than using the above logic to name/order your fields accordingly. -------------------------------------------- If you have a polygon with only a default polygon schema (OBJECTID, SHAPE, SHAPE.AREA, SHAPE.LEN) then the default display field is going to be set to SHAPE.LEN and this won't publish to Portal 10.4. I have fixed this in our problematic polygons by creating a next text field: XXX.NAME This way the default display field sees this as the first text field with the word “name” I then set a default value to the text field, probably not necessary for this fix but useful in our maps.. I have verified this fix works to publish these problematic polygons to Portal 10.4

‎04-21-2016

Hi Bill, sorry, very late reply.... Here's an update on where I've ended up going with our Portal. It's a complete change of direction for me but I was successfully convinced to do so by Esri's release of a Chef cookbook for installation. I have documented that here: GIS Standardized Installation Tool - Chef Provisioning Cookbooks I have setup Portal by hand on separate servers, took many days to do this. And I have stood up a Dev, a Test and a Production Portal using the cookbook in about a half a day per machine. You still have to configure everything and you have to have sufficient resources in order for everything to run on one box. We're in a very plentiful VM environment where resources are no problem. But we also don't have anything into production yet where many users are hitting things. That will be the real test of course. I setup our Prod Portal to use a fileserver for the config files with the intent to implement an HA setup shortly. That will be awhile probably though since once Portal is up, my time is dedicated to standing up data, etc... So far in our testing, things seem to work pretty well. With large complicated maps we have learned to save the map often because we occasionally have things hang up. I am leaning towards this being an IE issue and not a Portal issue because when one of my analysts reports that he is now hung, I can go onto Portal and things work fine. One of the convincing arguments for me regarding the allinone box was that you only have one box to go down instead of three or four. i.e. you reduce your odds of a hang/reboot scenario. Assuming you have sufficient resources to throw at the box, this makes sense to me. I finally convinced myself to go with the all in one setup for two reasons: (1) the ease & consistency of the setup with Chef (2) I can always end up going back to my stand alone setup if needed. I will report back to this thread as our experience with this setup grows.

‎04-21-2016

Jianfeng: Have you found a work around at this time to take care of the issues?

‎04-15-2016

From: http://server.arcgis.com/en/server/latest/administer/windows/about-using-your-server-with-portal-for-arcgis.htm "Only ArcGIS Server sites using version 10.2 or later can be federated with a portal. To federate, the installed versions of ArcGIS Server and Portal for ArcGIS must be identical. You cannot federate if the software versions don't match. If you've already federated and you're upgrading to a later version, ArcGIS Server and Portal for ArcGIS must be upgraded to the same version."

‎04-14-2016

Gary, that's a great idea for using the Geo Event Processor! Also triggers a lot of other ideas regarding data changes.

‎04-13-2016

I can't contribute to a solution. No experience with Portal and pass cards. But I am curious about one thing: you're using AD, but importing individual users? So you're not using AD groups for controlling user access? I'm just curious because we're in the middle of setting up our IWA/Portal security so I'm thinking about the various scenarios that can be used.

‎04-11-2016

Dirk: There is the case of using the JavaScript APIs to hook to AGOL services which I believe also flows to Portal. For example, we have a Javascript API based Mapzilla that uses AGOL's routing service. To do that involves getting a token, etc... (the naming of the link below is slightly misleading, it discusses how to get tokens to AGOL services, etc...) Implementing Application Authentication | ArcGIS for Developers I seem to recall that this is based more on a registered application and a client id than an actual named user. And it is consuming a service rather than a web app but it's a similar concept. In essence, we have coded a robot to interact with AGOL's routing service. I am confused a bit by one of your statements: "We also have a robot who only needs the AGS Rest API. And several hundred “unnamed users” who only consume web map content served into our applications and nothing more regarding the PFA." Do you mean that your robot and unnamed users are consuming content through your own custom written applications? i.e. basically via the REST endpoints? If so, isn't that just normal AGS consumption? I believe that a federated to Portal AGS's REST endpoints are still available to us via the normal REST mechanisms. (I sure hope I'm not wrong about that.) But if the AGS data is being consumed via applications that are being created under Portal with the new smart maps and web apps, etc... then these are utilizing a lot more of Portal's functionality than just the REST endpoints, right? You're taking advantage of the "...simpler API. ...easier to design and configure web maps ....publish more of them more efficiently" I'm thinking from what you wrote that you are taking advantage of the Portal's ability to easily create smaller, lighter, more directed applications. And that indicates to me the need for named user accounts to access those web apps. BTW - I like your description (below) of Portal, AGOL, etc.. Although I would say that the concept of a web map has been around for a very long time. For example: IMS or custom written JS web apps, etc... Stealing from your well written words: What we are being given now is the rich functionality and much simpler API with which we can publish web maps and web apps much faster and more efficiently. "Along came ArcGIS Online (AGOL) and PFA and with it came the concept of a web map - i.e., a collection of GIS services (maps, mostly) with rich function functionality embedded in the map that could be consumed by a much simpler API. Because it is easier to design and configure web maps, it’s possible to publish more of them more efficiently. And because the ArcGIS Rest API is still available, our GIS automation doesn’t have to change." I think these are somewhat the days of unchartered waters. But it's my understanding (or maybe it's more a belief) that if I automate functionality, say via Python scripts utilizing arcpy and ArcREST, then I'm in essence only extending myself. The named user that I'm going to utilize in my scripts is going to be my Portal/AGOL admin account. Or perhaps as Tim suggests, we'll set aside a named user account, similar to how we might setup a domain level service account in our AD shop. I'll be working with our Esri account/tech rep next week on just this sort of thing. As others have said, I suspect there may be individual differences across accounts as to how some things are setup and allowed, etc... e.g. We're under an ELA with certain licensing perhaps being unique to us. If I learn anything generic to Esri, I'll post it up. One thing that I've learned about these new days is that Esri is open to feedback. It's a learning process right now, not only for us but also for them. More and more unique situations are going to be coming up and the more we can appraise Esri of how their licensing does or does not fit our needs and how we would like (or need) to see things changed then the more likely we are to end up with a mature product that benefits all parties. Cheers!

‎04-07-2016

What is your database? In Oracle, we build views with synonyms, etc... to look across databases. I don't if Data Reviewer will work with a view but that's what I'd try first.

‎04-06-2016

Did you have two separate web adaptors setup? Been awhile since I did the federation by hand but I don't recall any problem doing it. How about your CA? If you're using self-signed, that might be the problem. I believe Portal requires a CA. We use a domain certificate. I believe I've read that Portal won't work with a self-signed cert. I suppose that might not apply on an all in one box. You might be able to get away with setting up the cookbook and then running it against your current install. It might then correct any issues it finds. But I think if it were me, I'd wipe it all out and start from scratch. Well, I might try it once just to see if it fixes things but then I'd redo it from scratch. Otherwise anytime something didn't work, I'd be wondering about the setup. But that's me... Good luck

‎04-06-2016

yes, you can do this. The best, easiest and only way I will ever do this again is by using the Esri Chef Cookbook. It puts Portal, AGS, DataStore and the web adaptors onto one machine. I have setup a development, test and production Portal using this technicque. I'm now working on the HA version of Production Portal. There are also cookbooks here for ArcGIS Desktop and License Manager. LM doesn't do all the settings needed for a Windows install (like opening ports and such) but one can customize one's cookbook to do this for you. The released cookbook doesn't do ports because it's too specific to the install. At least not yet... I have done all this by hand in the past. That would take me at least a day and probably more like multiples as I do read documentation very thoroughly. Now, I can set up a FULL Portal environment in about 30 minutes. I have a VM template with the 10.4 installation files already extracted. Go to: Get Started With ArcGIS Cookbook · Esri/arcgis-cookbook Wiki · GitHub

‎04-05-2016

I have not done this but I do see that your AGS error 2 says: Data versioned with the option to move edits to base cannot be replicated. What happens when you turn off that flag? I assume you've checked your permissions in the database to verify the user taking the data off line has edit permissions? BTW - I'm working on scripting edits of versioned data and it's not trivial. Not the same problem as yours but what I am learning is that there are a number of steps that have to be done in the right order. There is a decent overview of editing versions, while it's just the PPT slides and it's not related to offline data, maybe something in here will spark a clue for you: https://community.esri.com/docs/DOC-1837?q=editting ver

‎04-05-2016

Do you need to have the Feature Service setup for Synching? I don't know, we're just starting to work on this type of process but maybe that's a requirement for "live" updates? I also seem to recall something about setting a refresh time? But I could be confusing that with something else Esri related.

‎03-31-2016

Sometimes one can use ModelBuilder for those tedious field copying tasks. Drop in FCtoFC then at least you have a GUI look at the input features and can remove the fields you don't want. Test it and examine your output to see if it's the output you meant to produce. Then export that simple model to python. Saves typing a lot of possibly cumbersome fields names, screwing around with syntax, etc...

‎03-29-2016

Good news! I think that was my fix awhile back I think you might have some trouble with self signed cert. I think you need CA or a domain one. Also, if using IE, need to turn off compatibility mode. There are a couple of longer threads (under Issues Closed) about this sort of thing on the Esri Chef Cookbook on GitHub. Worth the read. -Paul Davidson

Online Status	Offline
Date Last Visited	‎03-23-2026 09:31 AM

My Ideas

Latest Contributions by PaulDavidson1

Re: sharing to Portal (publishing) fails

Packaging succeeded, but publishing failed. ERROR 001369: - One Solution

Re: Portal Best Practices for setup?

Re: re-federate ArcGIS server

Re: Is it possible to use Portal 10.3 with Server 10.4

Re: Send notifications when survey is submitted.

Re: Portalpy question on a Portal that uses AD credentials for login.

Re: Does a named user need to be a human being?

Re: Can I connect multiple databse in batch jobs to validate the rules.

Re: Can you have Server and Portal on the same machine if you want to Federate AGS

Re: Can you have Server and Portal on the same machine if you want to Federate AGS

Re: Offline Data editing on Versioned Data

Re: Synchronize externally changed database with feature service in Portal

Re: Need help building my first script

Re: Navigating within portal changes url from https to http

Re: Does a named user need to be a human being?

Re: Preferred order of stopping Portal, ArcGIS Ser...

Re: Intermittent 504 gateway timeouts with hosted ...

Re: ArcGIS Data Store services cannot start after ...

Re: Upgrade to Portal 10.4 but can't get past the ...