During The First Steps into Darkness, I discussed a workaround for missing External Content Types. Once those are set up where they belong, the next section of the setup goes pretty smoothly. You set permissions for each of the three main areas of Vault Professional:
- Files
- Items
- Change Orders.
This makes it possible to create lists in SharePoint for each area of Vault.
The next step in the initial setup, is to configure the Vault login. This is a set of login credentials that will give SharePoint access to the Vault database. First things first, a Vault User must be created and given read only access in the Vault to the areas needed. The best advice is to make this a Vault only user, rather than a Domain user. Give the user access to any groups it may need, to access the appropriate Files and Items. At the very least, give them the Vault Change Order Editor (Level 1), Document Consumer and Item Reviewer Roles.
Once that user has been configured in Vault, follow the documentation instructions for configuring the Vault login. This is the login that gives SharePoint the right to access the Vault. The SharePoint Vault Settings screen should look like this:
- The Server field is the name of your Vault server, or it’s IP Address.
- The Database field is the name of the Vault you want access to.
- The User field is the username for the user you just created in Vault.
If you are setting the password for the first time, or changing it, select the Update Password checkbox. The pages section should be filled in already, pulling from the previous steps of the integration. At the bottom of the page are checkboxes for visualizations. All three are selected by default, but to maximize your search results I recommend leaving only the top one checked. This is up to your discretion.
I showed you this and described some of the steps found in the documentation, because it’s right here where I hit a massive brick wall. I even started having visions of myself sitting at home in my sweat pants, drinking coffee, unshaven, unwashed and looking through online job listings.
I entered all of the information just as you see it above, with the addition of the password, clicked the Save button and was greeted with the following message:
EXECUTE permission was denied on the object ‘proc_putobjectTVP’,database ‘SharePoint_Config’, schema ‘dbo’
Um,… what? This one went way over my head so I called in my IT support. After a bit of digging and searching, he was able to find an answer on the internet. The one good thing about error messages, is the chances are pretty good someone else has already seen it or something like it, and posted a fix online. This case was no different.
The object was slightly different, but the fix was the same… which was a good thing because we ran into two more of these after the fix was applied to the first one, like dominoes. This is an excerpt from the web article providing the steps to assign the necessary permissions for these objects. This fix is applied to the SharePoint Config database on your SQL Server.
Detailed Steps
In order to resolve the issue, I provided Execute permission to the database role “WSS Content_Application Pools” into the stored procedure “proc_putObject”. I performed the following steps to do this:
- In the database server, expand SharePoint Config database and navigate to Programmability/Stored Procedures/db0.proc_putObject using SQL Server Management Studio.
- Right click on the above stored procedure and select Properties.
- On the popup screen, select Permissions on the left and click Search button.
- On the new popup screen, click Search, select (WSS Content Application Pools) database role and click OK.
- Click OK again.
- On the first popup screen, select the role, check Execute permission and click OK
Once we fixed the first error, we also had to apply the same steps to the following procedures:
proc_putclass and proc_getnewobjects.
So, everything is all fine now, right? Not so fast. After these errors were overcome, a new one popped up that had everyone stumped, including the Vault development staff I spoke to. No one had seen this one before.
SharePoint 2013: Event ID 6398 An update conflict has occurred, and you must re-try this action
I think we stared at this message for about three days, trying everything we could come up with, before we once again found a blog post that was directly related to this error.
“Issue: (from Microsoft) This issue occurs if the contents of the file system cache on the front-end servers are newer than the contents of the configuration database. After you perform a system recovery, you may have to manually clear the file system cache on the local server.”
This fix is performed on the SharePoint server. The file system cache will rebuild itself after it has been cleared, with no damage to anything else within the site. So, since this was still in the test environment we just pulled the trigger and cleared the cache as outlined in the blog post. I re-entered the login credentials… again…. and hit the save button. To an audible sigh of relief the message we received was: Your changes have been saved! We were in. Our SharePoint tenant was now talking to our Vault. Now we just had to decide what we wanted it to say!
Searching, Listing and Filters
Image Credits: Powell Fabrication and Manufacturing inc and The National Guard (Flickr)
[subscribe2]
