I’ve had some issues with OneDrive recently that required lengthy support from Microsoft to resolve. Whilst working on the issue, it was noticed that instances of ID numbers relating to user/machine combinations were identical on different machines and we wondered if this may have something to do with the issues we were seeing. Ultimately, a resolution was found without making any changes to these IDs, but it was noticed that the format of the IDs was similar to the SIDs we used to have to change on target machines after cloning in the days of Windows XP. This was done using a utility called NewSID, but later on, using Acronis bare metal restore, an option was available to change the SID during the cloning procedure.

My understanding is that changing the SID on a cloned machine has been unnecessary for many years as detailed in this article.  This is presumably why Reflect doesn’t do it. I did send this to Macrium support asking for clarification, but their reply wasn’t very helpful and suggested running SysPrep to change the SID. The problem with this method is that it’s a very complex and involved procedure for such a minor tweak – hence the NewSID utility.

Even if it isn’t necessary, as would appear to be the case, it still looks wrong seeing an ID that’s supposed to be unique, appearing identically on different machines and it could be argued that changing the SID offers some advantage from a purely diagnostic point of view. These IDs get used in many different places - For example, we could see them used in the title of OneDrive update tasks in Windows Tasks Scheduler and in the name of the temporary folders used by OneDrive. In these and many other cases, having IDs that are different makes it easier to see what’s going on and it may even be worth considering changing the SID on this point alone, provided that it can be done easily reliably and safely.

The NewSID utility was officially retired years ago and was not supposed to work on Windows 7, but it looks like it’s still available for download here and, if the contents of the page is to be believed, it was updated last year and is compatible with Windows 7-10!

Anybody tried this or know anything about Sharewarepros?

Then there’s a utility called SIDCHG that’s supposed to be okay with Windows 10.  Anybody had any experience of using this utility?

Any other thoughts and comments on this would be most welcome, in particular, my question about changing SIDs simply to restore them as a unique identifiers, which is, after all, what they’re supposed to be and what you’d have if machines had been built individually.

+x

 

Tolqua - 21 June 2018 3:55 PM

I’ve had some issues with OneDrive recently that required lengthy support from Microsoft to resolve. Whilst working on the issue, it was noticed that instances of ID numbers relating to user/machine combinations were identical on different machines and we wondered if this may have something to do with the issues we were seeing. Ultimately, a resolution was found without making any changes to these IDs, but it was noticed that the format of the IDs was similar to the SIDs we used to have to change on target machines after cloning in the days of Windows XP. This was done using a utility called NewSID, but later on, using Acronis bare metal restore, an option was available to change the SID during the cloning procedure.

My understanding is that changing the SID on a cloned machine has been unnecessary for many years as detailed in this article.  This is presumably why Reflect doesn’t do it. I did send this to Macrium support asking for clarification, but their reply wasn’t very helpful and suggested running SysPrep to change the SID. The problem with this method is that it’s a very complex and involved procedure for such a minor tweak – hence the NewSID utility.

Even if it isn’t necessary, as would appear to be the case, it still looks wrong seeing an ID that’s supposed to be unique, appearing identically on different machines and it could be argued that changing the SID offers some advantage from a purely diagnostic point of view. These IDs get used in many different places - For example, we could see them used in the title of OneDrive update tasks in Windows Tasks Scheduler and in the name of the temporary folders used by OneDrive. In these and many other cases, having IDs that are different makes it easier to see what’s going on and it may even be worth considering changing the SID on this point alone, provided that it can be done easily reliably and safely.

The NewSID utility was officially retired years ago and was not supposed to work on Windows 7, but it looks like it’s still available for download here and, if the contents of the page is to be believed, it was updated last year and is compatible with Windows 7-10!

Anybody tried this or know anything about Sharewarepros?

Then there’s a utility called SIDCHG that’s supposed to be okay with Windows 10.  Anybody had any experience of using this utility?

Any other thoughts and comments on this would be most welcome, in particular, my question about changing SIDs simply to restore them as a unique identifiers, which is, after all, what they’re supposed to be and what you’d have if machines had been built individually.

Thanks for posting. It's definitely a subject that creates a debate,  



A SID isn't meant to be a GUID, i,e, globally unique, they are only unique within the OS. 

You may have seen this article already, but in case you haven't, this is from Mark Russinovich himself on why NewSID was retired.

https://blogs.technet.microsoft.com/markrussinovich/2009/11/03/the-machine-sid-duplication-myth-and-why-sysprep-matters/

In essence, the Machine SID doesn't leave the computer and is never a gateway for access. 


Using tools to change SIDs can also be considered a security risk because the location and usage of each SID is proprietary and not available to the world outside MS....


And finally, Mark (the author of NewSID and CTO af Azure) even says...

Kind Regards

Nick

Macrium Support

See our reviews on

Nick beat me to most of what I was going to say, but Microsoft's official position is that all system deployments must come from a sysprepped image, and sysprep is the only supporter SID change mechanism. Whether or not skipping sysprep and possibly performing a SID change with some other tool will ever cause a problem is debatable, but what's very likely is that if you're on a support case with Microsoft that involves a system deployed from a non-sysprepped image and they suspect a SID issue or something similar, then they will probably stop supporting the case until you reproduce the problem on a system that was built from a sysprepped image.

That said, if all you want to achieve with sysprep is a SID change, then that's not complex at all.  You just run the "sysprep /generalize /oobe /shutdown" command and then capture an image before you allow the system to boot from that OS again.  Otherwise, the Windows ADK used for creating proper sysprep unattend is indeed a bit "much" if you just wanted to do some simple things, but if it helps, I've attached a very basic unattend file that is broadly applicable and could easily be used for sysprepping without having to do through all of the normal hassles.  It just sets the time zone and bypasses the out-of-box setup.  It can be extended fairly easily to enable auto-logon for a specified number of occurrences if desired and/or create local users, otherwise just make sure that you've set the Administrator password and created any desired additional users beforehand.  Ideally you will NOT have logged in as those users before capturing the image though.  The best way to do that is to build your image using "Audit Mode", which uses the built-in Administrator account and can be accessed by pressing Ctrl+Shift+F3 at the out-of-box setup on the PC from which you first build the image.  Anyhow, if you want to use this, just add the "/unattend:pathtofile" switch to the sysprep command I already mentioned.  Also change the extension on the attached file to XML.

Thanks Nick and JP.

Sorry for the late response, but it’s clear that I need to give some more detail of my situation and this took some time to write up.

I had read Mark’s article some years ago (think there’s a link to it in the page I pointed to), but re-read it again and it reassured me that machines with identical SIDs shouldn’t be a cause for concern in terms of security or accessibility, but that’s not really what I was asking. My question was whether it was safe to do so without resorting to Sysprep and, if so, suggested that it may be worth doing so purely to avoid the distraction caused by having several systems with the same SID when troubleshooting certain issues.  It seems, from what’s been said, both here and by Mark, that the answer is a 'no'.  Is it fair to conclude from this that it’s best to either leave them alone or use Sysprep, then?

I’m reluctant to use Sysprep, though, because I spent some time working with it a few years ago and it didn’t end well. I set up Hyper V and used VMs to get to grips with creating answer files and experimenting with customisations using Kari’s excellent tutorials on the TenForums site. Without these I’d have stood no chance, but even with these it’s no walk in the park. The biggest issue is the intrinsic difficulty in trying to get right all the configuration and settings in one go knowing that many of them are not apparent or will change after you’ve been using the machine for a while. However, one very powerful feature I was keen to use was the copyprofile=true function. Some users had asserted that using this would always give rise to issues and I, indeed, found I was seeing some odd browser issues that were visible even on the VMs after sysprepping with copyprofile=true . I also found that using /generalize /oobe /shutdown removed configuration and settings which added significantly to the list of actions that needed to be applied after a deployment so I decided to try cloning a working machine after I’d been using it for long enough to have a machine that was reasonably well configured. Not ideal, and certainly not the MS ‘supported’ way, but worth a go since cloning in this way seemed to be being widely used without major issues for many years with Acronis and Macrium. Also, given that the PCs to which I wanted to deploy are all new Dell Optiplex 7050 MTs, it shouldn’t even be necessary to use Redeploy. I can’t remember whether I used this or not on the first clone, but it worked well except for a problem with OneDrive that required its re-installation to remedy.

The next clone was purely experimental. My XPS13 laptop had recently been returned from Dell with a stock image so I took a Reflect backup and tried cloning from one of the Optiplex PCs using redeploy, of course. All was fine except for the same OneDrive issue as I’d seen on the first deployment. This time I recognised the symptoms: (newer files being replaced by older ones of the same name) and was able to demonstrate this to the Office 365 Concierge Support engineer. I had the source and target machines both syncing OneDrive folders (personal and business). I then added a test files on the source PC and watched it disappear as soon as the target machine became ‘Up to Date’ a few seconds later. Then I repeated this and added a second test file on the target machine before it synced up. I was then able to watch as both machines alternately deleted then restored the other’s files - locked inexorably in an argument as to which one’s state was correct. Of course this is the very thing a sync engine is supposed to resolve and I suggested that this appeared to be happening because OneDrive (locally or in the cloud) was failing to distinguish between the two machines and that this was likely to be connected with the cloning process.

As we worked on this, the engineer spotted the similar SIDs in the names of the hidden OneDrive temp folder and wondered if this was worth further investigation. I pointed out that this is exactly what I’d expect to see as a result of the cloning and not having done anything to change the SID. At this point we spent some time discussing SIDs. His position on SIDs, as recalled from many years ago, was the classic view that the SID should always be changed (by Sysprep), so I referred to Mark’s article and we left the SIDs alone. After trying a number of actions to sort the sync issue, it was resolved by uninstalling and reinstalling the sync client as before. It looks like it may be best to uninstall the OneDrive client app before cloning as an unavoidable and necessary step, but it was this experience that had me wonder whether changing the SID could be worth considering simply to introduce a difference - Not a GUID, as you say, but at least not identical to other machines on the network. It wouldn’t be achieving anything more than avoiding ‘looking wrong’ which, in the above case would have saved some time, but would only be worth doing if it could be done easily and without any negative impact. I’d argue that, for me at least, this rules out Sysprep on both counts, but it also appears that using a utility to change the SID, whilst quick and easy, may well have consequences at some point in the future.

One further point that’s worth mentioning is in regard to the suggestion that using any image-based method of deployment without running Sysprep could lead to issues when getting support from Microsoft. This is interesting because that was a concern of mine so I asked the engineer if he’d been given any instructions in this regard and he said he hadn’t and that the importance of applying ‘best effort’ to resolve issues would mean that any such directive should not be used as a way to avoid offering help wherever possible. Obviously this isn’t conclusive, but it’s refreshing to hear such noises coming from MS and it does look like they now have a much more helpful approach to making support available, at least to Office 365 users (my experience of MS support outside of this is, frankly, appalling).

Sorry for the lengthy post, but hopefully it’s helped to explain my position and why I revisited the question of changing SIDs when cloning.

I personally wouldn't bother with using a third-party utility to change the SID.  It sounds like the OneDrive issue could have been caused by its own internal GUID, not necessarily the system SID.  It's certainly possible that Sysprep may be programmed to change that as part of its routine, or OneDrive may be programmed to reset its own GUID when it sees a SID change, either of which would mean that a SID change would avoid the OneDrive problem, but if you can trigger a GUID change with a simple uninstall and reinstall, then you may not need to bother with the SID change.  The other possibility of course is that Mark's article is still generally applicable but that there are some applications for which a unique SID (or detection of a SID change) actually matters to them, especially applications that may have been released since that article was written a while ago.  In that case, you may find that in your own use case, SID changes aren't necessary if as long as you take some additional steps, but that doesn't guarantee that they won't be necessary for someone else's application set.  But you may also find that in some case where a SID change is necessary, differences in the behavior of a third-party SID change utility compared to sysprep will make the difference between success and failure.

CopyProfile has become a nightmare on Windows 10.  I've tested it on all releases of Windows 10, and the only one where it worked almost perfectly was Win10 1607, but even there the Quick Access icons were broken because their paths pointed to the Administrator profile folder, not the user's own folders.  In newer versions, using that has caused things like Windows Search to be completely broken on new profiles.  Manually deleting certain cache files before sysprepping has has sometimes worked around that, but that's not confidence-inspiring and shouldn't be necessary.  I think I remember a TechNet article saying that CopyProfile was no longer recommended on newer versions of Windows 10, which would explain the havoc it induces, but I do miss that feature.  It looks like Microsoft's proposed replacement is to export a custom Start menu layout as described here, which is what I've been using since then and which does work.  And even CopyProfile doesn't always copy over ALL custom settings; some of them get reset anyway.

As for getting sysprep just right, I'll typically build it in a VM and then take a VM snapshot just before running sysprep, then sysprep and reboot so I can see what happens when the system goes through the new system setup.  If it doesn't configure itself the way I want, then I can revert to that snapshot to get right back to the way the system was before it was sysprepped, and try tweaking my unattend file or whatever.