All future Autodesk Vault hotfixes will depend on the above SP's being installed. If logging a Support case, Autodesk will check that these are installed and require that they are installed before continuing any problem investigation.
Hotfixes for each release
Install these only if you are experiencing the issues described in the readme or wish to avoid future issues. If logging a Support case, Autodesk will check what hotfixes are installed and if the issue might be fixed by installing one or all of the later hotfixes. Autodesk will require that they are installed before continuing any problem investigation.
In Inventor 2014, trying to login to the Content Center using the "Content Center library read only user", you will get this message.
1) Create a Vault User account on the Vault Server with "Content Center Editor" role and with access to a Vault Database. Tell all users to use that account to log in to the CC Server. Note: if a licenced version of Vault is used for the CC Server, it will double the licence consumption. For this reason, use Vault Basic Serveras the CC server. It is possible to detach the CC libraries from a Vault Workgroup\Professional 2014 Server and attach them to a Vault Basic 2014 Server
2) Dont "use separate server for content and Vault". Attach the Libraries to the Vault Server.
Development are aware of this issue, but because there is a workaround, its planned to be addressed in a future release.
The new Autodesk Vault Thin Client 2014 has been completely redesigned to provide a superior experience when accessing a Vault through a web browser. The redesign includes Enhanced user interfaces, Customizable view functionalities, New BOM interface, and Enhanced report printing. See Autodesk Vault Thin Client 2014 for more information.
"Edited Out of Turn" Workflow Improvement:
In previous releases, we received feedback regarding unmanageable situations where Inventor recomputable updates were involved in creating Edited out of Turn files. With this subscription release, we address the situation by having the vault add-in reflect the last downloaded state with modifier information, and allowing the user to continue with his/her workflows following a save operation, like the following operations:
Check In – The system shall not include the files that are not checked out to the user (as per the current behavior).
Check Out – The system shall only allow files that are of the latest Revision (or newer version on local disk) to be checked out (as per the current behavior).
Revert to Latest in Inventor – The user has to continue using the Revert to Latest command if he/she does not have the latest Revision on disk (regardless of local disk modification) to check out the files.
Revit Integration Enhancements
Revit Project Information Property support: Vault now supports the Project Information properties of Revit models, which can be mapped to Vault UDPs and automatically imported which can then be used for easy searching and property editing in Vault.
Import from Vault: The new Import from Vault feature lets you import RVT, DWG and DWF files stored in the Vault into the current Revit project.
Load Group: The Revit add-in now supports loading Model groups, Detail groups, and Attached Detail groups from the Vault into the current project. This allows Revit users to select or exclude specific groups within a file.
New Lifecycle, Revisions, and Categories support: The Revit add-in now supports change state, revise file, and change category workflows, making it easier for you to manage this information about your design right from inside Revit. Enhanced tooltips show you state information for your files in Vault.
Shared Parameters support: Revit users can now point to a shared parameters file stored in the Vault, making it easier to activate shared parameters.
Improved Load Family From Vault workflows: Revit users can now load all of the family types in a selected family in one click, making it faster to retrieve all of the family types needed for a project. Additionally, the Load Family from Vault dialog makes it easier for users to find the family types used most often by defaulting to the last folder location from which a family type was loaded.
New Mapping User Interface on the Vault Options dialog: The Mapping tab on the Vault Options dialog has been enhanced to streamline common workflows.
New Login Interface and Connection Status: The Log in and Log out buttons on the Revit Vault ribbon have been combined to create a single toggle button. Users can view their connection status by hovering their mouse over the button.
Link more file types: You can now link DGN, SAT, and SKP files from the Vault.
Maintain Link to DWF: Previously when linking to a DWF or DWFx file, the link was read-only and users would have to manually check out DWF markups to modify them. Now if a user checks out a file that has a DWF link, the DWF file is automatically checked out as well. When the file is closed, the DWF link is automatically checked back into the vault.
If you have any thoughts, comments or queries on this, please log them via the Vault Discussion groups or log a Support case with Autodesk.
You notice that that under Build 188.8.131.52 you see "Update 2"
This should read "Update 1"
Its minor, but possibly confusing. The build number indicates the installed versio. Autodesk development are not currently intending to address this. However, it will be addressed if the opportunity arises in another update\fix.
Error: Soap Exception ( mesg-id = 635071590603372501 ) Exception: RestrictionsOccurred  Stacktrace: Server stack trace: at Connectivity.Product.BusinessLogic.ItemBL.CheckRestrictionsByItemIterationIds(ProductRestrictionCodes restrictionCodes, Int64 itemIterationIds) at Connectivity.Product.BusinessLogic.ItemBL.EditItemRevisionInternal(Int64 itemRevId, Boolean bypassWIPRestriction, String comment) at System.Runtime.Remoting.Messaging.Message.Dispatch(Object target) at System.Runtime.Remoting.Messaging.StackBuilderSink.SyncProcessMessage(IMessage msg)
Exception rethrown at : at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg) at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type) at Connectivity.Product.Services.ItemService.EditItemRevision(Int64 itemRevId) at Connectivity.Web.Services.v18.ItemService.EditItem(Int64 itemRevisionId) at SyncInvokeEditItem(Object , Object , Object ) at System.ServiceModel.Dispatcher.SyncMethodInvoker.Invoke(Object instance, Object inputs, Object& outputs) at System.ServiceModel.Dispatcher.DispatchOperationRuntime.InvokeBegin(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage5(MessageRpc& rpc) at System.ServiceModel.Dispatcher.ImmutableDispatchRuntime.ProcessMessage31(MessageRpc& rpc) at System.ServiceModel.Dispatcher.MessageRpc.Process(Boolean isOperationContextSet)
The client can see this:-
"Operation cannot be performed because the item is locked for edit by user ‘<vaultusername>’."
In this situation, it occured whilst a user was editing an Item, but the Connectivity.VaultPro.exe was killed in Task Manager to simulate a client crash mid-way through editing the Item. The error in the vlog is generic. When the Vault client was restarted, Right clicking on the Item and selecting Edit resulted in the above message in the User Interface and the entry in the vlog.
In this situation you would need to wait 30 minutes before being able to edit the Item. The reason this locktime is enforced is because when an Item is edited, it needs to be temporarily locked to allow the user time to complete their task without the risk of another user overriding their edits. Without this lock, it would be possible that a user might start editing the Item, get distracted and then continue editing it, but when they finish editing it, another user may also have tried editing that Item. At this stage Vault could either overwrite the second users edits or display an error saying that the Item has changed. This would lead to confusion. So to prevent this from happening, if an Item is edited, it is locked until either the user cancels their edit or completes it.
I managed to reproduce this by editing an Item, then killing the process in Task Manager, mid-edit. Similar to a crash, the server would have had no message sent to it that the user has either canceled or completed their task. It assumes therefore that the user is still editing, until the 30 minute lockout expires.