Software Deployment

Mostly correct, but there are some caveats you should consider, mainly that self-reparing/healing will not work properly in a TS environment. You will have to rebuild/change any packages that does this. Google brings you to http://forum.installsite.net/index.php?showtopic=9137 where you can pick up some tips.

What I normally do is change the package logic to use Active Setup instead, as explained by Ed Tippelt. Beware that MS thinks they own the HKLM\SOFTWARE\Microsoft\Active Setup\Installed Components key and might tell your fellow admins to delete that key to fix other setup-related problems. Which is why some prefer to do all setting of user specific values in a login script. Ick. Not as satisfying and not as portable, in my opinion. Active Setup will let you do what you need on both server and client installs and thus you package once, deploy everywhere [;)]

Wise Package Studio has some tests to verify if a package (might) work correctly for a Terminal Server. Quoted from Wise's QA Assurance doc and also found in their online help:

Terminal Server Compatibility

Checks for errors that might cause problems when the package is installed in a
Microsoft Terminal Services or Citrix environment. With terminal service applications,
installation resources must reside in per-machine locations rather than per-user
locations. Errors result from this test if the installation is set to install per-user, if any
keypaths reside in user-specific locations, or if environment variables are present in
the installation. If environment variables are present, using the Correct button
duplicates the variables, creating a per-user set and a per-machine set, one of which
is installed depending on the value of ALLUSERS. Correcting some errors might cause
keypaths to be empty, and might cause a one-time repair. You can set a release to be
compatible with Terminal Services. See ALLUSERS Property in the Windows Installer
SDK Help.