Windows Server/NetBIOS issues with WinXP Mode VM Oracle. Help?

[edy]

Hi folks,

I have a small office running WinXP machines (5 computers) all tied in to a single Windows server. I have started to migrate (at least some of the client machines) to virtual machines running Win XP Mode in VirtualBox.

I managed to successfully get 1 machine running no problem by creating a WinXP Mode machine and giving it the old WinXP PRODUCT KEY of that specific computer. It detects the Windows Server, gets proper user authentication to log in to the domain, I have access to the shared drives, all good. When I full screen it feels like running natively.

I decided (to be quick) to just CLONE that virtual machine to my other client computer. At first it booted up and accessed the network no problem. That worked for a few months! Everything worked great, the machine was an exact clone, same computer name, username/password was used, both machines ran at the same time and access the Windows network and shared server no problem.

Recently, it stopped working on the second cloned machine.  I am trying to log in to my network and it keeps giving me an error about unable to login to the domain, can't find the server, etc. If I disconnect the network (it is Bridged) I can log in locally using the last known password (from a month ago when it worked), but it has no connection to the server. As soon as I turn on the network access again, Windows gives me an error that my credentials are wrong and I need to login again (Ctrl-Alt-Del to LOCK computer and login again) because the password changes monthly.  But when I try the NEW password it gives me that error.

I've pulled out my hair trying to figure out what is wrong. I know it's not the network setup and it sounds to me like the 2nd machine is detecting the Windows server because it is telling me my credentials are wrong. I can also change the computer ID/network name by logging in as the administrator of the network, so the client machine must be talking to the User Authentication on the server.

So the only thing that I can come up with is that for whatever reason, after several months of using Win XP Mode on the 2nd cloned machine with no problems, NOW it may have detected that both machines have the same PRODUCT KEY and the server is having an issue allowing 2 different WinXP Mode machines with the same key connect?

By the way, BOTH client computers still has the original WinXP on it (I set up the new boot and virtual machine as a separate partition and boot). So when I boot up the old WinXP directly on the 2nd machine (that has the cloned VM of WinXP Mode) it works fine. I also have the product key for this 2nd computer. So I could make a NEW WinXPMode VM and enter in the 2nd computer's PRODUCT KEY but I didn't want to go through the trouble of doing all that. Also, WinXPMode does not allow changing the product key after installation like WinXP does (I can't just change the registry value and run the OOBE program to initiate a new activation).

SO... Has anyone heard of this? Is this because of using the same PRODUCT KEY on more than one client machine logging in to the same Windows Server network? Why did it work initially for a few months and only now give me problems? Should I just scrap the 2nd clone and make a NEW clone and see if that works (maybe the original got corrupted or just worked as long as the password authentication hadn't expired)? Otherwise I will have to just go ahead and create a new VM with the PRODUCT KEY of the 2nd client machine, I just didn't want to waste the time if it was something else simple to try first.

[rrinker]

 If you cloned the VM without doing SYSPREP in Windows then every one of those machines has the same machine GUID which is generally a Bad Thing.

It's not so important with the newer versions but XP/Server 2008 needed sysprep to create a deployable image in a virtual environment. Since you can;t sysprep an XP Mode VM, you either need to make XP Mode machines one to one for the old XP workstations, or build a VM of a standard XP install and then sysprep it to put it in a state where it can be cloned as many times as you want.

I'll leave off the obvious question.

[edy]

If you cloned the VM without doing SYSPREP in Windows then every one of those machines has the same machine GUID which is generally a Bad Thing.

It's not so important with the newer versions but XP/Server 2008 needed sysprep to create a deployable image in a virtual environment. Since you can;t sysprep an XP Mode VM, you either need to make XP Mode machines one to one for the old XP workstations, or build a VM of a standard XP install and then sysprep it to put it in a state where it can be cloned as many times as you want.

I'll leave off the obvious question.

Thank you for the help. I had a look at Sysprep at the following page to try and understand what is involved:

https://www.techrepublic.com/blog/windows-and-office/how-do-i-use-sysprep-to-create-a-windows-xp-image/


So does that mean when sysprep creates this "clone" of a standard Win XP installation it removes the GUID or makes some GUID value that is known to be a clone and therefore no longer a problem for the Server? [EDIT: I read more about it, and apparently it creates a "generalized" version of the installation which upon cloning to another computer then creates a new machine SID and does whatever is needed to give it a unique status again]. I also found this comment on that page:

Note this comment from Mark Russinovich, who now works for Microsoft:

"The more I thought about it, the more I became convinced that machine SID duplication ? having multiple computers with the same machine SID ? doesn?t pose any problem, security or otherwise. I took my conclusion to the Windows security and deployment teams and no one could come up with a scenario where two systems with the same machine SID, whether in a Workgroup or a Domain, would cause an issue."

http://blogs.technet.com/b/markrussinovich/archive/2009/11/03/3291024.aspx

If you read the above blog post it shows that same Machine SID shouldn't be an issue.

I guess the easiest thing for me to do which would take the least amount of time would be to just create a new WinXP Mode installation and enter each machine's PRODUCT KEY in it, one for one. It is easier for me to do that and install the few bits of software I need (a specialized WinXP legacy app, Microsoft Office, and a few printer drivers) than to do a sysrep on the original WinXP machine because the original WinXP computer has the warning about it being unsupported, Windows defender doesn't work on it, etc. Plus it was in use for years and full of all sorts of garbage by now, registry, temp files, windows updates, etc. It is far more clean to use a WinXP Mode install from fresh.

Note that duplication of WinXP Mode gives me no problems otherwise, I can run the same machine all over the place... The problem is how it connects to Windows Server which is giving me issues. But running the machine on the same network, even with internet access, no issues. Not that I want to do that. I bought product licenses for each and every WinXP machine in my office and all was working fine. So I think I will start first by copying my existing 1st VM again... just in case the 2nd VM got corrupted somehow. Then if that doesn't work, I'll create a brand new 2nd VM but registered to the 2nd computer's PRODUCT KEY and see if that solves the problem.

Ok, now I'm curious.... What is the obvious question? 

[EDIT:  I could also just stop the automatic password reset on the account every 60 days because maybe that triggers the authentication cycle and causes the issue].

[edy]

  

Ok, my hunch was right.... It was the password change in Active Directory that caused the problem to start happening on the second VM. Let me explain.

So I made one WinXPMode VM, then cloned it by Exporting Appliance... in VirtualBox. I copied to the second computer and Import Appliance... so it copied itself into VirtualBox. At the time, BOTH machines were logging in with same username/password to the server initially because they were just clones of each other and I was using the same account on both.

Then, the password reset 60 day timeout happened and I guess it was updated on one of the VM's so it continued to be able to login no problem. I guess that's when Active Directory Windows Server started to reject or get confused about the status of the 2nd VM. It didn't matter that I tried OTHER user accounts and passwords on the 2nd VM as well (that had not changed).... Something triggered outright rejection of all login attempts from the 2nd VM to the server, regardless of username and typing the new passwords.

On the 2nd VM I could still login LOCALLY using the previous password (the one I had used prior to the 60 day change) but not to the network. I would have to disable network connection to allow me to login otherwise it would be checking Active Directory on the server for the current user credentials. But immediately after turning the network back on, Windows would complain that my credentials were not good and I wasn't able to connect to any of the network drives on the server. Ok, but even typing the NEW password on the 2nd VM would NOT let me get back in.

So to fix it, I just now EXPORTED again the 1st VM that was working (which already was logging in with the new password to the server) and copied it again to the 2nd machine and IMPORTED it to VirtualBox. The 2nd VM now works with the new password. So I can use both at the same time again.... just like it was the first time I did the clone. So it seems to be an issue that happens upon password reset. Whatever computer first logs in with the newly changed password must trigger something that messes up the ability of any clones to also login even when typing in the new password also, but not only with that username but perhaps other user names?

I will have to try one more thing... to create a unique username for each VM and see if that works. I am not sure if the other usernames I tried also had updated the password in the meantime which messed up the 2nd cloned VM. If I have separate usernames that I designate to use only one either the 1st VM, and another on the 2nd VM, and the passwords reset, that may keep them from messing each other up.

Another solution for now (the lazy solution, I admit) is to stop with the password auto-reset at 60 days. I know that is not the best security policy. Alternatively, I could just export/import as I did just now every 60 days. It takes maybe 20 minutes and a few clicks of a button to copy it over. The long and proper way around it is for me to create separate VM's for every machine with their own unique PRODUCT KEY.

[amyk]

I've seen this a few times. It's nothing to do with product keys, just active directory authentication.