Upon looking through event and SharePoint ULS Logs (present in the 14 hives folder), we identified the issue below<\/p>\n\n\n\n After further investigation, we determined that the source of the problem was probably a result of:<\/p>\n\n\n\n \u2022 Special characters in the imported CSV files (which contained document metadata) that were provided in the document migration. We gave the issue some careful thought, eventually coming to the following conclusions for resolving the version history issue:<\/p>\n\n\n\n \u2022 On the existing Document Set, we developed a tool to replace the special characters, using code provided here and shown below. We also updated the custom developed workflow in order to handle the issue. The Result<\/strong><\/p>\n\n\n\n Once we implemented the above solutions, the clients were able to capture Document Set version history again without a hitch. It not only made the client happy because their primary requirements were met, but it also made us happy because we were able to come to a reasonable solution right in the nick of time. Problems like this are definitely frustrating, but it\u2019s also incredibly rewarding once we get them straightened out.<\/p>\n","protected":false},"excerpt":{"rendered":"![\"\"](\"https:\/\/viewmyprojects.com\/winwirewp\/wp-content\/uploads\/2023\/11\/Problem.webp\")
<\/figure>\n\n\n\n
\u2022 Users copying content from Word documents into the document metadata.
\u2022 Special characters in the managed metadata, details of which are specified here.
The Solution<\/strong><\/p>\n\n\n\n
\u2022 We updated the managed metadata by replacing the special characters. For example, all instances of \u201c&\u201d were replaced with \u201cand,\u201d so anything like \u201cComputer & Information System\u201d would become \u201cComputer and Information System.<\/p>\n\n\n\n![\"\"](\"https:\/\/viewmyprojects.com\/winwirewp\/wp-content\/uploads\/2023\/11\/Solution.webp\")
<\/figure>\n\n\n\n