Our VPN is controlled by our MS Exchange 2003 SP2 Server. We've opened a remote warehouse, got DSL and set up a workstations there, connected to our network via VPN. VPN is working, remote PC can access network resources, etc. The remote PC has a local printer, connected via USB interface, which is shared. When I browse for printers (.....Find printer in the diretory, Find Now) I can see the remote printer in the list of printers, but when I try to add it I get an error message, saying either the connection broke or the printer stopped responding. (Connection is OK, and the printer if fine.) I've disabled Windows Firewall on the remote machine and later put it in DMZ all together, thinking that DSL router was blocking the traffic, but this did not help. Can anybody help with getting this to work? People from the main office need to be able to send print jobs to this printer at remote warehouse. DSL line at the remote site is only 1.5 / 800. Can limited bandwidth be the issue here?

you can set the machine that hosts the printer to have the same ip everytime you connect to the vpn. That is the only way i can keep track of our warehouse computers. If you are simply logging in with windows vpn you just set the user that you are using to login to have a static ip address. in ADUC you can go to the users properties that you are using to validate the vpn connection. On the dial in tab there is the selection to allow access. Under that you will see the assign static address chechbox. Just fill that in with whatever ip address that that machine got last time from DHCP. you can also take that address out of the DHCP pool so just in case that machine is down for a while another VPN user doesn't snag it. You can also control the ip through Routing and Remote access policy but this way is simpler.

BTW you probably won't get teh dial-in tab unless you're on your server. The edition of ADUC that came with ADMINPAK doesn't have the dial-in tab.

Now I noticed the printer is no longer listed in the list of printers. Also, the remote PC is no longer pingable by the Computer name. However I can ping it/connect to it by the IP. When I try to ping it by the computer name it resolves to it's old IP address that it had when it was in the main office. I deleted the DNS entry for it, but still couldn't ping the computer name. Then connected to it \\192.168.0.116, selected the shared printer and clicked on "connect to it". The connection worked and I was able to print to it from the main office. Any suggestion on what would be the best way to this it up? Should I make a new TCP IP port and connect to it from the main office? New to this printing over VPN stuff.. :)

Printing over VPN is exactly like printing to any other subnet with a slow connection - no special VPN tricks. You should be able to use whatever printer access method is most useful for you in the main office.

I also just realized that while I can now print to the remote printer by being connected to \\192.168.0.116\Printer Name, it won't work as a permanent solution. After this VPN session disconnects chances are the remote machine will get a different IP address once it reconnects. I've created a DHCP reservation, going by the MAC of Virtual VPN adaptor. Thoughts?

I also just realized that while I can now print to the remote printer by being connected to \\192.168.0.116\Printer Name, it won't work as a permanent solution. After this VPN session disconnects chances are the remote machine will get a different IP address once it reconnects. I've created a DHCP reservation, going by the MAC of Virtual VPN adaptor. Thoughts?

If this is an IPsec vpn, make sure your clients have the right DNS server options in dhcp.

If it's a client software vpn solution, set up each client to point to the dns servers.

you can set the machine that hosts the printer to have the same ip everytime you connect to the vpn. That is the only way i can keep track of our warehouse computers. If you are simply logging in with windows vpn you just set the user that you are using to login to have a static ip address. in ADUC you can go to the users properties that you are using to validate the vpn connection. On the dial in tab there is the selection to allow access. Under that you will see the assign static address chechbox. Just fill that in with whatever ip address that that machine got last time from DHCP. you can also take that address out of the DHCP pool so just in case that machine is down for a while another VPN user doesn't snag it. You can also control the ip through Routing and Remote access policy but this way is simpler.

BTW you probably won't get teh dial-in tab unless you're on your server. The edition of ADUC that came with ADMINPAK doesn't have the dial-in tab.

Big Thanks to all of you guys!!! The workaround seems to be instead of going through Add Printer, Network Printer, browse, etc.... The way to make this work is to connect to the machine through windows explorer or Run window \\192.168.0.116 and then click on Printers & Scanners, right click the shared printer and click on CONNECT. It takes about 1 min, but it does connect.

Kimberlin - your post was the last piece of my puzzle, I appreicate the info on how to assign VPN users static IPs. I've created a reservation for this IP as well, so it should not get assigned to any other workstations.

As long as Active Directory and DNS are working correclty you should not need to set a static IP address. You have a DNS issue that you should resolve so that all of your machines can be accessed via their hostnames rather than memorizing IP addresses.

another thing to look at is in the VPN connection itself. Right click the VPN connection and go to properties > Networking. Click on the TCP/IP connection and click properties. you can put the address of your DNS server in where you can use following DNS server. now click advanced. You should see the use defualt gateway on remote network. That will reroute all your traffic on that machine through your remote (office) netowork anytime the VPN is on. This one burned me once. I usually uncheck this box. click the dns tab. you should see a checkbox at the botton that says register this connection's addresses in DNS. Check that and try to reconnect. that might solve your issue with resolving to hostname. If that is important to you.

Hardcoding IPs (not using IP underneath which is obviously part of the network stack) is fragile for many reasons. Using DNS names is important not as a memory aid, although that is nice, but because it makes the application or service IP agnostic.

If a useful DNS entry was created for the remote printing service, such as offce2-print.company.local, then client-side setups on any number of servers and workstations would be unaffected even if the printer was: moved to a different workstation or server, IP assignments were changed for that location, there was an IP overlap, the subnet changed, the host and printer were moved to a different location, etc. Any amount of changes would result in nothing more than a single DNS entry change.

Best Practice always has DNS entries used over direct IP addresses whenever possible. It saves a lot of headaches in addition to just being easier.

I have a web application that is going through this right now. An IP address was put in directly to a configuration file and now that the network of the server has changed do to a datacenter relocation every remote client has to be updated manually when the move would have been transparent with DNS.

Obviously there are drawbacks to abstractions layers like DNS but, generally, system performance is so high these days that the benefits greatly outweigh the overhead. There is, of course, the flip-side in which your DNS can be flaky and it impacts everyone when a simple IP address would just keep working. I see this from time to time and it is a pain. But, overall, I find it far better to keep my DNS clean and happy and avoid manual IP management. It's two best-practices in one!

I should point out that if your network has five users, manual IP management is trivial. If you have 500 it is impossible - so size is a major factor. I lean heavily towards scalable solutions even for small companies because growth is a more linear proposition in those cases.

0

This discussion has been inactive for over a year.

You may get a better answer to your question by starting a new discussion.