msdeploy (Distribuzione Web) riesce con 401 auth problemi

Sto cercando di ottenere msdeploy installato e configurato. Ho installato il servizio remoto sul server web, ma tutti i miei test mi dà un 401 unauthorised error. Il server è Windows 2008 R2.

Sto testando un molto semplice msdeploy comando:

msdeploy -verb:dump -source:contentPath=c:\inetpub\wwwroot\MyApp,computerName=<IP HERE>,userName=Domain\msdeploy,password=MyPassword

E l’errore:

Error: Object of type 'contentPath' and path 'c:\inetpub\wwwroot\MonApp' cannot be created.
Error: Remote agent (URL http://<IP HERE>/MSDEPLOYAGENTSERVICE) could not be contacted.  Make sure the remote agent service is installed and started on the target computer.
Error: An unsupported response was received. The response header 'MSDeploy.Response' was '' but 'v1' was expected.
Error: The remote server returned an error: (401) Unauthorized.
Error count: 1.

Ho creato un utente chiamato msdeploy e l’ho aggiunto al gruppo amministratori locale sul server.

Ho controllato:

  • Che il servizio non installato correttamente e ho iniziato
  • Varie combinazioni di non usare la parte del dominio, il nome utente, e l’aggiunta di authType=Base
  • Dato autorizzazioni per la cartella a tutti
  • In IIS consentire le connessioni remote
  • Aggiunto il Servizio di Gestione Delega regole per il mio “msdeploy” utente per contentPath e iisApp (vagamente basato sulla lettura questo)
  • Provato con un altro account admin io uso per la connessione desktop remoto al server…
  • Provato con diversi contentPaths e diversi msdeploy comandi
  • Creato un account specifico, e ha aggiunto che il conto alla IIS_Users. Aggiunto l’utente al mio sito web “IIS Manager Autorizzazioni” e l’installazione “Servizio di Gestione Delega” per tutti i provider.

 

5 Replies
  1. 56

    Sto assumendo hai configurato correttamente il server per WebDeploy 2.0 di cui al presente articolo:

    Configurare il Web Deploy (IIS.NET)

    Nota: MS ha rilasciato un aggiornamento di Distribuzione Web 2.0 e il link originale non è davvero la validità. Ho aggiornato questo, ma penso che sarà un bersaglio in movimento nel tempo.

    È necessario anche installare Distribuzione Web 2.0 sul vostro sviluppo/build/CI della macchina.

    Se si sta ancora utilizzando 1.0 quindi mi consiglia di aggiornare, ci sono alcuni grandi miglioramenti nella versione 2.0.

    Utilizzando Visual Studio 2010 Funzione Pubblica:

    Visual Studio è possibile pubblicare un sito con un clic destro sul sito e selezionare “Pubblica”. Questo porta la seguente finestra di dialogo:

    msdeploy (Distribuzione Web) riesce con 401 auth problemi

    Ci sono un paio di gotcha con Visual Studio 2010 e con distribuzione web 2.0. La prima è che VS2010 non è WebDeploy/MSDeploy 2.0 a conoscenza. Quindi, se si tenta di pubblicare, si avrà un errore come il seguente:

    1 errore di Web attività di distribuzione
    impossibile.((04/02/2011 12:30:40) Un errore
    si è verificato quando la richiesta è stata
    trattati sul computer remoto.)

    msdeploy (Distribuzione Web) riesce con 401 auth problemi

    Potrete anche vedere il seguente errore nella Richiesta non Riuscita l’Analisi per il servizio di gestione web sul server in C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 supponendo di aver attivato:

    AspNetModuleDiagErrorEvent

    Uri /msdeploy.axd

    eventData Analisi
    agente di distribuzione eccezione. ID richiesta
    “. Richiesta Timestamp: ’02/04/2011

    Sistema.UnauthorizedAccessException: Accesso al percorso ‘D:\’ negato.

    msdeploy (Distribuzione Web) riesce con 401 auth problemi

    La lettera di unità variano in base a quale unità di IIS sito si trova.

    Out of the box, il GUI Pubblicare meccanismo predefinito utilizzando la versione sbagliata di MSDeploy (1.0). Vogliamo dire VS2010 utilizzare MSDeploy 2.0. È possibile farlo modificando Visual Studio 2010 devenv.exe.config file che si trova in (supponendo che hai fatto un default c:\ drive di installazione):

    Per sistemi a 64 bit: c:\Program Files (x86)\Microsoft Visual Studio 10.0\Common7\IDE
    Per sistemi a 32 bit: c:\Program Files\Microsoft Visual Studio 10.0\Common7\IDE

    Aprire devenv.exe.config nel vostro editor XML preferito (l’ho usato Visual Studio 2010) e copiare il seguente codice xml:

    <dependentAssembly>
      <assemblyIdentity 
        name="Microsoft.Web.Deployment" 
        publicKeyToken="31bf3856ad364e35" culture="neutral"/>
      <bindingRedirect oldVersion="7.1.0.0" newVersion="8.0.0.0"/>
    </dependentAssembly>
    

    A questo si aggiungono /configuration/runtime/assemblyBinding sezione:

    msdeploy (Distribuzione Web) riesce con 401 auth problemi

    Una volta fatto questo chiudi tutte le istanze di Visual Studio 2010 per consentire la modifica abbia effetto. Riavviare VS2010, aprire un progetto web e quindi si tenta di pubblicare di nuovo. Questa volta dovrebbe essere di successo.

    La pubblicazione con una Build del Pacchetto:

    Visual Studio può produrre un Pacchetto che può essere eseguito dalla riga di comando. Questo è generato utilizzando Project -> Build Deployment Package. Utile per l’integrazione continua e simili (il pacchetto può anche essere generato utilizzando msbuild con il /t:Package switch).

    La cartella di output per il pacchetto di solito di default obj\Package.

    Purtroppo Visual Studio 2010 ottiene questo un po ‘ sbagliato e genera un msdeploy wrapper script batch rivolti 1.0 e pensati per la distribuzione al server, piuttosto che a livello di sito.

    Non c’è soluzione rapida per questo, oltre che per creare il proprio msdeploy.exe riga di comando. Ho dividere su più righe per rendere questo un po ‘ più leggibile.:

    "C:\Program File\IIS\Microsoft Web Deploy v2\\msdeploy.exe" 
    -fonte:archiveDir='d:\sites\DemoApp\obj\Package\Archive' 
    dest: 
    auto, 
    computerName= "https://yoursite.com:8172/msdeploy.axd?site=yoursitename', 
    userName='demosite', 
    password='somepassword', 
    authtype='base', 
    includeAcls='False' 
    -verbo:sync 
    -disableLink:AppPoolExtension 
    -disableLink:ContentExtension 
    -disableLink:CertificateExtension 
    -setParamFile:"d:\sites\DemoApp\obj\Package\Archive.SetParameters.xml" 
    -allowuntrusted 
    

    La prima cosa da notare è il percorso msdeploy.exe. Visual Studio genera un percorso alla versione 1.0. Ho cambiato questo per utilizzare il 2.0.

    Notevole parametri:

    -source:archiveDir= dice msdeploy siamo la distribuzione di un pacchetto e fornisce la posizione locale

    computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' – questo dice MSDEPLOY per la distribuzione a un sito specifico su IIS7. yoursitename deve corrispondere esattamente al nome del sito in IIS.

    userName e password sono è il nome del delegato utente di gestione per il sito. Questo viene configurato utilizzando la “Gestione IIS” Autorizzazioni di funzionalità a livello di sito. L’account deve essere un locale di account utente di Windows.

    -authtype='basic' – questo impone l’autenticazione di base altrimenti l’autenticazione NTLM è tentato.

    -allowuntrusted – che ignora qualsiasi certificato SSL errori, se si utilizza il built-in self-signed SSL cert.

    Se si utilizza quella riga di comando, allora si dovrebbe essere in grado di distribuire in un remoto IIS7 server con successo.

    Pubblicazione Raw Contenuto:

    A volte si desidera solo di pubblicare alcuni contenuti statici (o forse anche un Classic ASP o PHP sito) direttamente da una cartella locale. Possiamo farlo utilizzando il seguente msdeploy.exe riga di comando:

    "C:\Program File\IIS\Microsoft Web Deploy v2\\msdeploy.exe" 
    -fonte:contentPath='d:\websites\mysite' 
    dest: 
    contentPath='nomesito', 
    computerName= "https://yoursite.com:8172/msdeploy.axd?site=yoursitename', 
    userName='demosite', 
    password='somepassword', 
    authtype='base', 
    includeAcls='False' 
    -verbo:sync 
    -allowuntrusted 
    

    Di nuovo le stesse regole si applicano come prima per -dest:contentPath e computerName.

    Credo che il MSDeploy versione il problema possa essere risolto nel service pack 1 (che non ho avuto la possibilità di guardare la sicurezza).

    Una Finale VS2010 Gotcha:

    Quando la pubblicazione di utilizzo di Visual Studio 2010, la “Pubblicazione” costruire pacchetto provoca l’ACL del sito account anonimi per cambiare Solo la Lettura di tutti i file e cartelle con l’eccezione del App_Data cartella che è cambiato a Leggere e a Scrivere.

    Ciò può essere evitato aggiungendo la seguente impostazione per il .csproj file sotto ogni <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">:

    <IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination>
    

    Oppure, se si utilizza msbuild:

    msbuild.exe myproject.csproj /t:Package /p:IncludeSetAclProviderOnDestination=False
    

    Ho scoperto che utile pepita da qui:

    Saltare l’impostazione di un ACL Visual Studio 2010, il pacchetto di distribuzione (WayBackMachine link perchè il contenuto non è più disponibile)

    • Questo è un grande post Kev – informazioni realmente utili qui. Per il mio problema ma ho ancora visto 401 auth errori a meno di non utilizzare il computer account admin (spiegato nella mia risposta qui sotto).
    • Il msdeploy.axd?sito=nomesito è che ha risolto per me. Se ho lasciato il sito parametro out ho avuto un 401. Grazie
    • Grazie per questa risposta impressionante. ?sito=… era quello che ho appena trascorso 3 ore della mia vita! 🙂
    • Questa è solo una risposta impressionante…Grazie 🙂
    • il primo link è stata la parte finale per me! grazie!
  2. 6

    Per me, la pubblicazione ha lavorato in Visual Studio, ma non ha funzionato quando ho eseguito il .deploy.cmd script.

    Impostando <UseMsdeployExe>true</UseMsdeployExe> nel .csproj, è possibile forzare VS utilizzare msdeploy.exe invece di un’attività MSBuild. Poi alzando il livello di registrazione (Strumenti > Opzioni > Progetti e Soluzioni > Creare ed Eseguire > MSBuild progetto di costruzione di uscita verbosità) si può vedere la linea di comando che VS usa.

    Problemi con il mio .deploy.cmd sono stati:

    • Mio IIS utente aveva solo le autorizzazioni su quel sito, quindi ho bisogno ?site=<SITENAME> in computerName.
    • Ho bisogno di AuthType='Basic' in -dest: parametro.
    • Grazie per il suggerimento del <UseMsdeployExe> attributo
  3. 3

    Siamo stati di fronte a un problema simile al vostro.

    Per questo è necessario avviare l’agente remoto servizio di servizi.
    Abbiamo usato il nome del PC perché l’indirizzo IP è stato dando un errore. Quindi, provare a utilizzare il nome pc, nome utente e password.

  4. 1

    Alla fine non ho mai fatto suss i permessi che mi mancava con il mio distribuire account utente -, ma ha scoperto che se ho usato la macchina account admin, che la distribuzione sarebbe successo. Per ora sto usando l’account di amministratore per eseguire la distribuzione.

    Complimenti a Kev per il fantastico e il riepilogo informativo di configurazione di ms distribuire 2 🙂

  5. 0

    Per quello che vale. La pubblicazione era lavoro per me, e poi un giorno ho avuto questo stesso problema (401 non autorizzato di errore) Riavvio VS2012 risolto il problema. Vorrei che fosse provato che prima di provare ogni altra soluzione.

Lascia un commento