none
Diritti per riavviare un pool in IIS RRS feed

  • Domanda

  • [Win Server 2008]
    Ci sono gruppi in cui inserire un utente affinché abbia il diritto di riavviare un'applicazione dall'Application Pool di IIS7 (tramite batch che ho già creato) senza, però, che abbia diritti amministrativi sugli altri ruoli del server?

    venerdì 19 aprile 2013 14:52

Risposte

Tutte le risposte

  • invece di fornire una mezza soluzione già realizzata (come dico sempre) puoi spiegare l'esigenza primaria ?

    perché c'è la necessità di far riavviare una applicazione ad un umano :-)  quando già ci sono le impostazioni di recycling del worker process

    http://msdn.microsoft.com/en-us/library/aa720473(v=vs.71).aspx

    a fare proprio questa cosa ?

    cosa non funziona in questa web app ?


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    sabato 20 aprile 2013 09:34
    Moderatore
  • Sono d'accordo con Edoardo, è strano che tu abbia la necessità di riavviare il pool manualmente....

    Comunque non credo che esista un modo per creare una delega vera e propria per l'utente, si potrebbe creare uno script avviato con privilegi amministrativi (ad esempio tramite CPAU o runas) che richiama una riga di comando "appcmd" opportunamente configurata e far utilizzare all'utente direttamente il collegamento allo script, oppure sfruttare uno script remoto WMI.

    Trovi ulteriori informazioni su come richiamare "appcmd" o sullo script WMI qui: http://technet.microsoft.com/it-it/library/cc770764(v=ws.10).aspx


    sabato 20 aprile 2013 10:45
    Moderatore
  • Sky sei fortunato da iis 7 è possibile usare un accrocchio per riavviare un pool, vedi i link sotto (per questa problematica in precedenza ho usato un task temporizzato che cerca in una dir un file con il nome del pool da riavviare, l'utente delegato ovviamente aveva il permesso di scrivere in questo folder...)

    IIS 7 Delegate Remote Application Pool Recycling for Non Administrator http://blogs.msdn.com/b/asiatech/archive/2011/07/21/iis-7-delegate-remote-application-pool-recycling-for-non-administrator.aspx

    Operations on application pools as admin and non-admin http://blogs.iis.net/msdeploy/archive/2010/09/22/operations-on-application-pools-as-admin-and-non-admin.aspx


    Gastone Canali >http://www.armadillo.it

    Se alcuni post rispondono al tuo quesito (non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili . GRAZIE! Ricorda di dare un occhio anche QUI

    sabato 20 aprile 2013 14:28
    Moderatore
  • Non sapevo di questa possibilità, il link è interessante.

    sabato 20 aprile 2013 14:49
    Moderatore
  • Edoardo Benussi [MVP] ha usato la sua tastiera per scrivere :

    invece di fornire una mezza soluzione già realizzata (come dico sempre) puoi spiegare l'esigenza primaria ?

    perché c'è la necessità di far riavviare una applicazione *ad un umano :-)*  quando già ci sono le impostazioni di recycling del worker process

    http://msdn.microsoft.com/en-us/library/aa720473(v=vs.71).aspx

    Non devo riavviare l'applicazione regolarmente, ma solo se e quando si verifica l'anomalia che sto cercando di correggere.


    a fare proprio questa cosa ?

    cosa non funziona in questa web app ?

    E' un gestionale che ogni tanto (per fortuna non spesso), per qualche ragione che non ho ancora capito, butta fuori tutti e poi si rifiuta di autenticare gli utenti che cercano di rientrare. Sto aspettando una risposta dall'assistenza ma nel frattempo devo tamponare. Riavviando l'applicazione in IIS, riprende a funzionare tranquillamente ma non posso sempre collegarmi io per farlo.

    Penso che applicherò la soluzione di Gastone: Se non riesco con "msdeploy" posso sempre optare per ln batch temporizzato che controlla la presenza di un file in una cartella condivisa.



    sabato 20 aprile 2013 17:30
  • Penso che applicherò la soluzione di Gastone: Se non riesco con "msdeploy" posso sempre optare per ln batch temporizzato che controlla la presenza di un file in una cartella condivisa.


    l'approccio che Gastone Canali ha suggerito è, a mio avviso completamente sbagliato, ma ognuno è libero di fare le sue scelte.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    sabato 20 aprile 2013 19:23
    Moderatore
  • Nel suo scritto precedente, Edoardo Benussi [MVP] ha sostenuto :

    Penso che applicherò la soluzione di Gastone: Se non riesco con "msdeploy" posso sempre optare per ln batch temporizzato che controlla la presenza di un file in una cartella condivisa.

    l'approccio che Gastone Canali ha suggerito è, a mio avviso completamente sbagliato, ma ognuno è libero di fare le sue scelte.

    ciao.

    L'applicazione si blocca al massimo una o due volte a giorno (e ci sono stati giorno in cui non si è bloccata), in orari diversi, quindi non posso certo schedulare un riavvio automatico ogni tot tempo che causerebbe più problemi di quelli che ho già.
    Non saprei come testare automaticamente il blocco dell'applicazione perché, in realtà, in IIS non si disattiva niente. Tutte le applicazioni del gestionale, in IIS, restano comunque attive, ma da un momento all'altro non accettano più il login (e non c'è nessun evento strano nel registro).
    A questo punto l'utente mi chiama, io mi collego da remoto e riavvio le applicazioni. Volevo semplicemente rendere il cliente autosufficiente in questi casi, perché se io non potessi collegarmi, loro sarebbero fermi.

    sabato 20 aprile 2013 21:35
  • Se motivassi i tuoi "complemante sbagliato" impareremmo tutti qualcosa ;)

    Ciao


    Gastone Canali >http://www.armadillo.it

    Se alcuni post rispondono al tuo quesito (non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili . GRAZIE! Ricorda di dare un occhio anche QUI

    sabato 20 aprile 2013 21:35
    Moderatore
  • Skywalker ho avuto un problema simile, una web application "fatta male" si bloccava randomicamente, accorciare il timing del recycle avrebbe creato ancora più problemi agli utenti attivi, allora si inventò la pagina web autenticata che scriveva nella dir il file .... attività  svolta dall'operatore che non svegliava il sistemista di notte ed evitava l'attesa del prossimo recycle!

    Se poi vogliamo parlare di un processo di sistema che ogni 120 minuti necessita un "recycle" con quello che comporta ....


    Gastone Canali >http://www.armadillo.it

    Se alcuni post rispondono al tuo quesito (non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili . GRAZIE! Ricorda di dare un occhio anche QUI



    sabato 20 aprile 2013 21:49
    Moderatore
  • Se motivassi i tuoi "complemante sbagliato" impareremmo tutti qualcosa ;)

    ritengo il tuo approccio a questo problema completamente sbagliato perché il malfunzionamento di una web app può essere dovuto al fatto che l'applicazione non è stata sviluppata in modo corretto oppure il web server non è correttamente configurato.

    nel primo caso, sia che l'applicazione sia home made sia che sia stata prodotta da una software house, il problema riguarda strettamente i devs che devono indagare ed individuare cosa faccia piantare l'applicazione.

    nel secondo caso, se la stessa applicazione funziona correttamente su altri n web server e male su uno, il problema è di configurazione di quel particolare web server ed in questo caso rientra nei compiti del sistemista quello di indagare ed individuare le eventuali cause di una configurazione errata per correggerle.

    adottare l'approccio di consentire un riavvio forzato del worker process perché la web app non funziona correttamente significa solo usare un palliativo, spazzare la polvere ed infilarla sotto al tappeto, cucire una toppa sul buco e quando c'è la toppa sul buco per cui il freddo non entra più nei pantaloni nessuno pensa più a rammendare con cura i pantaloni perché tanto il problema è bypassato.

    ecco il motivo per cui non condivido affatto l'approccio anche se la soluzione dal punto di vista tecnico funziona.

    ciao.


    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    domenica 21 aprile 2013 06:36
    Moderatore
  • Ti stai contraddicendo, sembra quasi che tu voglia aver ragione a tutti i costi, quando sei stato proprio tu a consigliare di utilizzare  il recycling del worker process!! 

    Io ho solo consigliato un modo per farlo puntualmente, quando necessario, al bisogno!!

     Capita che le possibilità di base offerte dal sistema  operativo, in questo caso quelle della Recycling tab di iis, non rispondono alle necessità della nostra web app, tanto che i lungimiranti sviluppatori di microsoft danno la possibilità di pilotare un recycle via API, WMI, eseguibile (appcmd), vbs (iisapp)... 

    Capisco che le scelte offerte per attivare un recycle automatico, potrebbero sembrare tante: ogni tot minuti, in base alla memoria occupata, alle richeste fatte, ad orari fissi etc.  ma spesso non sono risolutive ma peggiorative, perchè attivare un recycle automatico quando non necessario, solo perchè esempio sono fatte 11111 richieste, quando tutto sta funzionando bene?

    Ciao passo e chiudo 

    http://blogs.msdn.com/b/david.wang/archive/2006/01/26/thoughts-on-application-pool-recycling-and-application-availability.aspx

    http://weblogs.asp.net/owscott/archive/2013/04/06/why-is-the-iis-default-app-pool-recycle-set-to-1740-minutes.aspx

    http://thatextramile.be/blog/2010/06/why-do-we-recycle-our-application-pools


    Gastone Canali >http://www.armadillo.it

    Se alcuni post rispondono al tuo quesito (non necessariamente i miei), ricorda di contrassegnarli come risposta e non dimenticare di contrassegnare anche i post utili . GRAZIE! Ricorda di dare un occhio anche QUI

    domenica 21 aprile 2013 14:45
    Moderatore
  • Ti stai contraddicendo, sembra quasi che tu voglia aver ragione a tutti i costi, quando sei stato proprio tu a consigliare di utilizzare  il recycling del worker process!! 


    il recycling dei worker process è qualcosa di previsto dal sistema e quindi qualcosa di fisiologico. l'azione che suggerisci tu è qualcosa di esterno e quindi di patologico che, imho, non è necessario introdurre oltre le patologie già presenti nella web app. ritengo sia preferibile cercare le cure.

    Edoardo Benussi
    Microsoft MVP - Directory Services
    edo[at]mvps[dot]org

    domenica 21 aprile 2013 17:13
    Moderatore
  • Sembra che GastoneCanali abbia detto :

    Skywalker ho avuto un problema simile, una web application "fatta male" si bloccava randomicamente, accorciare il timing del recycle avrebbe creato ancora più problemi agli utenti attivi, allora si inventò la pagina web autenticata che scriveva nella dir il file .... attività  svolta dall'operatore che non svegliava il sistemista di notte ed evitava l'attesa del prossimo recycle!

    Per fortuna a me succederebbe solo in orari di ufficio e, a quanto sembra, abbastanza raramente, ma volevo evitare comunque la situazione in cui l'utente mi chiama in un momento in cui sono impossibilitato ad intervenire.
    Questo non esclude che sto cercando di capire il perché di questo malfunzionamento quando tante altre installazioni dello stesso prodotto su sistemi pressoché identici, non danno problemi del genere.

    domenica 21 aprile 2013 17:54
  • Dopo dura riflessione, Edoardo Benussi [MVP] ha scritto :

    Se motivassi i tuoi "complemante sbagliato" impareremmo tutti qualcosa ;)

    adottare l'approccio di consentire un riavvio forzato del worker process perché la web app non funziona correttamente significa solo usare un palliativo, spazzare la polvere ed infilarla sotto al tappeto, cucire una toppa sul buco e quando c'è la toppa sul buco per cui il freddo non entra più nei pantaloni nessuno pensa più a rammendare con cura i pantaloni perché tanto il problema è bypassato.

    ecco il motivo per cui non condivido affatto l'approccio anche se la soluzione dal punto di vista tecnico funziona.

    Sicuramente si tratterà di una soluzione temporanea, finché non troviamo la causa scatenante. Purtroppo (o per fortuna) l'applicativo non è di nostra produzione quindi siamo in contatto col produttore che sta, a sua volta, analizzando la situazione.
    La soluzione di Gastone non è certamente ortodossa, ma mi consente di dare al cliente un modo per ridurre al minimo l'impatto del problema sulla loro attività.

    domenica 21 aprile 2013 18:00