Latest Contributions by PaulDavidson1

Do you mean this is happening when you go down to a custom scale smaller than the default? I've always assumed that it's because the basemap has no data at that scale. You'd have to create your own basemap with the appropriate smaller scaling. ... View more

Changes to the webapp will not migrate to the mxd.  The webapp is consuming the mxd's layers. Changes to the mxd need to republished to Portal for the webapp to see them. Under current Portal versions, when you change and republish the mxd, it will cause certain modifications made in the webapp (like renaming layers, etc...) to be overwritten with the new mxd info.  (or the layers will go back to the previous names.  If I recall, the same thing applies if you move the order of the layers around.) I believe the 10.5 release of Portal is going to address some of these issues. ... View more

Hi Shay:  To comment and clarify:  the FGDB is typically faster because it's usually setup as a file directly attached to the server.  I mean, it will sit somewhere on the root drive of the server so it's being accessed as a local file.  Of course in a VM world, this can mean something different.  Our VMs are able to access our shares at backplane speeds or close to anyway.  An EGDB is typically accessing across a network with both the network transports in the way as well as the dB drivers, etc..  You then have at least 3 potential areas of delay, the network, the dB driver and the dB server (and probably some other delays I'm not considering.)  With multiple users reading a FGDB, via a server, you're accessing the data via the map service which typically has caching going on.  In our case, we put a copy of the FGDB onto each server.  At one time I was considering a file share in order to just one copy of the data but our Esri rep convinced me that a copy per server is the way to go for speed. As I mentioned, I have been considering moving data from other sources out of the EGDB and into a FGDB scenario for our desktop users.  And I too have wondered about the access.  But like you point out, the county is (or at least was, not sure of current status) accessing the FGDB data for the desktop users.  I believe that was around 30 concurrent users. There were some issues when they first went to FGDB but that was stuff related to NETAPP and drivers, etc... Eventually it all worked out and the response times were quite good.  The external data published to the public is also via FGDB, map services and a website app built with GeoCortex.  I think a lot of how you setup to handle this is based on organization structure, # of users, etc... Some places have distributed GIS groups while others have one centralized group (or maybe like us, two centralized groups, the GIS Analyst side and the IT side but we work together.) ... View more

Some Pros for Portal:   Use Portal if you have sensitive data that you need to keep behind your firewalls.   You are concerned about credits and want to host your own geoprocessing services (routing, etc...)   Portal can also let you setup an IWA/SSO (single sign on) environment. AGOL lets you do OAuth/SAML but not IWA (as far as i know anyway)   Portal allows you to deal with limited named users in a better way than AGOL.  You can publish maps and web apps that are for "Everyone" but because it's behind your firewall, everyone means only authenticated users. Federation with ArcGIS Server, lets you move your security model over to Portals identity based one vs. Server's community (or role base) one Supports 3D hosted services Supports large data services You control the update schedule.  This might matter to some places where riots occur when software is updated. Some Cons for Portal: Setting up and maintaining Portal is not a trivial task.  Tim is spot on here. It requires a number of resources to setup a full system:           (Portal, AGS, Data Store and IIS/Web Adaptors.) AGOL is instantly scalable to you (not your headache if you suddenly have a million hits.) Typically, updates to the software start with AGOL and then migrate to Portal.         e.g. I'm waiting for 10.5 because it offers some functionality in Portal  that is now available in AGOL.  Supposedly, this is switching though to where new functionality will first be released with Portal?  If you do stand up Portal, highly recommend first taking Esri's fairly new course:  "Deploying Portal for ArcGIS" .  ... View more

That is an excellent and critical point to make Neil! And is also one of the hurdles of republishing Feature Services. If you have moved or renamed them on a map/web app, and then republish the FS, things go back to the original setups. I believe that issue is being cleaned up with the 10.5 release.  (I may not have described the FS issue all that well.) ... View more

I actually got on here to describe an alternate format that I have seen used by a GIS group that was really very good but got sidetracked.  😉 This organization had started out with a Microsoft SQL EGDB.  But this is fair bit of overhead and cost in licensing, hardware (even virtual) and personnel.  You now need a server (or 2-3 for Dev & Test), a DBA and one versed in GIS and SDE, etc...  This group was finding it was a fair bit of work to deal with the EGDB.  The manager also noticed that the editing of the individual Feature Classes (FC) were all typically being edited by single users.  The manager made the decision to go away from an EGDB and so they split the data out into individual file geodatabases that were owned by the individual editors.  When an editor has a new data release ready to go, they copy the file.gdb into a staging folder and set a semaphore file.  There are then scripts running in the background that see the semaphore pop up which triggers a script to run and copy the staged file.gdb into another  staging area where the data is QC'd.  When the QC is successful, another semaphore is set and that night, a script sees the new semaphore and the now QC'd data is then copied into and onto the production ArcGIS Servers. Obviously what makes this scenario viable is if your data sets can be setup in such a way that they are owned and edited by a single user.  I guess there are ways to deal with multi-user file.gdbs but if you're going that route, you should be on an EGDB (seems to me anyway...) I've explained this scenario to some long term GIS folks who are very suspicious of it (understandably.)  And I think many folks think it might work for smaller organizations but not a big one.  However, the group that was using this method was a very large county with some very big data sets. But again, at the end of the day, it was all about how the underlying system of record is laid out. ... View more

We utilize a format very similar (identical?) to Neil's.  I'll lay it out in some detail in case it helps your thinking. Our enterprise geodatabase (EGDB) is composed of Feature Data Sets (FDS) that delineate various groups of data. These FDSs then are typically published as group layer in an mxd that is then published as a map service. The mxd is pointing, like Neil, at a file.gdb up on the ArcGIS Server. This allows for speed and guarantees no data corruption of the EGDB and keeps the data read only. (Feature Services are another game and require an EGDB as pointed out by Neil.  In our case, we want these for offline work and the data can remain read only.  So we're replicating to a secondary read only EGDB where we then creating Feature Services.) We are in essence duplicating our EGDB into a file.gdb with Python scripts. We've been at this for over a decade so pretty much all of our layers are already into the file.gdb and follow the same FDS layout.  And almost all the layers are on mxds and published via a map service. We do have two large file.gdbs that are published.  One is all of our assets (pipes, valves, etc...) and the other is all of our 220,000+ service points (or meters.)  These are split this way basically due to how we obtain and process the underlying data and its data sources.  We are considering splitting our large asset file.gdb into smaller separate ones.  e.g. one for water assets, one for wastewater, etc...  We think this might make sense with Portal. I think a big key here is proper use of the FDS to keep data organized. We also deal with a lot of external data from related tables that is typically brought in and updated via links/views using scripts and arcobject code.  There are numerous tables and even Feature Classes that are not inside a FDS. But the more organized you can keep your data, the easier it is to keep your map services well defined and organized. But there are still new layers or unpublished layers that occasionally come up. Typically though they fit into our existing FDS layout. So adding them to a published map service is nothing more than adding them onto an mxd and republishing it. We also have a lot of data from other local entities that is scripted and stored in our EGDB.  Since we don't edit this data, I am considering pulling it out of the EGDB and keeping it in file.gdbs for both the servers and the local data editors.  The sticking point is the large number of existing mxds that would need modification. I think that having a standard set of map services is what you are looking for to keep things organized.  Don't create a new map service when someone wants a new layer.  Just add it to an existing map service; unless it's a new layer that doesn't fit your existing layouts.  We just had such a case so we had to create a new map service which is publishing previously unpublished data from an existing FDS. At the end of the day, it's really all about the layout of your EGDB.  If you have a well organized one, then the organization of your published services should flow from it. I have heard others describe the Data Store as sort of a wild wild west approach to a database and think that's a fairly good analogy.  Since it's a black box to us, we're leaving it for end users to create and publish their own smaller unique data sets.  Any data that is considered to be critical to the organization belongs in our EGDB as the system of record. Our Portal is new and I have been struggling with how to provide our users to access to our normal data sets. I could tie into our existing 10.1 ArcGIS Servers (AGS) but have decided that the best long term way to go is to create another Federated AGS that is part of the Portal site.  The purpose of which is to publish our standard map and geoprocessing services that are then made available to Portal users. ... View more

Alaa: Did you make sure that your Portal Configuration is set to use to https only? (My Organization > Edit Settings > Security) After setting that to true and saving the configuration page, go back to it to make sure it stuck. It doesn't always stick, so make sure it has taken before proceeding to set the user and group configuration stores. Make sure the account defined in the user and group ID stores has sufficient permission into your AD server. It's best to use a domain account with a password that never expires for that account. Make sure that you have a set a Windows domain account to be an admin in Portal before going to IIS and switching over to Windows Authentication enabled. You also need to make sure you browser has been setup to allow Windows Credentials to pass through. Internet Options, Security Tab >Local Intranet > Sites > Advanced Add your portal's FQDN to trusted sites. I think this is documented if you log into Portal as an Admin, click the drop down by your name and  click the bottom entry: Administrator Guide Then look for Secure Your Portal > Configure Web-Tier... > Use Integrated Windows Authentication with .... Should be somewhere like: https://yourPortal.FQDN/portal/portalhelp/en/admin/help/#/Use_Integrated_Windows_Authentication_with_your_portal/017s00000066000000/ ... View more

Joe, in a multi-user, multi-editting environment, shouldn't those tables be in an EGDB, at least if one is making use of the GenerateID table.  Which the documentation says must not be versioned.  And/or to share with others the various rules one sets up. Depends of course a lot on how one's org & editing workflows are setup. ... View more

Hi Derek: Thanks for taking the time to respond! ... View more

Bryson, I'd add a few comments regarding setting up Portal. My experience is:       Start with a CA certificate.  Self-signed certs have seemed problematic to me.  I've seen issues go away when I've installed a CA certificate and gone to https only on Portal.       If your licensing allows it, use Portal 10.4 or 10.4.1.  The updates have added great functionality.  Some of the updates coming in 10.5 look great.  Portal is such an expanding product that it's worth the effort to update.  I'd also plug the Chef Cookbooks, especially for creating a provisioned environment that makes updating much more painless.  That's another topic...      The virtual world is the way to go if you can afford it.  Especially true for standing up new servers, doing upgrades, etc...  Just snapshot the current environment before you start an upgrade.  If it the upgrade goes south, it's a quick reset.  I cannot calculate how many hours (days!) I've spent rebuilding hardware boxes over the years either from scratch or off a tape or disk image.  No comparison.      I've noticed on Geonet (and personally seen) a number of issues go away with an uninstall of Web Adaptor and then a reinstall.  I always do a reboot with major installs/uninstalls/reinstalls.  This of course assumes you have sufficient IT permissions to do such things. ... View more

Derek: Thanks for the replies and clarification. Can you clarify two other things regarding Portal. My memory from the 2015 UC, is that you said something to the effect of:      Use HTTPS only with Portal.  We're moving to it as a requirement rather than calling it a Best Practice. Is that true or is my memory wrong? Personally, we've gone to https only on Portal and it seems to clear up certain issues. Does Portal require a valid CA certificate or will it work with a self-signed certificate? ... View more

Jane: Virtualbox is software to virtualize a Windows environment on a Mac. From the various solution, it sounds like this is related to screen resolution, maximized views, etc... Folks can help you better if you provide more info:  what version of ArcMap?  Are you on a Win PC or a Mac?  Desktop or laptop?  screen resolution, graphics card etc might come into play. Because of that, this sounds like a problem possibly best handled 1:1 with Esri support. They can share your screen and get into the weeds with you. Good luck ... View more