This seems strange as our upgrade/hotfix rules are based on this step.
I am going to do some tests and then let you know if I reproduce.
Thank you Fabien,
I can reproduce this on 12.8.0 and 12.8.2
But only if 32bit OS is selected.
Thanks in advance,
I have tested this step and it behaves correctly. on Windows 7 32 bits.
I can see in your screenshot that you have selected both Windows 10 32 bits and Windows 7 32 bits.
Could you let me know on which OS you have executed this rule and what were the error type, error code and error detail on them ?
Could you also provide a screenshot for rule logs in which we can see all information about 'verification' and 'execution' phase ? I your screenshot we can see verification is starting but nothing more.
Additionally to that could you provide a screenshot of workflow panel for your step. Depending on the way you have set it this can change step behavior :
Fabien Carmagnolle schrieb:
Because nothing more happend
My Workflow tab looks exactly like yours. I save the screenshot.
Win10 x86 + x64,
I swear it worked a few days earlier if I only selected a Win x64 OS, nothing matter which one.
Today all crashes but "Windows Server 2016" (the OS of the device).
I ma be miss something but your are on a Win 2016 x63 so this is logical only Win2016x64 verification step succeeds.
The behavior is definitely not correct. There is no real check at all because the rule never comes out of the Verfication phase.
You can also use this component to perform jumps within an op rule.
If Winx32 do this, else jump to Componente 6, if Win10x64 is installed do that.
No op rule will start while this component is added. Each assignment always fails at the Verfication phase when this component is called.
As you can see, your op rule fails "at the right" phase, the execution phase and not whitin the Verification Phase.
I have now started up my PC again, because that leaves me no peace.
I think I expressed myself wrong or you misunderstood me.
I just wanted to express the ability to use jumps, not that I tried that in this example.
But here, this is what happens if I use the Check OS Rule not at the first position:
The rule fails at Verification Phase Step 6 (sequence 7) and never enters the execution phase.
And with jumps:
Sequence 3 checks if Windows Server 2016 is installed and S8 checks if Windows 10 x64 is installed and if not, jumps from 8 to 10.
Again the check starts but did not end. The whole rule is useless.
I do not understand why suddenly the x64-check does not work anymore. I know for sure that last week was still going on. Today, not a single check works, unless it's just the right operating system.
Now its getting weird!
If I modify the workflow of all 'Check OS' components like this:
Could anyone explain this behavior?
I totally sure it's not correct and it worked at 12.7 with "Yes" and not with "do not verfiy".
Besides, if I read the explenation, "do not verfiy" doen't make sense, doesn't it?
Should I still open a case or do I completly understand something wrong?
1 of 1 people found this helpful
We just upgraded to BMC Client Management Version 12.8.0 Build 190124r and we are seeing the same issues. We have hundreds of OpRules failing post upgrade because the Workflow is acting differently regarding the "Verification Phase" and failing the OpRule all together. I have opened an incident with BMC Support this morning but I have yet to hear back from them.
I already have one open and support is looking into it.
1 of 1 people found this helpful
The verification phase is used to perform some check before to download packages and schedule the execution of the rule.
If the rule fails during the verification phase, then the rule will be verified again after 2 min (value of the StatusInterval parameter present in the OperationalRules.ini file).
The GoTo feature is only applicable during the execution phase of the rule.