Hi,
I downloaded a copy of VisualCron yesterday and am trying to determine if it will work for us, but I've run into a problem right away. I, and the developers who will use the software, need to be able to connect via our domain accounts. I have made my account a member of the admin group on the server. (Since we'll only be using VisualCron for our development server, it won't be a problem to make all of the developers admins on the box.) But when I try to connect, I get an error that the account does not exist. I am enterting my username as semi\myname, where SEMI is our domain and MYNAME is my computer ID. Any help will be greatly appreciated.
Beverly

For now, VisualCron uses it's own authentication system as we initially did not want to depend on the AD. So you need to create users from the VisualCron Client (while connected). The users have nothing to do with domain accounts.

---

Thanks, Henrik. I think this means this product won't work for us.
Beverly

We have received requests before but never allocated time for this change. One questions is how to handle new users and their permissions. If we should work with Windows groups or not. There are a lot of permissions that each user has which is not specifically connected to any Windows permissions. We are willing to investigate more and discuss this more if you have time and are interested.

---

The problem is that we only decided recently not to renew our support with the existing product, so I only have a few weeks to find a replacement.
Thank you so much for your quick responses to my questions.
Beverly

We can do some research this week and get back to you.

---

That would be great. I'll be on vacation May 6th - 13th, without access to email. I'll be back in the office and online Friday, May 14th. Here are my basic requirements. I sent them to a guy in my group a few minutes ago, to see if he could come up with something. FYI, BCL is our in-house written Batch Control Language, that sits on top of a C-Shell product.
1. Developers need to be able to run batch jobs (usually BCL, but can be anything—PERL, .NET., etc.) on the remote server.
2. They need to be able to run these jobs as their domain accounts. This includes being able to connect to Oracle via these NT-authenticated accounts. This is where the “psexec” program failed my testing.
3. They need to be able to pass a command string—not just call a batch script on the server. For example, “d:\dev\app\common\exe\runjob.cmd testsend dbadmin parm1 parm2 parm3 etc”
4. Since this is just dev, we can make the developers admins on the box.
5. The GUI should allow them to enter their userID/ password and the command string. That’s pretty much it.