Problema di autorizzazione solo quando il percorso exe è completo. Perché non sempre?

Question

Quando provo ad eseguire l'SQL Server 2012 BCP.exe utilità per scaricare il contenuto di una tabella in un file utilizzando un percorso completo per l'exe,

D:\SQL2012\110\Tools\Binn\bcp.exeDBNAME.DBO.TABLENAME OUT %FileServerProject%\IMPLEMENTATION\DAT\Pre_Run_BaseTables\CDB_ACCT_CURR.DAT -S%SqlServer% -T -N >> %LogFolder%\Log.log

.. .Vedo un errore ACCESS DENIED.

Tuttavia, quando rimuovo il percorso completo per l'exe ed eseguire,

bcp.exeDBNAME.DBO.TABLENAME OUT %FileServerProject%\IMPLEMENTATION\DAT\Pre_Run_BaseTables\CDB_ACCT_CURR.DAT -S%SqlServer% -T -N >> %LogFolder%\Log.log

Funziona benissimo.

Se il percorso non è qualificato, il mio intendimento è che Windows cercherà ogni cartella specificata nella variabile ambientale PATH cercando l'exe specificato ed eseguirà il primo trovato. Così, ho eseguito il seguente comando dalla console per vedere la mia variabile PATH.

ECHO %PATH% 

Ripulire i percorsi non collegati vari dall'uscita, ho visto la seguente cartella SQL legati restituito in questo ordine:

D:\SQL2012\110\DTS\Binn\; 
D:\SQL2012 (86)\110\Tools\Binn\; 
D:\SQL2012\110\Tools\Binn\; 

Quest'ultimo Tools\Binn percorso è stata l'unica cartella che conteneva l'utilità bcp.exe .

mia domanda è questa:

Poiché la stessa EXE è stato eseguito se mi sono qualificato in modo esplicito il percorso o sinistra di Windows per trovarlo cercando la variabile di percorso, perché ho ricevuto un errore di accesso negato quando mi sono imbattuto con il percorso completo e non quando non ho qualificato il percorso?

Si noti che in entrambi i casi ero in esecuzione con un ID che aveva letto ed eseguito i diritti per la cartella TOOLS\BINN. Nel caso in cui stavo utilizzando il percorso completo, se avessi aggiunto l'account al gruppo Locale, avrebbe funzionato, ma questa non era una soluzione praticabile. Inoltre, l'ID aveva i diritti LogOn As Batch sul server.

Aggiornamento:

Ora ho alcun dubbio che quando eseguo utilizzando il bcp.exe percorso qualificato che io sono in realtà eseguendo l'unica copia del bcp.exe sul server. Per cominciare, ho usato Cerca tutto per cercare estensivamente tutte le unità sul server. Ho trovato tre occorrenze. Ho quindi ribattezzato il 2 che non volevo fare accidentalmente riferimento.

Ho poi reran il processo utilizzando il qualificato bcp.exe percorso e utilizzando processo scheda del Task Manager, ho trovato bcp.exe in esecuzione con l'account di servizio.Ho quindi fatto clic con il pulsante destro del mouse sul nome del file e selezionato il menu di scelta rapida "Apri posizione file", e mi ha portato all'unica posizione del file bcp.exe che non è stato rinominato, il file che stavo intenzionalmente cercando di indirizzare con il nome qualificato.

D:\SQL2012\110\Tools\Binn

Dal momento che il bcp.exe non era qualificato, è stato eseguito correttamente.

Aggiornamento 2 Finora, 42 persone hanno guardato questo. Sarei curioso se le persone guardino questo detto "è impossibile, che i fatti di questo caso non debbano essere esattamente come ho detto".

Quasi lì: Ho semplificato il file batch fino al minimo necessario per riprodurre il problema. Noterai che ho cambiato i nostri veri percorsi, ma ne ho mantenuto il senso.

Ecco la "Prima" Codice:

---------------------------------------------------------------- 
Output of messages for workload object TESTDUMP/GHG9999I.11/MAIN 
Start date Fri Sep 25 13:33:36 2015 
---------------------------------------------------------------- 

C:\Users\MyServiceAccount>WHERE bcp.exe 
INFO: Could not find files for the given pattern(s). 

C:\Users\MyServiceAccount> D:\SQL2012\110\Tools\Binn\bcp.exe MyDB.DBO.MyTable OUT \\MyFileServer\IMData\MyDB_SOURCE\IMPLEMENTATION\DAT\Pre_Run_BaseTables\MyTable.DAT -S MyDbServer\int -T -N 1>>\\MyFileServer\IMData\MyDB_SOURCE\Logs\MyTable_BCP_out.log 
Access is denied. 

C:\Users\MYSERVICEACCOUNT>ECHO RESULT=1 
RESULT=1 

Ecco il "dopo", che ha lavorato

---------------------------------------------------------------- 
Output of messages for workload object TESTDUMP/GHG9999I.10/MAIN 
Start date Fri Sep 25 13:33:00 2015 
---------------------------------------------------------------- 

C:\Users\MyServiceAccount>WHERE bcp.exe 
INFO: Could not find files for the given pattern(s). 

C:\Users\MyServiceAccount>"D:\SQL2012\110\Tools\Binn\bcp.exe" MyDB.DBO.MyTable OUT \\MyFileServer\IMData\MyDB_SOURCE\IMPLEMENTATION\DAT\Pre_Run_BaseTables\MyTable.DAT -S MyDbServer\int -T -N 1>>\\MyFileServer\IMData\MyDB_SOURCE\Logs\MyTable_BCP_out.log 

C:\Users\MYSERVICEACCOUNT>ECHO RESULT=0 
RESULT=0 

nota che la differenza è che il percorso BCP che ha funzionato è stato racchiuso tra virgolette. Avrei pensato che sarebbe stato importante solo se il percorso contenesse spazi incorporati. Sono confuso perché è importato in questo caso.

Una seconda preoccupazione secondaria è il motivo per cui il comando WHERE non è riuscito a funzionare quando è in esecuzione in MYSERVICDEACCOUNT tramite uno scheduler. Il comando funziona quando effettuo l'accesso manualmente sotto MYLANID, passa a c:\users\mylanid e provalo.

Se qualcuno può spiegare perché le citazioni sono importanti, ottengono 100 punti e la mia gratitudine.

Update 4:

mi trova il file AgentParm.txt su un server in cui lavora lo stesso codice. E 'stato sotto la cartella Programmi:

# Agent settings for nt-x86-64 
agentname=MyWorkingServer 
log.archive=2 
oscomponent.jvm=server 

Sul server che abbiamo discusso in cui ho il problema quando il file batch è non quotato, vedo il seguente nella cartella Program Files (x86). Tutte le altre linee erano uguali, quindi le ho escluse. Non ho visto nessuno menzionato su oscomponent.cmdprefix.force.quotes.full.

# Agent settings for nt-x86-32 

agentname=MyServer 

Ho bisogno della versione a 64 bit di CA scheduler per eseguire 64 bit exes? In tal caso, avrò un problema che esegue exe a 32 bit (come SQL Server dtexec.exe) con lo scheduler CW a 64 bit?

Answer 1

Potrebbe avere qualcosa a che fare con ciò che hai indicato? probabilmente inavvertitamente

32Bit D:\SQL2012 (86)\110\Tools\Binn\ 64Bit D:\SQL2012\110\Tools\Binn\ il tuo percorso difficile sta chiamando a 64 bit e la tua variabile %PATH% sta trovando prima la versione a 32 bit.

Answer 2

Non ho familiarità con lo scheduler di CA Workload Automation, ma si sta utilizzando la sintassi JIL quando si specifica il lavoro?

Una ricerca di documenti di supporto sembra indicare che i due punti (":") sono un carattere speciale in JIL e devono essere sfuggiti da virgolette o backslash.

Rule 5 
Valid value settings can include any of the following characters: 
■ Uppercase and lowercase letters (A-Z, a-z) 
■ Hyphens (-) 
■ Underscores (_) 
■ Pound signs (#) 
■ Numbers (0-9) 
■ Colons (:), if the colon is escaped with quotation marks (" ") or a preceding backslash (\) 
■ The at character (@) 
Note: Object names can only contain the following characters: a-z, A-Z, 0-9, period (.), underscore (_), hyphen (-), and pound (#). Do not include embedded spaces or tabs. 

Answer 3

Questo non è esattamente la stessa situazione che hai descritto, ma sembra che esso può avere la stessa causa principale e correggere. documentation here (p45) descrive una situazione in cui i lavori con percorsi qualificati passati a CA Workload Automation Agent in Windows si comportano in modo imprevisto quando vengono citati. Questo vale per i percorsi sia con che senza spazi.

In poche parole - sembra essere stata fissata con l'aggiunta di un parametro oscomponent.cmdprefix.force.quotes.full al file agentparm.txt, che è possibile impostare per true o false a seconda del comportamento che si desidera.

La situazione descritta non esattamente partita vostro, quindi non sono sicuro al 100% questa è una correzione, ma varrebbe la pena di commutazione che l'impostazione per verificare se è attivato il comportamento si osserva.