schedule a task on a W2003 server to run on a w2008 server is slow when users are accessing w2008

Alle Antworten

• Freitag, 9. September 2011 18:53

   

   
  

  0
  Hi,
  
  My guess is that you are referring to slowness with a job that is accessing a mapped network drive or UNC share. This slowness is due to difficulties with older operating systems accessing shares when they are hosted on a system that is running SMB 2.0. To Disable SMB 2.0:
  
  

  sc config lanmanworkstation depend= bowser/mrxsmb10/nsi

  sc config mrxsmb20 start= disabled

  
  If you upgrade the 2003 system and want to re-enable SMB 2.0:
  
  

  sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi

  sc config mrxsmb20 start= auto

  
  

  If this isn't the case, what exactly is the slow job doing?
  

  
  

  ---

  -- Mike Burr
  Technology
  • Antworten
  • Zitieren

   
• Samstag, 10. September 2011 07:59

  Moderator

   

   
  

  0

  Hi,

   

  Thanks for posting here.

   

  After reading you post I understand that you are facing a slow performance issue on Windows Server 2003 when attempt to execute a program where stored and shared on a remote Windows Server 2008 fileserver .

  If misunderstand please let me know.

   

  Have you also tried to manually execute remote program file with the same way that defined in batch file? will get same phenomenon ?

   

  You mentioned that this issue will occur only when these remote program and data files were also been locked by other users at same time, this made me believe that the program might not been designed or optimized for multi user environment perhaps.

   

  Will you also encounter performance issue when attempt to transfer files between these two server host via SMB protocol?

   

  Thanks.

   

  Tiger Li

  ---

  Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.
  • Antworten
  • Zitieren

   
• Dienstag, 13. September 2011 15:07

   

   
  

  0

  Hi Mike;

  Thanks for the suggestion.

  The batch file does map two drives to the W2008 Server( shared directory) and then executing the program, which resides on the w2008 server as well as the data.

  This is a new server and not an upgrade from W2003 server.

  If I execute the same batch file as a scheduled task on the W2008 server it runs fast and there is another user accessing the files.

  If I execute the same batch file as a schedule task on the W2003 server it runs slow and there is anotehr user accessing the files.

  If there is no one accessing the files on the W2008 server, the process runs fast either started from  the W2003 or W2008 server.

  I will see if SMB2.0 is enabled on the W2008 server and if it is disable it and see what happens.

  • Antworten
  • Zitieren

   
• Dienstag, 13. September 2011 15:14

   

   
  

  0

  Good Morning and thanks for reply;

  You are correct that the program and data is on the W2008 server yet the batch file that is a scheduled task is from the W2003 server.

  If I schedule the task on the W2008 server it runs fast, so I am thinking that it is something going on between the w2003 server and the w2008 server.  I do map two drives to the W2008 server in the batch file.  The P is mapped to a shared directory and U is mapped to a subdirectory down one tree level.

   

  Here is the contents of the batch file.

  SET COBSW=-F+B2
  SET COBDIR=P:\programs\;U:\
  SET PHXDIR=P:\ftpdata\
  SET RPTDIR=P:\USERS\FUNDUSER\REPORTS\
  SET NSCCDIR=P:\users\funduser\nscc\
  SET SECDIR=P:\SECURITY\
  SET ACFDIR=P:\ftpdata\
  SET MPACSDIR=
  net use P: \\Phx01w2k8r201\Shared_Data
  net use U: \\Phx01w2k8r201\Shared_Data\mfappsrv5.1\bin
  SET PATH=%COBDIR%;%PATH%
  U:\run sbdexbeg

  • Antworten
  • Zitieren

   
• Freitag, 16. September 2011 02:14

   

   
  

  0

  Hi,

  I noticed that you have already perform the following test:

  1. If I execute the same batch file as a scheduled task on the W2008 server it runs fast and there is another user accessing the files.

  2. If I execute the same batch file as a schedule task on the W2003 server it runs slow and there is anotehr user accessing the files.

  3. If there is no one accessing the files on the W2008 server, the process runs fast either started from the W2003 or W2008 server.

  As we known, when someone is read a file, others can read it and edit it. But when someone is editing it, other can only open it as "read mode" and wait.

  So, i guess in the test 1, another user have not edited the files. But in the test 2, the files has been holded by the another user, so the batch file (Scheduled Task) needed wait for releasing.

  To narrow down this issue, please peform the following test:

  1. Run the task on W2003 when another user was just "read" the affected files.

  2. Run the Task on W2003 when another user was "edit" the affected files.

  Thanks.

  ---

  “Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.”
  • Antworten
  • Zitieren

   
• Freitag, 11. Mai 2012 17:56

   

   
  

  0

  I don't know if you ever found a solution to your problem, but we ran into similar issues when scheduling Phoenix jobs, as well (which seems to be what you are dealing with).  They were not able to provide a solution, but we managed to find a way around it.  If it would work for you, you should consider using Windows Remote Management.  Similar to using a RemoteApp in a Windows Remote Desktop Services session, winrs is a command that lets you run a console app/process on another machine, but get any error codes and output locally.  So, for example, you could schedule the batch file on your W2003 server, but the process would actually run on the W2008 server.

  To get started, run the following command on the W2008 server, and respond to the prompts that follow, to enable Windows Remote Management:

  winrm quickconfig

  Then, put the batch file, generated by Phoenix, somewhere on the W2008 server (not the W2003 server).  For example:

  C:\PhxBatch\PhxJob.bat

  Then, schedule the following command to run on the W2003 server:

  winrs -r:phx01w2k8r201 C:\PhxBatch\PhxJob.bat

  This will run the batch file as a process on the W2008 server, sending all stderr/stdout to the calling process on the W2003 server.  Just note that the user running this will need all appropriate permissions on the W2008 server to A) access the batch file and run it and B) access the Phoenix data/programs.  As long as you set the schedule to run as a user with those permissions, this should resolve any speed issues you are seeing.

  ---

  - GT

  
  

  • Als Antwort vorgeschlagen Grant Tregay Freitag, 11. Mai 2012 18:00
  • Bearbeitet Grant Tregay Freitag, 8. Juni 2012 22:09 winrs command line should not have included 'file:' before server name.
  •  
  • Antworten
  • Zitieren