Depends on what you actually want to do and what the security requirements are. There are several options. The easiest one is to use the copy command with UNC path for the remote computer \\hostname\sharename\directory\actual.file. Important is, that the remote computer has the share defined and permits write access (on file and share level) for the user hudson is running under. This also means that you can't run hudson under the local_system account. (default option if you run Hudson as a service)
Actually I would prefer robocopy over copy. I think microsoft offers robocopy for free. Study the documentation (help) of robocopy, it is a program for administrators who are supposed to know what they are doing. Robocopy is not only robust, if used with the wrong switches, it can also 'unintentionally' delete files.
Other options would include SCP and FTP, Master\Slave configurations where the slave downloads the artifacts from Hudson using http/https protocoll.
EDIT:
comment from vishu
Thanks for your prompt response. As
your answer explains that you have
good knowledge in Hudson, I would
like to give my requirement in detail.
My requirement is , I like to deploy
war in tomcat server located remotely
in another windows machine through
Hudson (war will be generated in this
machine) which is located in another
windows machine. FYI, Both windows are
on the same network or intranet.One
more thing to Linux deployment we are
using plink. Is there any alternative
for Windows deployment?
I usually deploy to Websphere Application Server. So i needed to read a little bit on how to deploy to tomcat. It looks like you just need to drop the wat-files into the right directory and you are done or change the configuration files that are currently used by tomcat and it will pick it up automatically (provided everything is configured correctly).
Since the deployment scenario and your setup is very simple I would consider two options. My preferred on is to install a ssh service on the target Windows machine and reuse your plink scripts that you already have (for this or other projects). The idea is here to stick to one technology. The other option is to use windows shares. In this case make sure that Hudson uses a 'real' account so that Hudson does not explicitly need to map the share (can be scripted, but passwords might be stored unencrypted). Create a share on the target system with write permission for Hudson. Than the rest is nothing else than a copy. For the copy you should have a look at robocopy, since it is far superior for this kind of jobs than the copy command. My assumption here is that the build job does the deployment.
In case you have two jobs, the first one creates the artifacts and the other one deploys the artifacts. I currently prefer the use of wget to retrieve the artifacts from job1. This implies that job1 archives its artifacts. The second job gets the artifacts from the first one (using wget and the run URL for job1). In this case you can run a Hudson slave on the target machine and you can deploy locally. You can use similar scripts for windows and Linux. You can get wget for windows with cygwin (at least I think so). With cygwin you might even be able to use your linux script on windows. The advantage is, that you don't need shares and no separate artifact repository. If you run the slave as a service, you don't even need to install an ssh server on the target machine.
If you trigger your deployment manually, you can use the batch task plugin. Than it is practically one job and you don't need to worry to move artifacts between jobs. The disadvantage is, that you can only deploy from the most recent job run, since it depends on the workspace of the job. Deployment of older versions (if your project is broken right now or if you need to downgrade because of a major bug in your app) is not possible.
If you already have an artifact repository, use the master slave setup and check the artifacts out of your repository from the target machine.
I could come up with more options, which will become more and more esoteric. In the end you have to decide what you like the most and what is easiest to implement AND maintain as well as satisfies your other (minor) requirements (e.g. certain security restrictions).