Closed Didrole closed 4 years ago
Thanks for the report. I will do some research and find an alternative way to get the remote-host's OS architecture.
I did some research on what other methods there is to getting the OS architecture remotely via different WMI classes, or registries. I noticed there was a way to get the processor architecture, but that was not going to risk Super Grate not detecting the right architecture if someone installed a 32 bit version of windows on a 64 bit processor. So I am sticking with the WMI class OperatingSystem and Property OSArchitecture. What I ended up doing in the commit 0e0f82d28762ce7934f6ed7388c0961dae67565a was just doing a String.Contains("64") on the string returned from WMI. Hopefully, other Windows languages contain the number 64 in their localized version of the OSArchitecture property.
Here is a build of this commit if you would like to test it out on the french version of windows server.
https://belowaverage.visualstudio.com/SuperGrate/_build/results?buildId=97&view=results
Click here to download the build:
Describe the bug The function
Misc::GetRemoteArch
uses WMI'sWin32_OperatingSystem
class to detect computer's architecture. Unfortunately theOSArchitecture
property can be localized (https://docs.microsoft.com/en-us/windows/win32/cimwin32prov/win32-operatingsystem), leading to unexpected values being returned.To Reproduce Run SuperGrate on a localized version of Windows (I've tested on a French installation of Windows Server 2008 R2). Select some accounts, click on start. Watch the migration fails (it won't be able to find USMT path due to unhandled architecture string, ie:
USMT::USMTPath
returnsnull
).Expected behavior Account migration starting.
Logs
Edit : USMT won't work on Windows Server anyway but the bug is still valid.