Latest Contributions by SamJehle1

‎09-06-2018

We were able to import the site successfully after dropping one of the portal machines! Going to do some additional troubleshooting to help identify the cause, but our DR environment is back up and running. Thank you for the help Jonathan!

‎09-06-2018

The console reports that the standby portal machine is removed, usually taking around 2 minutes. After that step it almost immediately fails. However looking back through the logs I do notice that the import for portal started to fail when the primary portal switched to the second machine and the logs also indicate it fails to delete content from the portal it has supposedly removed from the site. I'll try the import without high availability later today.

‎09-05-2018

Here are the event viewer errors from the last import attempt: ERROR pg_ctl: the PID file "C:/arcgisportal/db/postmaster.pid" is empty 09/04/2018 14:45 ERROR pg_ctl: PID file "C:/arcgisportal/db/postmaster.pid" does not exist 09/04/2018 14:55 ERROR Is server running? 09/04/2018 14:55 ERROR pg_ctl: could not send stop signal (PID: 11308): No such process 09/04/2018 14:59 Here's portal logs during the same time. After the DR backup failed we went ahead and re-entered the PSA. Sorry, it's not the best format: WARNING HA: Error in testing connection to the master database at <computer FQDN>:7,654. null 2018-09-04T14:45:17,585 WARNING HA: Master down, check if this node needs to be elevated to be the new master. 2018-09-04T14:45:17,585 SEVERE HA: Error in HA plugin. No node in the standby.nodes property is running 2018-09-04T14:45:18,588 WARNING The web server was found to be stopped. Re-starting it. 2018-09-04T14:46:22,821 WARNING The web server was found to be stopped. Re-starting it. 2018-09-04T14:46:35,201 WARNING Failed to rename the directory <DR content Directory>\arcgisportal\content. 2018-09-04T14:49:19,246 SEVERE Failed to update log settings. java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up. 2018-09-04T14:55:32,508 SEVERE Migration failed. com.esri.arcgis.portal.admin.core.PortalException: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up 2018-09-04T14:55:32,509 SEVERE com.esri.arcgis.portal.admin.core.site.migration.MigrationException: com.esri.arcgis.portal.admin.core.PortalException: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up at com.esri.arcgis.portal.admin.core.site.migration.Migration.a(Migration.java:277) at com.esri.arcgis.portal.admin.core.site.migration.Migration.migrate(Migration.java:109) at com.esri.arcgis.portal.admin.core.site.backuprestore.BackupRestore.importSite(BackupRestore.java:819) at com.esri.arcgis.portal.admin.rest.site.SiteResource.importSite(SiteResource.java:566) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43) at java.lang.reflect.Method.invoke(Method.java:498) at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60) at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$ResponseOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:205) at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75) at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:302) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108) at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147) at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1511) at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1442) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1391) at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1381) at com.sun.jersey.spi.container.servlet.WebComponent.service(WebComponent.java:416) at com.sun.jersey.spi.container.servlet.ServletContainer.service(ServletContainer.java:538) at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:910) at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:858) at com.sun.jersey.spi.container.servlet.ServletContainer.doFilter(ServletContainer.java:812) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.obtainContent(SiteMeshFilter.java:129) at com.opensymphony.sitemesh.webapp.SiteMeshFilter.doFilter(SiteMeshFilter.java:77) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at com.esri.commons.web.AppFilter.doFilter(AppFilter.java:265) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at com.esri.arcgis.portal.admin.rest.filters.AdminFilter.doFilter(AdminFilter.java:87) at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:241) at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:208) at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:218) at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:122) at org.apache.catalina.authenticator.AuthenticatorBase.invoke(AuthenticatorBase.java:505) at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:169) at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:103) at com.esri.arcgis.portal.util.TomcatValve.invoke(TomcatValve.java:43) at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:116) at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:442) at org.apache.coyote.http11.AbstractHttp11Processor.process(AbstractHttp11Processor.java:1083) at org.apache.coyote.AbstractProtocol$AbstractConnectionHandler.process(AbstractProtocol.java:640) at org.apache.tomcat.util.net.JIoEndpoint$SocketProcessor.run(JIoEndpoint.java:316) at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142) at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617) at org.apache.tomcat.util.threads.TaskThread$WrappingRunnable.run(TaskThread.java:61) at java.lang.Thread.run(Thread.java:745) Caused by: com.esri.arcgis.portal.admin.core.PortalException: com.esri.arcgis.portal.admin.core.PortalException: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up at com.esri.arcgis.portal.admin.core.log.LogManager.updateLogConfigurationLocal(LogManager.java:181) at com.esri.arcgis.portal.admin.core.site.migration.Migration.a(Migration.java:164) ... 51 more Caused by: com.esri.arcgis.portal.admin.core.PortalException: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up at com.esri.arcgis.portal.admin.core.store.GenericConfigStore.getLogConfig(GenericConfigStore.java:630) at com.esri.arcgis.portal.admin.core.log.LogManager.updateLogConfigurationLocal(LogManager.java:130) ... 52 more Caused by: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up at com.esri.arcgis.discovery.persistence.impl.DBConfigPersistence.b(DBConfigPersistence.java:494) at com.esri.arcgis.discovery.persistence.impl.DBConfigPersistence.get(DBConfigPersistence.java:288) at com.esri.arcgis.portal.admin.core.store.GenericConfigStore.a(GenericConfigStore.java:839) at com.esri.arcgis.portal.admin.core.store.GenericConfigStore.getLogConfig(GenericConfigStore.java:623) ... 53 more 2018-09-04T14:55:41,763 SEVERE Failed to import site. com.esri.arcgis.portal.admin.core.PortalException: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up 2018-09-04T14:55:41,764 SEVERE Failed to update log settings. java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections.. 2018-09-04T14:58:54,762 SEVERE The process of creating a new site failed. Reverting site creation. com.esri.arcgis.portal.admin.core.PortalException: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb Connection refused. Check that the hostname and port are correct and that the postmaster is accepting TCP/IP connections. 2018-09-04T14:58:54,762

‎09-04-2018

Hello, I've been managing a highly available production and DR portal 10.5.1 environments for several months now, and as of 2 monthes ago the webgisdr tool stopped importing portal content into the DR portal environment. I've been unable to troubleshoot why. The resulting error from the import: Failed to restore the Portal for ArcGIS. Admin Url: https://alias.domain.com/webdadaptor. {"error":{"code":500,"details":null,"message":"Failed to import site. com.esri.arcgis.portal.admin.core.PortalException: java.lang.Exception: Cannot connect to database: jdbc:postgresql://localhost:7654/gwdb FATAL: the database system is starting up"}} After doing some more digging, the portal's postgres sql log shows the following: FATAL: terminating connection due to administrator command LOG: disconnection: session time: 15:51:16.671 user={adminaccount} database=gwdb host={serverIP} port=63277 LOG: autovacuum launcher shutting down LOG: shutting down LOG: database system is shut down --4minute break-- LOG: database system was interrupted; last known up at 2018-07-08 06:00:52 PDT LOG: connection received: host=127.0.0.1 port=55163 FATAL: the database system is starting up LOG: received fast shutdown request LOG: redo starts at F/97000028 LOG: shutting down LOG: database system is shut down After that point the portal admin page reverts back to Create new site or Join new site page. The data store, host server and another federated server environment all import correctly. The strange thing is, once I re-enter the PSA account the disaster recovery site loads up with the same portal site before the import started. Has anyone come across a similar issue? To give a little bit of a background, the portal environments are identical except for server names and IP addresses. All servers are running on the same OS (Windows Server 2016). The DR environment machines have had their host files modified to always redirect the web context URL to the VIP in their data center as well. They both use the same context URL allowing for the webgisdr tool to work in the past. I've tried a wide variety of things: re-establishing the PSA and retrying the import, reinstalling portal in the DR environment, reconfiguring the DR environment from scratch, importing a backup that previously worked and no luck. I noticed the release of a portal security patch recently and that is one of my next steps. However I'm a little hesitant to move forward with applying the patch before identifying the current issue. I'm also trying to identify if any windows patches or ports are being blocked or are interfering with the backup import, but I wanted to put the question here before going down that rabbit hole. Thanks!

‎06-20-2018

Thanks for the quick response, Jeremie.

‎06-19-2018

Hello, I notice this was mentioned earlier in the thread, but has anyone been able to incorporate multi-line text within this widget? I've gotten a request to add in the capability to this widget and figured I should start here first. It seems like it would be a large undertaking.

‎06-11-2018

I have a couple of Portal environments set up with a federated ArcGIS Server instance and I'm coming across the following logged error for each of them: The service is shared with our Portal organization and not publicly. After digging a little bit deeper into the logs, I noticed that the first time a user tries to establish a connection to the services the request comes across as anonymous and ultimately reports back the error above: Users access a web application that is hosted on a web tier machine, which is the bottom http refer link. Oddly enough users are still able to load the services with no problem as long as they are a named user. However, when I look in the ArcGIS Server logs it is flooded with "severe" level logs. Has anyone observed this issue before? The post ArcGIS Portal/Server Exception setting 'ownership' role. makes it sound like this isn't critical, but I'd like to elimate this issue from our logs. Our portal setup is as follows: Web adaptor/web app hosted on the same standalone box; leveraging IWA Portal on a standalone box ArcGIS Server on a standalone box Thanks!

‎03-13-2018

After mapping the drive and reconfiguring the the data stores, the web dr tool is working. Thank you for all your help Jonathan!

‎03-12-2018

Gene, As it turns out, we need to open up both port 443 on the web adaptor box and port 7443 on the portal box for the AirWatch VPN clients. I'm not exactly sure, but it seemed as though even when you try to hit the web adaptor at 443, the client will still need to contact the portal box directly. Thus every time I was trying to hit the portal for authentication I was being denied by the fire wall and getting a canceled response.

‎02-12-2018

After reconfiguring the data store in the primary environment and standby environment, the data store import was sucessful! Thank for you for the bug information Jonathan. Once I get the environments configured with the mapped drives my setup will hopefully be good to go!

‎02-09-2018

Yes to both.

‎02-09-2018

Jonathan, Thanks for the quick response. I'm using ArcGIS Enterprise 10.5.1 on Windows Server 2016 virtual machines. Regarding the data store here's the webgisdr log (I modified the URLs and server names to remove some sensitive info): ========================================== Starting the webgisdr utility. ========================================== The configuration and base backup time in the current Web GIS ------------------------------------------------------------- Portal: https://gis.domain.com/portal at 2/5/18 11:23 AM | |-- Federated Server: https://gis.domain.com/server at 2/5/18 11:23 AM | |-- Hosting Server: https://gis.domain.com/hostserver at 2/5/18 11:23 AM | | | |-- Data Store: https://standbydatastore.domain.com:2443/arcgis Unzipping the backup file The configuration and base backup time in the incoming Web GIS -------------------------------------------------------------- Portal: https://gis.domain.com/portal at 2/6/18 10:38 AM | |-- Federated Server: https://gis.domain.com/server at 2/6/18 10:38 AM | |-- Hosting Server: https://gis.domain.com/hostserver at 2/6/18 10:38 AM | | | |-- Relational Data Store: https://primarydatstore.domain.com:2443/arcgis Starting the restore of ArcGIS Data Store: Admin Url: https://standbydatastore.domain.com:2443/arcgis/datastoreadmin. Failed to restore the ArcGIS Data Store. Admin Url: https://standbydatastore.domain.com:2443/arcgis/datastoreadmin. {"jobId":"ccbf3243-1a03-496c-9b58-34cf2625c328","errorMessage":"Failed to import data to your replicated site.. Extended error message: Failed to import data to your replicated site.. Extended error message: D:\\arcgisdatastore\\data\\backupedContents20180206\\backup_DSBackup1","description":"Deploy data store snapshot February-6-2018-10-38-49-AM-CST-79-FULL from \\\\shareddrive\\GIS_Environments\\DR\\Backups\\WebGISSite1517941612799\\dataStore\\4525fa2f-8aeb-4913-bd13-63d812774562","lastModified":"2018-02-06 12:37","status":"failed"} Do I need to have a common alias for the data store servers as well? The standby host server logs state that are unable to find datastore "AGSDataStore_ds_6tnsqywy" and I noticed the standby environments data store has a different name. I'm unable to pull up the host server logs at the moment, but I will post that information when I can access them. Regarding the site replication. You hit the nail on the head. Both of our data centers are on the same network and I can't have duplicate server names. I'll start working on getting those mapped drives added.

‎02-09-2018

They are not the same. The the primary and standby environments have different locations: Primary Server - \\shareddrive\GIS_Environment\Server Standby Server - \\shareddrive\DR_Environment\Server The help arcticle below makes it sound like I should be able to import the primary export into a standby environment as long as the portal and server URLs are the same: Configure disaster recovery for ArcGIS Enterprise—Portal for ArcGIS (10.5.x) | ArcGIS Enterprise

‎02-09-2018

Hello, I'm currently testing the webgisdr utility and replicating a primary portal environment to a standby portal environment for disaster recovery. Each environment uses the same URL and references separate virtual IP addresses. My portal setup has a federated ArcGIS Server instance and a separate ArcGIS Server as the host server. I'm coming across two issues in the standby portal instance: The tool fails on the ArcGIS Data Store saying it is unable to find the data store in the standby environment since the names are different. Does the standby data store environment need to have the same database name? Besides the data store, everything seems to restore just fine. But, after futher investigation I noticed both the ArcGIS Server instances have had their directories changed to the same location as the primary environment. The site configuration file location for the standby sites are still the same. Is this normal behavior? I'm worried this will cause issues down the road when I'm importing the full site to the standby environment. I don't want to overwrite services that are in primary environment.

‎01-09-2018

Hello, I have setup ArcGIS Enterprise in a development environment that includes an ArcGIS web adaptor (IIS), portal and server all on separate virtual machines. For the web adaptor IIS settings, I have disable anonymous access and enabled windows authentication and have successfully tested IWA. Users are able to sign in through a web browser without providing any sort of credentials. I am now in the process of connecting Collector for ArcGIS to the portal on an iOS (iPad) device. The iPad is AirWatch enabled and successfully connects to our network. I select ArcGIS Enterprise and fill out the portal connection as https://.domain.com/portal , where portal is the name of the web adaptor. However, upon login I am unable to able to pass credentials through the sign in. I have try to include both the domain name formats (username@domain or domain\username) and without the domain with no luck. The only return is error "cancelled". I have some questions: Is it possible for iOS devices to log in through portal's web adaptor when IWA is enable while allowing single-sign on for web browsers on windows? The iPad is AirWatch enabled, however it does not pass on any credentials as a windows machine would. If I enable anonymous access through IIS the portal login pops up with no issue and I can log in, however users are required to provide their credentials when going through a web browser. I would like for Collector to log in at the same end point while maintaining windows single sign-on. If it is not possible for iOS devices to log in when IWA is enable, is a problem with have two web adaptors registered with the portal: one for IWA on web browsers (e.g. https://.domain.com/portal )and another for signing in with mobile devices (e.g. https://.domain.com/mobile)? The mobile web adaptor is only used to log in through Collector. I am able to connect to collector using the mobile web adaptor and sign in. Web maps show up, and I'm able to submit and view data. The only articles I could find were regarding highly available setups and a web adaptor on different machines with the same name. Thanks!

Online Status	Offline
Date Last Visited	‎03-02-2023 04:42 PM

My Ideas

Latest Contributions by SamJehle1

Re: Web GIS DR tool Stopped Working

Re: Web GIS DR tool Stopped Working

Re: Web GIS DR tool Stopped Working

Web GIS DR tool Stopped Working

Re: eDraw widget

Re: eDraw widget

Federated ArcGIS Server Logging Issue

Re: Standby Portal Webgisdr issues

Re: IWA and iOS

Re: Standby Portal Webgisdr issues

Re: Standby Portal Webgisdr issues

Re: Standby Portal Webgisdr issues

Re: Standby Portal Webgisdr issues

Standby Portal Webgisdr issues

IWA and iOS

Re: Authentication Issue using Survey123 Website

Re: Portal for ArcGIS 10.5.1: Extremely Slow Perfo...

Standby Portal Webgisdr issues

IWA and iOS

Portal 10.5.1 Forward Proxy