Latest Contributions by JonathanQuinn

I wouldn't think it would be a problem for Portal and Server to be on separate domains yet use IWA for Portal.  The reason is because Server doesn't need any access to the Portal AD.  All of the authentication occurs on the Portal end and then, I believe, simply sends the authorization information that's already validated to the Server.  If the user can be validated in the Portal, then they should be able to reach the service.  I'm not sure your setup is very common though and there could be some unknowns or "gotchas" involved. ... View more

Simulating a disk failure may be hard, but if you're on a VM, you can shut down the VM through the VM management console instead of shutting down the actual machine.  If it's a physical machine, unplugging the ethernet cord simulates a network outage. ... View more

Ahh, sorry, Lloyd, I meant to update it to arcpy.AddMessage(<message>).  You'll never see print statements when running a GP tool or GP service.  If you still have your try: except block, remote that and let errors come back directly through the GP service. You don't need to set any scratch workspaces, folders or geodatabases.  The default path for them is correct.  For ease of use, simply use the default of arcpy.env.scratchFolder to construct the path to output data that exists in folders. The scratch folder doesn't need to be registered on the Server, as it knows it can write to the directory already, (providing it's left at the default location).  I wouldn't think that the raster data location is a problem, as it would fail earlier in the script. ... View more

Stopping the Data Store service doesn't cause a failover, as that's considered a deliberate action.  To cause a failover, the machine needs to have a disk or network failure, (again, not simply stopping/shutting down the machine). ... View more

The standby machine shouldn't have a .done file, only a .conf file and .conf.bak file.  If it has a .done but it's still the standby, that indicates that while failover was happening, the standby was stopped/restarted as well, which disrupted the failover.  In this case, failover will never fully complete because that file indicates that the DB has failed over, which is why you see those errors in the logs.  If you remove the .done file so you only have the .conf and .conf.bak, you should see a proper failover when you stop the primary. ... View more

You should print the traceback error, as there's no way to know why it failed if it's in your try: except block.  Can you update line 65 to: print "Error updating CFS Charts spreadsheet from template\n{0}".format(traceback.format_exc()) You can parse out the traceback error however you like, but it's important to return it.  In this case, it may be best to remove the try: except block so you can return all of the messages within the GP service framework.  Be sure to import the traceback module at the beginning of your script. ... View more

Thanks for posting this idea, Bill! ... View more

Unfortunately, there's no built-in mechanism to send emails when WARNING or SEVERE logs appear.  The approach would be to run a script at a prescribed time to query the logs for specific messages or codes and send emails if necessary.  We're know that such a system is necessary, though, so it's something we'll be looking at for later releases. ... View more

It sounds like there are two problems.  If you have a primary and standby, both running and healthy, the standby should have a recovery.conf file, not a recovery.done file and possibly a recovery.done.  The presence of a recovery.done file tells the standby Portal it has successfully promoted itself to the primary, which is why you don't see the fail over in "normal" circumstances, (you simply stop the primary while the standby is running). Your next problem is a current limitation that we're looking to improve upon for later releases.  The next problem is a timing thing.  If you stop the standby, primary removes it from the HA configuration to make sure that it knows the standby is done.  Once the standby comes up again, it adds it back.  If you stop the standby and then stop the primary, and finally start the standby, it won't promote itself to primary because it won't have the latest snapshot of the data from the primary database, (since it was down).  If it were to promote itself, you will have lost any data created on the primary while the standby is down, since the data wasn't replicated from the primary to the standby.  In your case, where you stop both machines, it sounds like a similar scenario.  Based on the timing of when you stop both, the standby may have stopped first, and then the primary.  When you start the standby, it won't promote itself as that would potentially cause data loss. **Edit: it's fine if one or both machines have a recovery.done file within the db directory. That's an indication that it had at some point, promoted itself to primary. The presence of the file won't affect future failover/failbacks. ... View more

If the Excel file isn't generated, then we should focus on that first before looking into running the .vbs script.  What version are you using?  If you're creating an .xls file, what if you use arcpy instead?  I'm not sure if you use your other module due to a formatting thing. What is the spreadsheet_template_filepath variable set to?  I imagine the GP service would fail if Server couldn't access the file.  Can you add a message for the Excel variable and see what it returns, (arcpy.AddMessage(Excel).  It may not be the actual data but at least you can verify if it's opening the template Excel file or not.  I wouldn't move anything within wwwroot, because then you introduce latency going through your web server. ... View more

Hi Ahmed, It doesn't appear that the standby Portal completely promoting itself to primary.  If it did, it would attempt to connect to it's own database, not the previous primary database.  In the db folder of the standby, do you see a recovery.conf or a recovery.done file? ... View more

The arcpy.env.scratchFolder environment variable is set for you when you run the GP service.  There's no need to set it to anything within your script.  Simply construct the path to your output data using the arcpy.env.scratchFolder environment variable: vbs_filepath = os.path.join(arcpy.env.scratchFolder,"Build_raster_Charts.vbs") Do you see your "Failed to create .vbs file" message?  Is there anything in the server logs?  Try to set the logs to DEBUG. ... View more

The scratch folder is set automatically by the software in both ArcMap and ArcGIS Server.  In ArcMap it'd be set to C:\Users\<your_username>\Documents\ArcGIS\scratch by default, and on the Server it'll be set to C:\arcgisserver\directories\arcgisjobs\<service_name>\<unique_jobID>\scratch.  It will create this folder whenever the service is run and put any intermediate or output data there.  You don't need to overwrite it within your script, just use arcpy.env.scratchFolder to call on it Ex. vbs_filepath = os.path.join(arcpy.env.scratchFolder,"Build_raster_Charts.vbs")‍ arcpy.env.scratchWorkspace is the <unique_jobID> folder and arcpy.env.scratchGDB is the <unique_jobID>\scratch.gdb file geodatabase. This may not specifically address the problem you're running into, but it's a best practice and can help to make sure that things are written to the jobs directory correctly.  What you can also do is add a few more arcpy.AddMessage print statements so you get a better indication of how far along the script has progressed, for example: arcpy.AddMessage("Creating .vbs file.") ... arcpy.AddMessage("Created .vbs file.")‍‍‍ ... View more

So if you were to sign in to your organization, and then go to the map viewer, ensure it's accessed over http, and then add the service accessed via http, you get the "Unable to create a secure connection" error?   What browser are you using? ... View more

Is that the syntax within the unpublished script, or the published one?  What happens if you construct the path using the os.path.join function and the scratch folder environment variable: vbs_filepath = os.path.join(arcpy.env.scratchFolder,"Build_raster_Charts.vbs") csv_filepath = os.path.join(arcpy.env.scratchFolder,"{0}.csv".format(local_label) By doing this, you use the scratch workspace of the Server when running the GP service, (the arcgisjobs directory), to maintain unique job folders for each run of the tool that are cleaned up automatically by the software.  Typically, the published script will be updated to use this directory during the publishing process.  Also, using os.path.join avoids potential path problems when publishing GP services. ... View more