XPost: cp.products.vpn-1, mailing.comp.vpn   
      
   I'm not sure if this is what you're talking about, but I think there   
   is an option Checkpoint for enabling "Secure Domain Login". You had   
   mentioned cached credentials earlier so I'm assuming your pc is a   
   domain member but you log on using cached credentials then connect via   
   vpn.   
      
   If that is the case, you migh want to try changing Checkpoint so the   
   Secure Domain Logon is enabled. I think it's "Configure, then look   
   under "Passwords". It's a toggle on or off. What happens after reboot   
   is you put in your credentials and the vpn stuff almost at the same   
   time. You then get your domain logon scripts etc so if that is where   
   the drive mappings are coming from you should now have them back.   
      
   HTH   
      
   If I somehow missed the mark on this, sorry! :)   
      
   Harry   
      
      
      
   Mike Drechsler - SPAM PROTECTED EMAIL   
    wrote:   
      
   >davidl@yourmama.com wrote:   
   >> Hi again,   
   >>   
   >> I am oviously not sure where the problem lies. Internally everything   
   >> works great. When I VPN in the server share has to be remapped and the   
   >> LDAP service and related Exchange account has to be erased and put   
   >> back into the mail settings every time. I have read the slow link   
   >> pages on Microsoft but I don't see how that would fix this. I need to   
   >> be able to log on to the server with the VPN already established if   
   >> that is possible.   
   >>   
   >> On Sat, 09 Apr 2005 05:41:45 GMT, Mike Drechsler - SPAM PROTECTED   
   >> EMAIL wrote:   
   >>   
   >>   
   >>>davidl@yourmama.com wrote:   
   >>>   
   >>>>I am using a highspeed connection (4.5 Mb DSL) to connect to the   
   >>>>internet. I then use a VPN client to connect to the endpoint (FVS318).   
   >>>>I would like to find a way to log directly onto the DC using this   
   >>>>setup so the mappings (and LDAP) remain intact. The DC is already set   
   >>>>to NOT update GP settings on a slow link detect (< 128Kb/s) . I   
   >>>>appreciate the attempted help but I don't see how this applies in my   
   >>>>case as the mappings and LDAP are failing on the client side not on   
   >>>>the DC.   
   >>>>   
   >>>>On Sat, 09 Apr 2005 04:01:13 GMT, Mike Drechsler - SPAM PROTECTED   
   >>>>EMAIL wrote:   
   >>>>   
   >>>>   
   >>>>   
   >>>>>davidl@yourmama.com wrote:   
   >>>>>   
   >>>>>   
   >>>>>>How can I log on to a domain not using cached credentials , this is to   
   >>>>>>resolve mapping and Exchange (LDAP) issues . The client connects fine   
   >>>>>>and is solid but the drives have to be remapped everytime and Exchange   
   >>>>>>has to be reconfigured on every boot as well. Any help would be   
   >>>>>>appreciated. I am trying to us the Netgear client onto an FVS318 but   
   >>>>>>the principle is all that is needed. I don't see how to use "logon   
   >>>>>>using dialup connection " when the VPN client is not shown as an   
   >>>>>>available connection.   
   >>>>>   
   >>>>>Change your slow link detection thresholds in group policy on your   
   >>>>>domain controller.   
   >>>>>   
   >>>>>For more info you might want to do some searches on "slow link   
   >>>>>detection" on microsoft's technet website, or google. Also the newsgroup:   
   >>>>>microsoft.public.windows.server.active_directory   
   >>>>>Will be better at dealing with this problem if you can't find the info.   
   >>>   
   >>>Le me put this another way.   
   >>>   
   >>>Q: How does the VPN relate to LDAP or drive mappings?   
   >>>A: It doesn't. They are 2 separate and distinct pieces of technology   
   >>>and as long as the IP link is established, you do not have a problem   
   >>>with the VPN.   
   >>>   
   >>>   
   >>>If you are having trouble with Exchange, then why are you posting in VPN   
   >>>newsgroups? As long as your VPN connection is giving you IP level   
   >>>connectivity to the server and assigning the correct DNS and WINS   
   >>>servers then your problem is not with the VPN.   
   >   
   >Many things are tied to slow link detection. The workstation stays in   
   >offline mode if the link to the login server is detected as slow.   
   >   
   >There is also the possibility that your VPN connection is not configured   
   >properly for DNS and WINS server settings. If your VPN client is given   
   >the IP of your ISP's DNS server instead of the internal active directory   
   >DNS server your client will not even know that it's connected to the   
   >corporate network. It needs to lookup some special records in DNS when   
   >you connect. Every time you bring up a new connection with the   
   >microsoft client bound to it, the client will attempt to locate the   
   >domain controller to see if you just connected to the corporate network.   
   > If it cannot find the domain controller because you are giving the   
   >client the wrong DNS settings then this will also cause the problem you   
   >describe.   
   >   
   >If the client is getting all the correct DNS and WINS settings when you   
   >connect but the link is detected as being slow then you will not   
   >automatically reconnect network shares. You will not get login scripts   
   >to run. The client will not download certain group policy changes.   
   >Exchange probably has it's own behaviour on a slow link but I'm not   
   >familiar with it right now.   
   >   
   >To test you can connect the vpn and try to ping:   
   >gc._msdcs.DOMAIN where DOMAIN is the full domain name of your active   
   >directory you are trying to log on to. eg: if you configured your   
   >active directory to be marketing.yourmama.com you would test by doing:   
   >ping gc._msdcs.marketing.yourmama.com   
   >If you DNS is working while connected to the VPN it should resolve to   
   >the IP address of one of your global catalog domain controllers. If   
   >it's not then you will get a failure. Though strangely enough after   
   >trying my example I now notice that there is a wildcard entry for the   
   >yourmama.com domain so anything and everything *.yourmama.com will   
   >resolve to the ip 64.40.102.41. Maybe a bad example but it does at   
   >least illustrate that even if your ping command generates a response you   
   >should double check to make sure that the IP returned is a correct one.   
   > In the case of the global catalog servers the dns lookup should report   
   >one of the domain GC's at random due to the round robin dns   
   >configuration that is used for this lookup. If you only have a single   
   >GC server then you will always get the same IP. If you don't flush your   
   >DNS cache you will keep getting the same IP reported until your local   
   >resolver cache expires. (You can flush the local DNS cache by using the   
   >ipconfig /flushdns command)   
      
      
   Ha®®y   
      
   HarryKrishna.nospam@online.ie   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)   
|