Best approach to deploy DLL file updates to Win7 clients

Question

We are in a Windows 7 / Server 2008 R2 domain environment. We have a .NET application with lots of internal libraries for different UI and other features. We deploy it from a share where a directory is created for each "release" with the latest version number. Occasionally, there are some departments that need something tweaked in the application for their specific needs, and they need the change urgently before the next release. We can do that by giving them some number of custom DLL files with the requested changes in them. I am trying to devise the most reliable and efficient way of having our client machines automatically check for and copy down these "custom" files. I want to do this in a way that is most efficient, reliable, centrally managed and with the least amount of overhead on the clients. Preferably, when we have custom files to deploy, we would like all of the clients to copy them down within 24 hours after we put them on the share. They would go in a subfolder of the current network release directory, named "Custom" or something similar. We do not have SCCM at this time, so I am looking at the following options:

1. Batch file logon script for users that will check the network directory and copy down (overwrite) local files using robocopy or xcopy. This would require the user to log off and back on, so there could be a delay in getting any custom files. Users would have an easy, relaible way to trigger it so that would be a plus.

2. Scheduled task configured via Group Policy Preference item, to check the network directory perhaps a few times a day for any custom files. This might get the file more quickly than a user logon script, but I have no experience with GPP Scheduled Task items. Is it reliable and simple to setup and maintain? Again, this task would run a batch script to check for files on the network and kick off robocopy with the /xo option. If we put any files in the custom directory we are going to assume they are needed, regardless of the versions. Simply checking the file dates should work, so they won't be re-copied over and over once they are in place.

3. A Scheduled Task same as above, but triggering based on an event log entry. Is this reliable? I have never tried it. It might be advantageous to find an event trigger that would indicate the application was just launched (or closed), and then copy the files right away so there's less chance of the user's work being interrupted.

4. I know there is also a Group Policy Preference item for managing /copying files. I believe that would be too much work to manage in this case, because there could be the potential for several files at a time, over multiple versions of the application.

5. I also considered a Powershell script, which could do interesting things like compare the actual DLL file versions, etc, but this will probably require more resource overhead (run slower), and is really doing more than needed.

Any other ideas on what might work best? Is the simplest answer (user logon script) really the best here?

Answer 1

I ended up going with option #1, a user logon script, and this has been working reliably for some time now. I would post the whole script here but it is full of internal application details that would render it mostly useless for general use. The most interesting detail is we are using wmic to get the internal version number of the locally installed application, and using that to refer to the correct version directory on our deployment server. This code sets a variable named Version to match the value returned from wmic.exe

set "myfile=c:\\progra~2\\%AppFolder%\\AppName.exe"

for /f "tokens=*" %%f in ('wmic datafile where "name='%myfile%'" get version /value ^| findstr "="') do set "%%f"