BDC

Hi

Aswell as the obvious - authenticating - what are the other advantages to haveing a BDC, were is the best place to store a profile so every client has full access to it regardless of the bandwidth and or how many people are logging on at that time.

Lee H

Find more posts tagged with

Save $250 on 2025 certification boot camps from Infosec!

Book now with code EOY2025

Button

Comments

RTmarc

Redundancy. If you have only one DC and it craps out, you are in trouble. Two will allow you authenticate even if the primary is crapped out.

Danman32

As of Windows 2000, there is no such thing as a BDC. AD is a multi-master model. Any DC can authenticate.
Now there are roles (5 of them), which one could also call services, that can only be running (active) on one DC at a time, but you can distribute the individual roles to different DCs. The PDC emulator role mainly emulates the NT PDC when you still have NT BDCs, but even when you are in native mode, the PDC emulator manages time sync, as well as being first to receive authentication updates (passwords), and will be the next to be queried for authentication if the original authenticator denies the authentication because of incorrect password. The reason behind this is because the user's password may have been changed by an admistrator against one DC, but the DC that the user is authenticating against may not have gotten the change replicated to it. If the user uses his new password, his DC would otherwise deny access. Before it does though, it checks with the PDC emulator which should have the change.

sprkymrk

Danman32 wrote:

As of Windows 2000, there is no such thing as a BDC. AD is a multi-master model. Any DC can authenticate.

Actually under NT4 any DC could authenticate - the big difference was that only the PDC was writable. The BDC was read only on the SAM.

To the OP - advantages include redundancy mentioned by RTmarc and also a sort of load balancing if you have a lot of users logging on at the same time. As far as the best place to store a profile, you can't get away from dealing with bandwidth. The best place is as close to the user as possible, with something like DFS to help with muliple users logging on at once.

Danman32

A roaming profile does not have to be stored on a DC by the way. You configure the location of the profile individually by user, so you don't have to put everyone on the same server.

Lee H

thanks for the info guys

we have a problem with our profile not being pulled on just under half the machines, they have to log off and then log on again in order to get the profile. The last week of term some weeks ago we changed our scope onto a new range, the pupils have been back a little over a week so we are finding that the scope change may have caused some profile issues

anyone have any ideas?

i am sorry if it appears vague, i could type a massive page but then are you gonna read it??

lee

sprkymrk

Lee H wrote:

we have a problem with our profile not being pulled on just under half the machines, they have to log off and then log on again in order to get the profile. The last week of term some weeks ago we changed our scope onto a new range, the pupils have been back a little over a week so we are finding that the scope change may have caused some profile issues

Do you mean you changed IP Addresses as in DHCP scope? Is the problem isolated to a specific LAN segment? Are the clients XP or 2K? Thanks.

Lee H wrote:

i am sorry if it appears vague, i could type a massive page but then are you gonna read it??

Good point!

Danman32

If you changed IP addresses, do all replicas of the DNS zones know about the change?

If WS A is using DNS server A to find the IP of server P that has the profiles stored on it, and WS B is using DNS server B to do the same, but both DNS servers have different information regarding server P, then one or both workstations are going to fail to connect to server P. Thus, no profile (or at least the cached one would be used).

Lee H

hi

the boss has spoke to one of his friends and thinks he has ther answer, the DNS information for each client has somehow not been deleted so when a client logs on there are 2 sets of information, 1 that pertains to the old scope and 1 that pertains to the new.

does anyone know what am talking about because this stuff is way to advanced for me am still studying 70-290

spymark wrote: Do you mean you changed IP Addresses as in DHCP scope? Is the problem isolated to a specific LAN segment? Are the clients XP or 2K? Thanks.

Yes we are now using a totally new scope, we only have 1 LAN, 2 VLANS, other vlan gets IP from local council, our VLAN comes from our own DHCP server, all clients XP.

Lee

Danman32

Make sure that the old DHCP server (or service) has been shut down. Otherwise it can win in giving a WS an IP and configuring DNS.

You can check your client config with IPConfig /All. It will show the DNS server IP it will use, as well as the IP of the DHCP server it got an IP from.

If the WS is rebooted, then the DNS cache is cleared. If it hasn't been rebooted, you can run IPConfig /flushDNS.
IP registration of the client in DNS doesn't affect the client logging in, though it might prevent another WS from being able to reach that WS, such as for peer file sharing.
But if a server gets its IP from DHCP, that could be a problem. A DC should not get it's IP via DHCP, especially if it is a DNS server. The analogy of that would be calling information for your friend's phone number. But I don't know the number for information, I think it changed its phone number. Call information then and get information's new number.

Run netdiag /fix on the DCs to check on their registration in DNS.

sprkymrk

Lee H wrote:

hi

the boss has spoke to one of his friends and thinks he has ther answer, the DNS information for each client has somehow not been deleted so when a client logs on there are 2 sets of information, 1 that pertains to the old scope and 1 that pertains to the new.

does anyone know what am talking about because this stuff is way to advanced for me am still studying 70-290

spymark wrote: Do you mean you changed IP Addresses as in DHCP scope? Is the problem isolated to a specific LAN segment? Are the clients XP or 2K? Thanks.

Yes we are now using a totally new scope, we only have 1 LAN, 2 VLANS, other vlan gets IP from local council, our VLAN comes from our own DHCP server, all clients XP.

Lee

Well it looks like your boss may be on the right track. I was just wondering if it was possible that (since by default) a WXP box will load a profile while waiting for the network that might be why it takes 2 logoff/logons to get the network profile - it loads a local profile in the mean time. There is a registry setting and/or Group Policy setting you can use to force it to act like W2K that "waits for the network". This may increase logon times, but will ensure the roaming profile is loaded.

http://technet2.microsoft.com/WindowsServer/en/library/cbf5e8ab-9df4-4585-b2a7-f14f5e1caa451033.mspx?mfr=true

microsoft.com wrote:

Windows XP includes new features that provide faster start up of a computer by not waiting for the network during boot and logon.

By default, Windows XP (but not Windows Server 2003) does not wait for the network to be fully initialized at startup and logon. Any existing users logging on are logged on using cached credentials, which results in shorter logon times. Because the computer doesn't wait for the network to be fully started, Group Policy is applied in the background once the network becomes available. This has a number of effects on the logon process:
Changes to some user object properties may take two logons to become effective. Because users are logged on using cached credentials, changes that are made to the user object, such as adding a roaming profile path, home directory, or user object logon script, may take up to two logons to be detected.

Anyway, read that whole url because there is a lot that may shed some light on your issue.

You can try using a script to remotely reboot your workstations if DNS is the problem, and turn your lease time on your DHCP way down and let DHCP register DNS information for your clients. Alternately, use the script to run an ipconfig /registerdns on all your clients.

Lee H

thanks guys

Danman32

I still say workstation IP registration in DNS is irrelevent. Nothing in the login process is going to try and resolve the workstation's name to an IP. Remember, it is the workstation that is initiating all requests for resources, and the resources it is looking for are on servers. However server registration is quite relevent.

Run netdiag /fix on all servers to verify proper server registrations in DNS. Also be sure the workstations have correct DNS client configurations so that they can efficiently find the servers. If the clients have bad DNS configurations, they will try and fall back to Netbios broadcast resolution, but that can be time consuming and prone to failure.