How is the job failing ? can you attach the bldeploy log from the target where this fails ?
06/13/16 13:10:21.912 WARN
bldeploy - [New External Cmd] [stderr: 1] Logon failure: unknown user name or bad password."
This is the problem...
If you need to copy a file to another server using UNC paths within an external command, you must be using automation principals with a domain account, or if the computers are on a workgroup, you must make sure that the local account used exists on the target computer and has the same password.
If you're not using automation principals, it means the BladeLogicRSCD user will be used to authenticate, which does not always have the same password depending if it's installed on a domain member or a domain controller. You can lock the BladeLogicRSCD account that way if you're not careful...
06/13/16 13:10:21.673 INFO bldeploy - [New External Cmd] Executing command: "cd C:\urt1
copy TCS*.mef3 \\172.31.14.205\c$\tmp\stage\"
06/13/16 13:10:21.674 DEBUG bldeploy - [New External Cmd] chdir to PkgDir: 'C:\temp\stage\52e9e1ac679a326dbd4f56249858ee2e\' 06/13/16 13:10:21.676 DEBUG bldeploy - [New External Cmd] exeFullPath = (null), CmdLine = "C:\temp\stage\52e9e1ac679a326dbd4f56249858ee2e\bldeploycmd.1.bat", workingDir = NULL 06/13/16 13:10:21.808 INFO bldeploy - [New External Cmd] [stdout: 1] TCS_13JUN2016_TDCWEBLOG01.mef3 06/13/16 13:10:21.912 INFO bldeploy - [New External Cmd] [stdout: 1] 0 file(s) copied. 06/13/16 13:10:21.912 WARN bldeploy - [New External Cmd] [stderr: 1] Logon failure: unknown user name or bad password.
this is failing because you are trying to copy to another system and you need to authenticate to access the c$ on the remote server. right now that's happening as the BladeLogicRSCD user from the target server. so you need to first do a net use w/ the user/password that has access to c$ on the 172.31.14.205.
or why not use a file deploy job or nsh script job to do the file copy here ?
...or use automation principals with a domain account...
How to enforce the job to use "Automation principles" ?Automation Principles are defined, but how to use them here?
I had already tries the same thing using NSH job but that too failed.
The steps to setup the ap are well documented. so what exactly have you done?
How did the nsh job fail, and what was in your script ? does the 172.x host have a rscd on it ?
If you're automation principals are defined but don't seem to be used, it's because either the role you're using is not configured properly to use them, or that your app servers are not going through the NSH Proxy (configured in the secure file).
I'm looking for "the" documentation explaining how to setup your environment for them but I can't find it... All I found is this: Considerations for automation principals and Windows user mapping - BMC Server Automation 8.5 - BMC Documentation
From what I know you need the following:
- Each app server's secure file must point to the NSH Proxy:
-appserver_protocol ssoproxy -T encryption_only -e tlsYou need to restart the app server after this change. Note: make sure to review the NSH Proxy configuration options to further tweak the max connections and settings because enabling this all of a sudden can affect the overall performance and capacity of all your NSH Script Jobs if not properly configured. Every job using NSH will be funneled through it now... for this reason, I usually configure it on each application server of my environment and add a local hosts file entry in each for the AppServiceURL I'm using pointing to the local IP of the app server, so it always points to its own NSH Proxy. (i.e. if you're using a VIP named bsa.mydomain.com when connecing to the BSA console, you should add that in the hosts file of each app server, and point it to the primary IP address of the server so that each app server will refer to itself when connecting to that address instead of falling on one of the servers behind it.). If in doubt contact support, they will help.- You must create automation principals: Creating automation principals - BMC Server Automation 8.5 - BMC DocumentationOnce you have that a simple test to check if it worked is to run a simple "agentinfo" command in a NSh Script Job against targets you want to test, and look at the Permissions line. If it shows the BladeLogicRSCD account it's wrong, but if it says something like this:...then it means it worked.
Well, a bldeploy won’t use the nsh proxy…
Hmm, I made a test with both a BLPackage with an external command and a file deploy job with a post-command doing the following in it:
And run both jobs against a target and a role that was configured to use automation principals. The result showed the automation principal user being used (domain\username) and the cmd process called by the deploy jobs were all showing as being run by the domain account as well. So this works...