Share via

How to handle signed int exit code/error code/return code in a SCCM Task Sequence?

  • Article

Question

Thursday, April 5, 2018 5:20 PM

Hi

In a custom Task Sequence, I am running a command line step with the following command: cmd /c bdehdcfg -target default

If you run bdehdcfg on a machine where all partitions are already in place, and you are good to go to enable Bitlocker, bdehdcfg returns the following exit code: 3231711234

Now I would like to test for this exit code in a Task Sequence to see if a reboot is required or not. So I do a condition check on the built in _SMSTSLastActionRetCode variable just after I run the above command line step to see if it is equal to 3231711234. But the problem is, when I look in the smsts.log, the _SMSTSLastActionRetCode get set to the value -1063256062 ??? So a couple of question comes to mind:

  • Is it possible to test for this negative value in a Task Sequence? If I type in -1063256062 in the condition value instead of 3231711234, the step does not show up in the smsts.log at all.
  • Why does _SMSTSLastActionRetCode get set to -1063256062 in the first place, and not just 3231711234 ?

So far I have had no luck trying to find the answer myself, so I hope someone can shed some light on this, or point me to some documentation describing what is going on, and how to handle this.

Regards Brian             

All replies (4)

Thursday, April 5, 2018 10:52 PM

1063256062 is the two's complement of 3231711234. Not sure why that's what it's seeing, but in the signed value world, that's really the same thing.

As for how to handle it. first, don't use cmd.exe to launch another .exe -- that's pointless "inception" that can actually cause current working directory issues.bd

Next, if neither -11063256062 nor 3231711234 work in the condition, how about wrapping your bdehdcfg.exe command-line in a batch file that checks for the return value and returns an easily checked value like 3010 if a reboot is needed.

Jason | https://home.configmgrftw.com | @jasonsandys

Friday, April 6, 2018 6:21 AM

Hi,

Are you running on a virtual machine or a physical machine?

Someone has tested it on his VM and got the exit code 3231711234:

It looks like the exit code 3231711234 is the code it gives when you receive the message "bitlocker is properly configured, bdehcfg does not need to be run" I added this code as a success message and it went ahead and finished on my VM.

Reference: https://www.reddit.com/r/SCCM/comments/2pkrs3/how_to_enable_bitlocker_on_existing_pcs/

Best Regards,

Lorry

Please remember to mark the replies as answers if they help. If you have feedback for TechNet Subscriber Support, contact [email protected].

Friday, April 6, 2018 8:23 AM

Hi Jason

Thanks for taking the time to respond to my question, much appreciated! I have now removed the cmd /c from the command line.

I did manage to figure out that the 3231711234 represents a 32-bit unsigned integer, and that -1063256062 is then the 32-bit signed integer. So some conversion is going on before _SMSTSLastActionRetCode get set: I usually use errorlookup.com to try and figure out error messages https://errorcodelookup.com/?type=ntstatus&code=C0A00002

So during all my testing, my task sequence step ended up looking like this:

And the machine kept rebooting, because the first condition is always true. And that also explains why the last condition was not showing in the SMSTS.log, because there is no need to evaluate any more conditions if the first one is true. So off course the if statement should have been an NONE, I feel so stupid now J   

So just in case anyone else is wondering if you in a task Sequence can check for negative 32-bit signed integer exit codes in a condition value, you can.

Regards Brian

Friday, April 6, 2018 8:52 AM

Hi Lorry

Thanks for replying.  

Yes, that is part of what got me confused in the first place. When you run the command, and you don’t want the Task Sequence to “break”, you add the number 3231711234 to Success Codes (as in the picture below).

So I assumed the same number would show up in the _SMSTSLastActionRetCode variable. But if you look in the SMSTS.log file, you can see that it gets converted to a 32-bit signed integer:

So as you can read in my reply to Jason above, I made a mistake in the if statement in my task sequence, so I ended up thinking is was not possible to check for a 32-bit signed integer.  

But yes, it is confusing that the success code is not the same as the _SMSTSLastActionRetCode.