POST
|
Thank you everyone for your posts and contributions. Recently, I believe that I found the culprit for the issue. Short version: The network connection to the separate network share was not solid enough. When we changed to new network storage hardware, running webgisdr via a scheduled task now works properly. For how we identified the cause, please read the Long version. Long version: Back when things worked properly, the webgisdr backup files were first being stored on a data drive on the server. When the .website file became too large, I updated the webgisdr.properties file, to save the .website file to a network share. When that network share filled up (it was used by several other offices), I again updated the webgisdr.properties file, to save the .website file to a separate network shared device with lots of space. This device worked well with managing (automated cleanup) of all other backups. When I manually run the webgisdr utility, saving the file to the device also seemed to work fine. About three months ago, we replaced our portal server with a new one. In the process, as most of you know, we use the Join Site process, as documented online (Migrate ArcGIS Enterprise with the Join Site operation—Portal for ArcGIS | Documentation for ArcGIS Enterprise). In the Join Site process, the content directory is copied to a network share, where all the servers can access the folders. In our case, just to have lots of space, we used the same network share where our other backups go. With an eye of simplifying future server migrations, we opted to leave the content folder on that network shared device. Over the course of a few days, our Portal system experienced issues, giving errors about loss of network connectivity to the Content folder. We then decided to move the Content folder to the new server and this change solved the network connectivity issues. The issue seemed to be that the network connection was good enough for all of our other applications, but not good enough to support the ArcGIS Portal system. When we began to use the new network share hardware, I first ran webgisdr manually and confirmed that things worked properly. Then I tried running webgisdr via a scheduled task, with the destination on the new network share hardware. This time webgisdr worked via the scheduled task. So the cause of the problem was the network shared device. The device worked fine for all other uses, but it caused problems with our ArcGIS Portal system and the webgisdr utility running via a scheduled task.
... View more
01-27-2025
10:16 AM
|
0
|
0
|
323
|
POST
|
@JakeSkinner I followed the instructions and watched the video too. I am experiencing something odd. I updated my path, adding in the location for the runtime python folder. In the cmd window at c:\ , when I enter python, it cannot find it. When I enter webgisdr, it can find it. Any suggestions?
... View more
03-28-2024
03:19 PM
|
0
|
2
|
2759
|
POST
|
@HenryLindemann Thanks for the tip. I double-checked the start in parameter for quotes. There were no quotes present.
... View more
03-28-2024
03:11 PM
|
0
|
0
|
639
|
POST
|
Hi Ming, Thank you for your response. See my response to Henry. I agree with you, and I checked the permissions on the network share. I log into the server using the GIS service account, and run the webgisdr.bat file, and the Scheduled Task in Windows Task Scheduler as the GIs service account. The service account has full privileges on the server and on the network share, where the backups are being stored. It very puzzling that it works, as GIS service account, via cmd but not via Scheduled Task.
... View more
03-26-2024
03:31 PM
|
0
|
2
|
2795
|
POST
|
Hi Henry, Thank you for your response. I did not provide this info in my original problem description and I apologize. I log into the server using the GIS service account, and run the webgisdr.bat file, and the Scheduled Task in Windows Task Scheduler as the GIs service account. The service account has full privileges on the server and on the network share, where the backups are being stored. It very puzzling that it works, as the same user, via cmd and not via Scheduled Task.
... View more
03-26-2024
03:28 PM
|
0
|
0
|
2795
|
POST
|
We have each part of our portal running on a different machine. -Arc Server: Windows Server 2019 Standard, ArcGIS Server 10.9.1 -Portal: Windows Server 2012 R2 Standard, Portal for ArcGIS 10.9.1 -SQL Server: Windows Server 2019 Standard, SQL Server 2016 -Data Store: Windows Server 2012 R2 Standard, Data Store 10.9.1 -Image Server: Windows server 2012 R2 Standard, ArcGIS Server 10.9.1 -Clients running on Windows 10 SHARED_LOCATION in webgisdr.properties is on a network share, like the following example. SHARED_LOCATION=\\\\NetworkSharedFolder\\ServerBackups\\portalserver I can manually run the webgisdr.bat file on the portal server via cmd window, and it completes successfully. This is the command I use: webgisdr --export --file .\webgisdr.properties After things complete, I can see the final file 20240321-180336-PDT-FULL.webgissite in \\NetworkSharedFolder\ServerBackups\portalserver. However, when I run the webgisdr.bat file via the Windows Tasks Scheduler, I observe the following. - webgisdr says it completes successfully - I can see the temp folder in the Recycle Bin (because it deletes it after completing) - The webgissite file is missing on the NetworkSharedFolder I have run the webgisdr.bat via Windows Task Scheduler and the results are always the same. Some time ago, webgisdr.bat WOULD run via Windows Task Scheduler, but it has not for a while now. FYI: We plan to upgrade our ArcGIs system later this year. Has anyone else experienced this issue, or does anyone else run the webgisdr.bat from a scheduled task?
... View more
03-22-2024
11:01 AM
|
1
|
12
|
3580
|
POST
|
Speaking of the Portal server specifically, when we installed Portal (v10.5.1), it went into C:\Program Files\ArcGIS\Portal. After creating our portal, there was also the C:\arcgisportal, where the content apparently goes. I was able to use the webgisdr tool (C:\Program Files\ArcGIS\Portal\tools), to successfully make a backup of our Portal system. Later, we had a failure and had to restore from the webgisdr backup. Unfortunately, the Datastore and ArcGIS Server backups restored fine, but the Portal part did not. Since the content went into C:\arcgisportal, it seemed that all IT had to backup from their side, was this folder. Our IT folks do not usually do full disk images on servers. During the troubleshooting, I learned that the C:\arcgisportal folder is insufficient to restore from (for just the Portal part). What must we have our IT folks backup, so that we can restore the enough of the disk, to come back up, if the webgisdr backup has a problem?
... View more
10-04-2019
04:20 PM
|
0
|
1
|
540
|
POST
|
Version: Windows, 10.5.1 (soon to upgrade to 10.7.1) Background: Before I knew about the deletebackup utility, I manually deleted some old tilecache backups, via windows explorer. Now that I know about the utility, and listbackups, these old backups are still showing in listbackups. When I try to use deletebackup on the applicable backups, it gives me this error. command: deletebackup [TheBackupName] Result: Error encountered: Backup [TheBackupName] doesn't exist in current data store. Is there any way to clean out the entries that no longer have backups associated to them?
... View more
09-30-2019
05:20 PM
|
0
|
0
|
451
|
POST
|
Thanks guys! Your replies are helpful. @Jake: Thanks for this very specific info; it answered my question.
... View more
09-05-2019
08:23 AM
|
0
|
0
|
1061
|
POST
|
We have two ArcGIS systems. System one (call it ArcGIS Enterprise) has ArcGIS Server on one machine (call it server1), and the geodatabase resides on a separate server running SQL Server (call it sql1). System two (call it Portal) is a Portal, with its parts also running on separate dedicated machines. For the question, we can label them as follows: Server, server2; Portal, portal1; Data Store, ds1). The Portal also points to and uses the geodatabase on the SQL Server machine (sql1) in System one as a database. The Portal Data Store machine has a smaller (C:, primary) and larger (E:, secondary) hard drives. We installed the Data Store on the larger, secondary drive (E:, 100 GB). While we currently use the Data Store some, we mainly rely on the geodatabase on sql1. We are about to upgrade from 10.5.1 to 10.7.1. Prior to doing the upgrade, we want to back things up. Since we installed our Data Store on the "secondary" drive of its machine, due to its larger size, where are hosted feature datasets stored? It seems (from reviewing in This PC) that things are only getting stored on the E:, but I want to verify, before getting started, that the Data Store DOES NOT store things on the C: (primary) drive, somewhere that I have not looked.
... View more
09-04-2019
04:35 PM
|
0
|
3
|
1118
|
POST
|
Hi Jake, Do you know if the most recent version of ArcSDE supports column with IDENTIFY properties? It has been three years, and I was wondering it this capability is available now. George
... View more
10-15-2018
02:02 PM
|
0
|
1
|
2349
|
POST
|
Firstly, thanks to Asrujit and Rex for your assistance, I appreciate it. For a reason unrelated to this issue, at the end of the day, we restarted our ArcGIS server. We added RAM and had to restart. After restarting, Tina M. (ESRI Tech) called. We opened ArcCatalog again, to see review the situation. This time the Enable Geodatabase text color was black again, without us doing anything. Never the less at my request, we went through the process of dropping the database, and bringing it back in, and things worked OK. It seems that something was amiss with the server, and when my folks restarted it, the problem cleared. For the benefit of anyone else who finds this discussion, I will summarize and include some info, for other “newbees” like me. Before starting, note that we cannot use a Basic License to do this task (from Asrujit). (from Tina) Steps to create the geodatabase. Create your SQL Server database in SQL Server Create your database connection in ArcCatalog Enable the database as a geodatabase using ArcCatalog - Open the database connection - In the Catalog Tree, right-click on the database connection and select Enable Geodatabase Register the database connection in ArcGIS for Server Steps to delete the geodatabase (the official way) -- How to clean out a database and start over. In ArcCatalog remove the connection from the data store In ArcCatalog, remove the database connection In SQL Server, drop the database In my case today, what we did was… - In SQL Server, just drop the table again - In SQL Server, restore it from the same backup as I did before, so it had the same name as I wanted - In ArcCatalog, since I still had the database connection, right-clicked on Enable Geodatabase - We checked the database properties, and the table was already registered Conclusion: What I was trying to do earlier should have worked, but something was amiss and restarting our ArcGIS server cleared that problem. After the restart, everything worked properly.
... View more
06-24-2016
08:57 AM
|
1
|
0
|
4278
|
POST
|
No. We are using ArcGIS 10.3.1 for Desktop License type: Advanced. If I create a connection to one of our other "regular" SQL Server databases, the Enable Geodatabase... option text color is black. When I started this process, the option text color was black also, but it changed to grey, after I ran the Enable Geodatabase process, which made sense.
... View more
06-23-2016
02:25 PM
|
0
|
0
|
3596
|
POST
|
Here is some additional info that may or may not be helpful. We have our ArcGIS (version 10.3) running on one server. Our SQL Server (V2012) is on a different server. I am running ArcCatalog (10.3.1) from a laptop running Windows 7 Ultimate SP1.
... View more
06-23-2016
01:54 PM
|
0
|
2
|
3596
|
Title | Kudos | Posted |
---|---|---|
1 | 03-22-2024 11:01 AM | |
1 | 06-24-2016 08:57 AM |
Online Status |
Offline
|
Date Last Visited |
01-27-2025
06:34 PM
|