Latest Contributions by PF1

FYI for the community.  The Problem: So I recently ran into a problem where I wrote a nice little python script to export some feature classes to a FGDB and then zip the FGDB for delivery.  Every time I tried to zip the FGDB in the same python process as my 'feature class to feature class conversion' execution the zip routine would fail with a message that looked similar to: Traceback (most recent call last):   File "<OBSCURE_PYTHON_FILE>.py", line <#>, in <module>    ...     ...   File "C:\Python27\ArcGIS10.2\Lib\zipfile.py", line 1149, in write     with open(filename, "rb") as fp: IOError: [Errno 13] Permission denied: u'<OBSCURE_PATH>\\<FGDB_NAME>.gdb\\_gdb.<HOSTNAME>.23104.8124.sr.lock' Indicating that something within my process had an 'sr' lock (schema lock??).  By placing some time.wait() statements... I tracked it back to the command: res=arcpy.FeatureClassToFeatureClass_conversion(fc,destination_fgdb,fc) It appears that the arcpy.FeatureClassToFeatureClass_conversion function was placing a .sr.lock file in the FGDB and that it was not released until the code completed execution. This is a problem since I'm trying to zip up the FGDB after placing some data in it.  The FIX: Based on this thread... Lucas Danzinger came to the conclusion that: The reason it worked when I had it in a function is because the variables were automatically deleted once the code in the function completed successfully. so I took the arcpy.FeatureClassToFeatureClass_conversion() call and placed in a function called 'tmp()'.  As soon as I did that the .sr.lock files disappeared before my time.wait() executed and the zip process finished with success.  An alternative (and my preferable method) is to delete the 'res' object (arcpy.Result) once completed.  That also effectively removed the sr.lock file.  res=arcpy.FeatureClassToFeatureClass_conversion(fc,destination_fgdb,fc) if res.status !=4:     #do something del res So bottom line... Get in the habit of executing arcpy operations in a function (the .lock will be bound to the scope of the function* and upon completion of the function the .lock file should be cleanly removed) OR delete the result object returned by the function call.  *If the result is written to a global variable, then the scope would be larger than the function and would most likely still retain a .lock file.  Hope this article helps others with these type of issues.  ... View more

This is more for informational purposes to hopefully help the community resolve this issue if they come across it (Knowledge Base) Background: We have an on-premise deployment of the Portal for ArcGIS product (ArcGIS for Server Extension).  Currently running 10.2.1 but working on an upgrade to 10.2.2.  Config-store/content directories are all local C Drive.  Windows Server 2008 R2 64-bit Virtual Machine (VMWare) with 2 vCPU and 6GB Ram.  The portal has a web-adaptor and is configured with Integrated Windows Authentication (IWA) using kerberos (and/or NTLM if needed).  All communication over HTTPS using a TLS 1.0 or higher connection.  The portal has 1 federated ArcGIS Server (no web-adaptor) and designated as a hosting server.  We have no publishers, the AGS hosting server is not used to actually host features/services, it is only there to enable users to upload zipped shapefiles (up to 1,000 features). We have a pretty large ArcGIS for Server deployment in our enterprise that our users publish to (outside the portal) and then manually register content with our internal portal if necessary.   Our Issue: We had a lot of issues during the upgrade, but finally worked through them all except being able to add the AGS as a federated/hosted arcgis server.  We were not able to do an upgrade in place (10.2.1 to 10.2.2).  After about 90 minutes it would fail starting the windows NT service.  A complete un-install of 10.2.1 and re-install of 10.2.2 pointing to an existing content directory worked.  But the AGS federation was still an issues (for the past 2 weeks).  We watched network traffic, and when trying to federate the AGS it was calling a page like this: https://dnsalias.domain/portal/sharing/proxy?https://agsservername.domain:6443/arcgis/rest/info?f=json we kept getting an HTTP Error code response 403 (forbidden) and an IIS log entry that looked something like: #Software: Microsoft Internet Information Services 7.5 #Version: 1.0 #Date: <DATE> <TIME> #Fields: date time s-ip cs-method cs-uri-stem cs-uri-query s-port cs-username c-ip cs(User-Agent) sc-status sc-substatus sc-win32-status time-taken <DATE> <TIME> <Server-IP> POST /portal/sharing/proxy https://agsservername.domain:6443/arcgis/rest/info?f=json 443 <DOMAIN>\<USERNAME> <CLIENT-IP> Mozilla/4.0+(compatible;+MSIE+7.0;+Windows+NT+6.1;+WOW64;+Trident/5.0;+SLCC2;+.NET+CLR+2.0.50727;+.NET+CLR+3.5.30729;+.NET+CLR+3.0.30729;+Media+Center+PC+6.0;+.NET4.0C;+InfoPath.3) 403 0 0 306 We tried multiple methods of federating the portal (including manually doing it through the portaladmin rest interface).  No matter what we did, we could not get past this 403 forbidden.  The Resolution: After exhaustive research... (and about to open a ticket w/ Esri) we finally stumbled across the Configuring a reverse proxy server with your portal help article (which I do not remember when we originally installed our portal @ 10.2).  Executing this configuration setting solved our issue! Now we technically do not have a reverse proxy (other than the out of the box web-adaptor) in front of the portal, but it seems to have fixed our problem with the alias.  We had also tested this in an environment without the alias and did not need to implement this configuration setting when we had no alias applied.  ... View more