On my current project, we have a Bamboo continuous integration server that deploys an ASP.net application packaged with MSBuild to our dev integration IIS server. This deployment happens via MSDeploy using the following command in the MSBuild script:
"C:\Program Files\IIS\Microsoft Web Deploy\msdeploy.exe" -source:package='path\to\the.zip' -dest:auto,wmsvc='https://iisserver:8172/msdeploy.axd?Site=MySite',userName='*****',password='*****',includeAcls='False' -verb:sync -disableLink:AppPoolExtension -disableLink:ContentExtension -disableLink:CertificateExtension -setParamFile:path\to\the.SetParameters.xml -allowUntrusted
Everything is good with the command and deployments to iisserver were happening many times a day for a few months. Then the other day, the dev integration deployment job started failing with the following error:
Error: (build date) An error occurred when the request was processed on the remote computer.
Error: Unable to perform the operation. Please contact your server administrator to check authorization and delegation settings.
Nice error! Very informative. So I go ahead and check all the usual things: did a code change break something (no); did the user account represented by userName in the command get locked (no), or did its password expire (no); was the wmsvc agent running on the server (yes); were any Windows updates installed on the server (yes, on the same day the deployment started breaking); were there any changes to the Window or IIS server configuration (no)
With these checks done, the only one that seemed possible was one of the Windows updates might have done it. So I backed out the updates. But that didn’t fix the issue. Hmm, alright. After quite a bit of effort and time expended by myself and our systems administrators, I finally dug up this StackOverflow issue that sounded similar. The answer is what caught me:
…Turns out that when you install web deploy it sets up two local accounts WDeployConfigWriter and WDeployAdmin. These passwords on these accounts are set to expire…
Ah ha! Wait, what?! In addition to the domain service account I use on the command line, there are 2 more local accounts required by the tool? That I didn’t know were there? And they had passwords set to expire after 90 days? Really? Awesome. In any case, after “fixing” those two accounts on the dev integration server, they deployments started working as they had before.
A Software Guy's Blog 