We're using full SQL replication and as far as I know, the document numbering schemes are having no issues with being used across multi-sites so on face value, I can't see why the Item numbering schemes should.
Technically speaking again, I get the 'if a workgroup goes down' theory but to be honest if a business is large enough to justify having multi-site replication, it'll be sitting on a pretty good IT infrastructure so although you can never say never, it's a rare occurence for a site to compeletely go down. However, item's being created is an event that occurs multiple times, hundreds of times per day.
In addition to that, I worked in the reseller channel for nearly a decade and this was never publicised by Autodesk, I had no idea that we needed to consider this when building multi-site implementations. A Google search for "autodesk vault item number replication" returns zero information on this and confirms that I haven't missed an technical publications on this story.
The concept of having a numbering scheme per site isn't a practical one, if you allowed the option of defaulting a specific numbering scheme to a specific site then it would be close to being a considerable option. If it was up to me, I'd consider altering product behaviour to either:
1) Provide an administrative option whereby if a workgroup goes down, prevent any Items being generated. Then it's up to me, if a site goes down I can simply stop Items being made until things come back online.
2) Keep the current existing workflow, but in the event of a disconnection between publisher and subscriber, when the failed site comes back online, Vault creates an ADMS task to automatically renumber any Items created during that time with the [@WORKGROUP suffix], giving them the next available number. Warn all users with an in-client prompt that the Items they're creating may be automatically renumered when the system fault is resolved.
3) Most if not all everyday Vault users are not going to have a clue about what we're talking about here, so when this numbering conflict occurs through standard workflow, at least give them an in-client prompt or warning explaining why their Item number isn't now what they first thought it was.
4) Make the Item numbering schemes work the same way as the document numbering schemes!
I can think of many more options, most of which including the above are all much more favorable than what we have now which is Vault modifying production data at will without any warning to the user.
Once a file\folder is replicated from one site to another, the challenge is to unreplicate.
Currently there appears to be 2 options to unreplicate a file.
1) In the ADMS Console, edit the "Replicated Folder" and untick the folder that you want to unreplicate, then delete the file(s) from the vault, re-add it to the "unreplicated" folder. This will prevent the file from being replicated in future
2) Disable the Vault on the site, delete the local filestore, Enable it. This can be dangerous if the file is not present on at least one other site. Its OK if you know all files are replicated to at least one site.
The wish is to untick a folder in the "Replicated Folder" dialogue for that site and for the ADMS Console to check to see if that file appears on another site before allowing the Admin to unreplicate the folder. Once the check is completed, the files in the selected folder are removed from that sites filestore.
If you think this would be a useful enhancement, add a comment to this thread...
A customer who must plan for disaster recovery scenarios would like the ability to restore the primary Vault Database and Filestore from a replicated Database and Filestore. If it is not possible to do this now might the capability be added in a future release?
i think that there is an opportunity to improve the functionality of "manage ownership" tools, when in a replicated environment.
for example, i am in the process of deleting a dwf file that is associated / linked to an inventor file. i see that during the delete process, that i cannot complete the task because of error (something like) "cannot complete task ownership is not assigned to your workgroup".
now, we stop what we were doing, navigate to the file location (if you are not working in the folder eg working from a search result folder). take ownership of the file, or in my case, the folder that the file resides in. then navigate back to the original task (run an advanced search for particular file and resume the delete process.
idea: allow "manage ownership" functionality from within the context of the original scenario. eg, i see the task "cannot be completed due to vaulting restrictions / ownership is not currently assigned to your workgroup" ... so, let the user choose "attempt to take ownership of file or parent folder" at the time while they are in the process of another task.
note that part of this functionality could also be applied to another area of vault; eg whether in a "Search Results" page, or in view "Job Queue" display, allow multiple file selection to be part of a similar "manage ownership" functionality, and allow the functionality to be extended to manage the parent folder(s) of the files that are currently selected.
i think that if some consideration is given to this then with some development we could achieve a practical and improved result.
(please note that this is written with reference to vault collaboration 2012. i cannot say whether these things are already available in 2014)