Out of curiosity, what happens if you throw in a delay between "rasdial" and the "net use"-- say, "ping -n30 127.0.0.1" to throw in a 29 second pause. I've noticed that the RAS client, at least in Windows XP, plays around with the routing table for a few seconds after the connection comes up.
I'm not aware of any documentation that describes what the RAS client does to the routing table. When I connect to a RRAS server from a Windows XP client with the "Use default gateway on remote network" option unchecked I see the folling behaviour:
- A "classful" route to the remote network is added to the routing table
- Within roughly 3 - 5 seconds that route is removed and a route with the same subnet mask as the RRAS server is added to the routing table in its place
When the "Use default gateway on remote network" option is ticked on, I see the following behaviour:
- A default gateway route to the remote network is added to the routing table
- Within roughly 3 - 5 seconds a route with the same subnet mask as the RRAS server is added to the routing table (and the default gateway route remains)
Supposedly if you use the Connection Manager Administation Kit you can create RRAS client entries that execute a script and/or have customized routing table entries. I've never gotten this functionality to work, though.
I'd take a snapshot of the routing table immediately after 'RASDIAL' completes (route print > before.txt) then again after a pause (route print > after.txt), figure out what lines change (fc before.txt after.txt) and add a little loop to the script to print the routing table, look for the line that signifies that the "after" condition has occurred, and if not, pause for a second and loop.
It's grungy and hackish, but it ought to work.
BTW: The behavior is different in Windows 7. You have an option to "disable classful route addition".
The while proxy ARP nature of the RRAS server has always been a little off-putting to me. I prefer VPNs where the clients end up in their own subnet and the VPN server routes traffic to them. Still, I suppose I can understand why Microsoft implemented it the way they did. RRAS clients, in their model, just end up appearing as cleints on the same wire as the LAN, and the proxy ARP "magic" that the RRAS server provides makes the sysadmin blissfully free not to have to think about IP routing.
I have the same problem.
This is what I checked.
What is the name of your batch file? Could it be a .bat? Try renaming it to .cmd
SQL Server agent is running the job. Does the service account for that service ha rights?
Do you use a call statement or do you just write the name of the batchfile?
I think you do not need a call statement (you mentioned it).
Is the owner of the job sa. This is normal today.
Do you have any net use commands or copy del etc that needs /Q /Y or other statements?
The job cannot answer any questions like there are open files are you sure etc.
Is there a windows firewall involved?
My gotcha was: I tried to do more than one thing in the job.
Don't.
Rename one thing with one job. Rename another thing with another job.
Don't do more than one thing with each job. Sounds stupid I know, but you should do it anyway for troubleshooting purpose.
easiest way to test something is net use z: \server\share and see what you get in the event viewer and job history log. Keep it simple then enter a real command.
I am very sorry it does not work like it did before when it was top-of-the-line.
Best Answer
Network drive mappings exist per-user session, so when your shortcut runs within the security context of administrator, no drive mappings exist.
Try calling the batch script in your shortcut via UNC, rather than referencing a drive letter.