PDC/Terminal server

It don't think it really is another step. Once you tell the client where the profile is, it start communicating at that path. Yes, if it is on PDC, it already has the name resolution so it just starts the communication, on the other hand if it is ona different machine, it will need to resolve the name first.

So, if your name resolution is setup properly, I do not see it being a big issue when it comes to performance. It might even be faster if the PDC is busy authenticating other clients instead of paying attention to your profile request.

HTH

Not really. In fact, in larger domains, it's better to separate the two. If you have limited domain controllers on the network, then the PDC will be busy answering authentication requests, and it would lighten the load on it to not have to send profiles as well. Using a separate server for the profiles frees up the PDC to just answer auth and browse requests.

Be aware of this as well. If you are running SP5 on the terminal server, there is a bug that will hand the processor on the server. When users log off the terminal server, their profile will not unload properly and that session's CSRSS.EXE will hang the processor on the server (see Q234606). This was corrected in SP6, but SP6 has a problem with the ICA browser service (is youare using Citrix MetaFrame). This is fixed in Q269214. I hope this helps...

Most installations of Term Server recommend using a seperate server to house user profiles. Due to the nature of how Terminal Server works it would probably benefit your PDC to move profiles to a different location.

Dave I know this is going to sound stupid, but Ive seen it before. This might not be your case, but if you have had the PDC down and your Terminal Server is looking to authenticate users, it will setup a secure channel with your BDC. Then when you bring the PDC back on line, its supposed to realize the fact. Ive seen it continue useing the BDC over the WAN. One way to check is to use the Domain utilities with the resource kit. You can also disconnect that secure link with the remote bdc and your local Terminal server. Finally a very non technical way to fix it is, shut down your BDC and then logon to your terminal server, it will force it to negotiate a session with your PDC and then bring the BDC back online. This happens often when you have had your PDC down even for a short time in the arrangement you have given me.

This question was closed by the author