server 2003 logon takes longer than NT 4

By AnAnyMouse ·
I am setting up our first MS Small Business Server 2003 server. Until now we only had a single nt 4 server. I am noticing that user logon from an xp pro client takes considerably longer with 2003 than it did with nt. Is this normal? Is it because of active directory or have I goofed up my new 2003 server somehow? I am using the same xp machine just joining the new domain. I expected the initial logon to take longer, but every logon takes over a minute longer than it did with the nt domain. I have tried switching back to the nt domain and it is still ok - only takes a few seconds to logon. But when I try again with the 2003 domain it takes over a minute. I have also tried other client pcs with the same result.

This conversation is currently closed to new comments.

4 total posts (Page 1 of 1)  
| Thread display: Collapse - | Expand +

All Answers

Collapse -

Check Workstation DNS

by Churdoo In reply to server 2003 logon takes l ...

Are the client workstations looking to the Small Biz Server for DNS? Having a DNS other than the SBS 2003 server would cause your symptoms.

Collapse -

I don't want to run my own DNS

by AnAnyMouse In reply to Check Workstation DNS

I do not want to run my own DNS. I am not going to be using the server for email or internet access at all. We run Lotus Domino on an IBM eSeries for email hosting and all of our pcs go directly to a pix firewall for internet access. This server will be used primarily as a print and application server, along with user logon to the domain.

Collapse -

Active Directory relies on AD-integrated DNS

by Churdoo In reply to I don't want to run my ow ...

DNS is one of the major differences between NT4 domains and Active Directory; Active Directory depends on AD-integrated DNS. period.

That's why your logons are so slow. With AD, the first method of resolution as your workstations are looking for a logon server is DNS, and only after DNS times out unsuccessfully, do the workstations resort to NETBIOS broadcasts to find the logon server. This is precisely the reason for your delays in processing client logons.

Ideally, your internal AD FQDN should not be the same as your public domain for email and www, i.e. mycompany.local for AD versus for your public domain (email, www, etc.). You do not register your DC as your public DNS host; it's only used internally. Your internal clients should look to your DC as their primary DNS, and your DC should have FORWARDS set up in its DNS server to query your ISP DNS resolvers for all external lookups. So you're really not hosting your public DNS, rather channeling internal DNS resolution through a single source (or multiple/redundant paths if you have a second DC). In reality, this actually makes DNS-related issues easier to manage.

Even if you made your internal AD FQDN the same as your public domain, it's not that big of a deal because with Domino, your internal clients don't use MX records to figure out email delivery, so the only extra step is that you have to add a manual A record for your www. Again, you do not register your internal DC as your public DNS host, so your AD-integrated DNS server is used solely for internal name resolution and active-directory lookups.

Hope this helps.

Collapse -

I think that did it.

by AnAnyMouse In reply to Active Directory relies o ...

Thanks. I think that took care of the problem.

Back to Networks Forum
4 total posts (Page 1 of 1)  

Related Discussions

Related Forums