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 
I guess the code name for MSBuild is MineSweeperBuild. Never know where the hidden “stuff” is unless you step on it.
Good finding, glad you were able to nail it !
Thank you! Just ran into the same issue. In my case the two accounts were set up with the flag that the user has to change the password with next logon. Not really an option for an automated process…
Dude you are a legend.
Probably saved me hours of messing around :)
god msdeploy is such a piece of crap
thanks you saved me some time
Thanks, Eric. Very helpful post.
Thanks Eric – pro was ready to start throwing my computer.
Wow, thanks a lot, worked like a charm!
cheers… still saving people 4 years later….. “control userpasswords2” and a couple of clicks later and all sorted… thanks…
Helped me today :)
Thank you!
Thank you! So glad I found this post.
FYI, just for clarity. Simply uncheck ‘User must change password…’ and check ‘Password Never Expires’. That is all that is required!
this worked for me too.
Batch script to set these two properties without having to use the UI.
net user WDeployAdmin /logonpasswordchg:no /EXPIRES:NEVER
net user WDeployConfigWriter /logonpasswordchg:no /EXPIRES:NEVER
WMIC USERACCOUNT WHERE “Name=’WDeployAdmin'” SET PasswordExpires=FALSE
WMIC USERACCOUNT WHERE “Name=’WDeployConfigWriter'” SET PasswordExpires=FALSE
Can you please explain how the package is being created (.zip file)? Did you write a script to zip all the artifacts after the msbuild task or is there any bamboo task that does that? I am working on setting up a .net project in bamboo and am new to this. I am currently able to get the build done with msbuild using the .sln file but no .zip file is generated.
I have a target in my CIBuild.proj file, which uses a task similar to this:
<MSBuild Projects="MyProject.csproj"
Targets="Package"
Properties="Configuration=Prod;PackageAsSingleFile=true;PackageLocation=target\MyProject-Prod.zip;DeployIisAppPath=My_App;SkipExtraFilesOnServer=true" />
I have three other similar tasks, which create a package for dev integration, test and pre-prod.
Pingback: Wenn Web Deploy nicht mehr funktioniert | DaBeSoft Blog
Reblogged this on bradsegrest and commented:
Very helpful, Thanks for the info. When WebDeploy just stops working.
Life saver!!!
This has never happened on an older Windows Server 2012 we have been using as a staging server for 3-4 years. But a new server running Windows Server 2016 started throwing up this error!