adding WIN7 machine to domain via VPN

Usually that error is caused by not being able to contact the DNS servers to locate domain controllers.

You might want to double check you can ping the domain controllers over the VPN.  As well as when you add try using the FQDN instead of Netbios name and see if you have any luck.

Make sure DNS on the client points ONLY to the SBS, and add the new DNS suffix, my domain.local, to the VPN/PPP adapter.  Use the SBS public IP to connect the VPN, at least for now.
http://blog.lan-tech.ca/2011/05/14/vpn-client-name-resolution-2/

mmicha you mean

As well as when you add try using the FQDN instead of Netbios name and see if you have any luck.

never heard of this, doesn't it need the domain.local name not the FQDN?

RobWill

Make sure DNS on the client points ONLY to the SBS, and add the new DNS suffix, my domain.local, to the VPN/PPP adapter.

doing this now

Use the SBS public IP to connect the VPN, at least for now.

this I'm already doing.

I was just making sure you were using "domain.local" in the field, and not just "domain".

k, gotcha.

I just tried everything recommended above and still can't connect computer to the domain.

I was thinking I posted the following link in your last question, but I did not.  Have you reviewed the following as to how to join a domain using a Windows VPN connection:
http://blog.lan-tech.ca/2012/07/25/how-to-join-a-windows-domain-using-a-vpn/

So when mmicha asked in the first post; "You might want to double check you can ping the domain controllers over the VPN."  you had not confirmed that?

A basic rule of routing is all subnets in the path between client and host must be different.  Thus if you use 192.168.1.x at the server site, no client visiting a hotel, internet cafe', or at home that is using 192.168.1.x will be able to access the corporate VPN.  You should always use uncommon subnets at any corporate site that will include a VPN.  Having said that if the "use remote default gateway" option is enabled on the VPN client, it is by default, remote users will "often" be able to connect to the SBS regardless of the local subnet, but they will never be able to connect to any other resources on the same LAN as the SBS.

Glad to hear you have it resolved.

So when mmicha asked in the first post; "You might want to double check you can ping the domain controllers over the VPN."  you had not confirmed that?

I'll check again tonight and if possible can this post be reopened. I can't recall if I can ping or not but will test. I just go an email that a user had problems with Outlook but wasn't completely disconnected so it's better but something is going on.

Also another user emailed saying they're constantly being asked for their password.

If you run
NSlookup SBSname
from a computer connected by VPN does it resolve the server's IP

You are better to use rpc/http for Outlook access than a VPN.  More secure, more stable, and better efficiency.

If you run
NSlookup SBSname
from a computer connected by VPN does it resolve the server's IP

it fails NS Lookup, well it did before but I'll test again tonight.

You are better to use rpc/http for Outlook access than a VPN.  More secure, more stable, and better efficiency.

agree but users like using VPN mainly because they're used to it and they only use it from home. It's also easier for them to access their time entry software this way and data on the server.

If NSlookup fails, outlook will not work, and you will have issues accessing resources by name.

Please review:
http://blog.lan-tech.ca/2011/05/14/vpn-client-name-resolution-2/

Also are host and client both using 192.168.1.x ? Unrelated, but this will cause problems if so.

Also are host and client both using 192.168.1.x ? Unrelated, but this will cause problems if so.

they were, the gateway was .1 and the computer was .2 both using 192.168.1.0 network.

After I switched the router (clients offsite router) to 192.168.1.15 and changed the IP address range to start above 192.168.1.15 email begain working, the disconnect problems went away and now that I think about it ping and NS Lookup did work. Makes sense it did because Outlook worked as well.

I'm thinking about changing the server IP address, would like to change it to 192.168.0.0 network or change the server IP to something other than 192.168.1.2 because allot of home networks give the default router IP of 192.168.1.1 and the computer on the network 192.168.1.2.

>>"After I switched the router (clients offsite router) to 192.168.1.15 and changed the IP address range to start above 192.168.1.15 email begain working, the disconnect problems went away"
That is pretty much just luck.  Subnets need to be different.  To avoid conflicts the server site should never use any of the following, as they are common defaults with many routers:
  192.168.0.x
  192.168.1.x
  192.168.2.x
  192.168.111.x
  10.0.0.x
  10.1.1.x
  10.10.10.x
  172.16.1.x
Not that it is necessary but we usually use the last 2 digits of the client's street address. eg. if at 1123 Maple St, we use 192.168.23.00, it just helps us to remember.

>>"and now that I think about it ping and NS Lookup did work. Makes sense it did because Outlook worked as well. "
Is Outlook working then?

>>I'm thinking about changing the server IP address, would like to change it to 192.168.0.0 network or change the server IP to something other than 192.168.1.2 because allot of home networks give the default router IP of 192.168.1.1 and the computer on the network 192.168.1.2"
I would recommend doing so, but I would not use 192.168.0.x, please see the list above.  Also as soon as you do you need to re-run the SBS networking wizards and/or Fix my network Wizard.

That is pretty much just luck.  Subnets need to be different.  To avoid conflicts the server site should never use any of the following, as they are common defaults with many routers:

understood but this then makes the task of changing home routers daunting, I have one client with close to 65 users and they all remote in...well, actually they use RWW and only a few use VPN, but on the network I'm talking about above the server is 192.168.0.0 which is in the list below however most home routers use 192.168.1.0 so it's not been a problem.

Not that it is necessary but we usually use the last 2 digits of the client's street address. eg. if at 1123 Maple St, we use 192.168.23.00, it just helps us to remember.

you're talking about the business, correct...sorry had to ask. This is really cool, thanks for the tip.

>>"and now that I think about it ping and NS Lookup did work. Makes sense it did because Outlook worked as well. " Is Outlook working then?

yes Outlook began working after changing the IP. Working in the sense there was no longer any disconnects however now one user is constantly asked for her password.

I would recommend doing so, but I would not use 192.168.0.x, please see the list above.

makes sense, thanks.

Also as soon as you do you need to re-run the SBS networking wizards and/or Fix my network Wizard.

I'll do this and let you know if it comes up with any errors.

I wasn't suggesting changing any client routers or their respective subnets.  I was suggesting changing the SBS LAN subnet so that it doesn't conflict with all of the client subnets.  Never use a default subnet on a business LAN if at all possible.

gotcha makes sense wasn't thinking on the last install just overlooked it, I'll change the IP on the SBS2011, is this going to make a huge problem with DNS, DHCP, etc? I've done it before on a stand alone server and SBS2008, can't recall if I used the wizards or not. Got it all working didn't seem to create too many problems.

Yes, DNS, DHCP, Exchange, SharePoint all have to be updated, which is why you have to run the connect to the Internet wizard when you do so, which will update all.  Should also run  ipconfig /flushdns and reboot PC's.

changing the router IP address range so the local computer was different than the server IP address fixed it.