Cannot run Vault with custom service account.
Moderator: SourceGear
Cannot run Vault with custom service account.
I am trying to configure Shadow Folders. These folders will reside on a SAN on the network. I cannot configure Vault to run with a custom service account succesfully. I have followed the instructions provided in this article linked in the help file:
http://support.sourcegear.com/viewtopic.php?t=188
I have configured a Vault application pool on Windows 2003 and IIS 6 and have configured the Vault related sites to use it. Whenever I change this app pool to run under a custom account I get errors when trying to login. If I change back to network service account no troubles. I have attached an image of the dialog. The error is:
"File or assembly name bv1oazm_.dll, or one of it dependencies, was not found."
The DLL name changes each time the error is produced. I have search the server for the DLL name specified and can never find it. Other names that have popped up are: fbgx6hdp.dll, c7xwhtwh.dll, nafafbkl.dll, d7njwvme.dll, and hipjneri.dll. I guessing these DLLs are generating each time such as in the temporary ASP.NET folder beneath the .NET framework root directory.
Any tips appreciated.
Thanks,
Sam
http://support.sourcegear.com/viewtopic.php?t=188
I have configured a Vault application pool on Windows 2003 and IIS 6 and have configured the Vault related sites to use it. Whenever I change this app pool to run under a custom account I get errors when trying to login. If I change back to network service account no troubles. I have attached an image of the dialog. The error is:
"File or assembly name bv1oazm_.dll, or one of it dependencies, was not found."
The DLL name changes each time the error is produced. I have search the server for the DLL name specified and can never find it. Other names that have popped up are: fbgx6hdp.dll, c7xwhtwh.dll, nafafbkl.dll, d7njwvme.dll, and hipjneri.dll. I guessing these DLLs are generating each time such as in the temporary ASP.NET folder beneath the .NET framework root directory.
Any tips appreciated.
Thanks,
Sam
- Attachments
-
- Error that pops up whenever I try logging in with the Vault client and the Vault service is using a custom service account.
- VaultError.JPG (20.47 KiB) Viewed 7620 times
The article that you're referencing doesn't mention it, but Sourcegear has provided a tool to set the impersonation called IdentitySwitcher to help with setting up a custom account. It is recommended that you use that to set impersonation. I'll update the article to make sure that it references the tool.
Recent server installers (past 3.0.4, I think) create all of the application pools for you.
Recent server installers (past 3.0.4, I think) create all of the application pools for you.
IndentitySwitcher didn't work.
I downloaded and ran the IdentitySwitcher utility. I did get an Exception running it stating that the user was already in the local group, so I figured that was fine.
No change in behavior. As soon as I change the identity of the App Pool to VaultService, the name I used with the IdentitySwitcher, I receive the cannot find DLL error again.
Any other suggestions?
Thanks,
Sam
No change in behavior. As soon as I change the identity of the App Pool to VaultService, the name I used with the IdentitySwitcher, I receive the cannot find DLL error again.
Any other suggestions?
Thanks,
Sam
Sam,
Check out this post for a couple more hints.
http://support.sourcegear.com/viewtopic ... 3511#13511
Check out this post for a couple more hints.
http://support.sourcegear.com/viewtopic ... 3511#13511
Permission on C:\windows\temp worked.
I tried both suggestions mentioned in the link 1) reregistering asp.net with aspnet_regiis.exe and 2) installing the Vault server again, but neither did the trick. I was able to resolve the problem by using the FileMon utility (http://www.sysinternals.com/ntw2k/source/filemon.shtml) to monitor which directory was being accessed. It turned out that the C:\Windows\Temp directory was the culprit. I granted rights to the Vault service account - I copied the rights granted to the Network Service account and all is well.
Thanks,
Sam
Thanks,
Sam
It's the working directory that needs rights.
I don't think it's the C:\windows\temp directory in all cases, but it's the Working Directory configured in the Admin tool. In my case, I accepted the default setting which was %SYSTEMROOT%\Temp. So it might be the Working Directory that needs to have rights set.
Thanks,
Sam
Thanks,
Sam