If I had one wish for Remote Publishing to IIS…

The feedback from my first query really amazed me. It certainly helps to have real-life viewpoints as well different rationales… because we need to understand what is truly troubling you… not just the symptoms but the underlying cause.

So, I am going to put another hotly debated item up on the block… remote publishing to IIS. Over the years, IIS has steadily gained features and frameworks like ASP and ASP.Net to better service web pages and web services… but it really has not advanced much when it comes to publishing content to that server. In particular:

  • FTP Server really languishes the pack in terms of quality and features. The anonymous, non-extensible, and no-frills FTP implementation leaves much to be desired.
  • FPSE remains something everyone hates to love. Cryptic and unmanageable, non-scalable, and unreliable implementation makes it an easy target to hate.
  • WebDAV suffers from client-side confusion (Windows ships with two different WebDAV Clients in Internet Explorer and Windows Shell with different functionality support… try WebDAV over SSL and see what happens) and sketchy server-side implementation.

Yes, we know the situation is deplorable, but we have limited resources to address this problem space. So, I would like to hear your wishes and desires for remote publishing to IIS. For example:

  • If you had to choose ONE way to remote publish content to IIS, which would you choose and WHY? FTP, FTPS, FPSE, WebDAV, something else, or never?
  • If we had to cut support for any of those mechanisms, which would be ok and WHY (no, not because you’re not using it… 😉 but WHY should it just disappear).
  • What sort of features in remote publishing do you deem most important?

    • Support for non-NT Users and User Isolation
    • Custom Authentication/Authorization extensibility
    • FTP over SSL
    • Kerberized FTP
    • Etc

  • Maybe we should just give up and rely on Sharepoint instead?

Ok, enough hints from me. I want to know what you think.


Comments (29)

  1. Ben Rogers says:

    FTP by itself is insecure. It’s a dead end. FTPS sounds interesting, but I’d like to see client-side support built into Windows. We don’t want to tell all of our customers that they need to buy a third party FTP client just to upload a file.

    ISA would need to be able to handle any new protocols. We don’t need real deep support. But ISA (and firewalls and NAT boxes in general) should be factored into any decision.

    WebDAV has potential. It’s had it for a long, long time. It has some client side support, but it’s a confusing mess. In my opinion, it simply doesn’t work. WebDAV through ISA has been problematic. We’ve found that it’s best to take ISA out of the picture.

    We rely on Novell’s NetDrive for WebDAV client functionality. If Microsoft’s going to focus on WebDAV for deployment, you’d need to straighten out Windows support for WebDAV on the client side as well. Solving one side of the equation is not enough.

    I thought FPSE (the protocol) was getting whacked in favor of WebDAV? Is this not the case?

    At any rate, FPSE (the technology) is a non-starter for us. It’s non-standard. It’s a black box. Server side permissions on the server are a horrible, fragile mess. I don’t know how much of that has to do with the protocol, but FPSE has such negative connotations for us, that it’s difficult to envision ever relying on FPSE. Also, what’s the client side story for FPSE? Is there one outside of Office?

    "Custom Authentication/Authorization extensibility", which seems to include the first bullet, "Support for non-NT Users", sounds interesting. We’re an ISP. We have to hand out a lot of Windows accounts to third party developers. We’re trying to move away from Windows accounts wherever possible. Sometimes, the easiest way to secure a Windows network is to have less Windows users.

    Besides, most applications outside the Microsoft world don’t support Windows authentication (try to connect a Java application to SQL Server with Windows authentication). Even within the Microsoft world, it’s a hodgepodge.

    Why no SSH solutions like FTP over SSH? The UNIX world seems to have settled on SSH. It’s notably absent in the Microsoft world.

  2. Maurits says:

    FTP because it’s widely supported.  SFTP would also be a good option.

  3. Maurits says:

    FTP over SSL has implementation problems, due to FTP’s quirky habit of spawning additional TCP connections between the same client and server.  SFTP attempts to fix these… it’s a new protocol, not just FTP over SSL.

  4. Byron Pate says:

    Currently, we rely on a mix of Application Center and custom applications to publish content from Staging servers to Production servers. A few reasons prevent us from using FTP or FPSE for publishing. Due to SOX compliance, developers can not directly access web servers, only request that their content be published. Also content has to be published to 9 servers, so a certain level of automation has to occur.

    Having administered FPSE on web servers before I would never recommend it as a solution. It was a constant problem, and caused problems for ASP.NET applications.

    I’d like to see a small client application that uses NT Authentication or Custom Authentication (LDAP integration), similar to FrontPage but does not rely on IIS to publish the content. Almost like FrontPage combined with Napster.

    Regardless, this is an area where we need some new solutions, so its good that its being discussed.

  5. I think your answers are going to be all over the map, as usage varies a lot.

    FTP is "good enough" for a whole swath of cases.  There are excellent free FTP clients (FIlezilla of one), FTP client(s?) built into Windows, and FTP libraries for practically all programming languages.  If updates are script-driven (either push or pull) you are going to want something supported by your language of choice.  FTP usage is also portable, so the same approach can be applied to non-Windows servers.

    Depending on the usage – scp, rsync, or even CVS or Subversion – could be used from remote deployment.  (Common cross-platform usage matters to some folk.)

    In lots of cases there is going to be a need to run some one-time server-side code after a deployment – so generic solutions only work to a point.

    File replication kind’a looks like a solved problem.

    From the prior topic, it looks like the replication of IIS Server configuration changes is the hot spot. Perhaps some sort of "sync" operation is needed to force an update to IIS configuration.  For applications needing server-side update scripts, the "sync" operation should be callable, and read the new configuration from a file or another server.  For the mass-replication folks, a tool to broadcast a "do-a-sync" command to a list of servers may fit.

  6. Seth says:

    Our developers create environment-specific builds of our important applications and they applications themselves were designed to work in a multi-server, load-balanced environment The current tools (specifically Robocopy and Perl) work very well for us and we have no need additional tools for application deployment. That said I would welcome SFTP support with the choice to authenticate against Windows or a custom authentication database. This support would be great because it provides a way to securely transfer files without granting VPN access. The use of Windows authentication is not ideal in all environments. For example, if I need a client or vendor to FTP some files, I’m not going to implement a solution that requires allocating a Windows CAL for that user or purchasing External Connector Licenses. As painful as it is, we must stay legitimate with licensing. Using a custom authentication database would not require a CAL or ECL.

    Also, while not an IIS-specific issue, I would love to see an integrated SSH server in Windows. Microsoft certainly has the resources to make this happen and it’s LONG over due.


  7. Pablo says:

    I think WebDAV is the way to go, basically because is standard and a good one (basically), Windows client support for it will need to improve but is not a big issue. There are very nice implementation of tools using WebDAV and most of them work pretty cool (i.e. subversion) including maybe RFC 3744.

    I think the coolest new feate should be custom authentication/authorization including user isolation (big issue on any shared environment) and including specifically certificate based authentication PLEASE!!!!.

  8. Robert E. Spivack says:

    It’s not important how it’s done (the specific protocol).  The user experience (features) that we would like the ideal solution to have:

    The end-user simplicity of FPSE for "one button" publishing with intelligent differential sync’ing/updating only of changed files

    The universal client/industry-wide ubiquity of FTP client support

    The NAT traversal/firewall friendly nature of "port 80" solutions (referring to both infrastructure firewalls at the web server and most importantly soho and personal firewalls at the point of origin.)

    Zero new server administration – no layering of special user groups, permissions, and cross-linked black magic permissions that the current FPSE uses – when it doesn’t work, it’s a nightmare.

    Flexible authentication – Don’t force the use of local SAM or AD; conversely, don’t prevent the use of SSL, SQL-based authentication, or dotNET "providers" for authentication.

    Integration with new server functionality – it would be great if the solution was "volume shadow copy"-aware so the act of simply publishing would automatically be creating checkpoints of every file for each end-user initiated rollback file-by-file version-by-version.

    Support a "site duplication feature" which would simply copy site A on server A to a new site B on server B including site settings/configuration and not just the data files.  (I’m not calling this replication because I’m assuming a one-time user initiated copy, not an automatic replication.)

  9. We have used several deployment senarios.

    MS CRS and AppCenter.

    OpenDeploy from InterWoven.

    FTPS, FTP/SSL or WebDav sounds okay, but the solutions or tools, needs to be able to verify that all the content has been copied to the remote webserver, before it makes the publishing active and public.

    Here’s some bullets on what I’d like to see in a replication tool:

    – Secure connect and able to authenticate with the remote location.

    – Possible to have multiple different replication sets and schedules.

    – Reporting of successful/failed replication schedules.

    – Able to sync. metabase settings between IIS servers in a farm.

    That’s just my thoughts.


  10. Andy Longley says:

    There are several issues here that vary dependant on the implementation scenario. For Intranet we also do not allow developers to publish directly to production boxes but automating the dev –> UAT/Prod deployment is troublesome. Application center doesn’t scale geo physically either. Therefore a pressing need is the ability to synchronise content globally and securely. Admins tend not to like receiving .net apps as MSI’s from developers either. MSBuild does look interesting though it again requires customization for automating.

    For externally facing servers deployment through strictly managed firewalls is hard. Without a decent MS solution we have to kludge third party solutions together to deploy securely. Secure FTP is a must, SSL FTP, MS’s own SSH or the ability to plug into single sign on solutions is also welcome.

    To add to Peter Schmidt’s replication tool thoughts

    – The ability to test deploy – i.e. Show the differences before publishing / syncing.

    – Ability to compare content / configuration in load balanced farms.


  11. Seth says:

    Has anything come out of the suggestions that were posted either of the blogs what you solicited feedback from?


  12. David.Wang says:

    Seth – Yes, the suggestions and feedback has been great. I cannot exactly talk about it at the moment, but just know that you all have been heard and that things are in motion…


  13. Jerad says:


    I would love to see SFTP.


  14. David.Wang says:

    Jerad – Why?

    Ben, Seth – Regarding your comments about an integrated SSH server in Windows and Microsoft having the resources – other than wanting one, why would/should Microsoft build it? What sort of business opportunity/loss occurs without it?

    In other words, what would be the killer application for it on Windows, and you can’t say "because you’d lose out on whatever *nix is doing".

    I understand that SSH provides an encrypted tunnel between two machines over arbitrary ports and protocols (so you can run FTP over it, or X11 over it, or run a shell over it). So why not take over SSL? Why run SMB over SSH? Etc…


  15. Tix says:

    Publishing was great using Site Server 3.0. It was great and suited a purpose. Content publishing and replication. Simple yet works like a charm.

    Regardless of what solution gets put forward for FTP there is the question for many hosters out there is, how do i publish? There is no way in the world an administrator will allow developers to directly upload a file onto a production server but rather stage it first and then publish/promote. Perhaps we are touching on content management but hosters need a simple yet methodical means to publish content and not manage content.

    I see 2 area, IIS in large farms or many single sites on IIS. Both have different needs highlighted by the earlier posters.

    For example, running IIS servers in large farms, it is imperative to have configurations in sync, content in synch but yet the question begs, is this more a configuration management topic or a deployment topic?

    For one that runs many websites on an IIS server, ie in a corporate Intranet environment there must be a way to stage content promoti

    I guess in short providing FTPS is just a short term solution to enabling secure file transfers over DMZ’s. It should be firewall friendly, allow user authentication and provide a method in how content can be moved through the normal web content life cycle before it gets to prod.

    Did i mention i loved site server?

  16. Frank says:

    I would also be greatly appreciative of MS support for SFTP.  As a standard, SFTP solves the problems associated with FTP that get security folks excited.  Content providers in the *NIX world also have an easy time adopting SFTP, because it is so similar to FTP.

    My employer uses SFTP to publish out to our DMZ.  In our search for MS endorsed SFTP solutions, we’ve even gone so far as testing the Interix Remote Shell Services that use SFU, but the fact remains that entirely third party servers do SFTP much better (and require no additional Unix Services).

    I’d like to see SFTP supported under IIS (and subsequent support in the .NET framework, since I’m just dreaming here).  We’re already exporing the use of DFSR to replace the existing file-based replication product we’re using on our web farms.  Sure would be nice if MS would provide a simple and secure way of getting files out to our DMZ staging servers as well…

  17. David.Wang says:

    Frank – As I had responded in an earlier comment:

    Regarding your comments about an integrated SSH server in Windows and Microsoft having the resources – other than wanting one, why would/should Microsoft build it? What sort of business opportunity/loss occurs without it?

    In other words, what would be the killer application for it on Windows, and you can’t say "because you’d lose out on whatever *nix is doing".

    I understand that SSH provides an encrypted tunnel between two machines over arbitrary ports and protocols (so you can run FTP over it, or X11 over it, or run a shell over it). So why not take over SSL? Why run SMB over SSH? Etc…

    Basically, since Microsoft.com and MSN.com do not tell us "we need SFTP to publish to DMZ", we really need a good answer to "why should we do this"?


  18. Frank says:

    Hi David,

    I understand that the needs of my organization might not be universal, and may in fact be unusual, as SFTP was standardized as the de facto secure file transfer mechanism here some time ago.  I will say that as we evaluated various content management solutions recently, SFTP was widely supported by all vendors we spoke to.  Correspondingly, our growing number of .NET development projects have had to rely on third party components to talk to third party server products when posting dynamically generated content.

    SFTP support would have the most utility for file transfers between untrusted networks.  I once worked for an e-payment solutions provider that offered batch processing of credit card flat files.  These transfers happened over FTP, and we added IPSecurity entries to help mitigate risk associated with clear-text login credentials.  Not once did a customer ever request to use FTPS, but we very frequently were asked if we supported SFTP.  Perhaps the landscape is changing in support of file transfer protocols that run on top of SSL, but I haven’t seen evidence of this myself.

    I would say that the fact that *nix world has embraced SFTP and little brother SCP is worth something and shouldn’t be dismissed outright… At least it demonstatrates that there is a secure file transfer protocol that has seen some sort of widespread adoption.

    That SSH has seen pretty widespread adoption as a secure replacement for telnet might also stoke some interest for this purpose as well, but I see the killer app for SFTP in the Windows world being secure file transfer across untrusted networks.  As indicated before, DFSR appears to be a great technology on which to allow for Site Server like web farm content deployment, but it only functons within a single domain.  We’re still forced to find our own way of getting data outside of our firewall and onto that untrusted domain.  

    That SFTP is extensible with respect to authentication is a total bonus.  Where Kerberos is infeasbile due to trust or firewalls, certificate mappings and simple windows auth has consistantly fit the bill.  It would be awesome to see an SFTP server implemention that integrates such features with AD ala Directory Service mapping, perhaps.  

    Just my two cents.

  19. Ashley Frank says:

    The quickest and best solution would be for Microsoft to provide an SSH server IMMEDIATELY. Then work out webdav over the long term. It absolutely sucks how this issue is always the last thing with Microsoft.

  20. David.Wang says:

    Ashley – The golden rule about customer and users is to NEVER do what they say or want – you do what they NEED. So, my question, as I have asked many times before but never got answers, is WHY you need this – what is the opportunity cost and business justification/rationale.

    The issue is not whether we can provide an SSH server but rather why we need to provide and maintain one. You do want software that is maintained and updated, yes? Not like AppCenter?

    And to do that, there has to be a business reason/justification for Microsoft because then you get a team and money to do it.


  21. EDF says:

    David – There are several issues here.  At my company, as in some of the others mentioned here, we are bound to "no plain text transfers over the wire, especially into and out of the DMZ".  As a result, we install SSH server on the servers and use SSH client and batch files for automation (SSH is working on a .net API I am told).

    Our requirements are that file transfer must be secure, and this is resulted in us writing our own publishing program that does nothing more than take a file/directory and upload it using ssh commands (scp specifically) to some other server.  We expose that page as a web application itself on our intranet and secure that with NTFS persmissions (or if we were to port it to *nix – authenticate our people using siteminder and LDAP)

    A better solution?  Build an scp (better than sftp, IMHO) /sftp client add-on for visual studio 2005.  We can then gateway the SSH tunnel connection to the DMZ from boxes with authority to reach the DMZ.  Then we could publish from our development studio.

    Another solution…  although some security zealots might protest, we are discussing a way to make the publishing process a function of the application itself.  With the upload of a zip/msi/directory/file from the web browser over ssl.  There’s a file upload component in WS2005, and yoiu can secure it in any manner you would secure your business application (AD/LDAP/etc.) and do it over SSL from anywhere in the world.

    The problems we have with that regard publishing to a web farm…  exposing hooks to the server scheduler so that at 3pm on every server (ntp synched), a command executes and the code gets installed (whether that command is merely a copy, an msi install, or a zip being inflated and applied, or whatever else is needed).

    Problems we haven’t completely solved are synchroized publishing, publishing on demand.  Logging related to who did what and when when they do publish… and using a solution that could work for every IIS based application we have.  If we write it into the app, then I’m sure we could borrow code from one app to work in another, but that still doesn’t address publishing on demand in a fast fashion when you have 8 web servers that all need to be updated for an emergency bug fix.

    SSH tunneling of FTP doesn’t help.  First, we have banned ftp, telnet, and the like on all platforms.  Second, we increase the footprint of our webservers by adding ftp.  And it is unnessary to do so if the server can receive and scp or sftp request in the first place.

    I also agree with Frank – that many of our clients as requesting secure file transfer with us.  The majority are looking for an ssl upload (kind of like SA’s fileupEE), or a direct scp upload ability that can be automated.  In turn we are looking for means to provide that both internally and externally to our clients and our business units.

    Having your clients re-invent this wheel and to do so in their own ways are contrary to what Microsoft has demonstrated with VS2005.  The built in components that came with VS2005 were to reduce the number of times we had to re-invent the wheel, or go looking on the web for someone else’s source code to inspire us to create our own solution.  If often seems that this issuie of "we don’t want you to re-invent the wheel for common tasks" only applies to developers.  Rarely do we see such a mission for the administrators.  Maybe we do with the revisions shown in monad, but the reality is that this blog discussion is taking place now and you seem to be in agreement with us that it’s a pain point.

    Our requirements in a nutshell?

    authenticated users can publish to mulitple destination servers securely using well known protocols (I can only think of ssh and ssl really) to the destination servers where processes/commands can be executed to implement a software solution both on demand or on a scheduled basis.

    I know this is long, but I hope it is explicit enough.  I’ve been interuppted about 10 times writing this, so I hope it makes sense when I hit submit.

    Thanks for the listen and the blog…


  22. Frank says:

    EDF articulated our requirements very nicely.  The idea that some sort of scheduling be coupled with SCP in the MS solution is a nice touch, as scheduled press releases and code updates are an area which my organization is consistantly having to throw together some sort of custom solution (or be watching the clocks)…

    Either way, I am in agreement that MS should not be attemping to entirely reinvent the wheel here and should try to use an existing secure file transfer protocol (my vote is SFTP/SCP).


  23. Ashley Frank says:

    I need to be able to publish securely to Microsoft IIS web servers I do not control and I need to host Microsoft IIS web servers and allow customers to publish using web based protocols. These servers are on the internet with firewall. Some of these clients may not even be running windows so I need a standard. If you provide an SSH Server today then I can publish with the built in FTP part of Visual Studio 2005 using port forwarding.

    The only other possibility I can think of is add WebDav to the options of ways to publish from Visual Studio. While it is a bit of a pain to set up IIS for this at least non MS clients can use it.

  24. John says:

    WebDav with SSL is the only option.  FTP is not user friendly and requires other ports to be opened. You want to keep users in one familiar envronment, the web browser.

    IIS does have WebDav support with SSL, but it is not user friendly, nor is it fully functional. It needs to be able to upload and download directories as well as files. It should also utilize graphics to represent folders and file types. Finally, it could use drag and drop functionality.

    There are 3rd party products out there that can do this, but it would be nice if it was baked in.

  25. We are stuck with FPSE.  Why?  Because it is the only protocol that seamlessly integrates with InterDev 6.0 (yes, we are living in the past – and are committed to it until we can migrate the hundreds of classic ASP sites and applications we have to .NET).  We know it is a beast, and I have written scripts to monitor and correct the inevitable security flaws that crop up in the metabase (don’t get me started) on the various _vti directories.  Also, it does look like a team player as far as third-party revision control is concerned.  But, it works over the same HTTP connection that can be used to browse the site, while still allowing for a separate permission set for access to author.dll…

    WebDAV is a nice idea, but the implementation within IIS does not allow for clean separation of authoring actions from browsing actions; in order to enforce controls (such as authentication in order to author) it is easiest to create a separate WebDAV site in order to lock things down.  Do you want to consume another IP, use a non-standard HTTP port, or setup a complicated DNS scheme in order to use host headers?  Each possibility has its drawbacks.  I guess we could come up with a highly complicated NTFS security scheme and then just allow Anonymous WebDAV – frankly, I’d rather force authentication and security at BOTH the NTFS and IIS layers.

    FTP is outdated, lacks any form of versioning / authoring integration, sends passwords and data in the clear, etc.  SFTP only resolves one of those issues…

    As mentioned above, there are some features that need to be made available to any solution, one of them being a more atomic publish operation – at the very least the option of waiting until all of the files are transferred until overwriting the target files.

    SSH is nice because it is extensible, in terms of authentication, encryption, and application support via subsystems and tunneling, and I would certainly use it as a remote console application for managing IIS servers.  It would make a fine alternative to FPSE, FTP, and WebDAV as long as port 22 can be opened and as long as someone (in this case, Microsoft, since the topic is what they should do) provides subsystems to perform all of the appropriate authoring, versioning, etc. along with integration to the various developer tools.  Which amounts to the same amount of work required for all of the other solutions, plus integration, while centralizing the role of authentication and encryption in the SSH server.  Hey, at least we get the bonus of a secure shell by default.  Too bad so many of the tools for managing an IIS site have little or no command line support – makes integrating them as SSH subsystems rather difficult.

    Thomas S. Trias

    Senior Developer

    Artizan Internet Services


  26. I meant to say that FPSE "DOES NOT look like a team player"…

    Thomas S. Trias

    Senior Developer

    Artizan Internet Services


  27. Ben Rogers wrote:

    "FTP by itself is insecure. It’s a dead end. FTPS sounds interesting, but I’d like to see client-side support built into Windows. We don’t want to tell all of our customers that they need to buy a third party FTP client just to upload a file. "

    You can get a free command-line FTPS client here:


    For publishing web content, I use a dedicated server to which I can push files via SFTP, FTPS and HTTPS (my choice).  It’s hardened and behaving like a file server is its only role (the server has no ability to interpret or serve the content I upload to it).  Then I have a real-time replication task on another server pull the content, validate it (e.g., virus check it) and push it to the production web server.  That way I can edit my content from anywhere and avoid leaving a back door into my production web server on the Internet.  

  28. Jim Huffman says:


    My company has recently started receiving data from our client using ftp and even more recently SFTP. So, instead of using a VB6 app that traversed 3 ftp servers and downloaded changed files, I have to download manually. As dotNet doesn’t (at least, I haven’t found anything yet) handle SFTP – SSH, it looks as if I will have to use a third party component or continue to use FileZilla and manually download files. Seeing as how we’re talking 50 to 80 Terabytes a year, this could get painful.



  29. David.Wang says:

    Jim – IIS7 supports FTPS (FTP over SSL).

    It is unlikely to see SSH or SFTP (FTP over SSH) implemented by Microsoft within Windows, .Net, etc anytime soon. The hurdle there is legal, not technical. Unfortunately, customers get caught in the middle.