Having issues accessing shares between 3 computers with the same Device ID

Question

I think I have a unique situation. A little background. To save myself time, I setup one Dell PC the way I wanted it, made a disk image and applied to two other Dell PCs. I changed the names of the newly cloned PCs. I thought I would be good but then I ran into something strange. I shared a folder on one PC and tried accessing it from one of the other PCs. It asked for the credentials which seemed strange since it should immediately show the shared folders. I entered the credentials (identical on all PCs) and it came back with "username or password incorrect".

I thought there was something wrong with the share but I tried access the share from a completely different PC (not a clone) and accessed the share perfectly. Typed in \\DELL-PC and bam, saw the shared folders immediately. No credentials needed.

The only difference that I can see is that the cloned PCs all have the same Device ID. I tried changing the MachineID in the registry and rebooting but the Device ID in the "This PC" properties was still the same GUID as before and still had the issue accessing the share from one of the other clones.

Am I on the right track or is there something else that would cause this?

Thanks.

Answer 1

Hi,

People still run into duplicate machine SIDs on Windows setups. Thing is, if those machines came from a Dell factory image or some deployment tool like MDT or SCCM, they might not have gone through sysprep. That means they could end up sharing the same SID, even without you cloning anything yourself. OEM stuff often skips the full generalization step, you know. And if it was a recovery USB or one of Dell's custom tools, it might just quietly reuse that SID without telling you.

To check for sure, hop on PowerShell for each machine. Run this command to grab the machine SID. Get-WmiObject Win32_UserAccount | Where-Object { $_.Name -eq 'Administrator' } | Select Name, SID. Then look at the SID prefix, the part before those last four digits. If they line up the same across machines, yeah, they are sharing the base SID. That is probably your problem right there.

Another common headache shows up with credential conflicts in Windows Credential Manager. Windows likes to hang onto old or wrong credentials for network shares sometimes. Even if your username and password are spot on, it can block access anyway.

The fix is pretty straightforward, clear out those saved credentials. On the PC giving you trouble, fire up Credential Manager through Control Panel, under User Accounts. Peek at the Windows Credentials section for anything tied to the target PC, like \DELL-PC. Delete those entries. Give the share another try after that.

Answer 2

You cloned the image without “generalizing,” so the clones share the same machine SID/LSA secrets—peer auth breaks even if the usernames/passwords match. Fix it by resealing each clone: run %WINDIR%\System32\Sysprep\Sysprep.exe /oobe /generalize /shutdown, then boot and re-name/join as needed (this regenerates the SID/Device ID); as a quick workaround, use unique local accounts per PC and ensure time is in sync & “Password protected sharing” is configured.

Answer 3

Hi,

Nice work. You nailed the root cause and fixed it exactly the right way. Yep, that machine SID collision was the real culprit. As you saw, before sysprep all the clones had identical SIDs. Windows thought they were the same machine. Authentication broke between them. After sysprep each clone got a fresh SID. Network shares behaved normally again. Your unattended sysprep approach was a good call. It was especially smart for remote systems. That way you avoid being locked out mid-way through setup. A couple of takeaways for the future. Always sysprep and generalize your golden image before you capture it. That way every deployment boots fresh. It generates a unique SID. You don't have to worry about this again. Microsoft officially deprecated newsid.exe years ago. Sysprep really is the only supported way to regenerate a SID. If you're rolling out many machines, you might look at MDT. That's the Microsoft Deployment Toolkit. Or try Windows Autopilot. They automate this whole process. Unique SID, hostname, domain join, user setup, all that stuff. I totally get the nerve-racking part. It always feels risky doing sysprep on a remote system when you don't have hands-on access. But you handled it cleanly.

Answer 4

The solution was to run sysprep to get a new SID. Since these machines were remote, I created an autounattend.xml and ran it via command line. Took about 5 minutes before I was able to gain remote access. Always a bit nerve racking. ;)

C:\Windows\System32\Sysprep\sysprep.exe /generalize /oobe /reboot /unattend:C:\temp\autounattend.xml /quiet

I was able to access to the shared folder without any issues. Just like it should.

I don't think I'll be using this method again when it comes to setting up multiple machines.