Uno,
What you experienced (that a program from a CD-ROM didn't install and that
one downloaded from the Internet did) was just a coincidence. There's
nothing at all about the source of an executable program that determines how
or whether it will install.
The first step you need to do is to ensure that you are not giving your
users more rights on the machines than they need. That means not making
them power users or administrators. One thing I see all the time is an
administrator who can't get a program (for example Office 97) to run
properly putting the user into the local Power Users group. This often has
the desired effect, but is really too much.
The proper way to go about this is to find out exactly what file permissions
and registry permissions (yes, registry keys have permissions too!) need to
be relaxed to get a non-compliant program to run. Ideally, you should shout
at your software vendor and ask them to fix their broken application, but
that's life. Better still, buy someone else's application that actually
works properly. Anyway, that's another topic.
Assuming you have a clean environment where nobody needs to be a power user
or an administrator on the local machine, you will find that some programs
install and work, some install and half work and others just don't install.
It's all about what the installation program tries to do and what is allowed
by Windows. If an installation routine explicitly checks for administrative
rights, it will normally stop.
If the installation routine tries to copy files to c:\winnt, it will fail
because ordinary users don't have permissions to add files here. Similarly,
ordinary users can't modify or create files in c:\program files. Similarly,
modification of registry keys in the HKEY_LOCAL_MACHINE hive won't happen.
What I have seen some programs do is install themselves in the user's
profile (specifically under the Application Data folder) if they can't
install into Program Files. I seem to recall WinZip doing this, although I
haven't tested this in a while.
Windows also ships with a bunch of security templates that you can import
with the secedit command (or apply with group policy, but beware of doing
that as you can end up with some speed issues when group policy refreshes
and reapplies the template too frequently). These are called Securews.inf,
compatws.inf, hisecws.inf and so on and can be found in
%systemroot%\security\templates. Windows Help has enough to get you started
here (look up "secedit" and "security templates").
Other than that, Windows 2000 Group Policy has settings that you can use to
define which programs a user can or cannot run. You can start off with a
draconian policy that says "nothing runs unless I say so", or you can ban
specific programs from being run. However, there is a certain amount of
suckiness in the way this works on Windows 2000, namely that the mechanism
relies solely on the name of the executable. A user can rename UT2003.exe
to WinWord.exe and successfully bypass this policy. Similarly, if they
haven't yet installed the program, renaming setup.exe to winword.exe will
have the same effect.
I haven't played with this in person, but I'm reliably informed that Windows
Server 2003's Group Policy is a whole lot better. Firstly, it's implemented
at the loader level, so it's about as deeply-integrated into the OS as
possible. Secondly, you can choose to block by name or by performing a CRC
(cyclic-redundancy check) on the executable files and allowing only those
files that match. Renaming files won't get around this.
Anyway, I hope that goes some way to helping.
If you want to investigate the security templates further, the Windows 2000
Resource Kit contains a good section on this. It may even be available
online or on your TechNet CD. If not (and I'd recommend you do this anyway),
you can purchase the Resource Kit book. The full RK is about a foot long
and consists of several book, but you only need to get the Windows 2000
Professional Resource Kit, which is much cheaper.
Regards
Oli
