I have never encountered this kind of issue. Can you please share your exact scenario when you hit the issue & BSA version?
Thanks & Regards,
What error you see? [With only TARGET.OS property.
It never happened to me. There is something problem in setting up the variable in Windows.
I would recomend you to echo the TARGET.OS first and then set the variable. Modify your script as below, and you will come to know Whether it problem with Bladelogic or Windows:
####Added 2 New lines####
echo "TARGET OS is -- ??TARGET.OS??"
echo "OS VERSION is -- ??TARGET.OS_VERSION??"
IF %OSMAJOR% NEQ %OSMJV% (exit 1151) ELSE (echo This Server is Windows)
IF %OSMINOR:~0,4% == %OSMIV% (echo This Server is 2003) ELSE (exit 1150)
the odd thing about this situation is, it initially works and then just stops randomly. The fix is to paste the exact same code into the external command and save it, then it works fine again. The pain point is once we promote the packages they become locked and I no longer have access to them. I think I will try adding the initial echos from above for our next release and see if that works.
Might be a stupid question, but you never know... Have you checked to see if all those properties actually had values in the target you're running this against?
when you re-add the external command are you doing it as the role that the package was promoted to ?
if yes, can you demote it back to the 1st role and see if the same behavior exists ?
when you initially create the blpackage and external command does the promoted role have any access to the blpackage ?
So there are 3 roles involved. I create the package with one. The the permissions are removed off of the package and the AO Bladmin and regular Bladmins only have access (we deploy via AO).
The sequence goes as follows
1) I create the package with a builder role
2) it is locked and only baldmins have access
3) it deploys successfully for a couple of days
4) randomly it stops passing in the server property value (I verified the server property is populated on the server)
5) Bladmin re-adds the same external Command and it works again.
This is the minority. The os check is in every package my team creates and only a few have this issue randomly. Even stranger, in the same external command it passes in ??TARGET.OS_VERSION?? but doesn't pass in ?TARGET.OS??
so there are no changes (check the audit trail) between step 2 and 3? and the 'AOBLAdmins' are dong the deploy in steps 3 and 4 ?
also - the blpackage is created from scratch each time by the builder role? or is it copied in some fashion?
can you setup the external command so that it fails when the property values are blank, and set the option in the deploy job to leave the staging contents behind on failure? and also set the 'DEBUG_MODE_ENABLED' property on the job to true. i think that the properties will get resolved and written into the ??STAGING_DIR??/bldeploycmd.bat file and the debug log should show the property resolution happening. that might give some indication of what is going on.
i was thinking that if it was always happening after the promotion there could be some permission issue w/ some of the internal property instances. not sure if that's the case though.
There are no changes between 3 and 4 and our AO automation automatically creates the job at the time of deployment with the default settings so technically no job exists until minutes before the deployment. We just has this happen again today with another package and the locked package has been deployed for over a month and today it had the issue. It deployed to over 4K servers before it ran into an issue. I will try to catch the issue and make a debug set job the next time it happens. We do copy a base BL package when initially creating the new package. But only a handful experienced this issue and many have deployed fine with the copied package.
what role created the blpackage that you copy ? and does AOAdmins own it now ?
is there a reason you copy the blpacakge vs creating from scratch ?