Force authentication to a specific DC

You can also force replication.  But here is a link that will show you how to force a workstation to logon to a specific DC:

http://www.winnetmag.com/Article/ArticleID/13535/13535.html

Also you can use SETPRFDC:


Service Pack 4 includes a new utility, SETPRFDC.EXE, which will direct a secure channel client to a preferred list of domain controllers.

The syntax is:

C:\> SETPRFDC <Domain Name> <DC1, DC2, ....., DCn>

That would be the way I would go.  Good Luck!  :)

I don't believe that there is any way to 'force' the workstation to authenticated against a specific DC.

However, you can trigger AD replication (rather than wait impatiently for standard replication intervals). There are lots of ways to do this. I reommend you use Repadmin.exe (intall it from the support tools, which are found in the support directory on your windows 2003 cd).

Refer to the following article for options and an overview of how to use it:
(The article is for Win2000, but the tool is the same)
http://support.microsoft.com/default.aspx?scid=kb;en-us;232072

As a good alternative, you can see the server that logged you on by checking the 'logonserver' environment variable (go to a command prompt and type "set" to view environment variables). Authentication and such will generally stay with this server unless it becomes unavailable to the client for some reason. (The discovery process happens at boot time to select a DC in the domain for authentication)

If you are testing changing various settings and may logoff and logon, you can make your changes on that domain controller (the one that logged you on) and your workstation should use that DC for it's info. (You can select the domain controller you are using to make the changes. For example, if you are making changes using "Active Directory Users and Computers" admin tool, right-click the top of the tree (label "Active Directory Users and Computers" and select "connect to domain controller..." to select the DC you are looking at / modifying. Changes are immediate on that DC and will be replicated out to the rest. This should allow you to test immediately without taking measures that could pollute your production environment.

Hope this helps.

rmullins,

You may not believe it, but it is in fact correct and can be done.  Try it and see!

Valicon,

First, your solution is geared to NT 4.0 clients... You stated SP4, but you left out that it is SP4 for NT4, not Win2000.

Perhaps I should have stated that differently. I can think of LOTS of different ways to make the system know of only one domain controller... but I think that is a poor solution for a production environment since it has so many side effects. The link to the solution you posted will work fine for NT4, but Win2000, Win2003 and WinXP aren't as reliant on NetBIOS naming for basic functions. I could certainly go on and on, but that wouldn't be appropriate here. Also, changing the NetBIOS resolution method a system to use broadcast vs. a name resolution service (which is part of what you are proposing) is generally not a good idea. You are creating unnecessary traffic and this won't work for systems on different segments (unless you are bridiging that type of traffic on your network, which is definately not a good solution).

Also, setting a default of 'Mixed' mode for NetBIOS name resolution creates unnecessary broadcasts on a network, which is obviously undesirable. In addition, all access from a system modified as you suggested via NetBIOS to any system on a different network segment will be slow because of the wait for timeout to resolve the name via a broadcast first... I just don't think that solution is a good one because of all the side effects. It requires making unnecessarily detrimental changes to the client.

The solution that I proposed doesn't have any side effects and doesn't require having to change anything on the client (more or less having to remember to change it back later).

Newer clients can leverage DNS... Depending on client config, the solution you propose may not work for newer clients (since they don't rely on WINS). A similar thing could be done with DNS but is also undesirable in my opinion.

The NT4 methods will help nothing trying to force authentication against a certain DC. A client running W2k or later that is a member of a W2k domain will use DNS to find a DC.
What might work (I haven't tried this yet) is to setup a DNS server (used exclusively for testing) with a primary zone named like your AD domain. Recreate the SRV records as they appear in your "real" DNS, but leave out all the entries for other DCs (and create a host entry for your DC as well). Or get your DNS entries the other way around: Make your zone a secondary zone of your original, replicate the entries. Change the zone type on your test DNS to primary, change the SOA, and delete the host entries from the SRV records that you don't want to logon to.
Then use this DNS server only in the TCP/IP settings of your test machine. It should now only find the DC that was left in your test DNS.
If someone has an easier way, I'd be glad to be corrected.

How Domain Controllers Are Located in Windows XP
http://support.microsoft.com/?kbid=314861

Those might be good options for most people, but I'm not a domain admin.  This is at an air force base, and they take secuirty VERY seriously!

If they saw me trying to fiddle with the DC's or setting up DNS, They would have me for lunch! :)

Thanks for the responces.

My mistake on SETPRFDC sorry!  But if you are not a domain admin look into using the lmhost file

Jared,

Given that you aren't a domain admin, won't the solution that I proposed work?  Checking the currently connected DC and making the changes to that one?  That covers the vast majority of 'common' changes, such as user account changes.

I assume you've been delegated some permissions to make the changes you mentioned? More specifics would help if this solution is inadequate for your needs. Such as:
     What client OS are you using?
     What are you changing that you want to test?
     What kind of permissions do you have / have you been delegated?

oBdA is correct in his post. My post didn't assume anything about the client OS version, since you didn't provide that. However, his solution work work (for Win2k or XP) but would produce some side effects (like you can't resolve any other DNS names from that workstation and wouldn't be able to connect at all if either the specified DNS server or DC were not available). I'm not saying it's a bad solution, just that it has side effects.

rmullins:

Your right.  The solution that you mention is what I have already been doing up to this point.

I have a vmware workstation that I do all of my testing with.  I was hoping that there would be a way to lock just that workstion into authenticating to the PDC emulator just for convenience.  It would seem that the concensus is that this is not possible without causing more problems.

Since you asked:

I'm running winxp pro
I'm changing mostly gpo's and security policy's
I have full control of the OU's that I'm in charge of.

Well then, I go back to my previous response.... I don't believe there is any way to lock it in by ONLY configuring the client. (unless you setup your own DNS server on a different VM on your system and do as discussed).

Another workaround would be to have the test workstation on the same subnet as only 1 other DC and then you should get that DC each time (assuming it is available). The 'discovery' process (not really called that any longer, but same idea) will try to locate a DC on the same subnet as most preferential (then in the same site if not on same subnet).

The network guys should also be able to 'virtually' put a system on the same subnet as a server, assuming you are using decent network gear and if they are willing and savvy enough. If not on the same subnet as any DCs, you could put your system in a different site with 1 other DC. Then you will always get that DC (assuming it is available).

Answers to those questions would have been helpful before I did all that 'work' on this question... ;-)

Just a quick glance but doesn't it help to put the specific DC and your client in a site definition ?

I've never heard of that.  Do you need to be a domain admin to do that?

How is it done if not?

Jared

I assume you mean the separate site thing (as I mentioned as an alternative to the same subnet in my last post)?

Unless you were delegated permission to create a site, you would have to have a domain admin to create one and move systems and/or DC to it... This would modify the way that replication works (in short, sites are geared to allow systems on same network to replicate with each other quickly and sites only replicate data once and then the other systems in the site replicate amongst each other, thereby reducing bandwidth requirements for systems in different sites. Think of home office and satellite office over WAN connection... or two groups of people with one messenger between them. (I am simplifying this so that you get the concept of sites)

Workstations try to find a DC on the same subnet, if not found, prefers a DC in the same site (as I describe above).

Here are instructions on how to create a new site and move systems to it:
http://support.microsoft.com/default.aspx?scid=kb;en-us;318480

This wouldn't have side effects that would break anything else, but it would modify the way replication happens (it would still happen though). By default, replicaiton times from that DC to/from some other DC's would probably increase (depending on network setup).

If you don't have that permission, it is unlikely that the network admins will do this...

thanks for filling me in on the sites definition.

I can guarentee that they will not do squat with the DC's!  As far as I'm concerned, they are untouchable.

Unless someone else has a suggestion, I'll just have to take the answers that I have and make the best of it.

Jared

Here's some points to feed your tired fingers! : )

heh... Thanks. I hope that some of the info was helpful.