I know that this does not exactly belong into this forum section, but I have not found a better one and still think this may help some people...
These days, a friend of mine who uses two Windows 11 VMs complained that he no longer could use a Samba share on A from B. After a long time of diagnosing this, I found that some Windows update (KB5065426) caused the problem. After uninstalling the update, things went as normal. But then, after a short while, the problem came up again and now I know why:
Microsoft deliberately does not allow Samba or RDP connections between Windows installations with the same SID any more.
This problem often arises when a VM is being cloned, which is not the way the Microsoft gods intended machines to be duplicated (i.e. they want you to use sysprep). By cloning an instance, you keep the SID. You can check it with the psgetsid Sysinternals tool on the Windows command line (in administrator mode).
Even Mark Russinovich, the original author of the Sysinternals suite, even if he correctly stated that different SIDs were not needed at all, is now "proven" wrong. And I dare to say "deliberately", because for certain enterprise customers, who ran into those problems, they offered an inofficial fix to the problem, which shows that there is no technical reason for this behavior.
The best remedy to this is to change the SID on either of the machines. The old Microsoft tool newsid will not work correctly on modern versions of Windows, but sidchg will do the trick. You also start that in an administrator window. On my machines, it first gave only the message "Reboot computer to complete stop of UCPD Driver before running SID Change." and did nothing but disable that driver. You only have to reboot the instance, disable WIndows Defender and call sidchg again. You will be logged out, but wait until the machine reboots or stops after the second call. The UCPD driver will be re-enabled automatically as noted on the tool page.
BTW: I used SIDCHGL64, but you always have to input the license key that you can find on the website above. Until today, there always has been a key for free use.
Upon a fresh boot, you will have a new, random SID on the machine. The Windows activation was still valid on my instance.
Just to be sure, create a snapshot before you try this, and in case of problems, roll it back.
These days, a friend of mine who uses two Windows 11 VMs complained that he no longer could use a Samba share on A from B. After a long time of diagnosing this, I found that some Windows update (KB5065426) caused the problem. After uninstalling the update, things went as normal. But then, after a short while, the problem came up again and now I know why:
Microsoft deliberately does not allow Samba or RDP connections between Windows installations with the same SID any more.
This problem often arises when a VM is being cloned, which is not the way the Microsoft gods intended machines to be duplicated (i.e. they want you to use sysprep). By cloning an instance, you keep the SID. You can check it with the psgetsid Sysinternals tool on the Windows command line (in administrator mode).
Even Mark Russinovich, the original author of the Sysinternals suite, even if he correctly stated that different SIDs were not needed at all, is now "proven" wrong. And I dare to say "deliberately", because for certain enterprise customers, who ran into those problems, they offered an inofficial fix to the problem, which shows that there is no technical reason for this behavior.
The best remedy to this is to change the SID on either of the machines. The old Microsoft tool newsid will not work correctly on modern versions of Windows, but sidchg will do the trick. You also start that in an administrator window. On my machines, it first gave only the message "Reboot computer to complete stop of UCPD Driver before running SID Change." and did nothing but disable that driver. You only have to reboot the instance, disable WIndows Defender and call sidchg again. You will be logged out, but wait until the machine reboots or stops after the second call. The UCPD driver will be re-enabled automatically as noted on the tool page.
BTW: I used SIDCHGL64, but you always have to input the license key that you can find on the website above. Until today, there always has been a key for free use.
Upon a fresh boot, you will have a new, random SID on the machine. The Windows activation was still valid on my instance.
Just to be sure, create a snapshot before you try this, and in case of problems, roll it back.
Last edited: