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.
//David
Comments
- Anonymous
March 22, 2006
The comment has been removed - Anonymous
March 22, 2006
FTP because it's widely supported. SFTP would also be a good option. - Anonymous
March 22, 2006
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. - Anonymous
March 22, 2006
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. - Anonymous
March 22, 2006
The comment has been removed - Anonymous
March 22, 2006
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.
Seth - Anonymous
March 22, 2006
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!!!!. - Anonymous
March 22, 2006
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.) - Anonymous
March 23, 2006
The comment has been removed - Anonymous
March 24, 2006
The comment has been removed - Anonymous
April 05, 2006
Has anything come out of the suggestions that were posted either of the blogs what you solicited feedback from?
thanks. - Anonymous
April 05, 2006
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...
//David - Anonymous
April 11, 2006
David,
I would love to see SFTP.
Thanks!! - Anonymous
April 12, 2006
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...
//David - Anonymous
April 17, 2006
The comment has been removed - Anonymous
April 24, 2006
The comment has been removed - Anonymous
April 24, 2006
The comment has been removed - Anonymous
April 25, 2006
The comment has been removed - Anonymous
April 28, 2006
The comment has been removed - Anonymous
April 28, 2006
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.
//David - Anonymous
May 01, 2006
The comment has been removed - Anonymous
May 02, 2006
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).
-Frank - Anonymous
May 15, 2006
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. - Anonymous
May 23, 2006
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. - Anonymous
September 13, 2006
The comment has been removed - Anonymous
September 15, 2006
I meant to say that FPSE "DOES NOT look like a team player"...
Thomas S. Trias
Senior Developer
Artizan Internet Services
http://www.artizan.com/ - Anonymous
July 31, 2007
The comment has been removed - Anonymous
August 13, 2008
The comment has been removed - Anonymous
August 17, 2008
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. //David