Because OpenOffice is free and you have to pay a substantial fee for Microsoft Office, you might be tempted to migrate your entire organization from Microsoft Office to OpenOffice. After all, migrating to OpenOffice would save an absolute fortune in Microsoft Office licenses, which is important in a time of shrinking IT budgets. Before you jump right in and begin a migration, though, there are a few issues that you need to be aware of.
Before you begin
Before you commit to a migration, you need to be aware that with OpenOffice, you get what you pay for. When you buy a copy of Microsoft Office, you’re buying a mature suite of many different products. Your Microsoft Office purchase also entitles you to technical support. Although OpenOffice is comparable to Microsoft Office in many ways, there are a lot of places in which it’s seriously lacking. For example, technical support is pretty much limited to whatever information you can find on the Internet.
Another major limitation to OpenOffice is that, although it offers programs that compete with Microsoft Word, Excel, and PowerPoint, it does not offer products similar to other Microsoft Office applications. The most notable example is that there is no OpenOffice version of Microsoft Outlook. You can also forget about getting OpenOffice equivalents to Microsoft Office 2003 products such as Microsoft OneNote, Publisher, InfoPath, and Access.
Best online Microsoft MCTS Training, Microsoft MCITP Training at certkingdom.com
I’ll be the first to admit that there are decent open source database and desktop publishing applications. The fact that OpenOffice doesn’t offer such programs might not be a big deal since you can get these types of applications for free from other places. However, even if equivalencies to Word, Excel, and PowerPoint were all you needed, you should still think twice before giving up Microsoft Office in favor of OpenOffice. That’s because the programs that come with OpenOffice do not have as many features as their Microsoft Office counterparts.
Unless you’re a power user, you may never even notice the features that are missing from OpenOffice. The majority of the missing features are things that the average user doesn’t tend to use. Even so, the missing features can make converting Microsoft Office documents to OpenOffice format difficult. For example, in Microsoft Office, macros are encoded in Visual Basic Script. However, OpenOffice doesn’t support Visual Basic script.
This means that if you have a Microsoft Office document that you want to convert to OpenOffice, and the document contains macros, you’ll have to completely recreate the macros once the conversion process is complete. You can open a Microsoft Office document containing macros into OpenOffice, but the macro code will not do anything. You can view or edit the code, but you can’t execute it.
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.
Migrating to OpenOffice
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.