Shadow folders does not work after upgrade to Vault 4.1.2

davenovak · Post by **davenovak** » Wed Jun 18, 2008 10:31 pm

I'm actually upgrading from Vault 3.5.2 to Vault 4.1.2.18185. After selecting a repository, I click on the Shadow Folders link and receive the following error:

Code: Select all

Server did not recognize the value of HTTP Header SOAPAction: http://www.sourcegear.com/schemas/vault/TestServerConnection.

Yet the Shadow Folders service appears to be running (I can access http://localhost/VaultShadowFolder/Vaul ... rvice.asmx just fine at least). Neither the Vault log (in debug mode) nor the Shadow folder log contain any errors in them.

I hope this is an easy configuration fix as the Shadow folders feature is essential for our migration to 4.1.2.

Thanks,

--Dave

Post by **jeremy_sg** » Thu Jun 19, 2008 10:33 am

If you look at the VaultShadowFolderService.asmx file in a web browser, do you see the TestServerConnection method? Can you click on it and hit the Invoke button?

davenovak · Post by **davenovak** » Thu Jun 19, 2008 10:38 am

Yes -- that works just fine. Here's the server reply:

Code: Select all

  <?xml version="1.0" encoding="utf-8" ?> 
  <boolean xmlns="http://www.sourcegear.com/schemas/vault">true</boolean>

But yet the shadow folders link from admin site still does not work.

davenovak · Post by **davenovak** » Thu Jun 19, 2008 10:58 am

Just to give you more details, I installed Vault 4.1.2.18185 on a new machine which never had Vault on it. However, my Vault 3.5.2 sgvault database was on this machine during the install so that it would be converted.

Other than that, a fairly typical install.

Post by **jeremy_sg** » Thu Jun 19, 2008 10:59 am

Do you happen to have multiple web sites on your machine? Is it possible that the admin tool is finding the 3.5 shadow folder asmx on a site other than localhost?

Post by **jeremy_sg** » Thu Jun 19, 2008 11:01 am

Also, debug logging might help in this case. Set your log level to debug and check the Vault server log file.

davenovak · Post by **davenovak** » Thu Jun 19, 2008 11:03 am

No, this is the only web site on this machine. And older versions of Vault were never installed on this machine.

Also, as mentioned in the original post, I am already using Debug logging and no errors show up in the Vault log.

Post by **jeremy_sg** » Thu Jun 19, 2008 12:01 pm

My next question is: what do you get when you look at the tblplugins table in your sgvault database. It may have the URL to the old server.

davenovak · Post by **davenovak** » Thu Jun 19, 2008 12:16 pm

YES! That was indeed the problem.

In my tblplugins, there are two rows for the Vault Shadow Folder Service:

Code: Select all

http://rtgbuild.ddcinternal.com/VaultShadowFolder/VaultShadowFolderService.asmx
http://localhost/VaultShadowFolder/VaultShadowFolderService.asmx

After updating the first one to be localhost instead of rtgbuild.ddcinternal.com, Shadow Foders is now working.

So here's my next question: since shadow folders service always runs on the same machine as Vault service and the database is always on this same machine too, would a single http://localhost/VaultShadowFolder/Vaul ... rvice.asmx entry suffice? Can I delete the first row (that contained a reference to the old machine) or do I need to update the first row to be a reference to this machine (which is rtgbuild2.ddcinternal.com)? I just wasn't sure if this first row was how shadow folders service referenced stuff externally and the second was for internal, or if the two rows are needlessly redundant and the one can be deleted. Please advise.

Post by **jeremy_sg** » Thu Jun 19, 2008 12:29 pm

You should only need one localhost entry.

davenovak · Post by **davenovak** » Thu Jun 19, 2008 12:54 pm

It seems to work just fine with the one row in there that references localhost.

The mystery to me is how the other row got there in the first place (the one that referenced the old machine). Did Vault 3.5.2 put that there or was there some UI option where I entered that value? All I know is that I didn't specify that during this install.

I ask mainly because anybody moving to a new machine may run into the same issue and it would be good to know what all to look out for or change when moving the database to a new environement.

Thanks for your help resolving this issue.

Post by **jeremy_sg** » Thu Jun 19, 2008 12:57 pm

3.5 put that entry there. The main issue that you ran into was that your 3.5 server was still up. If it had been down, the request would have failed with a webexception, and we would have prompted you for the URL to find the shadow folder service.

davenovak · Post by **davenovak** » Thu Jun 19, 2008 1:00 pm

Indeed the old server is still running (as the new server right now is just a test environment, in preperation for the real migration this weekend). This all makes sense now.

Thanks again for your help with this!

davenovak · Post by **davenovak** » Fri Jun 20, 2008 10:44 am

One more related question:

The Web.config file under Inetpub\wwwroot\VaultService\VaultShadowFolder contains a key called shadowfolder_vaultserver that is currently set to value="http://rtgbuild2.ddcinternal.com/VaultService" (Vault machine name). Since both the shadow folder service and the vault service run on the same machine, can this be changed to be simply "http://localhost/VaultService"?

I'd prefer killing any and all hard-coded machine names if possible.

Post by **jeremy_sg** » Fri Jun 20, 2008 10:48 am

Yes, you should fix that as well. The reason we avoid localhost is that there are lots of customers who install Vault on a server with multiple web sites.