I recently upgraded a client to SBS 2003 using Swing Migration. On one client workstation, which was not in use when we did the migration, we were getting an error in the Event Log every time the user sent a fax. The fax server attempted to send the workstation a notification when a fax had been sent successfully but the notification failed and showed up in the Critical Errors in the 'morning report'. I posted this issue to the Partner Managed Newsgroup and received a recommended course of action. Great!
I logged onto my client's network remotely and used RDP (Remote Desktop Protocol) to access the workstation to make the Microsoft recommened fix. Oops! RDP couldn't find the workstation. I figured the user had shut it down for the evening. I was informed that the workstation was left on always. So, when I went to their office next, I checked to be sure that RDP was properly configured. It was. I then, later and from my office, tried to see if it was available via Remote Web Workplace. It showed up in the list of workstations I could access. But I could not access it when I tried. So I RDP'd into the server and tried PINGing the workstation. The ping failed. I noted the IP address was 10.0.0.100 which seemed somewhat 'convenient'. I looked in the DNS zone and found .100 to be the listed address for this workstation. I checked the DHCP leases and found an entry for the workstation which was 10.0.0.114, a bit different from that listed in DNS. I tried using RDP from the server to 10.0.0.114 and I got in. Apparently when I did the Swing Migration, the workstation's IP address was migrated over in DNS. But, since the workstation had not been in use for while, when it came up with a new IP address, somehow the old DNS record remained.
I deleted the stale record from the forward DNS zone and on the workstation performed IPCONFIG /registerdns from the Command Line to force it to be properly registered in DNS. Then I was able to access the workstation by name from RDP from the server and via Remote Web Workplace. The fax issue was resolved, thanks to Microsoft's Partner Managed Newsgroups, by setting the Messenger service on the workstation to Automatic startup and starting it.
Another Lesson(s) Learned :-)