I’m gonna try to make an appointment with the Business Team at the Apple store. There is probably something super simple that I am missing. It took me forever to set upi the printers because I kept looking in the wrong spot.*
I’ll give log me in free a try, but there may soon be an issue with installing non approved programs on the work PC. Since remote desktop is built in, it should not be an issue.
*For those interested in the story, I use network printers. I kept looking for them under the IP section of printers, but it turned out they were showing up under default all by themselves, all I had to do was click on them.
Domain entries are names that are prepended to base machine names to see if they can be resolved, you can have a lot of these. They are essentially a list of networks that will be searched to resolve a name.
Nameservers are the DNS servers that will be consulted.
This is where the system preferences places the results of what you configure. When you switch networks it overwrites this file with the values for the new network. So, you can check that the right network settings are in place, and you can also forceably overwrite the contents (you will need to use sudo to do so) to try out explicitly setting the values to be correct - with the knowledge that the changes will be overwritten if you change networks. It is this file that has a maximum number of four used nameserver entries.
This is the domain and name server for my ISP. Does not have an entry for either my employer nor my wife’s. I tried it connected and disconnected from the VPNs.
Since I so royally screwed the pooch with my first post (and likely my second), I want to point out that the # in front of those lines mean they are comments. The file you have output is essentially empty.
FWIW (which isn’t much), I downloaded Remote Desktop Connection onto my PowerBook. I’m still using the beta version, though I have the non-beta version on my 2001 iMac. (I put it on later.) I connect to ‘me.domain.org’ to connect to my PC at work. Other people connect through the server, but the main program I use is only on my PC (licensing thing), so I connect directly to it.
I still have VPN on my computer, which is what we tried first. I don’t remember why we stopped, but it might have been an changing IP issue.
Ah, you are using Snow Leopard, I’m out of date on that. So after a bit of reading, we need to try something more useful.
At the command prompt type:
scutils --dns
The contents of the the first resolver are the most important.
(The file /etc/resolv.conf would appear to have slowly been reduced in importance. The comments at the bottom are placed there automatically to tell you what the file would have held if the system were using that file. But otherwise the file is mostly ignored in Snow Leopard)
Sounds like I have a very similar problem, in that my work requires me to use a Cisco VPN client to connect to one set of machines (and a different VPN for others), and that Cisco VPN is configured to COMPLETELY HOSE all other routing on the client system, as in I lose connectivity to anything except that VPN and the systems behind it (including the other VPN). In the end it is likely up to IT to configure the Cisco VPN to support you, but good luck with that. My IT department has been of no help to me whatsoever in my work environment.
Curiously this problem with CiscoVPN is probably the inverse of the OP’s problem, but very much related. It seems that Apple changed the behaviour of the DNS system in Snow Leopard, and this new behaviour is exactly what causes your problem. Worse there seems to be no useful fix.
The issue is that the Snow Leopard resolver system regards the first result from a DNS as final. That is if a DNS replies that there is no such name, Snow Leopard believes it, and that is the end of the question. So if it hits your internal VPN’s DNS, which only serves internal addresses, your machine is useless. The next trick seems that it automatically rotates the DNS it will use from the list of DNS servers it has. This is claimed to be for load balancing. So if you have multiple DNS servers configured you get somewhat non-deterministic failures. There is a tweak to stop it rotating, and thus you can force it to use a primary DNS, but this still does not address the issue where you want to have two DNS servers supply a mixture of name resolutions.
For the OP, I suspect the solution is to create a small Applescript app that launches the remote desktop app with the right IP address. The dig command does not use the default rules for resolution, and it seems will successfully fight its way down all the DNS servers and resolve the address. So a script that used dig to find the remote machine and then launches the remoter desktop with that address should be robust enough for seamless use.
It would be worthwhile trying:
dig machinename
to see if it can successfully resolve the target machines IP address.
The last two lines actually weren’t preceded with #'s. I copied the out put twice, once connected to the VPN, and once not connected. Since they were the same, I decided to just post one. When I pasted it into SD, somewhere along the line I added them in (probably because the change from control+c and control+v on PC to command+c and command+v is screwing me up. I keep pasting older stuff accidentally).
dig can be forced to use a designated name server on the command line. So you can try to see if it can resolve your target PC like this:
dig @server-ip machinename
(i.e. put @ in front of the ip address of the DNS server on your VPN) and see if that allows dig to find the machine.
From the output of scutils, it would appear that the additional nameserver config is not making it to the network config, this is also confirmed by the contents of resolv.conf.
It turns out that Remote Desktop Connection isn’t scriptable. I guess MS didn’t feel the need to make their application totally integrate with a Mac. But it does use a property list file to hold saved session information, so a script can be used to overwrite the connection address property, and then RDC asked to open the file. So nearly as useful. The following assumes that you have RDC installed, and it has created a folder (RDC Connections) in Documents, which it seems it does, and it munges the Default.rdp file to use the ip address so found.
There is some pain left. RDC will probably treat each new IP address as a new machine, and thus will ask for your login credentials each time the address changes.
Getting the DNS working would really be better. I suspect setting up a local caching BIND server and pointing it at the various other servers would work.
Once you have a script working it is possible to convert it into something you can put in the Mac’s Dock.
set ip_address to (do shell script "dig +short foo.bar.com")
set thePListPath to (path to home folder as string) & "Documents:RDC Connections:Default.rdp"
set thePListPosixPath to POSIX path of (thePListPath)
tell application "System Events"
tell property list file thePListPosixPath
tell contents
set value of property list item "ConnectionString" to ip_address
end tell
end tell
end tell
tell application "Remote Desktop Connection"
open thePListPath
end tell