Active Directory authentication with Great Plains

We are experiencing a horrible performance hit with GP over Terminal Services with users authenticating to an AD server over a VPN.  Our current configuration has a GP server and AD server in location 1 and an AD server connected via IPSec VPN at location 2.  Location 1 runs like a champ when using TS to connect to Great Plains.  Users that authenticate on the AD server in location 2 take upwards of 2 minutes before the GP login screen appears.  During this period "Dexterity runtime" displays on the title bar of GP.  This happens even if you are in location 1 and use a login ID from location 2.

Can you specifiy which active directory server is used for authentication for specific users?

Thank you,

Joel Golden
moregtiAsked:
Who is Participating?
 
Netman66Connect With a Mentor Commented:
The only way to fix this is to use DFS with targets on both servers.  This way the home drive would map to the DFS share (\\domain\share).  The client would then use the Site information to map the home drive to the local DFS share rather than across the WAN.

0
 
victornegriCommented:
You can set up separate sites in Active Directory Sites and Services. The domain controller in closest site to the authenticating user will be used. You may also make sure that there is at least one global catalog server in each of your locations. Also run "dcdiag" to make sure everything is on the up-and-up on each of your domain controllers.
0
 
Netman66Commented:
Agreed.

Use the Default-First-Site-Name for your Main site - rename it if you like, but do not move the main servers out of this site.  Create and associate the correct subnet to this site.

Create a second Site for your site 2 and also associate a subnet to it.  Move the site 2 server into this new site in AD Sites and Services.

Make sure DNS is setup on both sites as well as a GC.

Do not forward from site 2 to site 1 - setup Forwarding to go directly to the ISP from each site.  Make sure you do not have ANY ISP DNS entries on any NIC inside either site.  This includes the clients.

0
Free Tool: Path Explorer

An intuitive utility to help find the CSS path to UI elements on a webpage. These paths are used frequently in a variety of front-end development and QA automation tasks.

One of a set of tools we're offering as a way of saying thank you for being a part of the community.

 
moregtiAuthor Commented:
I created unique sites and appropriate subnet entries for remote offices and moved the cooresponding servers to their sites.  I also verified all DNS entries were using the correct DNS.  This seems to have helped but all users located in location 2 still have a 60 second+ wait for the login screen to appear.  I can log in to the TS server with my user id from location 1 and there is no delay with the login screen.
0
 
Netman66Commented:
When you say "unique" did you retain the use of the Default-first-site-name for the main site and simply rename it?

0
 
moregtiAuthor Commented:
I renamed it and then verified the connections under the properties of each AD server in each site.  I then confirmed replication was working by checking the changes made under Sites and Services on all servers.
0
 
victornegriCommented:
What DNS server are your clients in site 2 pointed to? Are they pointed to the local DNS server? Is the DC in Site2 a GC also? If you disconnect the VPN connection between the 2 sites, can people still log on in site 2? Does the delay go away?
0
 
moregtiAuthor Commented:
Breakthrough!

I've determined the GP server is using the local DC.  I've also determined what setting is causing the delay.

userid1 from location2 is using the Connect To: feature under the Profile setting for the user account to connect to their home directory.  If I disable this feature and use a login batch file to map the drive then GP loads without delay.

Now... any ideas on that one?

Thank you,

Joel Golden
0
 
moregtiAuthor Commented:
We use BIND 9.x with dynmaic updates enabled for our DC controllers for all of our DNS.  Netdiag and dcdiag pass all tests.

0
 
moregtiAuthor Commented:
Is everyone as stumped as I am on this one?
0
 
victornegriCommented:
You may want to check your network provider order in Network Connections. Make sure the Client for Microsoft Networks is listed first.
0
 
victornegriConnect With a Mentor Commented:
Also, look at this:

http://support.microsoft.com/?kbid=832161

It may give some hints.
0
 
moregtiAuthor Commented:
We never found an actual fix for this problem.  The onyl work around was to add the home directory using a login.bat script.  Thanks to everyone who offered their help.
0
All Courses

From novice to tech pro — start learning today.