The case of the (sys)Native

November 11, 2012 - Deployment, SCCM 2012, Windows 7

While preparing for an OS migration to windows 7 with SCCM 2012, we were using a package in the tasksequence to do some finetuning of the OS.

as the OS was going to be x64 based, I encountered a typical phenomenon; the commandline in the package was working, but it wasn’t applied

we had to disable some OS features, which can be done with ‘dism.exe /online /disable-feature:<featurename> /quiet /norestart’ (mind the case-sensitivity in the featurename), but we all knew that already, didn’t we?

(the reason we disable the features in the tasksequence instead of in the offline image, is to be able to turn the feature on if we have to in the future)

back to the commandline, as I wrote it ran but the features weren’t disabled.  So, what did the dism.log say (you can find that one in windows\logs\dism folder)?

Not much actually, at least there were no errors in it… but the thing is that I saw this: ….. running architecture=x86

so it was using the wrong version of dism.exe (on a 64 bit machine you will have one in windows\system32 and one in windows\syswow64)

The commandline step was running in the full OS, so the problem should be something else

that’s when I came across this:

32-bit applications can access the native system directory by substituting %windir%\Sysnative for %windir%\System32. WOW64 recognizes Sysnative as a special alias used to indicate that the file system should not redirect the access. This mechanism is flexible and easy to use, therefore, it is the recommended mechanism to bypass file system redirection. Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one.


So I decided to modify my commandline into: ‘%systemroot%\sysnative\dism.exe /online /disable-feature:<featurename> /quiet /norestart’

to find that it is working now!

the dism.log displays …. running architecture=amd64….