Using xec issues with Jenkins

Because automatic integration testing is required, automatic deployment is required. Because ci server and test server are two different servers in the LAN, remote execution is required, therefore, I thought of using objective xec (the latest version is 1.98) in Microsoft's free tool PSTools ). When using ipvxec in Jenkins, I encountered a series of problems and I was trying to solve them. Some problems were solved in this process, but there were still some critical problems that were not solved, but I will record these processes first.

 

* An error occurred while remotely executing a batch processing script. The message "MSBUILD: error MSB1009: Project file does not exist. Switch: ***. proj" is displayed"

Cause: You can use msbuild to call *** in batch processing ***. when performing operations on the proj file ,***. the proj file name must be given in an absolute path instead of a relative path. The relative path will depend on the current execution directory and be executed in Jenkins using the extension xec, increasing the complexity of using the relative path, therefore, it is easier to use absolute paths. How can I obtain the current path of ***. bat?

Solution: You can use % ~ in batch processing ~ Dp0 is obtained to solve the problem that ***. proj needs to use the absolute path.

 

*. When Jenkins calls a batch script that contains batch xec processing, the Jenkins build process remains stuck until it times out.

Cause: the license confirmation prompt box is displayed during initial use of license xec.

Solution: add the/accepteula option.

 

*. MSBUILD: error MSB1008: Only one project can be specified.

Cause: the path of the ***. proj file contains spaces.

Solution: Use double quotation marks on the entire path.

 

*. System error 1312 has occurred. A specified logon session does not exist. It may already have been terminated. The network connection cocould not be found.

This error occurs when you use net use to create a network disk ing to copy files to a remote server:

Net use \ 1.2.3.4 \ DropLocation/user: administrator password

Xcopy/s DropLocation \ 1.2.3.4 \ DropLocation/y
Net use \ 1.2.3.4 \ DropLocation/delete

This problem is very strange. Some people say they want to add domain names, but my server is not in jail. What should I do with the machine name? The result is true. Since the domain name/computer name is added before the account name, this problem has never occurred again. I cannot determine the real cause of this problem.

 

*. Access is denied. Couldn't access 1.2.3.4

After resolving the hung up problem, this problem followed one after another. This was a difficult problem to bypass when using javasxec in Jenkins. So far, no good solution has been found.

There is a clue:

Possible reasons:
1) psiexec.exe shows EULA message during first run.
2) Permissions
3) dll function can require user session.
To avoid these issues please try following scenarios:

1) with "-accepteula" argument
2) with "-s" argument
3) with "-I" argument

Http://stackoverflow.com/questions/5653836/psexec-hang-while-being-executed-from-a-very-simple-c-sharp-or-c-gui-program-c

However, the test is useless.

Another buddy said "Add-h", but I checked "Export xec /? No-h option was found. At this time, I began to suspect that I was using the PSExec version. At first glance, 1.96 was used, and the latest version was 1.98, hurry to Microsoft's website to download the latest javasxec (http://technet.microsoft.com/en-us/sysinternals/bb545027), the new version really supports-h, consider vista and later versions of windows permissions. However, after I tried-h, the problem still exists. I am very sorry with this Buddy:

---------------------------------------------
Posted: 12 February 2012 at 5: 51 am
Hi, I'm using the specified xec v.1.98 but still suffering the issue with-h option. What revision of your xec you're using? Thanks.
---------------------------------------------

 

In addition, there are still some Syntactic differences between ipvxec 1.96 and 1.98. 1.96 if the script that can run successfully in 1.98 returns an error:

Couldn't access 1.2.3.4:
Logon failure: unknown user name or bad password.

Finally, you need to change it to the following:

Export xec \ 1.2.3.4-u administrator-p password-n 60-accepteula "C: \ DropLocation \ ABC Deployment \ ABC. Database \ DeployABCDatabase. bat"

The problem persists.

 

Another buddy is said to be able to successfully execute the following statement, but no response is returned:
Export xec.exe-accepteula \ 1.2.3.4-u administrator-p password-w "DropLocation \ ABC Deployment \ ABC. database "" C: \ DropLocation \ ABC Deployment \ ABC. database \ DeployABCDatabase. bat"

But I tried it and it was useless.

 

So how can I use. net as a shell to call javasxec in a new process? Because manual running in batch files can be successful, but the call via Jenkins cannot be successful. The. net console application is used as a simple shell to directly create a process in it. The problem after use is the same:

The handle is invalid.
Access is denied.
Connecting to 1.2.3.4...
Couldn't access 1.2.3.4:

 

It seems that it is still the reason for executing the account. What if we can run as administrator? There are two ways to achieve this: CreateProcessAsUser and CreateProcessWithLogonW.

That uses CreateProcessAsUser to start cmd to execute a look (http://blogs.msdn.com/ B /alejacma/archive/2007/12/20/how-to-call-createprocesswithlogonw-createprocessasuser-in-net.aspx), it is a pity that the CreateProcessAsUser failed to execute, 1314 error (CreateProcessAsUser error #1314), someone said to enable the local user group target user the following permissions, you can run it normally:

Act as part of the operating system
Create a token object
Log on as a batch job

However, if I add it, it still does not work. It seems that the CreateProcessAsUser method has encountered an iceberg, so try another method CreateProcessWithLogonW and fuck and execute CreateProcessWithLogonW under Jenkins. There is also a problem: Access is denied. It's strange. What about Jenkins's Log on account? After being changed to Administrator, this error did not appear again. The CreateProcessWithLogonW seems to be a flash of process creation, and remote execution does not seem to be actually executed. Sad reminder... What's even more tragic is that the following problems have emerged:

'Abc. Service. deploy. cmd' is not recognized as an internal or external command, operable program or batch file.

 

The problem research is continuing... You are welcome to share your studies. Thank you.