Brought to you by our compatibility guru Curtis Sawin.
In Part 1 of this series, we discussed how to use OMPM to identify “conversion candidates,” which are documents that pose virtually no compatibility risks when you convert them from the binary format (e.g., xls, doc, and ppt files) to the Open XML format (e.g., xlsx, docx, pptx).
Let’s take a look at the process of actually converting the documents. This involves using the Office File Converter Tool (OFC.EXE), and using an exported list from the OMPM Reporting Tool (OMPM.accdr).
To recap, you can use the OMPM reporting tool to create a “low risk” filter to identify documents that:
The following WHERE clause can be used to meet this criteria:
WHERE MaxIssueLevelID > 2 AND DATEADD(d,-30,GETDATE()) > ModifiedDate AND FileID not in (SELECT FileID from Uv_FilterMacroIssue)
To convert files that meet these criteria, you can use the OMPM reporting tool to export the filtered list. After you’ve selected Apply Filter to add your criteria, select the Export… button to export the list of files.
The output will be one or more XML files that contain the full path to all the files in your result set. The folder in which the files have been exported will be referenced by the file conversion tool, OFC.exe
Next, open the OFC.ini file (found in the “TOOLS” folder when you download and extract the OMPM Toolset), and modify the FileListFolder item to point to the same folder where you exported the files. For example, if you exported the file list to the D:\DataExport folder, the FileListFolder item would look like this:
FileListFolder=D:\DataExport
Using the FileListFolder item will result in OFC.exe converting all the files that have been exported by the OMPM reporting tool. Further, using FileListFolder rather than the [FoldersToConvert] section of the OFC.ini allows you to ensure that you’re only converting files that you’ve specifically tagged as low-risk “conversion candidates.” Using [FoldersToConvert] section simply points OFC.exe at one or more folders and says “convert everything.” In some cases this can be helpful, but if your goal is to selectively convert files while retaining the ability to automate the conversion, using FileListFolder provides much more control.
To facilitate moving the converted files to the original location(s), the ofc.ini file has a [ConversionInfo] section that allows you specify the destination folder structure. For example, you could reproduce the folder structure by specifying the following:
[ConversionInfo]
SourcePathTemplate=*\*\*\*\*\*\*\*\*\
DestinationPathTemplate=X:\*1\*2\*3\*4\*5\*6\*7\*8\*9
This would result in the converted files being placed in a folder structure similar to the source folder in on the “X:\” drive. OFC.exe also adds the computer name to the destination path. If you can reproduce the folder structure, you’re in position to implement a repeatable process to move the new files and delete the old ones. Even better, you could create a script to automate such a process.
Also, OFC can convert to a maximum depth of 10 folders. For example, DestinationPathTemplate=I:\Converted\*1\*2\*3\*4\*5\*6\*7\*8\*9\ works correctly. However, DestinationPathTemplate=I:\Converted\*1\*2\*3\*4\*5\*6\*7\*8\*9\*10\ does not work.
One mitigation for this is to map a drive letter to a folder structure (ie, connect the “x:\” drive to \\myserver\myshare\folder1\folder2\folder3\folder4) and perform a find-and-replace in the exported XML file(s) to replace the folder structure with the drive letter.
The impact of this limitation should be minimal, but it’s a pain to troubleshoot, so we wanted to make sure you’re aware of this limitation.
Below are some screen shots that show examples of the various components.
Here is an exported XML file from the OMPM Reporting tool:
Notes:
Here is an OFC.INI file (with all the comments removed):
You can find more information about the items in the OFC.ini file in the TechNet article Convert binary Office files by using the Office File Converter (OFC) and Version Extraction Tool (VET)
Here is my source location of my legacy files:
The next step is to run OFC.exe from a command-prompt. No command-line parameters are needed if you have the ofc.ini in the same folder. Here is a screen shot of OFC.exe running:
Below is a screen shot of the resulting folder:
Check out the folder structure D:\Converted\Ninja99\f$\Converted. The Destination Path includes the computer name and drive letter (or UNC name) in the folder structure. This facilitates moving the files back to the original location.
Also, note the Date Modified and Size columns. The conversion process retains the original modified, accessed, and created time stamps (which is good if you have archive/storage solutions that are triggered using these time stamps), and the sizes are significantly smaller than the previous versions.
So keep in mind that using OFC.exe to “convert” files will require you to clean up the legacy files and replace them with the converted ones. Thus, when determining the ROI of a bulk conversion project, the time investment of this clean up activity must be considered.
Performing bulk conversion is an environment optimization task that will help you realize the value of your investment in Office 2010 by reducing your storage needs, which will save you money. Bulk conversion should be considered an optional task, and it should not be performed when preparing to deploy Office 2010, it should be used only post-deployment...and on low-risk files.
What I find is a huge problem with the OFC is the fact that all converted Excel files loose their links. In many larger corporations, anything from 5 to 20 percent of all Excel files contain links to other Excel files.
Since Excel files are converted (changing their extension!) and the originals are removed, these files loose their link to their source documents.
Jan,
Great point!
Files with links can be a problem during bulk conversion. In OMPM, a file with a link is considered a "yellow" issue. Using the above filter documents with yellow issues are excluded from the list of files to be converted.
However, this only solves half the problem. Even though the filter excludes files that contains links, it doesn't exclude files that are referenced (or linked to) by other files.
Excluding recently used files also helps to mitigate the risk that converted file are not actively being used...but not entirely.
Any bulk conversion project should definitely consider the ROI of storage savings, the time/effort involved in performing the conversion, and the risks of the project.