KACE - Custom Inventory Fields - Why this command does not work
Can anyone explain why this CIF does not return any information?
ShellCommandTextReturn(cmd /c dir /A %WINDIR%\SYSTEM32\KUSRINIT.EXE\)
I get no results at all; No data.
If I change the command in the CIF to this for testing, I get results, but, of course, to the wrong query.
Example of a CIF that works:
ShellCommandTextReturn(net localgroup administrators | find /V "^$" | find /V "Alias" | find /V "Comment" | find /V "Members" | find /V "-" | find /V "The command")
Manually, from a Command Prompt, I get a result like this: (below) (This would be great in the CIF, if it would populate there.)
==========
C:\>dir /A %WINDIR%\SYSTEM32\KUSRINIT.EXE\
Volume in drive C has no label.
Volume Serial Number is E026-7A88
Directory of C:\WINDOWS\SYSTEM32\KUSRINIT.EXE
File Not Found
==========
or:
==========
C:\>dir /A %WINDIR%\SYSTEM32\KUSRINIT.EXE\
Volume in drive C has no label.
Volume Serial Number is E026-7A88
Directory of C:\WINDOWS\SYSTEM32\KUSRINIT.EXE
03/11/2024 02:25 PM <DIR> .
03/11/2024 02:25 PM <DIR> ..
03/11/2024 02:25 PM <DIR> source9068_872686414
0 File(s) 0 bytes
3 Dir(s) 14,940,663,808 bytes free
==========
FYI:
(I'm trying to use it to help detect a Kace agent (13.2.23) install defect where a directory called "KUserInit.exe" is sometimes created here "C:\Windows\System32\KUsrInit.exe\" instead of the "KUserInit.exe" file/program being there instead. It causes login loops.)
Thank you for your time.
Please let me know your thoguhts.
Answers (2)
Top Answer
With AmberSDNB help I ended up using this:
ShellCommandTextReturn(cmd /c dir /A %windir%\sysnative\kusrinit.exe\ /s /on /b)
This helped determine problem computers that were impacted by an issue after 13.2 upgrade:
For some reason a minority of PCs (est. at 3.5%) had a directory in place of where a Kace agent file should be.
The directory "C:\Windows\System32\KUsrInit.exe\" (yes directory, not .exe file) existed with what looks like a subset of Kace program deployment and/or script file sources instead of the file called C:\Windows\System32\KUsrInit.exe .
Here is a copy of the script that I am using to correct most of them:
(The .BAT file in the Dependencies is not needed. It is remanent for failed attempts.)
Dependencies
KUsrInit.exe (You will need to upload a known good copy of this file)
Verify
Verify that the directory “%windir%\sysnative\kusrinit.exe\” exists.
On Success
Launch “\cmd.exe” with params “/C rmdir %windir%\sysnative\KUsrInit.exe\ /s /q”.
Launch “\cmd.exe” with params “/C copy KUsrInit.exe %windir%\sysnative\KUsrInit.exe /Y”.
Have you tried this? Should work. Agent being 32 bit on 64 bit system causes odd issues with querying of System32 vs sysWOW64 (sounds like v14 (in beta) is a 64 bit agent, so this may break when you update to v14)
ShellCommandTextReturn(cmd /c dir /A %windir%\sysnative\kusrinit.exe)
Similar oddities occur when you query the registry with the 32 bit agent. In the registry there is HKLM\Software\WOW6432Node, which is 32 bit registry keys on a 64 bit machine. When you go to query this with the agent, it only sees HKLM\Software as the same thing (without the WOW6432Node) since it's 32 bit.
Comments:
-
AmberSDNB you were definitely on to something. This did indeed help me get things working more like I wanted. I is hard for me to believe that I have never run into "sysnative" need before. I have been using Kace for 12 years. I guess that I and many other people generally do not need to play in the System32 path with scripting very often. With the Kace agent still being 32bit based, this is important to know.
Reference:
File System Redirector
https://learn.microsoft.com/en-us/windows/win32/winprog64/file-system-redirector
"
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.
Windows Server 2003 and Windows XP: The Sysnative alias was added starting with Windows Vista.
" - ejweston 8 months ago-
Glad that worked. :) It's not a traditional variable, just an alias as you mentioned so it's an odd one for sure. I think I stumbled upon it back in the days of cleaning up Flash and was so confused why it wasn't pulling.
"Note that 64-bit applications cannot use the Sysnative alias as it is a virtual directory not a real one."
-Sounds like when v14 SMA comes out and the agent is switched to 64 bit, anything using these will need to be adjusted. - AmberSDNB 8 months ago