Posts: 7
Threads: 1
Joined: Aug 2019
Reputation:
0
08-16-2019, 12:03 AM
(This post was last modified: 08-24-2019, 09:09 PM by MJFlash.)
Hi!
I'm set up so that I can run three Windows 10 boot configurations on my Apple 2015 13" MacBook Pro: - Booting from the internal Apple SSD's BOOTCAMP volume
- Booting from a WinToUSB clone of that volume on an external Seagate Barracuda 2TB HDD
- Booting from a WinToUSB clone of that volume on an external Sabrent NVMe M.2 1TB SSD
All works perfectly, except for one very serious issue: each time I boot from one of these systems, files that I've placed in OneDrive on any one of the systems disappear (are mysteriously removed) when I boot from another one! This is true for all files that I've tried, including screenshots (OneDrive/Pictures/Screenshots), as well as downloaded files (OneDrive/Downloads). This occurs whenever I do anything with OneDrive. Note that sometimes the files which are gone will appear in the Recycle Bin, but not often.
I'm trying to understand what's going on. Clearly, the drive IDs are still unique, or else Windows would refuse to permit them to even mount, much less allow copying, etc, which it does. My Windows 10 account is identical across them. Somehow, the cloning process has convinced Windows 10/OneDrive that when it sees new files on OneDrive to delete them! Curiously, if I intentionally delete files on OneDrive on one clone, it will stay deleted on the other volumes. It's only adding new files that causes this problem to occur.
Please help me to understand how to work around this, for I rely heavily on OneDrive! Is this somehow a result of WinToUSB cloning?
[EDIT UPDATE:] I'm beginning to think that having the convenience of being able to rapidly change boot modes may have just hidden the simple fact that it takes time for OneDrive to synchronize changes to files, and I may just not be giving it enough time to do so. If that's what's happening, WinToUSB cloning isn't the problem. More testing will ensue...
[2ND UPDATE] No, waiting for synchronization, by checking for the files online, shows that the problem is still happening - the files get deleted. The question is whether this is just a pure OneDrive problem, or whether it's a WinToUSB problem...
Thank you very much!
Best Regards,
Mark
Posts: 1,841
Threads: 11
Joined: Feb 2014
Reputation:
27
08-19-2019, 08:54 PM
(This post was last modified: 08-19-2019, 08:54 PM by admin.)
(08-16-2019, 12:03 AM)MJFlash Wrote: Hi!
I'm set up so that I can run three Windows 10 boot configurations on my Apple 2015 13" MacBook Pro:
- Booting from the internal Apple SSD's BOOTCAMP volume
- Booting from a WinToUSB clone of that volume on an external Seagate Barracuda 2TB HDD
- Booting from a WinToUSB clone of that volume on an external Sabrent NVMe M.2 1TB SSD
All works perfectly, except for one very serious issue: each time I boot from one of these systems, files that I've placed in OneDrive on any one of the systems disappear (are mysteriously removed) when I boot from another one! This is true for all files that I've tried, including screenshots (OneDrive/Pictures/Screenshots), as well as downloaded files (OneDrive/Downloads). This occurs whenever I do anything with OneDrive. Note that sometimes the files which are gone will appear in the Recycle Bin, but not often.
I'm trying to understand what's going on. Clearly, the drive IDs are still unique, or else Windows would refuse to permit them to even mount, much less allow copying, etc, which it does. My Windows 10 account is identical across them. Somehow, the cloning process has convinced Windows 10/OneDrive that when it sees new files on OneDrive to delete them! Curiously, if I intentionally delete files on OneDrive on one clone, it will stay deleted on the other volumes. It's only adding new files that causes this problem to occur.
Please help me to understand how to work around this, for I rely heavily on OneDrive! Is this somehow a result of WinToUSB cloning?
[EDIT UPDATE:] I'm beginning to think that having the convenience of being able to rapidly change boot modes may have just hidden the simple fact that it takes time for OneDrive to synchronize changes to files, and I may just not be giving it enough time to do so. If that's what's happening, WinToUSB cloning isn't the problem. More testing will ensue...
[2ND UPDATE] No, waiting for synchronization, by checking for the files online, shows that the problem is still happening - the files get deleted. The question is whether this is just a pure OneDrive problem, or whether it's a WinToUSB problem...
Thank you very much!
Best Regards,
Mark
The portable Windows USB drive cloned with WinToUSB is an exact copy of the original operating system, you should know that if the cloned data is incomplete or incorrect, Windows will not start properly. We've reproduced the problem you described in the our test environment, and we need some time to analyze the cause of the issue. Thanks.
Posts: 7
Threads: 1
Joined: Aug 2019
Reputation:
0
08-21-2019, 09:04 AM
(This post was last modified: 08-21-2019, 09:09 AM by MJFlash.)
Hi, Folks!
Thank you very much for acknowledging this issue. I've been trying alternate approaches, like trying to use Google Drive, but haven't yet come up with a decent solution. If I were to guess, the fix for the problem might just boil down to a single volume-identifier* GUID somewhere in the registry. I'm anxiously awaiting the results of your testing, and sincerely appreciate your support!
Best Regards,
Mark
*: The thought is that OneDrive might use a GUID to see whether each execution is the same machine or not, and will delete files that suddenly appear without its knowledge of that machine. When it encounters different GUIDs (different machines), it'll treat them as normal additions to its sync. Anyway, just a thought.
Posts: 7
Threads: 1
Joined: Aug 2019
Reputation:
0
08-21-2019, 09:14 AM
(This post was last modified: 08-21-2019, 09:42 AM by MJFlash.)
Gulp. I just had another thought, which would be much worse. If OneDrive were to generate a unique registry entry for each file that it's syncing on the machine, then the simple presence of a new file (on a volume which it thinks is the same), without its corresponding registry entry, could cause a deletion. Let's hope that this isn't the actual case!
EDIT: On the other hand, this might not be so bad after all. Once again, if OneDrive thinks it's a different machine, then its standard logic of saving files which are newly created will apply (since files are normally added on a different physical machine). Changing that GUID, if it exists, might just work in either scenario.
Posts: 1,841
Threads: 11
Joined: Feb 2014
Reputation:
27
08-21-2019, 11:59 AM
(This post was last modified: 08-21-2019, 12:01 PM by admin.)
Our tests show that this issue has something to do with the Security Identifier (SID). OneDrive seems to use SID to identify a computer, and if the SIDs are the same, it is thought to be operating on the same computer. The Windows cloned with WinToUSB is an exact copy of the original operating system, so the SID is exactly the same whether you start Windows from the BOOTCAMP partition or the USB drive. Our current recommended solution is to create different users to sign in to Windows on different devices.
Posts: 7
Threads: 1
Joined: Aug 2019
Reputation:
0
08-21-2019, 12:50 PM
(This post was last modified: 08-21-2019, 01:25 PM by MJFlash.)
(08-21-2019, 11:59 AM)admin Wrote: Our tests show that this issue has something to do with the Security Identifier (SID). OneDrive seems to use SID to identify a computer, and if the SIDs are the same, it is thought to be operating on the same computer. The Windows cloned with WinToUSB is an exact copy of the original operating system, so the SID is exactly the same whether you start Windows from the BOOTCAMP partition or the USB drive. Our current recommended solution is to create different users to sign in to Windows on different devices.
Very interesting. I've been using RegEdit to tackle the machine ID challenge, but thus far, it hasn't had any impact. Even when Settings/About's Device ID, and OneDrive's registry settings change, OneDrive behaves the same.
From your post, the challenge will be: how can I change the Security Identifier? Is it in the registry (it's not at HK/Local/SAM), or something which is just computed on-the-fly?
As far as using different accounts goes, that's unfortunately not a preferred solution. I need file access across these different accounts (although I do recognize that I could set up file sharing between the different accounts, if all else fails). I'll keep trying ( wmic useraccount get sid,name is sure interesting).
I sincerely appreciate your efforts!
Posts: 1,841
Threads: 11
Joined: Feb 2014
Reputation:
27
08-21-2019, 04:41 PM
(This post was last modified: 08-21-2019, 04:43 PM by admin.)
(08-21-2019, 12:50 PM)MJFlash Wrote: (08-21-2019, 11:59 AM)admin Wrote: Our tests show that this issue has something to do with the Security Identifier (SID). OneDrive seems to use SID to identify a computer, and if the SIDs are the same, it is thought to be operating on the same computer. The Windows cloned with WinToUSB is an exact copy of the original operating system, so the SID is exactly the same whether you start Windows from the BOOTCAMP partition or the USB drive. Our current recommended solution is to create different users to sign in to Windows on different devices.
Very interesting. I've been using RegEdit to tackle the machine ID challenge, but thus far, it hasn't had any impact. Even when Settings/About's Device ID, and OneDrive's registry settings change, OneDrive behaves the same.
From your post, the challenge will be: how can I change the Security Identifier? Is it in the registry (it's not at HK/Local/SAM), or something which is just computed on-the-fly?
As far as using different accounts goes, that's unfortunately not a preferred solution. I need file access across these different accounts (although I do recognize that I could set up file sharing between the different accounts, if all else fails). I'll keep trying (wmic useraccount get sid,name is sure interesting).
I sincerely appreciate your efforts!
Sysprep.exe can be used to change the user's SID, but our test results show that sysprep may cause Windows To Go USB drives to fail to start. Sysprep.exe may only be available for Widnows installations on internal hard disks, we're still trying it.
Our suggestion is to create a temporary account B, use B to log in to windows, delete the original account A, then create a account C with the same user name as the original account A, and finally use account C to log in to windows and delete temporary account B. This way you have an account C with the same name as the original account A and the SID of the account has changed.
Posts: 7
Threads: 1
Joined: Aug 2019
Reputation:
0
08-21-2019, 06:35 PM
(This post was last modified: 08-21-2019, 06:52 PM by MJFlash.)
Howdy!
Now that you offer this alternative, this is actually something that may just well solve the problem. I did just what you suggested, and while a few apps required some initial work (Google, Thunderbird, adding Taskbar icons), overall it wasn't bad at all. Most importantly, I have access to my OneDrive files. While I have a new SID, most of the digits are identical, where the only difference is moving from a trailing -1001 to -1006. I've now tested to ensure that newly-added OneDrive files stay there, and it works flawlessly! Congratulations!
Many thanks for coming up with what is actually a very reasonable, and fairly quick, compromise! If the cost of fixing this is less than an hour of my time for clones that I need to do real work on, I'm all in. Great job, folks!
Cheers!
Mark
Posts: 7
Threads: 1
Joined: Aug 2019
Reputation:
0
08-23-2019, 07:21 AM
(This post was last modified: 08-24-2019, 06:11 AM by MJFlash.)
Hi, Gang!
One of the consequences of this situation is that when folks use OneDrive with multiple clones, it will be necessary to actively manage this behavior. Each time a new account is added to Windows 10, it will essentially create a SID that's the last/final active account's SID plus 1, as in ...-1001 to ...-1002. Following admin's procedure exactly will therefore add SID+2 (+1 for the B account, and +1 for the C account). So, pay attention to your clones! When you follow this procedure on a second clone, it will be necessary to add 2 dummy accounts, not just one, to ensure that each volume's SID remains unique. To make this work, it's necessary to actually log in to each created account (this is when the new SID number gets created). For a third clone, you'll need to add 3 dummy accounts, and login in to each of those accounts before creating your new account, etc.
The way to manage this is to type: wmic useraccount get sid,name in order to track the SIDs on each volume. Tracking this is a bit of a pain, but at least it's a solvable problem.
FYI!
Mark
P.S. The discussion above assumes that the multiple clones are all copies of the same volume. If instead, you were to follow admin's procedure, and then clone that clone to another volume, you should be able to stick with the initial procedure (i.e. one dummy account for each "daughter clone"). This stuff isn't trivial, and you'll need to keep this in mind.
Posts: 7
Threads: 1
Joined: Aug 2019
Reputation:
0
One more thought. If you keep a cloned volume around as a backup and haven't followed the recommendations in this thread, don't be surprised when things go wrong months down the road and you boot that clone. It'll wipe out all your newer OneDrive files! I encourage folks who use OneDrive to implement admin's procedure now!
|