os: Windows Server 2012 R2
NW - 2020-01-22
We have come across an environment where facter is not reporting the correct data for the os.windows.system32 fact. We have successfully deployed the Puppet agent on other environments many times with no issue.
When we install the puppet agent, start a new PowerShell session and run facter os.windows the value returned is "C:\Users\username\WINDOWS\system32" instead of the expected "C:\Windows\system32"
The username changes based on who is running the command.
We get the same result regardless of whether we use a cmd or PowerShell prompt and whether it's a standard or Administrator.
We have tried this on 2 systems in this environment with the same result which seems to indicate an environment rather than an individual system issue.
Running set at a cmd prompt or Get-ChildItem in PowerShell reports the following expected settings:
A search of the internet led us to this link which seems to be where the fact is determined:
Using information found here http://pinvoke.net/default.aspx/shell32/SHGetFolderPath.html, we managed to translate the C++ source code in a C# type to add to PowerShell so we could see what was being returned. This is the code we came up with:
public class shell32
private static extern int SHGetFolderPath(
[Out] StringBuilder pszPath
public static string GetKnownFolderPath()
const int MaxPath = 260;
StringBuilder sb = new StringBuilder(MaxPath);
if (SHGetFolderPath(IntPtr.Zero, 0x0024, IntPtr.Zero, 0x0000, sb) != 0)
return "failed"; // add whatever error handling you fancy
When we run the following:
we get the expected output:
Which doesn't help at all.
We can probably work around getting the incorrect data in our Puppet manifests but that doesn't help for anything on the forge that might rely on that fact.
Initially we need help in determining why/how this is happening so this can then be fed back for further analysis and a plan of action determined whether that be a change in the environment to modifications to the facter code.
The below information is not directly related to the issue but is included for reference.
There is also this pull request that seems to want to change this code to use the correct CSIDL:
The Microsoft documentation also says that SHGetFolderPath deprecated and is now a wrapper for SHGetKnownFolderPath so maybe the code should also be updated to use the new function.