Does this work with TFS 2005

Feb 7, 2008 at 7:12 PM
I have tried to adapt the procedure into TFS Build 2005 and everytime I execute a build, it hangs. Does Team Deploy only word with TFS 2008?
Coordinator
Feb 8, 2008 at 3:33 AM
Hi,
Yes it does work with both TFS 2005 and 2008. I actually developed it against TFS 2005 and then tested it with TFS 2008. I think what might be happening is that the PS Tools require you to accept an EULA the first time you use it. Try calling the the PSEXEC and PSKILL manually in a command window. This should then allow you to use it from the build. I forgot I had to do this the first time.

Let me know if this fixes it.

Thanks,
Mike

jjgionta wrote:
I have tried to adapt the procedure into TFS Build 2005 and everytime I execute a build, it hangs. Does Team Deploy only word with TFS 2008?

Feb 11, 2008 at 4:01 PM
Hi Mike,

This helped things a little bit. I actually didn't some searching and founded an option for the pstools commands that allows users to acccept the EULA when calling the command. This might be something to look into for team delpoy. The option is -accepteula. I am still having access denied issues. Strange thing is that I run it from a command prompt and the command works fine. When I run the same command in team build I get an access denied error. I am running both commands witht he same account. Any ideas?

Thanks,

Jason
Coordinator
Feb 11, 2008 at 7:40 PM
Jason,

Would you check to verify that the user you are logged in the server with running the command manually is the same as the user that is doing the build? The Service is either called "Visual Studio Team Foundation Build" or "Team Build Service"? Also just to make sure, you are running the command manually from the same machine with TFS installed? Sorry these are not much of an answer. I'll keeping checking a few things to see if I can find a better answer.

Thanks for the option for accepting the eula. I'll get this incorporated into the next build.

Thanks,
Mike

jjgionta wrote:
Hi Mike,

This helped things a little bit. I actually didn't some searching and founded an option for the pstools commands that allows users to acccept the EULA when calling the command. This might be something to look into for team delpoy. The option is -accepteula. I am still having access denied issues. Strange thing is that I run it from a command prompt and the command works fine. When I run the same command in team build I get an access denied error. I am running both commands witht he same account. Any ideas?

Thanks,

Jason

Feb 12, 2008 at 4:38 PM
In the end, the service account didn't have admin access. However, I'm on to a bigger problem that I believe is on the psexec side where the msiexec command cannot open the MSI on the share and get an error 1619. I tried the command from a prompt and I get the same error. I'm really stumped on this one. If you had any experience with this I would appreciate some advice. I'm going to post something over in the Pstools forum. Thanks again for your help.
Coordinator
Feb 13, 2008 at 6:13 AM
Jason,

I think this error is more to do with MSIExec then PSExec. If there are any spaces in the share path or msi filename, try removing those. Also try removing the PSExec from the command line and create a batch file to install it on the local machine. Also you could try removing the share and try to use a local path to a local machine. I fought a long time trying to get the sytax of the process.start + psexec + msiexec + args right, there could easily be some flaws in it.
Thanks,
Mike

jjgionta wrote:
In the end, the service account didn't have admin access. However, I'm on to a bigger problem that I believe is on the psexec side where the msiexec command cannot open the MSI on the share and get an error 1619. I tried the command from a prompt and I get the same error. I'm really stumped on this one. If you had any experience with this I would appreciate some advice. I'm going to post something over in the Pstools forum. Thanks again for your help.

Feb 13, 2008 at 5:55 PM
Edited Feb 13, 2008 at 5:56 PM
Hi Mike,

So I guess my problem had to do with implicit logon versus explicit logon. As it turns out, if you don't specify a user and password through the option -u -p you don't have access to network resources. As a result, the psexec command had no access to the share. I also had to take the -s out because it was giving me access denied errors even though I was a system admin.

I didn't test TeamDeploy but I imagine that these type of problems would be presented if I did because essentially I'm running the same commands and environment (implicit). Were you able to install an MSI from a shared network location without specifying the options -u and -p? Also, other than making the TFS build service account admin on the targetmachine, is there any other settings that need to be set to get the -s option working? (Sorry your manual is a little hard to follow)

Thanks,

Jason
Coordinator
Feb 13, 2008 at 6:18 PM
Jason,

It does work for me to use a share however, I don't have any restrictive permission on the share. It has "Everyone" with "Read" permissions. Have you tried a share with these permissions? I would think it would acceptable to have domain users with read only access. I'm not sure if would work or not if I change everyone to domain users. I'll try this too. We use advertised shortcuts where the MSI would try to repair itself if a file was missing. I haven't had to do anything else. My TFS build user is admin on the target machines but that is it. I'll review the install instructions and clean it up and add some more detail. I probably made some assumptions that everyone's environments are just like mine :)

Thanks,
Mike

jjgionta wrote:
Hi Mike,

So I guess my problem had to do with implicit logon versus explicit logon. As it turns out, if you don't specify a user and password through the option -u -p you don't have access to network resources. As a result, the psexec command had no access to the share. I also had to take the -s out because it was giving me access denied errors even though I was a system admin.

I didn't test TeamDeploy but I imagine that these type of problems would be presented if I did because essentially I'm running the same commands and environment (implicit). Were you able to install an MSI from a shared network location without specifying the options -u and -p? Also, other than making the TFS build service account admin on the targetmachine, is there any other settings that need to be set to get the -s option working? (Sorry your manual is a little hard to follow)

Thanks,

Jason

Feb 13, 2008 at 7:37 PM
Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?
Coordinator
Feb 13, 2008 at 8:47 PM
Jason,
No. I have used this where the share is on the build server and a different server. It didn't seem to matter.
Thanks,
Mike


jjgionta wrote:
Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?

Feb 20, 2008 at 3:12 PM
Is your target machine a Windows 2000 Server?


mikedouglas wrote:
Jason,
No. I have used this where the share is on the build server and a different server. It didn't seem to matter.
Thanks,
Mike


jjgionta wrote:
Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?


Coordinator
Feb 21, 2008 at 4:13 AM
I use this to deploy to test workstations. All of my clients are either virtual or physical pcs running Windows XP. We do have another team that is using this to deploy windows services to a Windows 2003 server.
Thanks,
Mike

jjgionta wrote:
Is your target machine a Windows 2000 Server?


mikedouglas wrote:
Jason,
No. I have used this where the share is on the build server and a different server. It didn't seem to matter.
Thanks,
Mike


jjgionta wrote:
Yup everyone has read and write permissions on my share. Quick question, is your share located on your target machine?



Feb 21, 2008 at 5:44 AM
Well I'm going to finally close out this discussion. I tried using your source to do remote installs and I continuously hit permission and network access problems when trying to install an MSI on a share.

The problem occurs when not providing a username and password with the psexec command. This in turn uses Implicit authentication which doesn't allow for access to network resources. There are ways around this such as passing the username and password (not acceptable especially because the password is in clear text) and setting the Active Directory to allow for delegation of the TFS Build Service account on the test servers (quite out of hand in a large scale organization or where users don't have access to AD).

I did end up finding a suitable workaround for my situation. It involves copying the MSI to the target machine and running the psexec on the local copy of the MSI and then copying any log files back to the share.

I don't know how your setup is getting around Implicit authentication and network access, but its hard to believe that other people using Team Deploy over a Kerberos enforced domain won't encounter problems using your current implementation of Team Deploy. I look forward to hearing other Team Deploy users input and experiences. Thanks for all of your help and consideration.

Jason