Programming-related question

B

Bryan Dickerson

First I'll apologize for cross-posting. Shoot me. I figure the more people
that I can get this in front of, the faster my problem may get solved.

I guess this actually has more to do with security on Windows XP than
programming, but here goes.

With all of our in-house written programs, I have written them to be
installed such that when a user dbl-clicks an icon on his desktop, he is
actually clicking on another program I wrote that checks the copy of the
program on his pc versus the copy in a network location to see which is more
current. If the copy on the network is more current, then the network
version is copied down. Likewise for all the DLLs and OCXs used by the
program, to be complete, the shell for each DLL, un-registers the old
version, deletes it, copies the new version from the network, registers it
and then runs the program. All this to keep me from having to go to each
desktop and load the latest version of the program on the pc-all I have to
tell them is "log out and back in to get the latest version". Also part of
this picture is the fact that each user to this point has been setup with
"Administrative" rights to his own pc, and several people in the company
have abused this privilege by loading the latest junk software and thus
costing us the time and effort of replacing their machines. Ugh. So now
our network admin wants to move the users down to "Restricted User" status
to keep them from repeating the abuse of their pc. Enter Windows XP which
is pre-loaded on all the new machines we purchase***. I need to find some
way to still allow the updates to the company programs to flow easily and
correctly down to their machines, but keep them from downloading junk. I
tried redoing the installation packages from installing my DLLs and OCXs in
the Windows\System32 directory to installing them in a directory under
Program Files\Common Files. I also tried giving the "Restricted user" full
control over the Common Files sub-directory and the program files
sub-directory, but whenever there is a new update, the shell program seems
to copy and register new DLLs correctly, but when the program starts it gets
the error "429 ActiveX component can't create object" right off the bat.

*** Most of our machines have Windows 2000. I have tried to duplicate this
on Win2K, but have been unable to.


As I said, I think this is more about permissions and policies than
programming, but could anyone perhaps even point me in a good direction?
Some sort of tutorial on policies, etc. that might help me.


Thanks in advance!
 
B

Bryan Dickerson

Yes, I've considered it--honestly, for about 10 seconds. No offense
intended. I'm really not concerned with the actual installation right now,
so much as the on-demand ability to update the components of the program
when the user gets into the program under a 'restricted user' authorization.
 
G

Grinder

[snip]
As I said, I think this is more about permissions and policies than
programming, but could anyone perhaps even point me in a good direction?
Some sort of tutorial on policies, etc. that might help me.

Your intuition sounds right.

With the more restrictive settings, can you manually register the new files
successfully?
 
M

MikeD

Bryan Dickerson said:
First I'll apologize for cross-posting. Shoot me. I figure the more people
that I can get this in front of, the faster my problem may get solved.

Not a very good way to begin your post IMO. Nobody minds cross-posting as
long as it's to relevant newsgroups. It's multi-posting that aggravates
everyone. Even though you apologize, it doesn't come across as
sincere...and therefore is worthless. It's actually your "Shoot me" comment
that I found...oh...let's just say uncalled for.
With all of our in-house written programs, I have written them to be
installed such that when a user dbl-clicks an icon on his desktop, he is
actually clicking on another program I wrote that checks the copy of the
program on his pc versus the copy in a network location to see which is more
current. If the copy on the network is more current, then the network
version is copied down. Likewise for all the DLLs and OCXs used by the
program, to be complete, the shell for each DLL, un-registers the old
version, deletes it, copies the new version from the network, registers it
and then runs the program. All this to keep me from having to go to each
desktop and load the latest version of the program on the pc-all I have to
tell them is "log out and back in to get the latest version". Also part of
this picture is the fact that each user to this point has been setup with
"Administrative" rights to his own pc, and several people in the company
have abused this privilege by loading the latest junk software and thus
costing us the time and effort of replacing their machines. Ugh. So now
our network admin wants to move the users down to "Restricted User" status
to

I can relate to your predicament and I'm sure many others can too.

Look into ActiveDirectory...it has specific features for "managed"
installations, provided the installation is done using Windows Installer.
Permissions are not an issue because AD grants permissions for the purposes
of the managed installation.

I suggest you consult with your sysadmin or netadmin on this.

Mike

keep them from repeating the abuse of their pc.
 
B

Bryan Dickerson

Thanx for your thoughts.

You're the 3rd person to recommend Windows Installer as something to
investigate to resolve this. I currently use Visual Studio Installer. Are
we talking about the same thing? The first person(a good friend of mine)
recommended I use it then said he had no idea how, but he had heard that
it's great stuff! :rolleyes: I haven't heard a response from the second
person yet--a response in another forum. With all due respect, you do
understand that it's not the initial installation that I'm concerned with,
so much as the on-demand updates. I.e. A user has a problem, he calls me, I
find and fix a problem in a DLL and put the new file out in a predetermined
location on the network. The user then logs out and at the moment that he
gets back in to the program, the updated file is downloaded to his
machine(and in the case of a DLL, registered), he logs in and goes on his
merry way with the error fixed. If I updated the MSI file from which the
program was installed with the new DLL, would VSI see the new file and
'install' the updates? Is it that simple?
 
C

Chris Prajzner

Maybe you should reconsider InstallShield - for more than 10 seconds .. :)
IS does exactly what you describe below. In addition to doing the initial
installer, you can update individual components, individual files,
individual dlls, etc. on demand. Windows Installer too can do this, but I
have only experience using IS so I can't give a valid comparison. In any
case, I've normally found that it's never that simple.... except to the
marketing people.

Chris
 
B

Bryan Dickerson

Thanks for your response. One of the reasons that I didn't consider
InstallShield for any longer is that I'm not in a position here at my job to
buy software like this. I could recommend it, but our company is small and
we, as much as any other company, are trying to cut costs. I don't know if
I have enough information to establish a compelling reason to buy
InstallShield. Another reason is probably my laziness. In my main program
over the last several years, I have written out the need for several 3rd
party products and I'm drooling over the chance to really get my hands on
VS.Net so that some other 3rd party products can go bye-bye as well. Some
of them are just a pain to deal with.

Does anyone else have any experience with VS Installer? That is with how
you apply updates to installed packages? Anyone? Anyone? Bueller? Bueller?
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top