Page II: OpenOffice boasts many advantages, but migrating can be tricky. Here are elements to consider before switching.
Even though macros are the biggest cause of incompatibilities between Microsoft Office and OpenOffice, there are other types of things that are sometimes included in Microsoft Office documents that tend to cause problems with the conversion process. Other document features that are not supported by OpenOffice vary among document types. For example, a Microsoft Word document may not be converted to an OpenOffice document correctly if it includes AutoShapes, revision marks, OLE objects, indexes, tables, frames, multicolumn formatting, hyperlinks, bookmarks, Microsoft WordArt-based graphics, animated characters, animated text, or certain controls and Microsoft Office form fields.
Likewise, there are also some features that might be found within a Microsoft Excel document that may not convert correctly. These features include AutoShapes, OLE objects, pivot tables, new chart types, conditional formatting, some functions and formulas, and certain controls and Microsoft form fields. There are also restrictions on PowerPoint documents, although there are not as many restrictions for PowerPoint documents as there are for Word and Excel documents. OpenOffice has trouble converting PowerPoint documents that include AutoShapes; tab, line, or paragraph spacing; master background graphics; grouped objects; and certain multimedia effects.
If you have read the previous section regarding OpenOffice's various limitations and you still want to migrate from Microsoft Office to OpenOffice, then there are a few challenges that you'll face. One challenge is the actual deployment process. When you install OpenOffice, the installation program does not offer to uninstall Microsoft Office, and the installer does not attempt to configure OpenOffice based on your Microsoft Office settings.
OpenOffice is configured pretty well by default, but if there are one or more settings that need to be changed, it would be a real pain to have to modify these settings individually on every PC to which you are deploying OpenOffice. If you find yourself in a situation in which some of the configuration options need to be changed for all of your users, then I recommend creating a custom Windows Installer package.
A Windows Installer package is an MSI file that you can use to deploy the application. You can create a custom MSI package by using a free utility called WinINSTALL LE 2003.
What makes this utility so perfect for this type of deployment is that it uses a procedure called diffing to build a custom installation script. Basically, the way the diffing function works is that you would load Windows onto a PC and then install the same service packs and hot fixes as are being used on your workstations. You would then take a snapshot of the machine's hard drive by using the WinINSTALL LE 2003 utility.
After taking the snapshot, you would install OpenOffice on the machine and then configure OpenOffice in exactly the way you'd like it to be configured for your users. This means doing things such as setting up data paths, possibly placing an icon on the desktop, or even configuring Proxy Server options.
Once OpenOffice is running an ideal configuration for your environment, you'd run WinINSTALL LE 2003 again and make a second snapshot. The utility would then compare the two snapshots. The MSI file that is created is basically a log of all the files and registry entries that vary between the two snapshots. At the time the MSI file is created, a folder is also created to hold all of the files associated with OpenOffice.
One word of caution: WinINSTALL LE 2003 doesn't just look for new files; it also looks for any files that have been modified between the two snapshots. For this reason, it's extremely important that the machine used to create the MSI file contain nothing but Windows and OpenOffice. It's also very important that you deploy the MSI file only to machines running the same operating system and service pack level as the machine used to create the Windows Installer file.
Ideally, you could use SMS Server to remove Microsoft Office from all of the workstations, and then deploy OpenOffice by using the Windows Installer package that you created. If you don't have SMS Server or a third-party application management utility, you can use Active Directory to assign the application to the desired users.
Assigning an application means that Windows will automatically install the application the next time a user logs in. If a user somehow manages to destroy, damage, or disable OpenOffice, Active Directory will use the MSI file to figure out what has been changed to cause the malfunction and will repair OpenOffice. As you can see, by creating an MSI package for OpenOffice, you can automatically deploy a custom OpenOffice configuration and automate the repair process should a user damage OpenOffice.
10%
8%
This article sounds like it was written by Microsoft.
Also, (for example) if the writer did a decent amount of research he would have found out that no email client was developed for OpenOffice as there are already suitable open source alternatives ... and it's not worth the effort to duplicate an existing product.
On a whole, the quality of the article is lacking.
Andrew Smith