Configuration problems upgrading from Vault 5.0

[ThomasC]

I upgraded from Vault 5 to Vault 6.1 recently. The upgrade did not go smoothly and I was forced to mess around with various config files and IIS configurations to get it to work. However, I cannot get Find in Files to work and I don't know if Shadow folders is working.

When I navigate to <repository>/Find In Files and set it to "On", I get the error: "Object moved to here" where the url points to [url]https://<host>/VaultService/VaultIndexService/VaultWeb/Login.aspx?ReturnUrl=%2fVaultService%2fVaultIndexService%2fVaultIndexService.asmx[/url]. The VaultIndexService folder does not contain a subfolder nor vdir for VaultWeb; only VaultService (so one folder up) has a subfolder for VaultWeb.

When I navigate to <repository>/Shadow Folders, I get the error: "The server could not reach the Shadow Folder Service" and the url is [url]https://<host>/VaultService/VaultShadowFolder/VaultShadowFolderService.asmx[/url]. When I try to navigate to this ulr, I get a "resource not found" with the url /VaultService/VaultShadowFolder/VaultWeb/Login.aspx which again does not exist under the VaultShadowFolder virtual directory; it only exists under the VaultService subfolder one folder up.

Is there some documentation as to the official IIS (in our case IIS 7.5 via Win2k8 R2) configuration? For example, under the SourceGear site, I had to ensure that the following folders under VaultService were all converted to be applications: VaultIndexService, VaultNotifyService, and VaultShadowFolder. The installer did not do this for us. I also had to reconfigure the plug-ins to be [url]https://<host>/VaultService/<appname>/<appname>.asmx[/url]. For example, [url]https://<host>/VaultService/VaultIndexService/VaultIndexService.asmx[/url].

I have noticed in a couple of posts and places on the site the use of [url]http://<host>:443/...[/url] This format does not work even though the use of [url]https://<host>/...[/url] does work (meaning I can get to the web service's landing page).

I also had to go into a bunch of config files and reconfigure the <impersonate> tag with the proper credentials. In our case, our site is running under a domain account. Why the excessive use of the <impersonate> tag? In IIS 7.5, you shouldn't it be the case that you can simply reconfigure IIS to use the ApplicationPool's identity and not be required to store the credentials in a bunch of configuration files?

[lbauer]

We have developed a configuraton guide for the plugins:

http://support.sourcegear.com/viewtopic ... 13&t=21347

Also, Vault 6.1 has a convenient Plugins Configuration Manager in the Vault Admin Web Client.

After reviewing the guide, let us know what issues you are still encountering.

[ThomasC]

1. From Server Settings -> Vault Standard Plugins, I have already reconfigured all three to be [url]https://<host>/VaultService/<appname>/<appname>.asmx[/url]. Running the Test link on all three correctly produces the given service's manifest screen.

2. I have confirmed that the vault_server element in the web.config file for the VaultindexService and the VaultNotification service has been set correctly.

3. I have confirmed that the shadowfolder_vaultserver element in the web.config file for the VaultShadowFolder has been set correctly.

4. I restarted IIS via iisreset after making these changes.
---

1. When I navigate to Source Control Repositories -> <repository name> -> Shadow Folders, it still shows the error "The server could not reach the Shadow Folder Service.". If I copy and paste the url into a browser window, I do correctly get the manifest screen.

2. When I navigate to Source Control Repositories -> <repository name> -> Find in Files, if I set it to "On" and hit save I get "An error occurred updating the Find in Files for some of the repositories. The request failed with the error message: -- Object moved to here" with the following link: [url]https://<host>/VaultService/VaultIndexService/VaultWeb/Login.aspx?ReturnUrl=%2fVaultService%2fVaultIndexService%2fVaultIndexService.asmx[/url]. While the host is now correct, the folder "VaultWeb" does not exist under the folder VaultIndexService.

3. The last entry in %WINDIR%\Temp\SGVaultIndex\vaultindexservice.txt is:
12/4/2012 3:04:00 PM <generic>: SimpleLogger finalized
12/4/2012 3:04:48 PM <generic>: GetEntryAssembly() returned null; not logging assembly name
12/4/2012 3:04:48 PM <generic>: SourceGear Index Service started.

4. The last entry in %WINDIR%\Temp\SGVaultNotify\vaultnotifyservice.txt is:
12/4/2012 3:04:00 PM <generic>: SimpleLogger finalized
12/4/2012 3:04:20 PM <generic>: GetEntryAssembly() returned null; not logging assembly name
12/4/2012 3:04:20 PM <generic>: SourceGear Notification Service started.

What about the IIS settings? Is it the case that /VaultService, /VaultService/VaultIndexService, /VaultService/VaultNotifyService and /VaultService/VaultShadowFolder are all supposed to be applications in IIS?

[lbauer]

Looks like there are still configuration issues.

Is it the case that /VaultService, /VaultService/VaultIndexService, /VaultService/VaultNotifyService and /VaultService/VaultShadowFolder are all supposed to be applications in IIS?

The plugins are applications in IIS, in line with Vault Service. See my screenshot of IIS 7.5 with Vault 6 installed.

What OS/version of IIS is Vault Server installed on?

Did you log into Windows with Administrator priviledges when you installed?

[lbauer]

Based on the configuration issues you are encountering, it might be a good idea to start over. It looked like the Vault installer did not have adequate permissions to create the proper virtual directories, etc.

Uninstall, and this time run the installer from a command prompt as Administrator.

To run Command Prompt as Adminstrator, on Windows 2008 R2, click the Start button and type "cmd" in the search box. You should see "cmd.exe" listed in the search results. Right click on cmd.exe and select "Run as Administrator."

Then cd to the Vault .msi directory and type the name of the installer and hit return. The installer will run as Administrator.

If you'd like me to assist with the installation, we can schedule a remote assist session. Email me at support at sourcegear.com, ATTN: Linda.

Please include a link to this forum post.

[lbauer]

Note when you uninstall, choose to keep the databases when prompted. They have all your Vault source code, user info, etc.

Then when you install, also choose to keep the databases.

Make sure you have a good backup of your databases before any uninstall or reinstall.

[ThomasC]

I finally got around to working out the issues on the upgrade and will layout the issues. The problem is that the installer had two bugs.

The first is that on install it sets the path of the plug-ins incorrectly. The installer is currently setting the url paths to be <protocol>://<host>/VaultService/<plugin name>/<plugin name>.asmx. For example, the server url for the index service came out as: [url]https://<host>/VaultService/VaultIndexService/VaultIndexService.asmx[/url]. The correct url is [url]https://<host>/VaultIndexService/VaultIndexService.asmx[/url]. All three urls had to be updated.

The second bug is that in the web.config file for the VaultIndexService and the VaultNotifyService. Both config files have a "vault_server" key that does not get set correctly and must be manually updated. In both cases, the installer wanted to use 127.0.0.1 which does work if you are segmenting traffic on the IIS server by host. The obvious solution to this issue would be to adjust the installer to ask for the host (and protocol) that will be used to access the Vault server. Asking for the site isn't enough.

Another item that should be mentioned is that if you install SourceGear on a web server with other sites, you should setup the site you wish to use *before* doing the installation. In addition, I recommend making that site run under an application pool configured with the same credentials as will be used by virtual applications setup by the installer. I.e., if you are going to run the site under a specific user account, then configure the site itself and its application pool to run under that same account.

I would also suggest adjusting the installer so that it installs in the Program Files folder by default and adjusting the folder permissions when the IIS sites are created instead of asking where you want the site root (which is actually installation folder). It isn't obvious in the installer that when you are picking the site root you are really picking where all the installation files will be placed.

[lbauer]

Creating all the proper options in the installer has become more challenging over time, with all the many operating systems and specific configurations of user environments. We do make some assumptions (like using "localhost" for the plugins), which may not work in some environments.

We do have a detailed plugin configuration guide and a configuration manager in the Vault Admin Web Client when the assumed settings don't fit.

http://support.sourcegear.com/viewtopic ... 13&t=21347

I'm not sure about installing in Program Files, since Vault is a web site in IIS. It is possible to change the installation location during the install, if you click the Custom button, then use the browse button to browse to the directory of your choice.

We do appreciate your feedback and will use your suggestions as we try to make the installation more user friendly.