NT4 TSE run from _at_ scheduler call to batch script
Hi everyone,
I've been searching this forum and testing various different configuration all day long with my setup. Here is the situation:
My client has 10+ NT4 windows TSE servers. On each of these TSE's we have our application software installed. However, we are constantly updating all the compiled objects for our software several times a week. Updating each of these TSE's can be a laborous task. Keeping all the objects on each TSE up-to-date is even more of a challenge. All the TSE's are re-booted every morning (to clear their memory, since NT4 does such a terrible job releasing memory) and consequently the biggest problem we run into is that some of these TSE decide that they don't want to boot up again after the shutdown. This results in compiled objects becoming out of synch when they miss the daily update since we don't copy all objects, but rather only those that have newer versions.
Winscp seems like a great solution to our problem of keeping these compiled objects synchronised on each TSE server. What we would like to do is create a batch script which can be called at boot time to synchronise all the compiled objects as well as have the batch script scheduled to run at a specified time each day.
The problem we're having implementing the desired solution above is that the batch script ends up being run by the SYSTEM user and that user does not have access to the rsa-ssh keys registered under the administrator registry entries. Is there another way to include these keys in the registry so that all users can use a global entry of the keys?
I then tried to specify the use of the WinSCP3.ini in the batch file but that doesn't seem to work either. When I created the batch script under the Administrator account I ran the script manually and confirmed that it worked. The problem seems to be that the SYSTEM user does not have access to the key entries in the registry.
One final note: the servers we are using are all behind a firewall and exist on a trusted network. An option to simply turn off the check for the rsa-ssh keys or even ignore the check would be more than acceptable in our situation. Is this possible?
Please let me know if any more information is needed to figure out a solution to these problems.
Thanks in advance,
Matt
I've been searching this forum and testing various different configuration all day long with my setup. Here is the situation:
My client has 10+ NT4 windows TSE servers. On each of these TSE's we have our application software installed. However, we are constantly updating all the compiled objects for our software several times a week. Updating each of these TSE's can be a laborous task. Keeping all the objects on each TSE up-to-date is even more of a challenge. All the TSE's are re-booted every morning (to clear their memory, since NT4 does such a terrible job releasing memory) and consequently the biggest problem we run into is that some of these TSE decide that they don't want to boot up again after the shutdown. This results in compiled objects becoming out of synch when they miss the daily update since we don't copy all objects, but rather only those that have newer versions.
Winscp seems like a great solution to our problem of keeping these compiled objects synchronised on each TSE server. What we would like to do is create a batch script which can be called at boot time to synchronise all the compiled objects as well as have the batch script scheduled to run at a specified time each day.
The problem we're having implementing the desired solution above is that the batch script ends up being run by the SYSTEM user and that user does not have access to the rsa-ssh keys registered under the administrator registry entries. Is there another way to include these keys in the registry so that all users can use a global entry of the keys?
I then tried to specify the use of the WinSCP3.ini in the batch file but that doesn't seem to work either. When I created the batch script under the Administrator account I ran the script manually and confirmed that it worked. The problem seems to be that the SYSTEM user does not have access to the key entries in the registry.
One final note: the servers we are using are all behind a firewall and exist on a trusted network. An option to simply turn off the check for the rsa-ssh keys or even ignore the check would be more than acceptable in our situation. Is this possible?
Please let me know if any more information is needed to figure out a solution to these problems.
Thanks in advance,
Matt