Run webgisdr via Windows Tasks Scheduler

[GeorgeClark]

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?

[HenryLindemann]

HI @GeorgeClark, Scheduled Tasks can be problematic sometimes, please have a look under actions did you specify a start in parameter if this parameter has quotes then remove them, also the scheduled task will execute in No-Guie environment so if you have any screen prints comment them out.

Regards

Henry

[GeorgeClark]

@HenryLindemann Thanks for the tip.  I double-checked the start in parameter for quotes.  There were no quotes present.

[GeorgeClark]

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 ...).  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.