Invalid ProdID after upgrade to Office 2003--URGENT 1

[rschaeferhig]

I have an ASP/VBScript web app that instantiates a PowerPoint session through "Set ppApp = Server.CreateObject("PowerPoint.Application")". This is running on a Win2K server that was running Office 2k. Last night our intrepid Infrastructure folks upgraded Office to Office 2003 and now my app throws an "Invalid ProgID" error on the above CreateObject.

Any ideas? I tried "PowerPoint11.Application" and that didn't work. My app is down and 200 sales reps can't construct marketing presentations...

 

[HitechUser]

Some of this may help. It did for us.

Checking the Automation Server
The most common reasons for an error with CreateObject or New are problems with the server application itself. Typically, these problems are with the configuration or setup of the application. Here are some items to check:
• Verify the Microsoft Office application you want to Automate is installed on the local computer, and make sure that you can start the application from the Start and then Run dialog box. If the program cannot be started manually, it will not work through automation.
• Re-register the application by typing the path to the server in the Start and then Run dialog box, and then append /RegServer to the end of the line. Press OK. This should silently run the application and re-register it as a COM server. If the problem is with a missing registry key, this will typically correct it.
• Check the LocalServer32 key under the CLSID for the application you want to Automate. Make sure it points to the correct location for the application, and make sure the path name is in a short path (DOS 8.3) format. While it is not a requirement that a server be registered using a short path name, long path names that include embedded spaces have been known to cause problems on some systems (see later).

To check the path key stored for the server, start the Windows Registry Editor by typing regedit in the Start and then Run dialog box. Navigate to the HKEY_CLASSES_ROOT\Clsid key. Under this key you will find the CLSIDs for the registered automation servers on the system. Using the values later, find the key that represents the Office application you want to Automate and check its LocalServer32 key for the path.
+========================+=========================================+
| Office Server | CLSID Key |
+========================+=========================================+
| Access.Application | {73A4C9C1-D68D-11D0-98BF-00A0C90DC8D9} |
+------------------------+-----------------------------------------+
| Excel.Application | {00024500-0000-0000-C000-000000000046} |
+------------------------+-----------------------------------------+
| FrontPage.Application | {04DF1015-7007-11D1-83BC-006097ABE675} |
+------------------------+-----------------------------------------+
| Outlook.Application | {0006F03A-0000-0000-C000-000000000046} |
+------------------------+-----------------------------------------+
| PowerPoint.Application | {91493441-5A91-11CF-8700-00AA0060263B} |
+------------------------+-----------------------------------------+
| Word.Application | {000209FF-0000-0000-C000-000000000046} |
+------------------------+-----------------------------------------+

Does the path match the actual location of the file? Be aware that short path names can give you the impression that a path is correct when it may not be. For example, both Microsoft Office and Microsoft Internet Explorer (if installed in their default locations) will have a short path similar to "C:\PROGRA~1\MICROS~X\" where X is some number. It is not immediately obvious that you are looking at from a short path name.

You can test that the path is indeed correct by copying the value from the registry and pasting it into the Start and then Run dialog box (remove the /Automation switch before running the application). Does the application start when you select OK? If yes, then the server is registered correctly. If not, you should replace the value of the LocalServer32 key with the correct path (use a short path name if possible).

• Problems have been known to occur when automating Word or Excel if either the Normal.dot template (Word) or the Excel.xlb resource file (Excel) has become corrupt. To test if a corruption has occurred, search the local hard drives to find all instances of Normal.dot or *.xlb. (Please note that if you are running Windows 2000, Windows NT, or Windows 95/98 with profiles enabled, you may find multiple copies of these files, one for each user profile on the system.) Temporarily rename the Normal.dot file(s) or the *.xlb file(s), and re-run your Automation test (Word and Excel will create these files if they cannot find them). Does the code now work? If yes, then the files you renamed should be deleted since they are corrupt. If not, you should rename them back to their original names so any custom settings saved in these files won't be lost.

• If you are on a Windows NT, Windows 2000, Windows XP, or Windows Server 2003 system, run the application under the Administrator account. Office servers require read/write access to the registry and disk drive, and may not properly load if your current security settings deny this privilege.

 

[rschaeferhig]

Turns out our intrepid Infrastructure group neglected to determine which Office components were installed prior to uninstalling Office 2000. They installed their standard build of Office 2003 which did not include PowerPoint. I had them add in all the remaining Office components so as not to miss anything and the app is now working correctly.