I'm looking for a way to setup pull deployment as apposed to the traditional push deployment model under Windows.

The optimal situation would be:

  • Deploy the file(s) to the master server
  • The child server would check to see if the master had an update at a given time or time interval.
  • If the master server contains an update, then it would download the update and/or execute a script (something like nant?)

The solution needs to be as light weight as possible and must run under a Windows environment.

I've taken a look at Chef and SmartFrog but are not suited for this particular situation.

Edit: There are multiple pieces of software being deployed. These are database scripts, windows services and a web site. Each child will have it's own unique script as it's requirements and authentication details are different from the rest.

Edit 2: So far people have come up with great answers but the end solution really does need to be secure, run internally and all happen at the same time. This is due to compliancing, industry regulations and version issues (eg. db server out of sync with services). The end solution that I have in mind would be something like an FPT server on the master and Nant running on the children to execute the install routines (starting, stopping services, installing sql scripts, logging installs). This is the closest thing currently available, but is not ideal as nant works on a push basis (only executes when someone or program, eg. cruisecontrol, runs the script). I'm sure there has to be a solution to do a proper PULL deployment for Windows. Windows update and APT on Linux are great examples of pull deployment if you could do the the deployment across multiple servers all at the same time.


I'm not 100% clear on the type of app to be deployed - but if this is a Windows Forms application to be distributed to clients / end users, then you have looked at ClickOnce? This has modes for automatically polling and pulling down deltas from clients. But it seems that you are distributing to other servers?

I really don't think ClickOnce will probably cut it. I've added further details to my question about the software being deployed.

A couple of years ago I've implemented a system that did about what you are looking for.

For the client application we used ClickOnce deployment which just works great. For the windows services and websites we had to implement our own system because we could find nothing that would work for us.

For the database we tried replication (sql2005), this didn't work out to well took a lot of time and processor power. We chose to make a backup and restore data (it was all readonly on client servers)

In a nutshell

1) The master server will hold several zipfiles with the new version of Webservices, Websites and databases.

2) The client servers windows service daily scan the master server (using ftp) for new versions of the software.

3) When found it would - uninstall the windows service and replace the files and reinstall it - replace website files - replace the database

Unfortunately I'm really not interested in building our own. It's just too much work for us to build, support and maintain.It's really annoying as I have got a push deployment working using MSBuild, PSExec, NcFTP and a few other methods and it works perfectly. It's just that we can't drop PSExec and such tools which open up services and ports into our enviroment on the child/target servers.

Windows Live Sync

Have you given any thought to windows live Sync?

Its free, and all you would have to do is set up two folders. One in your Master server and one in your Child server.

Once set up, all files will be automatically synced.

Update should be really easy, once you update your Master folder, it will automatically be replicated in the Child end.

It is totally fire and forget.

I use this system (one deployed on a server) with six 'child' nodes, syncing 1000's files daily with ease.

Edit 1:

Forgot to mention, the files are encrypted, and it uses reverse connection, so there is zero router/firewall configuration.

Some servers have net connection some don't and those that do only have it for short bursts of time as it is a secure environment. Also install routines need to be run locally on each machine. Windows services need to be stopped, updated and the restarted otherwise you can't do the update. DB server need to download SQL scripts and execute them against the correct databases.The other problem is it would need to NOT be accessible from everywhere otherwise we would fail compliancing and security audits. Although I'm pretty sure we may be able to add mitigation routines, but its extra work.

Are yoy running domain controller? So that you can jsut "advertise" them? Doesn;t get any lighter that that. Modify this line for your path to see the UI, but it should be scriptable as well - at leas in PowerShell.

"C:\Windows\SysWOW64\rundll32.exe" "C:\Windows\SysWOW64\shell32.dll",#44 "C:\Windows\SysWOW64\CCM\SMSRAP.cpl",Run Advertised Programs

No domain controller.
Well, then it's high time to run that dcpromo on one :-) Seriously, you already paid for all infrastructure so you'll be much better off just using it instead of trying to reinvent the wheel like you are on a some poor Linux farm :-) You can make boxes transfer updates with BITS (background movement of data doesn't get any lighter than that) and you still have an option of either letting them install on the spot or wait for a scheduled time. Windows server farms usually spread normal updates (every box can have individual update window).

I have used a combination of cruise control .net and subversion for this exact usage with lot success in the past.

Subversion is secure and will act as the master server. Cruise control .net fully support both subversion and nant. Of course it can do a lot more. We used to have very complicated logic due to the industry we were in and its requirements (utility).

Pierre 303

Hi, I've heard of this situation before when I was talking to someone when I was in St. Louis for the "birthday party" of their website. I wonder if that was you.

In any case, I would use the Web Deployment Tool (MSDeploy) for this. MSDeploy is more like a sync tool then anything else. The concept is that you have a source and a dest, you want to sync them up. If you are doing a normal push deployment your build server would sync the output of some build with each target server. If you want to do a pull deployment, just drop the files you want into a shared location (you're calling this master server) then your client machine can sync itself to that master server.

Here are some more details which you mentioned in your question:

Deploy files to master server Your build server can use MSDeploy to deploy files to master server

The child server would check to see if the master had an update at a given time or time interval. There is no direct support for this, but there are really two things here. Thing one: You can run MSDeploy from a script (.cmd/PowerShell/MSBuild/etc) and it can determine if there is a newer version. I would do this by dropping a version file at the top level of your output folder. Then when your script kicks off just read what version is on the server. If a newer one is available then kick off a new new deployment. Thing two: MSDeploy supports incremental deployment so even if you kick off a new deploy it will just not make any changes. This is tricky when you start talking about DB deployments though so in your case probably ill-advised, I would go with some flavor of Thing one.

If the master server contains an update, then it would download the update and/or execute a script This is what msdeploy.exe is going to do for you.

Other related items

  • Incremental publishing: If your web contains 1000 files but only 5 changed, then only those 5 get deployed
  • Customization: MSDeploy supports parametrization, so when a client starts a sync you can provide the specific values for that client. With these you can change all types of files including web.conig/.xml files/text files/etc. You can even provide custom IIS settings
  • Authentication: You can use normal windows auth if you are using IIS 7 you can create WMSvc users and use those.
  • Security: WMSvc can be used for this

Does this suit your needs?

Sayed Ibrahim Hashimi
+1  A: 

You say you want to do Windows Software Deployment and yet you talk about build scripting languages such as NAnt. If it was me, I'd write a Windows Installer package using InstallShield and take advantage of it's UpdateManager service to get the clients pulling updates from your update server. These tools have been around and proven for a long time and will be far more secure then anything that you reinvent.

Christopher Painter
Have you got any supporting documentation or demo's you can link