UNC Connection issues Windows 2016 Server

%3CLINGO-SUB%20id%3D%22lingo-sub-1211857%22%20slang%3D%22en-US%22%3EUNC%20Connection%20issues%20Windows%202016%20Server%3C%2FLINGO-SUB%3E%3CLINGO-BODY%20id%3D%22lingo-body-1211857%22%20slang%3D%22en-US%22%3E%3CP%3ECurrently%20we%20are%20running%20a%203%20tiered%20environment%2C%20Web%20Server%2C%20App%20Server%20and%20Data%20server.%26nbsp%3B%20We%20have%20a%203rd%20party%20scheduling%20software%20that%20is%20installed%20on%20the%20App%20server.%26nbsp%3B%20This%20software%20basically%20runs%20a%20bunch%20of%20jobs%20for%20a%20slew%20of%20things.%26nbsp%3B%20The%20issue%20we%20are%20experiencing%20is%20if%20the%20environment%20is%20dormant%20for%20x%20amount%20of%20time%20the%20first%20job%20that%20tries%20to%20communicate%20to%20the%20data%20server%20will%20fail%2C%20but%20if%20we%20rerun%20that%20same%20job%20shortly%20after%20the%20failure%20it%20completes%20fine%20and%20we%20are%20off%20and%20running.%26nbsp%3B%20Everything%20in%20the%20environment%20is%20running%20Windows%202016.%26nbsp%3B%20Data%20server%20is%20running%20SQL%202016%20w%2F%20SP2.%26nbsp%3B%20The%20app%20server%20has%20our%20in%20house%20developed%20application%2C%20Web%20server%20is%20not%20even%20in%20play%20for%20the%20%22batch%20process%22.%26nbsp%3B%20This%20issue%20ONLY%20seems%20to%20be%20showing%20up%20when%20we%20run%20out%20nightly%20batch%20cycle.%26nbsp%3B%20Again%20from%20the%20app%20server.%26nbsp%3B%20So%20that%20is%20what%20we%20are%20experiencing...what%20we%20think%20is%20the%20issue%3A%3CBR%20%2F%3E%3CBR%20%2F%3EWe%20think%20we%20are%20having%20a%20UNC%20timeout%2C%20since%20when%20the%20app%20server%20needs%20to%20talk%20to%20the%20Data%20server%20it's%20normally%20in%20a%20%5C%5Cservername%5Cshare%20or%20%5C%5Cservername%5Cadmin%24share%20format.%26nbsp%3B%20And%20unfortunately%20we%20can't%20duplicate%20the%20error%20on%20demand%2C%20but%20it's%20a%20consistent%20issue%20that%20if%20nothing%20is%20going%20on%20in%20the%20environment%20and%20we%20try%20to%20run%20the%20batch%20cycle%20and%20the%20first%20hit%20to%20the%20data%20server%20it%20fails.%26nbsp%3B%20We%20don't%20know%20how%20long%20we%20have%20to%20wait%20for%20it%20to%20happen.%26nbsp%3B%20But%20if%20we%20re-run%20that%20failed%20job%2C%20it%20runs%20fine%20with%20no%20issue.%26nbsp%3B%20It's%20NOT%20the%20Scheduling%20Software%20since%20the%20issues%20happens%20if%20we%20run%20that%20same%20job%20from%20a%20command%20prompt...if%20it%20fails%2C%20re-running%20it%20a%20second%20time%20works%20just%20fine.%26nbsp%3B%20But%20again%20when%20the%20systems%20are%20dormant.%26nbsp%3B%20If%20someone%20is%20in%20there%20working%20between%20the%20App%20and%20Data%20server%20and%20tries%20to%20run%20a%20job%2C%20no%20issue.%3C%2FP%3E%3CP%3E%26nbsp%3B%3C%2FP%3E%3CP%3ESuggestions%3F%26nbsp%3B%26nbsp%3B%3C%2FP%3E%3C%2FLINGO-BODY%3E
Occasional Visitor

Currently we are running a 3 tiered environment, Web Server, App Server and Data server.  We have a 3rd party scheduling software that is installed on the App server.  This software basically runs a bunch of jobs for a slew of things.  The issue we are experiencing is if the environment is dormant for x amount of time the first job that tries to communicate to the data server will fail, but if we rerun that same job shortly after the failure it completes fine and we are off and running.  Everything in the environment is running Windows 2016.  Data server is running SQL 2016 w/ SP2.  The app server has our in house developed application, Web server is not even in play for the "batch process".  This issue ONLY seems to be showing up when we run out nightly batch cycle.  Again from the app server.  So that is what we are experiencing...what we think is the issue:

We think we are having a UNC timeout, since when the app server needs to talk to the Data server it's normally in a \\servername\share or \\servername\admin$share format.  And unfortunately we can't duplicate the error on demand, but it's a consistent issue that if nothing is going on in the environment and we try to run the batch cycle and the first hit to the data server it fails.  We don't know how long we have to wait for it to happen.  But if we re-run that failed job, it runs fine with no issue.  It's NOT the Scheduling Software since the issues happens if we run that same job from a command prompt...if it fails, re-running it a second time works just fine.  But again when the systems are dormant.  If someone is in there working between the App and Data server and tries to run a job, no issue.

 

Suggestions?  

0 Replies