Major problems using Vault on different machines

coderanger · Post by **coderanger** » Mon Mar 01, 2010 9:30 am

We have just got Vault v5.0.3 and myself and my colleague are in different locations, clearly on different machines as well.

We are using Visual Studio 2008 and the Enhanced Client.

Now if each of us checks in a project then the other gets binding errors and "Cannot locate project or working directory not set" which is utter rubbish. I have to check it out, overwrite my local project, locate the project again and all is well. Until my colleague 'gets' the project then he gets errors.

The thing that appears to be different is the SccLocalPath attribute in the vcproj file ... of course it will be different for different users and different machines:
My Colleaguess: SccLocalPath="2~e1ea6f62-3543-4243-afb2-4ce22711f3a0"
Mine: SccLocalPath="2~56a6f3be-778a-490b-b23c-b2e5a33b45a2"

This seems totally wrong, how can we get it to work for all of us together?

Beth · Post by **Beth** » Mon Mar 01, 2010 11:34 am

How did you add the project to Vault? Was it handed off from VSS, or added with the Vault GUI client, or added while in Visual Studio?

What type of project is it?

What does it's layout look like? Is the solution file at the top or are there parts that aren't beneath the solution? For example, when you were first adding it, was the layout on disk something like:
-----Solution folder
---------|---Solution File (.sln)
---------|---Project Folder
------------------|---project file (.proj)
------------------|---other project files or folders

coderanger · Post by **coderanger** » Mon Mar 01, 2010 12:06 pm

It was handed of from VSS and the Rebind Projects was run. I did try importing vss, but we realised the database was messed up as it screwed up a load of branched files and stuff; so we started at the beginning and used Handoff.

Our structure is:
$/Components/Reuse/reuse.vcproj
$/Components/XMLParser/XMLParser.vcproj
$/Components/Javascript/js.vcproj
...

$/Guide/Guide.sln
$/Guide/Guide.vcproj

Our Guide product solution has dependencies with reuse, xmlparser, js and a host of other reusable components sitting in $/Components

We have other product solutions that sit elsewhere in Vault which also reference these reusable components.

Beth · Post by **Beth** » Mon Mar 01, 2010 1:19 pm

The root cause of what you are seeing is most likely related to the layout you have. Here's a couple of ways to deal with it:

1) Instead of having all solutions point to the same project in the same location, you can share those projects in Vault, so that there is a copy beneath each solution. When one is updated in Vault, then all will update in Vault. After you bind to the shared copy, then other users can just perform an Open From Vault for the first time connecting, and then just use recent projects or open from disk every time after that.

2) Instead of using Open From Vault, all users will perform a Get from Vault, open the solution from disk, Ok through any warnings, then manually bind the project using Change Vault Bindings. After that they can open using recent projects or open from disk .

Our KB articles on the Enhanced Client may help explain further:
Visual Studio Enhanced Client FAQ
Welcome to the Vault/Fortress Visual Studio Enhanced Client

Specifically what you are running into is talked about in the FAQ at this post: http://support.sourcegear.com/viewtopic ... 672#p39065.

Give these suggestions a try and let me know if that helps.

Also, are all the solutions that reference those projects bound to the Enhanced Client? They will all need to use the same client to work properly.

coderanger · Post by **coderanger** » Mon Mar 01, 2010 1:27 pm

Yes they are all bound using the enhanced client.

1) Instead of having all solutions point to the same project in the same location, you can share those projects in Vault, so that there is a copy beneath each solution. When one is updated in Vault, then all will update in Vault. After you bind to the shared copy, then other users can just perform an Open From Vault for the first time connecting, and then just use recent projects or open from disk every time after that.

Only if they do/remember to do a full get for every shared project each and every time in all projects that depend on them. Its not automatic, its automatic on the server but not client side from my understanding.

I cant imagine sharing all the components into folders within each product is the right thing to do for the following reasons:
* Surely each vcproj will now point to the wrong place unless the vcproj cant be shared which is bad news for any sort of project change, cos now we need to update many, many copies everywhere
* Woudldnt it also mean you have multiple copies which need to be kept up to date on disk each time you build anything
* Wont this make the vault database much much bigger for no benefit

Generally though, sharing stuff multiple times all over the place seems very over the top just to change the structure into something Vault can handle. VSS never needed this.

Beth · Post by **Beth** » Mon Mar 01, 2010 5:04 pm

I know we currently have customers working in this fashion and I ran a short test on it as well. Shares don't make a copy of the history nor really of the file. It doesn't add significantly to the size. You do end up with multiple copies on your local disk though, but that's not a problem with most systems. When it's changed in one place, then in the other locations in Vault the status will change to Old to show that your version on disk is old. In Visual Studio you will see the icon change next to the file that is old, and when you hover over the file, you will be informed that it's out of date.

You don't necessarily have to go that route though. That's why I posted the additional option where the bindings are set manually. Users only need to do that once for each solution.

coderanger · Post by **coderanger** » Tue Mar 02, 2010 2:11 am

As I guessed, your second solution doesnt work. Exactly the same change is made to the SccLocalPath, Vault updates the project file with specific GUID for my machine, when my colleagues open the project its now broken for them and we are in the same situation over again. What is that GUID anyway, what does it represent and why is it different?

I really still cant understand why its like this, we all have the same folder structure on disk, the root is set to a different place, but ALL sub-projects are inherited from that location; the component projects included in the main production solution just have to go back down and then up the tree so the example used in the FAQ isnt the same.
Joe sets "$" working directory to c:\projects
Dan sets "$" working directory to d:\projectsgm

Guide solution is in "$/Guide/Guide.sln"
Components are in "$/Components/Reuse/reuse.vcproj"

Guide opens up and goes "../../Compoenents/reuse/reuse.vcproj" ... this will be the same for Joe and Dan and ALL setups regardless of where they have set their root working directory; the only time your example should highlight a problem is if they set "Components" to a different working directory like "MyComponents" and in this case they are daft and should be made to stand in the corner.

As I mentioned above; I still dont understand the share solution either (its a massive change just to see if it might work, breaking all manner of things); but wouldnt it make the same change to the SccLocalPath in the shared project so when I get that project which is now shared in a different product it will be broken as it was set for the original location in the first project; updating the project binding will now break it in the first shared project and all we have done is multiplied the same fault x-fold.

Of course, if I knew what the SccLocalPath GUID represented them my assumption might be false.

Russ Freeman · Post by **Russ Freeman** » Tue Mar 02, 2010 4:14 am

A solution based on changing your entire source structure is no solution at all. We have similar problems and similar project stucture and it would be near impossible to change this. Also, we have literally 100's of projects under source control that use these shared components and sharing them beneach each project every time you wanted to use one would be a massive waste of effort.

What's needed is a fix for this bug, not work arounds.

coderanger · Post by **coderanger** » Wed Mar 03, 2010 10:14 am

Hiya Beth, do you have any more news on this issue?

Beth · Post by **Beth** » Wed Mar 03, 2010 11:07 am

I'm working on a response.

Just to make sure everything was covered, can you tell me if you used the Rebind Projects function in the admin web page on these projects?

coderanger · Post by **coderanger** » Wed Mar 03, 2010 11:19 am

Yes I did, and I had to bind again when openining solutions.

To be clear our structure is this:
$/Components/ ... lots of reusable things like xml parsers and stuff

Then we have products at a root level or below
$/Utility/ ... internal utilities

$/Guide ... one of our main products and stuff

Everyone sets the root "$" to a "Projects" folder on whichever drive they use (c or d) and everything below is inherited

So there should be no problems traversing the tree, just down one and back up to components ... no problems at all. VSS had no issues with this, Visual Studio has none; Vault should not either.

Thanks Beth.

Beth · Post by **Beth** » Wed Mar 03, 2010 6:01 pm

Do all your .sln files have SccLocalPath in them? I don't see them in my solutions that use the Enhanced Client. It could be a case of where some project is still pointing to the classic client. Was this solution bound to something else prior to this? Are you and your colleague both setting the VS Tools - Options - Source Control to the Enhanced Client?

Vault can work with this tree structure. The first option I suggested, because it tends to be the easiest for customers to work with. Working with different layouts can affect how your users need to open their projects in some cases. Some projects react a little differently than others as well.

What will make a difference is the project relationships within the .sln file. In the .sln should be relative paths. Those same relative paths must exist both in the working folders and within the repository. For instance, if a solution has a project that is ..\..\..\ProjectB, then ProjectB.xyproj file better be in that SAME relative path within the repository as well as on disk.

I put together a document that shows both methods of working with projects outside a solution and have it attached. I think though that something is still pointing to the Classic Client if it was ever set to that or if this came from VSS.

coderanger · Post by **coderanger** » Thu Mar 04, 2010 1:22 am

Part 2 of your doc is what we want, but it doesnt work; we have all this SccLocalPath stuff in the project which is different on each machine so it always says the bindings are broken and we have to rebind each and every time a different user tries to open the main solution.

Also, nothing is pointing to classic client, nothing was ever pointing to it ... we did use VSS before and then did a handoff, chose Bind Projects in Admin and that was that. We set the Enhanced client in both our VIsual Studios yet this SccLocalPath is set in all projects (.vcproj) all the time. I have tried deleting it and Vault puts it straight back. I have not looked at solution files as solution files arent opened for each of the reusable component projects that are included in the main solution as dependancies.

Here is the info in one of our project files (it has no solution as its only ever 'included' into other products):

Code: Select all

<VisualStudioProject
	ProjectType="Visual C++"
	Version="9.00"
	Name="js"
	ProjectGUID="{4F1C93DA-60FE-4F99-9C9E-7EF7447689B8}"
	SccProjectName="js"
	SccAuxPath="http://vault.gipsymedia.com:8090/VaultService"
	SccLocalPath="2~e1ea6f62-3543-4243-afb2-4ce22711f3a0"
	SccProvider="SourceGear Vault Visual Studio 2005 Client:{1EA47954-8515-402d-82D9-B5C332120A8D}"
	TargetFrameworkVersion="0"
	>

Our product solution is (note all the relative paths):

Code: Select all

Microsoft Visual Studio Solution File, Format Version 10.00
# Visual Studio 2008
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "DataSource", "..\components\datasource\DataSource.vcproj", "{20811AD5-E3EA-4BD7-BC81-98303BA9FA91}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "DebugHlp", "..\components\debughlp\DebugHlp.vcproj", "{03AC29B5-4CA6-4CA6-8BA8-82B462547A24}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "DigiGuide", "DigiGuide\DigiGuide.vcproj", "{A242166E-BB63-4309-99F9-164EFFCBCB9A}"
	ProjectSection(ProjectDependencies) = postProject
		{8B485AF7-DE5B-4A28-8800-06768D3A452E} = {8B485AF7-DE5B-4A28-8800-06768D3A452E}
	EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "DigiGuide_dll", "DigiGuide_dll.vcproj", "{8B485AF7-DE5B-4A28-8800-06768D3A452E}"
	ProjectSection(ProjectDependencies) = postProject
		{70EB1800-011D-4C19-9F00-F6F96A56F10E} = {70EB1800-011D-4C19-9F00-F6F96A56F10E}
		{ED95E431-430C-4753-BEAA-2373BC9AF949} = {ED95E431-430C-4753-BEAA-2373BC9AF949}
		{49710E45-C4C4-4BF4-AE01-79EF470D48BA} = {49710E45-C4C4-4BF4-AE01-79EF470D48BA}
		{CF52666E-0C9B-48C1-A3DF-30CC958C14C7} = {CF52666E-0C9B-48C1-A3DF-30CC958C14C7}
		{03AC29B5-4CA6-4CA6-8BA8-82B462547A24} = {03AC29B5-4CA6-4CA6-8BA8-82B462547A24}
		{31191FCF-9A1E-4A90-972D-7B1910881D66} = {31191FCF-9A1E-4A90-972D-7B1910881D66}
		{A12BA3D2-7CB7-488F-B87C-832822FBF769} = {A12BA3D2-7CB7-488F-B87C-832822FBF769}
		{20811AD5-E3EA-4BD7-BC81-98303BA9FA91} = {20811AD5-E3EA-4BD7-BC81-98303BA9FA91}
		{4F1C93DA-60FE-4F99-9C9E-7EF7447689B8} = {4F1C93DA-60FE-4F99-9C9E-7EF7447689B8}
		{FF419AE1-DFD0-4463-962E-1A7EE9DAE555} = {FF419AE1-DFD0-4463-962E-1A7EE9DAE555}
		{528C3DE3-9F41-40A5-8076-927BFD17C4FD} = {528C3DE3-9F41-40A5-8076-927BFD17C4FD}
	EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ImgLib", "..\components\imglib\ImgLib.vcproj", "{FF419AE1-DFD0-4463-962E-1A7EE9DAE555}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Network", "..\components\network\Network.vcproj", "{49710E45-C4C4-4BF4-AE01-79EF470D48BA}"
	ProjectSection(ProjectDependencies) = postProject
		{ED95E431-430C-4753-BEAA-2373BC9AF949} = {ED95E431-430C-4753-BEAA-2373BC9AF949}
		{03AC29B5-4CA6-4CA6-8BA8-82B462547A24} = {03AC29B5-4CA6-4CA6-8BA8-82B462547A24}
		{57315FC9-3790-49AF-8B2E-DD9A5A8E635F} = {57315FC9-3790-49AF-8B2E-DD9A5A8E635F}
	EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Reuse", "..\Components\reuse\reuse.vcproj", "{ED95E431-430C-4753-BEAA-2373BC9AF949}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "Static library version", "..\components\gsmessagebox\static library version\Static library version.vcproj", "{A12BA3D2-7CB7-488F-B87C-832822FBF769}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ZLib", "..\Components\zlib\ZLib.vcproj", "{70EB1800-011D-4C19-9F00-F6F96A56F10E}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "icalexport", "ADDINS\icalexport\icalexport.vcproj", "{7CA159E3-4953-4DD8-BFB0-59B93209C43E}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "jpeglib", "..\components\jpeg-6b\jpeglib.vcproj", "{CF52666E-0C9B-48C1-A3DF-30CC958C14C7}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "js", "..\Components\javascript\js.vcproj", "{4F1C93DA-60FE-4F99-9C9E-7EF7447689B8}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "libcurl", "..\components\libcurl\libcurl.vcproj", "{57315FC9-3790-49AF-8B2E-DD9A5A8E635F}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "lpng103", "..\components\lpng103\lpng103.vcproj", "{31191FCF-9A1E-4A90-972D-7B1910881D66}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "xmlparser", "..\Components\xmlparser\xmlparser.vcproj", "{A78FF163-6D9B-4380-8901-7055A2F06616}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "GMXML", "..\Components\GMXML\GMXML.vcproj", "{C1B3262B-BD64-4FF4-B986-7045A2CEF046}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "ClientLoader", "ClientLoader\ClientLoader.vcproj", "{E8E73AEC-9E7E-4DF8-A9B5-C861404FD982}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "DigiGuide Crash Reporter", "DigiGuide Crash Reporter\DigiGuide Crash Reporter.vcproj", "{8C4F8DA7-CEAA-40E6-B7E4-CC5CC545718A}"
	ProjectSection(ProjectDependencies) = postProject
		{70EB1800-011D-4C19-9F00-F6F96A56F10E} = {70EB1800-011D-4C19-9F00-F6F96A56F10E}
		{C1B3262B-BD64-4FF4-B986-7045A2CEF046} = {C1B3262B-BD64-4FF4-B986-7045A2CEF046}
		{ED95E431-430C-4753-BEAA-2373BC9AF949} = {ED95E431-430C-4753-BEAA-2373BC9AF949}
		{49710E45-C4C4-4BF4-AE01-79EF470D48BA} = {49710E45-C4C4-4BF4-AE01-79EF470D48BA}
	EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "listings_data_downloader", "listings_data_downloader\listings_data_downloader.vcproj", "{B817227E-24A6-467C-B21C-2F80F0727360}"
	ProjectSection(ProjectDependencies) = postProject
		{70EB1800-011D-4C19-9F00-F6F96A56F10E} = {70EB1800-011D-4C19-9F00-F6F96A56F10E}
		{ED95E431-430C-4753-BEAA-2373BC9AF949} = {ED95E431-430C-4753-BEAA-2373BC9AF949}
		{0FA9058E-B907-4CAD-B348-6900563DF2C6} = {0FA9058E-B907-4CAD-B348-6900563DF2C6}
		{528C3DE3-9F41-40A5-8076-927BFD17C4FD} = {528C3DE3-9F41-40A5-8076-927BFD17C4FD}
	EndProjectSection
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "listings", "..\components\listings\listings.vcproj", "{0FA9058E-B907-4CAD-B348-6900563DF2C6}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "PCRE", "..\Components\PCRE\PCRE.vcproj", "{528C3DE3-9F41-40A5-8076-927BFD17C4FD}"
EndProject
Project("{8BC9CEB8-8B4A-11D0-8D11-00A0C91BC942}") = "LogLib", "..\Components\loglib\loglib.vcproj", "{620403C7-1365-4202-833C-C75D55C4FC21}"
EndProject
Global
	GlobalSection(DPCodeReviewSolutionGUID) = preSolution
		DPCodeReviewSolutionGUID = {00000000-0000-0000-0000-000000000000}
	EndGlobalSection
	GlobalSection(VaultVsipSolution-v2) = preSolution
		VaultHost = http://vault.gipsymedia.com:8090/VaultService
		VaultRepositoryID = 2
		VaultRepositoryGUID = 56a6f3be-778a-490b-b23c-b2e5a33b45a2
		ProjectCount = 22
		ProjectRelativeDiskPath1 = ..\components\datasource\DataSource.vcproj
		ProjectRelativeDiskPath2 = ..\components\debughlp\DebugHlp.vcproj
		ProjectRelativeDiskPath3 = DigiGuide\DigiGuide.vcproj
		ProjectRelativeDiskPath4 = DigiGuide_dll.vcproj
		ProjectRelativeDiskPath5 = ..\components\imglib\ImgLib.vcproj
		ProjectRelativeDiskPath6 = ..\components\network\Network.vcproj
		ProjectRelativeDiskPath7 = ..\components\reuse\reuse.vcproj
		ProjectRelativeDiskPath8 = ..\components\gsmessagebox\static library version\Static library version.vcproj
		ProjectRelativeDiskPath9 = ..\components\zlib\ZLib.vcproj
		ProjectRelativeDiskPath10 = ADDINS\icalexport\icalexport.vcproj
		ProjectRelativeDiskPath11 = ..\components\jpeg-6b\jpeglib.vcproj
		ProjectRelativeDiskPath12 = ..\components\javascript\js.vcproj
		ProjectRelativeDiskPath13 = ..\components\libcurl\libcurl.vcproj
		ProjectRelativeDiskPath14 = ..\components\lpng103\lpng103.vcproj
		ProjectRelativeDiskPath15 = ..\components\xmlparser\xmlparser.vcproj
		ProjectRelativeDiskPath16 = ..\components\GMXML\GMXML.vcproj
		ProjectRelativeDiskPath17 = ClientLoader\ClientLoader.vcproj
		ProjectRelativeDiskPath18 = DigiGuide Crash Reporter\DigiGuide Crash Reporter.vcproj
		ProjectRelativeDiskPath19 = listings_data_downloader\listings_data_downloader.vcproj
		ProjectRelativeDiskPath20 = ..\components\listings\listings.vcproj
		ProjectRelativeDiskPath21 = ..\components\PCRE\PCRE.vcproj
		ProjectRelativeDiskPath22 = ..\Components\loglib\loglib.vcproj
	EndGlobalSection
	GlobalSection(SolutionConfigurationPlatforms) = preSolution
		Debug UNICODE|Win32 = Debug UNICODE|Win32
		Debug UNICODE|x64 = Debug UNICODE|x64
		Debug|Win32 = Debug|Win32
		Debug|x64 = Debug|x64
		Release UNICODE|Win32 = Release UNICODE|Win32
		Release UNICODE|x64 = Release UNICODE|x64
		Release|Win32 = Release|Win32
		Release|x64 = Release|x64
	EndGlobalSection
	GlobalSection(ProjectConfigurationPlatforms) = postSolution
		{20811AD5-E3EA-4BD7-BC81-98303BA9FA91}.Debug UNICODE|Win32.ActiveCfg = Debug Unicode|Win32
		{20811AD5-E3EA-4BD7-BC81-98303BA9FA91}.Debug UNICODE|Win32.Build.0 = Debug Unicode|Win32
		{20811AD5-E3EA-4BD7-BC81-98303BA9FA91}.Debug UNICODE|x64.ActiveCfg = Debug Unicode|x64
		{20811AD5-E3EA-4BD7-BC81-98303BA9FA91}.Debug UNICODE|x64.Build.0 = Debug Unicode|x64
.... lots more of these ....
	EndGlobalSection
	GlobalSection(SolutionProperties) = preSolution
		HideSolutionNode = FALSE
	EndGlobalSection
EndGlobal

If I delete all the "Scc" attributes, the project will not be bound; if I bind it, then ALL values are added back.

Don't know how you get your SccLocalPath not to be output but I cannot reproduce that at all, Vault ALWAYS adds it and adds it wrong. Perhaps you are running a fixed version of Vault?

I might try and setup a test machine that has an empty Vault repository and create two new projects in a similar structure to show this problem for you to see as I am finding it hard to understand why you cant reproduce it.

Beth · Post by **Beth** » Thu Mar 04, 2010 8:32 am

If you would like I could take a closer look. Could you send an email to support at sourcegear.com (attn: Beth) with a link to this forum thread?

coderanger · Post by **coderanger** » Thu Mar 04, 2010 8:50 am

Thanks Beth. In trying to reproduce the problem I created a brand new repository and created brand new projects and solutions and it all worked as expected.

Once I did this I noticed in the project a very slight difference; in our repository (taken from a VSS Handoff) I noticed that there were files ending ".vspscc" and ".vssscc" for the projects and solutions. I remember these files being included when we upgraded from VC6 to VS2008, I deleted them from Vault and from the hard disk, and after going through all the warnings and rebinding I found that it then worked on the 3 different machines and folder structures I tested it on.

So the problem is basically due to the conversion from VSS still having files in source control that cause Vault problems. Another vote to get that exclusion thing working on the client I think; and, more importantly, files the VSS Handoff should not move over to Vault.

Anyway, when my colleague comes back Monday, I will get him going and hopefully prove that this solution worked. Fingers crossed!

SourceGear Support

Major problems using Vault on different machines

Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines

Re: Major problems using Vault on different machines