msdeploy (Web Deploy) in mancanza di problemi di autorizzazione 401

Question

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

sto testando un semplice comando di msdeploy:

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 msdeploy utente chiamato e ho aggiunto al gruppo amministratori locale nel server .

Ho controllato:

• che il servizio installato correttamente ed ho iniziato
• Varie combinazioni di non utilizzare la parte di dominio del nome utente, e l'aggiunta di AuthType = base
• Attribuite autorizzazioni complete a quella cartella a tutti
• In IIS consentono connessioni remote
• Regole di delega del servizio di gestione aggiunte per il mio utente "msdeploy" per contentPath e iisApp (liberamente basato su rea ding this)
• Provato con un account amministratore diverso che uso per RDC al server ...
• provato con diversi contentPaths e diverso msdeploy comandi
• Creato un account specifico, e ha aggiunto che conto ai IIS_Users. Aggiunta quell'utente al mio sito Web "Autorizzazioni Gestione IIS" e impostazione "Delega servizio gestione" per tutti i provider.

Answer 1

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

Configure Web Deploy (IIS.NET)

Nota: MS hanno rilasciato un aggiornamento di Web Deploy 2.0 e il link isn originale' È davvero più valido. L'ho aggiornato, ma penso che sarà un obiettivo mobile nel tempo.

È inoltre necessario installare Web Deploy 2.0 sul computer di sviluppo/build/CI.

Se si sta ancora utilizzando 1.0, quindi consiglio l'aggiornamento, ci sono alcuni enormi miglioramenti in 2.0.

utilizzando Visual Studio 2010 di Pubblica Caratteristica:

Visual Studio può pubblicare un sito facendo clic destro sul sito e selezionando "Pubblica".Questo fa apparire il seguente dialogo:

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

Error 1 Web deployment task failed.((04/02/2011 12:30:40) An error occurred when the request was processed on the remote computer.)

Si vedrà anche il seguente errore nel Richiesta non riuscita Tracing per il servizio di gestione Web sul server in C:\inetpub\logs\wmsvc\TracingLogFiles\W3SVC1 supponendo di avere questo acceso:

AspNetModuleDiagErrorEvent
Uri /msdeploy.axd
eventData Tracing deployment agent exception. Request ID ''. Request Timestamp: '02/04/2011
System.UnauthorizedAccessException: Access to the path 'D:\' is denied.

La lettera dell'unità varierà sulla struttura su cui si trova il tuo sito IIS.

Fuori dalla scatola, l'in-GUI Pubblica default meccanismo per utilizzare la versione sbagliata di MSDeploy (1.0). Vogliamo dire a VS2010 di usare MSDeploy 2.0. È possibile farlo modificando Visual Studio file di devenv.exe.config 2010 che si trova nella (supponendo che hai fatto un disco di default c:\ installare):

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

Open Up devenv.exe.config nel vostro editor XML preferito (ho appena usato Visual Studio 2010 stesso) 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> 

Aggiungere questo alla sezione /configuration/runtime/assemblyBinding:

Dopo averlo chiuso tutte le istanze di Visual Studio 2010 per rendere effettiva questa modifica. Riavviare VS2010, aprire un progetto Web e quindi provare a pubblicare nuovamente. Questa volta dovrebbe avere successo.

Publishing utilizzando una generazione pacchetto:

Visual Studio può produrre una generazione pacchetto che può essere eseguito da linea di comando. Questo viene generato utilizzando Project -> Build Deployment Package. Pratico per l'integrazione continua e simili (il pacchetto può anche essere generato usando msbuild con l'interruttore /t:Package).

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

Purtroppo Visual Studio 2010 ottiene questo un po 'sbagliata e genera uno script batch msdeploy involucro rivolte a 1.0 e targeting distribuzione al server anziché livello di sito.

Non esiste una soluzione rapida per questo oltre a creare la propria riga di comando msdeploy.exe. Ho diviso questo tra diverse linee per rendere questo un po 'più leggibile .:

 
"C:\Program Files\IIS\Microsoft Web Deploy v2\\msdeploy.exe" 
    -source:archiveDir='d:\sites\DemoApp\obj\Package\Archive' 
    -dest: 
     auto, 
     computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename', 
     userName='demosite', 
     password='somepassword', 
     authtype='basic', 
     includeAcls='False' 
    -verb: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 per la versione 1.0. Ho cambiato questo per usare 2.0.

parametri degni di nota:

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

computerName='https://yoursite.com:8172/msdeploy.axd?site=yoursitename' - questo dice MSDeploy per distribuire ad un sito specifico su IIS7. yoursitename dovrebbe corrispondere esattamente al nome del sito in IIS.

userName e password sono il nome dell'utente gestore delegato per il sito. Questo è configurato utilizzando la funzionalità "Autorizzazioni di Gestione IIS" a livello di sito. L'account deve essere un account utente Windows locale.

-authtype='basic' - questo impone l'autenticazione di base, altrimenti viene tentata l'autenticazione NTLM.

-allowuntrusted - questo ignora qualsiasi errore del certificato SSL se si utilizza il certificato SSL autofirmato incorporato.

Se si utilizza tale riga di comando, è possibile eseguire correttamente la distribuzione su un server IIS7 remoto.

Raw Content Publishing:

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

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

Anche in questo caso valgono le stesse regole di prima per -dest:contentPath e computerName.

Credo che i problemi della versione di MSDeploy saranno risolti in SP1 (che non ho ancora avuto modo di vedere).

Un finale VS2010 Gotcha:

Quando si pubblica utilizzando Visual Studio 2010, la "Pubblica" costruire pacchetto fa sì che l'ACL dispone di account anonimo del sito di modificare a sola lettura per tutti i file e le cartelle ad eccezione di la cartella App_Data che è stata modificata in Lettura e Scrittura.

Questo può essere lavorato intorno aggiungendo la seguente impostazione al file .csproj sotto ogni <PropertyGroup Condition=" '$(Configuration)|$(Platform)' == 'Debug|AnyCPU' ">:

<IncludeSetAclProviderOnDestination>False</IncludeSetAclProviderOnDestination> 

Oppure, se si sta utilizzando msbuild:

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

ho scoperto che pepita utili da qui:

Skipping setting an ACL in a Visual Studio 2010 deployment package (WayBackMachine link because the original content is no longer available)

Answer 2

Abbiamo dovuto affrontare un problema simile al tuo.

Per questo è necessario avviare il servizio agente remoto nei servizi. Abbiamo usato il nome del PC perché l'indirizzo IP stava dando un errore. Quindi prova ad usare il nome del pc, il nome utente e la password.

Answer 3

alla fine non ho mai fatto Suss che cosa p le ermissions mi mancavano con il mio account utente di deploy, ma ho scoperto che se avessi usato l'account amministratore della macchina, la distribuzione sarebbe andata a buon fine. Per ora sto usando l'account amministratore per fare la distribuzione.

Complimenti per Kev per la sintesi fantastica e informativo di istituire ms implementare 2 :)

Answer 4

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

Impostando <UseMsdeployExe>true</UseMsdeployExe> nel proprio .csproj, è possibile forzare VS a utilizzare msdeploy.exe anziché un'attività di MSBuild. Quindi, attivando il livello di registrazione (Strumenti> Opzioni> Progetti e soluzioni> Costruisci ed esegui> verbosità di output del progetto MSBuild) puoi visualizzare la riga di comando che VS utilizza.

I problemi con la mia .deploy.cmd sono stati:

• mio utente di IIS aveva solo i permessi su quel sito quindi avevo bisogno ?site=<SITENAME> nel computerName.
• Avevo bisogno di AuthType='Basic' nel parametro -dest:.

Answer 5

Per quello che vale. La pubblicazione funzionava per me e poi un giorno ho avuto lo stesso problema (errore non autorizzato 401) Il riavvio di VS2012 ha risolto il problema. Vorrei averlo provato prima di provare ogni altra soluzione.