First, and not exactly what you were asking, I think you might want to reconsider installing to the SystemFolder, as that isn't really recommended.
Assuming you want to do that, though, you can use COM extraction to insert the registration entries into your MSI tables, which is the recommended way to register COM files.
If you don't want to do that for some reason, you can also look into setting those files to use self-registration.
I'd suggest looking in the InstallShield help on those topics for detailed information.
What exactly is the problem with using the System Folder? I'm converting a basic Visual Studio installer project to IS2010, and that is how the developer was doing it. He doesn't like to change things without reason. Are there known issues with using the SystemFolder?
One of the COMs being placed there is a dll we have created, but the others appear to be normal windows things like SYSINFO.ocx and SetACL.ocx
The SystemFolder by best practice rules is for permanent files used by system level applications. Meaning that these files generally will not be removed or updated. For more commonly updated shared files they recommend you use the common files folder or create some custom defined default location your applications can be directed to search in.
