Anyone else ever experienced this? getOS() step is not correctly identifying CPU architectures. Fortunately, it's easy enough to detect other ways but stil...
I'll be opening up a support ticket but thought I'd ask here as well.
Yes, we've found the getOS() step does return the wrong results on a few systems - best we could tell it got a permission error trying to read the particular registry key it checks and 'defaulted' to x86. The machines that return the wrong result do so consistently. I ran a script across every machine to cross-check and assess how widespread this problem was. It only affected a handful of machines out of nearly 3000, and they were all at one particular customer site, deployed at the same time and quite old, so I put it down to some kind of initial build error and didn't worry about pursuing it further.
Yes. We've had similar problems. Also with reading text from files. I'm not sure what changed, but a few of the agent procedure commands are flaky now.
Certainly works fine for me.
In the agent procedure logs I see an extra line where a system script "Windows - 32 or 64 bit OS" is run (the getOS() call triggers this), This script checks the OS-bit-type. Your logs show your system apparently isn't running this script.
You may have a script library error- in which case it's time to run a 'reapply schema' to fix that.
We have identified about a half dozen agents where getOS() returns the wrong results (out of around 3000) - all built around the same time for the same customer, so we figured it was some kind of build error. From memory that script checks a registry key and I think odd permissions on that key caused it to default to assuming x86.
support advised re-running the loadsubagentprocs.sql which resolved the issue without having to do a full reapply schema.