Ok, so since it is 2003, I would try to logon using "username@domain" just to rule out any possibility there's some issue with locating the proper domain. This is really for peace of mind, and I don't think it is going to help much.


If the domain users you are trying to use remotely are administrators on the local machine (workstations), then you'll be able to logon and therefore to see the error messages. If they are not and you did not enable them to logon remotely, you won't be able to logon. But, in this case, just logon as with your account, go to user manager and make the malfunctioning account part of local computer administrators, and you're done. Or, alternatively, again using your admin account, you may include such malfunctioning user accounts into the list of those who can logon remotely: right-click on My Computer, Properties, Remote.
And actually, if you can do one of the above two things, than you have a proof that the workstation is actually properly connected to the domain. In fact, to add domain users to any local permission group, you need to access the domain through the workstation you're using, which implies that the workstation itself is properly authenticating to the domain (see what Tony explained above).


Partly it does.
If a user already logged on locally and a cache user profile was created locally, you should still get an error message saying that there was some problem authenticating the user in the domain, but then logon process would continue and the user would access to local resources but not to domain resources.
Unless, of course, you deliberately configured the domain or local machine policies to get a different behavior, such as, for example, denying local logon as well when you are not authenticated to the domain; this is a typical safer setup, actually, in "public" places such as computer labs in universities.

IF all users are failing to authenticate to the domain, but are being logged on locally based on a local cached profile, they should not be able to access domain shares on the domain server, for example.n You may want to check that too.
Again unless you deliberately changed the domain and domain server policies to allow anonymous non authenticated access to shares accessible by "everyone", but this is a very unusual setting and I think you would remember fiddling with policies and permissions to do that.


So if by replaced you mean taken from some other place a put on her desk, in other word changing the switch port it is connected to, then the domain server would not even notice.


Yes, it is possible. It is actually being done on a regular basis at work, as we have a group of people who would physically place machines in place, and another who has the needed Domain privilege to join machines to the domain. The latter usually work remotely. Two reboots of the workstations will be needed. One after you remove it from the domain. One after you join it again. Basically
1. Make sure you have the local workstation admin account. RD on the workstation as a local admin. Remove it from Domain. Reboot. You get kicked off of course.
2. While workstation reboots, RD on the Domain Server as a domain admin, and cancel the workstation from the domain. Then Add it again. Logoff.
3. Logon to the workstation which has just rebooted, as a local admin. Join it to the domain providing the domain admin credentials. Reboot it. You get kicked off.
4. Done. Now you may try to RD to the workstation after the second reboot is completed and check if you have any problem.