Microsoft Web Deploy is primarily used by web developers and IT professionals for deploying and managing web applications. It is often used by companies and organizations that rely on the Microsoft web stack (IIS web servers, ASP.NET, etc.) for their websites and web applications.
Web Deploy allows system administrators to package the configuration and content of installed web applications and use them for storage or redeployment. It is a valuable tool for synchronizing two servers or migrating across different versions of IIS. Web Deploy comes with snapshot (roll-back), differential synchronization, and automation features, making life much easier for administrators.
However, web deploy has severe limitations regarding scalability, lack of WAN optimization, and user-friendliness, mainly due to its client-server style architecture.
This is where Resilio Connect thrives with its peer-to-peer architecture, centralized management console, automation through scripting, and WAN optimization features. The speed of synchronization across a growing number of endpoints is phenomenal, making Resilio Connect a superior alternative to Microsoft Web Deploy without a doubt.
Background and overview of Microsoft Web Deploy
Microsoft Web Deploy was first developed by the Microsoft Web Platform and Tools team as a tool to aid in the deployment and management of web applications. The first version of Web Deploy, called “Web Deployment Tool,” was released in 2008. You can use its command-line tools and APIs to automate the deployment process. Initially, this tool could be used on Windows Server 2003 (IIS 6.0) and on Windows Server 2008 (IIS 7.0).
MS Web Deploy helps you keep sites or servers in sync with IIS and migrate them between different IIS versions. The most commonly used version is MS Web Deploy v3.6. However, the latest version is MS WebDeploy 4.0, built against .NET 4.5. No new features have been added other than some bug fixes. Currently, WebDeploy 4.0 is only available with Visual Studio 2017 and higher.
It is essential to mention that synchronizing merely two servers requires users to fulfill several requirements, like checking dependencies on source servers and installing them on target servers. Therefore, synchronizing multiple servers using MS Web Deploy can easily become bothersome and error-prone. Resources that can be synchronized include websites or applications, content folders and files, databases, registry keys, assemblies in the GAC and more.
Underlying MS web deploy architecture.
The architecture of Microsoft Web Deploy is based on the client-server model. When using Web Deploy, a client initiates a connection with a server, and then sends the files and configurations to the server. The server then updates the destination server with the new files and configurations. It uses HTTP and HTTPS protocols to transfer data based on the TCP/IP protocol suite.
Microsoft Web Deploy components
The main components of Microsoft Web Deploy are:
MSDeploy.exe: This is the command-line tool used to package and deploy web applications. It can also synchronize IIS servers, import and export IIS configurations, and create or delete databases.
Providers: Providers are the building blocks of MSDeploy. They are responsible for performing specific tasks, such as syncing content, creating and deleting databases, and configuring IIS settings. MSDeploy includes several built-in providers, and developers can also create custom providers.
Package: A package is a compressed file containing a web application’s contents and information about the application’s dependencies and configurations. Packages can be created using the MSDeploy command-line tool and deployed to IIS servers using the same tool.
Deployment rules: Deployment rules control how MSDeploy packages and deploys web applications. They define how the contents of a package are deployed, and they can be used to manage the order in which things are deployed and to specify which files or folders should be excluded from the deployment.
Manifest: A manifest is a file that describes the contents of a package and the deployment rules that should be used to deploy it. It contains information about the package’s dependencies and configurations, and MSDeploy uses it to determine how to deploy it.
Functions and features of MS Web Deploy
MS Web Deploy offers the following functions and features:
Package websites and applications:
It can easily package configuration and content files of installed web applications and use these packages for storage or redeployment.
Synchronization of IIS 6.0, IIS 7, and IIS 8.0 web servers
Sync operation enables administrators to synchronize a website or server and deploy changes to existing sites and servers. A synchronization allows you to synchronize one source with one destination. For example, you can synchronize two directory paths or two web servers.
Snapshot IIS 7.0 and above:
This is essentially a rollback feature allowing administrators to quickly take an archive of their website or server to mitigate possible future deployment failures.
Differential synchronization:
The tool will only synchronize what has changed between the source and the destination.
Delegate deployment tasks to non-admins:
Administrators can conveniently delegate deployment tasks to non-administrator users. More advanced delegation tasks can also be enabled.
Simplified deployment:
Server administrators will find the delegation useful, since deploying a Web application, including a GAC’d assembly, certificate and application pool, can be time-consuming even with all the permissions required.
Migration from IIS 6.0 and IIS7:
MS Web Deploy allows administrators to migrate sites or entire servers from IIS 6.0 to IIS 7 and above, IIS7 to IIS8, including their settings and content.
Troubleshooting and validation:
The -whatif parameter is designed to help administrators see what actions would happen when they perform an operation. This feature is handy for performing sync or migration, when you want to validate what changes will be made before performing them. Similarly, the -verbose parameter allows you to dig deeper into operational details, which is crucial for troubleshooting.
Easy scripting through PowerShell:
Common Web Deploy tasks can be automated using powerShell cmdlets.
Limitations of MS web deploy
- Lack of multi-vendor support
MS Web Deploy isn’t compatible with web servers other than the Microsoft IIS. Apache, Nginx, Cloudflare and OpenResty offer the most popular web server solutions. Microsoft-IIS is used by only 5.7% of all websites, according to W3Techs.
- TCP/IP architecture
TCP/IP-based architecture isn’t suited for WAN links as every packet loss, or acknowledgement delay is treated as network congestion leading to the activation of a back-off algorithm leading to sub-optimal utilization of the connection. In the case of wide-area networks (WAN), a delay or packet loss doesn’t mean the network is congested. Therefore, the logic of MS Web Deploy (and TCP/IP) is not appropriate for WAN connectivity.
- Lack of WAN optimization
Microsoft Web Deploy does not have built-in support for WAN optimization. It is a set of techniques used to improve data transfer performance over a wide area network (WAN) connection. These techniques can include compression, deduplication, and caching to improve data transfer efficiency.
While Web Deploy focuses on simplifying the deployment process of web applications, it doesn’t have specific features to optimize WAN connections.
- Lack of real-time file change detection
Microsoft Web Deploy does not offer real-time file change detection. It typically relies on an explicit action from the user to trigger the deployment process. The user can manually initiate the process of deploying files and applications using the Web Deploy command-line tools, the Web Deploy Management Service, or the Web Deploy API. Once the deployment process is initiated, Web Deploy will compare the files and configurations on the source and destination servers, and it will update the destination server with any changes that have been made.
- Weak transit encryption
MS Deploy relies on HTTPS for connectivity between different endpoints. It uses SSL (Secure Socket Layer) and/or TLS (Transport Layer Security) as its underlying encryption mechanism, which works on TLS certificates. These certificates are issued by Certificate Authorities (CA). The role of CA is to be a trusted third party in the client-server relationship.
However, with HTTPS, only the communication messages between your web browser and the serving web server are encrypted, while the IP addresses are not. Hackers can easily exploit this to launch man-in-the-middle attacks.
VPNs (Virtual Private Networks) are a better alternative to ensuring complete transit data encryption, including IP addresses. They easily accommodate TCP and UDP traffic, while HTTPS relies on the connection-based TCP protocol. Yet VPNs also have performance drawbacks.
- Authentication and Authorization issues
Web Deploy needs the correct permissions to access the files and directories on the source and destination servers. If the permissions are not set correctly, Web Deploy may not be able to access the files and directories. The flowchart diagram below explains it further:
If the destination is Windows Server 2003 running IIS6, you can connect to its Web Deployment Agent Service (also known as the Remote Agent Service) endpoint. Only administrator users have access to the Remote Agent Service, which provides security for this connection.
If the destination is Windows Server 2008 running IIS7 or Windows Server 2008 R2 running IIS7.5 and you are connecting with non-administrator credentials, you must connect to the Web Management Service endpoint.
If the destination is Windows Server 2008 running IIS7 or Windows Server 2008 R2 running IIS7.5 AND you are connecting with administrator credentials, you can connect to either endpoint.
- Version incompatibility on the source and target systems
You must check on several incompatibilities for error-free website and application deployments. Otherwise, MS Web Deploy can stop functioning or lead to suboptimal performance.
Some of these challenges are:
- Incompatibility between the version of Web Deploy installed on the source and destination servers. If the versions are not the same, this can cause errors or prevent the deployment from completing successfully. (Steve has shared in the comments section how he had to downgrade the Web Deploy version on the target server to successfully run a server Export/Import job between two 2008 R2 machines, both with IIS 7.5.)
- Incompatibility between the version of the .NET Framework used on the source and destination servers.
- Different versions of IIS.
- Incompatibility between the version of Visual Studio used to create the project.
- Different versions of Windows on the source and destination servers can lead to errors; and error messages that are difficult to decode.
- Error messages that are difficult to decode
Several users have reported all types of error messages generated by MS Web Deploy. Some are more general, like the “DESTINATION NOT REACHABLE” or the “ERROR_FILE_IN_USE” message, while others are not that easy to decode. One example is the “Object reference not set to an instance of an object” error message due to a missing IIS key in the Windows Registry of the target server. Although Microsoft has shared a list of Web Deploy error codes and also the ways to troubleshoot them, but this can be pretty frustrating at times. These errors can be caused by various issues, such as incorrect configuration settings, missing files or dependencies, or conflicting processes or services.
What are some of the alternatives to MS web deploy?
- FTP
File Transfer Protocol was developed in the 70s. As the name suggests, it is just a file transfer protocol and doesn’t work on the principle of replicating data changes only. FTP is insecure but it does have secure versions like SFTP and FTPS.
FTP works using TCP, which is why it doesn’t work well on unreliable networks. File transfer durations and complexity increase with the size and number of the files leading to severe scalability issues.
Direct uploads using FTP may appear convenient but are highly discouraged in a team environment. Some related concerns are:
- Can you be sure that you are uploading the correct version of your app?
- What if your app breaks down after uploading your code? Can you rollback easily?
- How can you be sure that you are uploading the correct file without having to upload the entire repository?
FTP is still very popular and works with all major platforms.
- Rsync
Rsync was introduced in the 90s for synchronizing Linux servers in simple scenarios using uni- and bi-directional file sync. It is suited for low-latency and smaller data sets. The reason is its reliance on TCP to compare local file chunks on the source system with remote file chunks on the target to make decisions on which files to replicate.
Rsync doesn’t offer real-time file change detection, in-transit encryption, dynamic IP support or WAN optimization. Overall, it is slow and doesn’t scale well.
- Robocopy
Robocopy is a CLI-based, one-way file transfer/synchronization mechanism that only works on Windows servers. It lacks real-time synchronization capabilities, and administrators have to strive to familiarize themselves with the Robocopy command-line syntax. It lacks WAN optimization features and experiences long syncing times when transferring large files over high-latency WAN network links. Moreover, Robocopy is still affected by multiple known bugs, like it won’t allow mirroring of folders and files on systems older than Windows Vista and leads to infinite loops that must be dealt with manually.
- Git
Git is an open-source, CLI-based version control system that manages and tracks application code changes. It provides a centralized repository for code, allowing for project collaboration and deployments on servers of all types (not just the Microsoft IIS).
But, it doesn’t offer built-in deployment automation and has to rely on additional scripts or tools to automate this process. Moreover, as you deploy codes using Git, the entire codebase needs to be transferred to the server, which can be slow and bandwidth-intensive.
- Jenkins
Jenkins is a powerful, open-source continuous integration platform built using Java that can automate the complete software development life cycle, including server deployment. It can be easily integrated with other tools, like Git, and has hundreds of plugins. It comes with a rich set of reporting and visualization tools that can be used to monitor the deployment process and understand what is happening. Overall, Jenkins is widely used in big technology companies due to its scalability and cross-platform support.
However, there are certain drawbacks to using this platform. It can be quite resource-intensive, especially if you keep a lot of your build history stored in the tool. Lastly, Jenkins offers limited support for non-Java applications.
- AWS Code Deploy
AWS CodeDeploy is a cloud-based solution specifically designed for Amazon Web Services (AWS) that can deploy applications to Amazon Elastic Compute Cloud (EC2) instances and on-premises servers. It provides several capabilities for deploying and managing applications, including automatic rollbacks and one-click deployments. AWS CodeDeploy can also deploy applications to on-premise servers running Microsoft Windows Server and Windows-based (EC2) instances.
When deploying to on-premises servers, you will need to install the AWS CodeDeploy agent on each server. This agent is responsible for communicating with AWS CodeDeploy and receiving deployment instructions. The agent is compatible with Microsoft Windows Server 2008 R2 and later versions.
Although AWS CodeDeploy can be used with Microsoft Windows Server environments, it is a cloud-based solution designed for use with Amazon Web Services (AWS). It can lead to bugs when used in non-AWS settings.
How Resilio Connect offers a better and faster alternative to web deploy
Resilio Connect is a multi-purpose file sync and management solution with enterprise-grade capabilities. Conventional server sync methods, like Microsoft Web Deploy, depend on a central hub to execute their functions. This often creates bottlenecks as more servers put more strain on the hub server, and performance degrades across every device trying to sync. On the contrary, Resilio Connect works using peer-to-peer technology and can sync new data from one-to-many and many-to-many servers in parallel without any bottlenecks.
The secret behind Resilio Connect’s scalability is this parallelism. This means that as endpoints (servers) are added to a sync job, the time it takes to update all of the files in the job is still about the same!
MS Web Deploy will need to keep copying files from server to server sequentially. Resilio Connect, by contrast, synchronizes files in parallel; across up to thousands of endpoints. Moreover, Connect users don’t have to worry about cross-checking a long list of dependencies before initializing synchronization across servers, like in the case of MS Web Deploy.
Multi-platform web server support
Resilio Connect works across all major web servers like Apache, Nginx, and Node.js, while MS Web Deploy is designed to only work with Microsoft IIS servers. Connect agents support prevalent operating systems such as Windows, Mac, Linux, FreeBSD, Android, and various NAS platforms. Connect also supports popular virtualization platforms (Citrix, Microsoft, VMware), servers, storage, networks, and cloud providers.
Real-time file synchronization
Resilio Connect’s efficiency is greatly enhanced by its real-time replication features. It achieves the highest file replication speeds with unmatched scalability thanks to its P2P architecture. Most server synchronization solutions, like MS Web Deploy, transfer files point to point using a dedicated server model in which only the hub server can transfer data to client servers; client servers can’t communicate directly with each other. With Connect, by contrast, a file is replicated across all the agents as soon as a change is detected. Changes can be replicated in any direction: one- or two-way, one-to-many, many-to-one, or many-to-many.
Resilio splits files into multiple file chunks, and then transfers each chunk independently to multiple destinations. Every device in your network can transfer file blocks to any other device. And transfers can occur concurrently, resulting in 3 – 10x faster transfer than MS Web Deploy.
Resilio is one of the only real-time replication solutions that can perform highly reliable bidirectional sync. As mentioned earlier, other options include
- One-to-one scripting, distribution, consolidation, or sync
- One-to-many scripting, distribution, consolidation,transfer or sync
- Many-to-one scripting, distribution, consolidation,transfer or sync
- N-way scripting, distribution, consolidation,transfer or sync.
WAN optimization
Resilio Connect comes with built-in WAN optimization/acceleration features based on its UDP-based transport protocol, Zero Gravity Transport (ZGT). This allows you to overcome latency and packet loss usually observed on WAN links (especially satellite and radio-based links). The solution is built in and does not require any dedicated software and/or hardware. ZGT speeds up sync across WAN by up to 100x over conventional file replication tools. MS Web Deploy doesn’t offer any such capabilities.
Centralized management
Resilio Connect comes with a user-friendly, centralized and web-based management console. It makes managing and monitoring all agents and all data transfer and synchronization job functions a walk in the park.
System administrators can control agents, manage users, create and run jobs, control bandwidth allocations, and deploy job instructions across the organization. Once jobs are running, administrators are able to monitor and collect statistical data globally.
By comparison, Microsoft Web Deploy does not include a centralized management UI. To manage multiple deployments, you need to set up separate instances of Web Deploy on each server you want to manage and then manage them individually, which can be time-consuming and error-prone.
Flexibility – Deploy and sync any types of files (apps, code, content, etc.)
Resilio Connect offers much greater flexibility than MS Web Deploy for deploying and syncing any type of file (application code, content etc) across various types of servers. It allows for customization and automation through APIs and scripts, while Microsoft Web Deploy has limited customization options. Connect is also optimized for large-scale deployments and offers advanced bandwidth management options, while Web Deploy struggles with large deployment jobs and doesn’t offer any bandwidth controls.
