Latest Contributions by PaulDavidson1

my.esri.com > My Organizations > Downloads > Server is where you will find the Portal install files.  If you're going to go through the work of setting up a Portal, I would highly recommend going to version 10.4.1 Your 10.2.2. desktop and servers should work with Portal 10.4.1, although you won't be able to federate your 10..2.2 Server with Portal.  I believe federation requires being at the same release. Correct Derek? If you're used to AGOL, & install portal 10.2.2, I suspect you'd be disappointed in the functionality difference.  In fact, you might even want to consider waiting for 10.5 since it is due out soon and it has some very useful Portal functionality over even 10.4.1  I'd also take a look at the Esri Chef cookbook for Portal.  Setting up and maintaining Portal is not a trivial task. I do find Portal more responsive that AGOL but since AGOL has security (FISMA certification?) you might consider if it's worth the effort. ... View more

You can also use the AGOL Assistant (there's an online version or grab the code from GitHub and customize it locally)  AGOL Assistant That's a point and click access vs. scripting. And GeoJobe offers a commercial product similar  to the above but I think with increased functionality. ... View more

Hi Michael: Regarding your note: "Are you SURE you want to IWA Portal?   You know that each user that logs in is auto assigned a Named User account, right?" There's an easy way around this, turn off enableAutomaticAccountCreation. Go to your portal admin directory: https://pri-gis-portal.abcwua.org/portal/portaladmin/security/config/update Then to Security > Config > Update Security Configuration set "enableAutomaticAccountCreation":false Click Update Configuration.  Personally, I'd also Test Configuration to verify still a good configuration setup. Now you get the benefits of IWA but you control who gets to be a named user. If the AD member isn't in a named user, they only get anon access, if you have that turned on. We use AD Groups to simplify the admin work.  ... View more

I believe this is a duplicate of: Enhance arcpy.Describe(obj) to show geometryStorage ... View more

I believe this is a duplicate of: Enhance arcpy.Describe(obj) to show geometryStorage ... View more

Hey Eric: My gut tells me the 5mbs would be too slow for imagery but you could always try it and then upgrade the pipe if needed. I'm sure you know that AGS and AGOL aren't mutually exclusive.  You can continue to use AGS internally and AGOL for the public facing side and/or a combo of them.  Since you have AGS, it means you also have a certain number of named users for AGOL based on your AGS license (unless you have an ELA, then Named users are negotiated differently.)  You could serve up your data from AGS, make it available on AGOL and publish a web app there that consumes the data from AGS.  You'd use no credits in that case but you would be pushing your data through your ISP pipe.  If your AGS is behind firewalls and if you're using SSL, it gets trickier.  The easiest way to avoid those problems it is to publish the data up on AGOL.  I think these days most organizations that are using AGOL or Portal are doing a hybrid of AGS, AGOL/Portal.  Obviously if using Portal, you have AGS in the mix.  And even groups with Portal often use a combo of Portal and AGOL. To be honest, AGOL makes it so easy to publish data for public consumption and there is a slew of data out there already from the OpenData project. In our case, as a water utility, we use Portal and AGS (with a Silverlight Mapzilla) internally.  We're slowly getting Portal off the ground.  We will use AGOL for a few public facing things that some groups are interested in publishing. The point I'm trying to make is that you can make this stuff all work together and with AGOL, you have a huge breadth of tools at your disposal, a Portal that is administered by others, scales as needed, etc...  I imagine you know that there is already imagery as a basemap available in AGOL.  If you're like us, we fly our own Ortho-Imagery, in conjunction with other local gov entities.  We do this to get a higher resolution than the standard available imagery.  But to be honest, if I think about what our folks use imagery for, I imagine the Google resolution is perfectly adequate.  Our 3X better resolution is useful for some entities, like Assessors, but I suspect our field guys mostly use it for reference and orientation. You can always give AGOL a try.  Publishing your own imagery to it is not something I've tried because we're talking a lot of data.  But you could serve it up from your own server and then publish other layers to AGOL to create the public maps you want.  I'd recommend just playing with it to see what it can give you.  Use the free imagery basemaps initially and if it looks like something worth pursuing, then dig into it using your own.  Of course, you've already got your maps published and running so why invent the wheel.  But you can also use AGOL as the Portal into your maps.  You register your maps with Portal as an existing app and they show up in the Gallery.  Lots of options.  Where I've seen AGOL really successful is with the smaller entities that don't have much of an IT staff.  With AGOL, you've got Esri basically being your IT staff for internet apps with the benefit of all the apps they make available to us now.  I imagine you know about the Local Government Solutions. Best of luck! ... View more

Mark: this is a total shot in the dark and I'd be surprised if this changes or fixes your problem but take a look at: https://community.esri.com/thread/175979 The fix this suggests is to change your default display field, perhaps to a text field. The problem this thread describes is about a failure publishing an mxd.  Not related to your issue.  However, the part that caught my eye is your statement that when you publish to AGOL, the problem went away. I had the same behavior, the mxd published to AGOL but not to Portal until I changed the default display field to a text field. Thought I'd bring this to your attention since it's a simple enough thing to try.  Best of luck solving this. ... View more

FYI - I tried installing the KB onto my Win 7 PC and got a message that "The update is not applicable to your computer." I had downloaded the correct version (64 bit win 7) etc... I think it's most likely that the patch was applied in later Win Updates since that KB is quite old, 2011. I did report this to support level I so they're doing some digging into it. ... View more

That's a pretty wide open question and will depend a lot on a range of factors. For example, are you pushing Imagery through the pipe?  That will eat up bandwidth. How's the connection from the hosting server to the internet?  What's the ISP in use, how are you connected, how's the bandwidth allocated, etc... How about the download/upload speed from the server to the ISP? The GIS Wiki might have some info or tools that could help you out: http://wiki.gis.com/wiki/index.php/Main_Page Most ISPs have much slower upload speeds than download. At least for the common consumer's link. Business are usually different.  But if you're a smaller muni using a standard ISP in the area, it could be that all your map service requests to your server could look like an upload to the internet and be throttled back. Does that make sense? I actually think you are a perfect candidate to utilize ArcGIS online. Put your data and map out on AGOL and then it will scale as needed depending on the number of hits the website is taking. If you're sensitive to credits, you could always host your data on an internal server, make the data available to AGOL but then put your map out there.  If the map were public to everyone, that scenario would consume no credits (I think...)  If you have AGOL host your data, you'll have some credit consumption but credits really are pretty cheap.  As an example, I put a 200 MB data file up on AGOL and it runs about 50 credits a month for AGOL's credit cost for Storage.  Credits cost 10 per $1 in blocks of 1000. So that's $5 a month and Esri deals with the server, scaling, etc... That's the way I'd go, given the info so far. ... View more

Thanks for the clarification Jonathan. I'm wondering if this represents a minor security breach?  For example, I can get to the query page without any login, which matches your clarification. But then I can do a query on 'd*' and get back names with a d in them. Since Portal is typically inside the firewall, maybe it's no big deal.  What is the design purpose of the sharing directory? Thanks... ... View more

Thanks for posting that back Greg. That is some “interesting” stuff. Makes no sense that you could obtain any info without a proper password. I’m assuming all the users you did get responses for were “named users?” ... View more

Given that this works on other Portals, it seems the issue is more with the Portal than the query? But just in case, maybe this will help (from: https://github.com/Esri/portalpy/blob/master/portalpy.py) : Def search_users(self, q, sort_field='username', sort_order='asc', max_users=1000, add_org=True): """ Searches portal users. This gives you a list of users and some basic information about those users. To get more detailed information (such as role), you may need to call get_user on each user. .. note:: A few things that will be helpful to know. 1. The query syntax has quite a few features that can't be adequately described here. The query syntax is available in ArcGIS help. A short version of that URL is http://bitly.com/1fJ8q31. 2. Most of the time when searching groups you want to search within your organization in ArcGIS Online or within your Portal. As a convenience, the method automatically appends your organization id to the query by default. If you don't want the API to append to your query set add_org to false. If you use this feature with an OR clause such as field=x or field=y you should put this into parenthesis when using add_org. ================ ======================================================== *Argument* *Description* ... View more

Portal is a beast.  It's a sneaky beast though. It appears on the surface to be pretty straight forward to setup and get working. But then behind the scenes there's a lot going on. And I don't think there's a lot of info out there about the more complex processes. ... View more

Joe: I came across this recently: http://support.esri.com/technical-article/000012357 Don't know if this would help but it at least sounds like it has some things in common with what you're doing.  Maybe there's a nugget in there that will help your understanding?  ... View more