Using Vault when no one is logged in

Jerry R · Post by **Jerry R** » Mon Aug 02, 2004 11:58 am

We have a computer which runs Studio in the middle of the night each day to generate builds. We have a program which uses the Solution object to open Studio, load solutions and compile them. Since we've switched to Vault and updated the program, it times out when it tries to open Studio.

This program runs without anyone being logged in to the computer, and I'm guessing that it hangs because when it opens Studio, it tries to log into Vault because of the source control integration and Vault is waiting for a user name and password. It does not hang if we run the program when someone is logged in. With the logged in user, we have set up Vault to automatically start up without input. How do we do this for when there is no one logged in?

dan · Post by **dan** » Mon Aug 02, 2004 12:31 pm

Vault gets the profile information based on the currently logged in user (stored in appinfo in the current users docs & settings folder). You may need to run the build process as a certain user instead of running it without a user (and have the user it runs under have a Vault profile defined). It might be possible to copy appinfo files to the "All users" folder, but I honestly don't know if that will work or not.

Jerry R · Post by **Jerry R** » Mon Aug 02, 2004 3:57 pm

The scheduler is setup to run the build program under the same user for which manually running the build program works fine. The Vault profile is defined for this user.

If we create a dummy solution/project which is not under Vault control, the build program runs fine when no one is logged on. This seems to imply that the problem is Vault-related. However, looking at the Vault log, it looks like it is being logged into and stuff is going on. So I'm not sure what to think. Any ideas of other things to check? Looking at the Windows Application log only yielded a 1524 warning, about the registry not being able to be unloaded.

dan · Post by **dan** » Tue Aug 03, 2004 7:29 am

If the user is being logged into Vault correctly, then it must be something that happens after login. Is it possible that there is a Visual Studio warning dialog that comes up, or the Vault Get dialog (if VS is configured to always bring up the Get dialog)?

Post by **jclausius** » Tue Aug 03, 2004 8:57 am

Jerry:

Are you using VS.Net's Automation Build components to do your build?
Can your project be compiled using "devenv /build" and the solution?

A quick thought -
If VS.Net is getting hung up on a Vault Login or Get Latest dialog, one solution would be to use Vault's Command Line Client (CLC), and do your builds from a scripting environment, building from the command line.

I'm not sure this is an option for you, but it was something I wanted to share.

Jerry R · Post by **Jerry R** » Tue Aug 03, 2004 9:08 am

Jeff, yes we're using the VS.NET components to do the build. It appears to hang in the Solution.Open() call. The thread doing the call does not return after 5 minutes. Manually opening the same solution within Studio does not produce any requests for user input.

We'll have to fool around with it some more later in the week. I'd like to continue to do the build using the VS.NET components, otherwise we'd have to rewrite a bunch of stuff. I don't know for sure that Vault is the problem, but I'll let you guys know what we find out. Thanks for the suggestions.

Post by **jclausius** » Tue Aug 03, 2004 9:15 am

Jerry R wrote: I'd like to continue to do the build using the VS.NET components, otherwise we'd have to rewrite a bunch of stuff.

That is what I thought.

Can you try a couple of tests?

1) Can you launch your build program manually (while logged in). Does that work?

2) Unbind the entire solution and all projects, now try your test program. Does the build work correctly? Even when launced from a scheduler and no-one is logged in?

Jerry R · Post by **Jerry R** » Tue Aug 03, 2004 9:36 am

We'd already tried #1 - launching the build program manually while logged in works fine.

I'll try #2 and get back to you, but that may not be until sometime Thursday. I assume you mean "build program" and not "test program" here.

Post by **jclausius** » Tue Aug 03, 2004 10:08 am

Jerry R wrote:I assume you mean "build program" and not "test program" here.

Yes.

I believe I understand what is happening. This is all "guess-work", but based on your description, I believe my hypothesis is correct.

One of the requirements for Vault client is the use of the special %APPDATA% folder which the Vault client uses to store server state information. So, when you launch your tool from an account, which is logged in, the process inherits security rights from the user which created the process (the person logged in). This person has rights / access to %APPDATA%.

However, when launched from a scheduler, unless configured or programmed, that process will be run under a security context which probably does not have all the necessary rights for the Vault client to operate correctly.

Again, assuming this is indeed the problem, you have a couple of different options:

1) Investigate the Win32 API for CreateProcessAsUser, LogonUser, LogonUserEx, or ImpersonateLoggedOnUser. Is it possible to make changes to the build tool ( or a build tool "launcher" ) so it runs the process under an account which can log in?

2) Investigate Command line utility - "runas.exe". See if you can use it to launch your program from the scheduler.

3) Can you run the scheduler itself under a known account?

Does anyone else have other suggestions?

Post by **jclausius** » Tue Aug 10, 2004 9:12 pm

Jerry:

Did any of these help?

Jerry R · Post by **Jerry R** » Wed Aug 11, 2004 8:53 am

Hi Jeff,

Sorry for the delay, we only just got to work on this some more this week. We tried using RUNAS, which requires a password to be entered manually via keyboard whenever it is run. So we found a program called SANUR which pipes a password into RUNAS. When we run RUNAS from a command prompt, it works correctly both using SANUR and not using SANUR. However, when run from the task scheduler, when a user is logged in, it only works when SANUR is not used. It seems to not run anything when run from the task scheduler when no one is logged in. So we are currently stumped.

Jerry R · Post by **Jerry R** » Wed Aug 11, 2004 9:45 am

Another update: I found another utility to use instead of RUNAS, called CPAU, which looks like it might work better. I should be able to let you know tomorrow whether it worked.

Jerry R · Post by **Jerry R** » Thu Aug 12, 2004 3:04 pm

Hi Jeff,

We ended up trying your #2 suggestion, first trying RUNAS with SANUR (a program to pipe passwords into RUNAS), but that didn't work at all for unknown reasons. We then found a substitute for RUNAS, CPAU.EXE, which lets you specify a password on the command line. This runs our build program properly, but the build program still hangs on the Solution.Open call when no one is logged on.

The command line to run the build program is similar to:

cpau -u account_x -p account_x_pwd -ex e:\build.exe parameters

When logged in under account x, this command line works properly from a shell prompt, and it works properly when run from the scheduler. But when no one is logged on, the same scheduler item it hangs as specified. If we change the build program settings to tell Studio to open a solution which has no source control bindings, it works without a problem.

Post by **jclausius** » Thu Aug 12, 2004 3:56 pm

Are you using the Task Scheduler to launch your build? If so, under what account is the Task Scheduler service running under? Is it Local System? Does the SYSTEM account (or whatever account the scheduler uses) have the Local security policy to Impersonate a Client after authentication?

Other than that, I'm running out of ideas here.

There is one last idea does come to mind. -
What if the Task Scheduler ran under the Windows account you were using to acess Vault?

I can safely say I have no idea if this would work. So proceed at your own risk. If you do look at this, you would need to grant that account some more Local Security Policy items so it can run as the Task Scheduler - "Logon as service, Logon Locally, Impersonate a Client after authentication, and anything else that looks relevant.

Additionally, I have no idea what that would do to any existing scheduled tasks.

Anyone else have ideas on this one?

Post by **jclausius** » Thu Aug 12, 2004 4:03 pm

If that doesn't work, perhaps we should look at this from the Vault end.

If you set your server into "Debug" logging mode through the Admin Tool, the sgvault.log file will be created with every call a Vault client makes to the server (including your build script). If a client "hangs", at least we can see what client calls made it to the server.

Additionally, if you've upgraded to Vault 2.0.5, you could also turn on client side logging as well. Perhaps something in the client log would let us know how far it got before the hang.