-1

I am re purposing old PCs that have long been replaced but are sitting on the bench. Here's the scenario.

Let's say I have a benched PC named "XXX-420-S01". This PC exists in an OU entitled "420". I boot the PC and try to login. Sometimes I will get a trust issue since the name has been taken over by the real "XXX-420-S01" that replaced it. I rejoin the domain (join pseudo-workgroup then rejoin under the same name) and get in (yes, I may have to fix the real "XXX-420-S01" but I don't care about that). I check for updates which are managed by WSUS and all is well.

I rename the PC to "XXX-200-S01". I'm still on the domain. AD is not smart enough to know the naming convention so "XXX-200-S01" is still in the "420" OU. I check for updates on WSUS and all is usually well.

Now I move the PC to the "200" OU and WSUS errors out. It can't check for updates and complains.

The way to fix this is as follows.

Let's say "XXX-200-S99" is already in the "200" OU and is working fine. I will name the new PC "XXX-200-S99" (essentially taking over this name). I will then check for updates on WSUS which works fine for obvious reasons. I then rename the PC to the desired name "XXX-200-S01" and check for updates again and it works fine. I then go to the "XXX-200-S99" machine and rejoin the domain. Now both "XXX-200-S99" and "XXX-200-S01" are in the "200" OU and play nice with WSUS.

What is all this funky jumping through hoops doing?

I do not have access to the AD servers since they are managed by another group but I believe they are Server 2008. The workstations are Win7.

Improve this question
4
  • 4
    This question appears to be off-topic because the OP doesn't have access to the server(s) to fully troubleshoot the issue. Advise to work internally with their IT groups to reach the answer.
    – TheCleaner
    Mar 18, 2014 at 18:26
  • 1
    support.microsoft.com/kb/902093
    – Nathan C
    Mar 18, 2014 at 18:28
  • @TheCleaner - Why is this off topic? I was wondering if this is a client side issue or perhaps things will replicate and fix themselves hence me asking
    – asdffffff
    Mar 18, 2014 at 19:50
  • 1
    @WTFWSUS - my vote was based on you not having access to the servers. As such, it makes it difficult to find anything beyond it being client side. As I mentioned in my answer comment you can still use the client side tools to see if it is a client issue or not. Closing the question doesn't mean the answers you've receive aren't valid or that your issue isn't valid, just that it would be more beneficial as Kathy said to work internally on this with your IT dept.
    – TheCleaner
    Mar 18, 2014 at 20:51

2 Answers 2

Reset to default
5

Wait...so you are purposely naming PCs the same as existing domain computers? That makes no sense.

How it should be done:

  1. Old computer gets moved to a workgroup
  2. Old computer gets the proper new name that will be on the domain
  3. Old computer gets added to the domain and placed in the proper OU
  4. IT waits for AD replication
  5. Old computer runs "gpupdate /force" to make sure the proper GPO that applies for WSUS is getting applied

At that point if you still don't see the PC properly in WSUS, you'll need to troubleshoot with the WSUS tools found here: http://technet.microsoft.com/en-us/windowsserver/bb466192.aspx

Improve this answer
2
  • If a bench PC is typically named "XXX-420-S01" and has been taken over I normally don't rejoin as that (since it would be pointless). I was just highlighting that WSUS works. I do however have to rename the PC to an existing one in the 202 OU to "trick" WSUS into working. I do not have access to the WSUS server
    – asdffffff
    Mar 18, 2014 at 18:06
  • 1
    You can still use the client diag tools, but honestly if you don't have access back to the WSUS server, work with the dept. that does. That's your best approach.
    – TheCleaner
    Mar 18, 2014 at 18:24
5

Wait, what?

Okay. What TheCleaner said, but. What?

Reading between the lines, what I assume is going on here is some kind of profoundly dysfunctional silo between two or more IT departments wherein in order to get patches for a machine, a machine is required to be in a specific OU. For whatever reason, you are unable to get the department that manages AD to put your workstations in the OU that receives patches in a timely manner. So you're deliberately breaking the trust relationships between Windows 7 desktops and AD so you can force machines into that OU and get patches. (Also, you don't care that the "real" machine with that name that's in use is now disabled and perhaps some poor user can't log in until you fix it.)

No. No no no.

I'm sorry, man. If I understand your problem, no, this is not a technical issue. You need to talk to the people who manage AD and WSUS. Perhaps you could have some kind of script that adds the machines to the correct OU when you add them to AD (it sounds like you can do that; if so, check out things like this instead). Or, if you added them, use Active Directory Users and Computers to put them in the right OU yourself (if you're creator/owner, you can do that, too).

Improve this answer
3
  • The poor sap is a bench PC in the 202 OU that happens to work. I steal its name and put it back. Also when a real machine is used we fix that right away. BTW this is the government....
    – asdffffff
    Mar 18, 2014 at 19:52
  • Also if we are replacing a computer, say "XXX-420-01" with one from the bench we simply rename a bench computer to "XXX-420-01" and force it on the domain. We then swap the PCs and everything is hunky dory. Yes you are supposed to join the old one to a workgroup first and wait for replication but who has time for that!
    – asdffffff
    Mar 18, 2014 at 19:54
  • 2
    0.o Sorry. You're doing it wrong.
    – Katherine Villyard
    Mar 18, 2014 at 20:18

Not the answer you're looking for? Browse other questions tagged .