The office paths are located on several locations.
Did you changed the correct ones.
The correct ones can be found in HKEY-LOCAL-MACHINE\software\microsoft\windows\currentversion.

Jesse,
Just to confirm, you've reviewed these articles, or taken other measures already:
https://kb.altiris.com/article.asp?article=24002&p=1
https://kb.altiris.com/article.asp?article=27686&p=1

It sounds like the Source Path Update task isn't working quite correct.  I've only just started messing with NS7, so it sounds like you're a good deal further in than I am, so I don't know how much I can help.  The end-user does have access to the location of the data1.msi file, correct?

Erik,
I did not change any source paths manually.  Rather, I create a Source Path Update task to change this.  That task doesn't seem to be working.  In the registry I was looking at HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Installer\Products\904000001E872D116
BF00006799C897E\SourceList\Net, whcih was mentioned in a KB article.  I don't see a source list under HKEY_LOCAL_MACHINE\software\microsoft\windows\currentversion like you mentioned.

Kyle,
The end-user definitely has access to data1.msi at that location, and the path is valid.  It's just odd that this issue does not show up until the NS7 agent gets installed.  And I agree, it does not seem like the Source Update Task is working correctly.  If it was, I wouldn't be getting prompted for the old source location over and over again.

In case it matters, the Source Path Update task has "Any Server" defined as the first server to use, and the FQDN of the NS as the last server to use.

I seriously narrowed this down today and reported all of my findings to Symantec.  The problem only occurs during the Software Discovery process that is performed by the Software Managment Framework Agent.  That task is hard to pin down because you won't see it running on the endpoint.  The only indication that it's starting is an event in the Altiris Agent log.

"SMF Software Inventory Thread thread 0xFBC beginning"

The Software Discovery settings were configured to scan on Sundays and Wednesday at 2AM, which it seems were the days that people reported this Windows Installer dialog box for Office 2000.  I added a system startup schedule to that task, updated the configuration on a test PC, and rebooted.  On every single reboot, shortly after that inventory started, the Windows Installer dialog would pop up.  Finally, I was able to consistently duplicate the problem.

I also already confirmed that the service pack level doesn't seem to matter.  Most of these are running 2000 SR-1, but applying SP3 yields the same result.  I sent a copy of the source files to Symantec to see if they can duplicate the problem on their test systems.  Hopefully they can, or it looks like I'll have to perform an Office migration in conjunction with the Altiris 7 migration, and I'm much rather not do that.

Hey Jesse,

How did you go with this issue?

I've got exactly the same one popping up for my office2k systems now as well, considering just removing it and installing 2k3..but i'd rather know why its happening in the first place, wondering if symantec got back to you or not?

Cheers

They did get back to me.  Eventually they were able to duplicate the problem that we were having, and development has isolated the cause.  It's scheduled to be fixed in NS7 SP3, which is tentatively due for November.

Great

They didn't happen to mention any work arounds did they?

Did they give you a more technical breakdown of what was happening with the issue?

There are a couple of ways to deal with this right now.

Update the Source List for your application.  For some reason the source path tasks that you create in the NS have not worked for me, so I use a task that runs a VBScript.  For Office 2000 it looks like this:

Dim wiInstaller
Set wiInstaller = CreateObject("WindowsInstaller.Installer")
wiInstaller.AddSource "{00010409-78E1-11D2-B60F-006097C998E7}", "", "\\SERVERNAME\SHARE"

That'll append a new source path in the registry.  As long as this share is readable by everyone the Software Discovery scan will be able to access the files when it needs to.

The next thing you can do is create a standalone inventory package and run that on the machines where this problem keeps popping up.  The standalone inventory task will still gather Add/Remove Programs information, but will not use the Windows Installer APIs that are triggering that dialog box.  The downside to this inventory is that the Software Component GUID will not be captured, which I believes means that these apps won't be populated in the Software Catalog, but don't quote me on that.  The steps for creating the standalone inventory package, straight from Symantec, would be:

1. In the Symantec Management Console, browse under Settings > All Settings > Discovery and Inventory > Inventory Solution > and select Stand-alone Inventory Packages.
2. Click the New package button.
3. Provide a Package name and/or Description.
4. Uncheck the box labeled 'Client Inventory data classes'.
5. Expand the section labeled Software > Common.
6. Check the option labeled Audit.
7. Under the Send inventory data to: section > Notification Server: make sure this location is reachable from your managed computers.
8. You can select Advanced and apply advanced options to the package as needed.
9. Click OK to save the package. It will be located at \Notification Server\NSCap\Bin\Win32\X86\Inventory\StandalonePackages (as seen under the location of the package).
Done!
Now this EXE can be deployed to all systems using either a Managed Delivery or Quick Delivery Task.

As far as the root cause, I'm not exactly sure.  I've always assumed it was an issue with the user context in which the scan was running.  The agent did not have rights to the network share where the source files resided.  You could even run the Altiris Agent as a specific domain user and everything WOULD work fine.  But this permissions thing doesn't explain why the source files are required during the scan, and only for certain applications.  So I really do not have a technical explanation for this problem.