How to speed up MSDeploy

It's been awhile since I used it, and I only used it with IIS 6 which doesn't include the web management part. You can modify the remote management URL and port and block it at the external firewall. See this: Customizing and Securing the Remote Service. It's main security mechanism appears to be user account security, but like you said, it's all within IIS, so an IIS vulnerability could render the security measures useless until patched. For that reason alone, I would be hesitant to allow updating web content from the internet, but this depends on your org's security requirements vs. your web developer's needs.

To avoid exposing the web deploy service to the internet, you can do the following:

• have the default website listen on an internal-only IP that is not NATed or part of the load-balancing IP range
• you could have the default management website listen on localhost only, then write a script that calls the msdeploy executable on each host to run locally (instead of using msdeploy to connect remotely to all hosts from a single point)
• have your load-balancer filter external requests that try to hit the web deploy URL (ex. https://server:8081/MSDeploy)
• have a designated (internal) deployment host that all your web deployments come from and only allow that IP to connect to your webservers on the deployment URL (block anything not from the single deployment host)

If there still a need to have web deployment functionality available directly from the internet say if all of your web developers worked remotely, (I can't imagine why this would be necessary directly with the widespread usage of VPN), you could have a 2-stage deployment process where you set up an isolated DMZ with a Web Deploy-enabled IIS 7 box in it (separate from your web farm's DMZ), and allow your web developers to connect to only that DMZ from the internet to deploy changes remotely. Then you could connect internally to that host and deploy to the rest of your web servers after reviewing the changes, testing, etc. Even this method isn't without risks though - a malicious user may end up compromising the web deployment functionality, introducing some malicious code without your knowledge and you could unknowingly introduce it into your production environment.

I looked into this a while back and to the best of my knowledge MSDEPLOY doesn't log anything on the client side. All you can do it is redirect its output to a file -

msdeploy.exe -verb:sync ... > logfile.log

Which of course is no good if someone is running this manually outside of an automated build and deploy tool.

You can log MSDEPLOY activity on the target server (if you're deploying using the Web Deploy service), but that's probably not so handy if you don't have complete RDP access to get at the logs.

I am guessing that MS see MSDEPLOY as just an ordinary tool much in the same way that that the C# compiler doesn't log something somewhere every time you compile your source.