Maintaining user software functionality in an ever-changing software environment - permission problems?

Hello,

One of my clients' domains will serve as an example of a growing problem: security vs. functionality in an ever-changing software environment.  Windows SBS 2003, domain security, desktop users are domain users and are NOT local admins, as we do not wish them to install whatever software they fancy.  Users running medical practice management software on their desktops, with various additional software packages for network fax, etc.  Installation of these packages can be completed by a domain admin, and the fully-functional workstation turned over to the user.  Over time (months), the functionality of the software begins to fade, problems arise  such as java script errors and certain users no longer being able to use certain software packages on certain workstations, while they can use them on others.  

If you log on to one of these problem workstations using a domain admin logon, the frequently disappear.  If you elevate the user to local admin, the problems do not occur.  Uninstalling / reinstalling the software package does not always fix the problem.  Thus, I suspect these are permission issues.  What causes them I do not know.  I suspect they are related to the constant cycle of software updates (Windows, Java, Adobe, vendor, etc) which install new versions of files which may have different permissions than the ones that used to work.

How do you all deal with this?  What is the most cost-effective way you have found to re-initialize a workstation?  Ghosting would not work for most cases, as the workstation hardware involved at many clients is of various vintages.

I would also like a good link to the best, easiest and correct way to unjoin / rejoin a workstation to an SBS domain, reset the computer account, etc.
LVL 4
StonewallJacobyAsked:
Who is Participating?
 
budchawlaCommented:
Hi there,
To answer your second question first, on the client PC, go to http://sbsserver/connectcomputer to join the domain. This is the best way to join the domain as it does a bit more than the standard network ID wizard....
0
 
budchawlaCommented:
Regarding the first part, I hope you get more responses for a wider point of view, but this is what I do:
On most SBS networks I look after, the main user IS a member of the local admins group. This is a by-product of using /connectcomputer with default settings. This behaviour can be modified (even by just manually editing the local permissions) but I generally leave it that way for SBS networks.

What I generally do is try to keep all software "managed" as far as possible - which means deploying it via group policy and also controlling updates and new versions etc by replacing it rather than having end users do their updates. This isn't a 100% bullet-proof method, but I find that it does ease quite a few headaches.

Of course, all software doesn't support being pushed out by Group Policy so it's not an all-encompassing solution, but one that does help quite a bit...  there are products out there that help with software management but they tend to be aimed at the enterprise so you're probably looking at higher costs than you want. On the other hand, these days enterprise software is filtering down to the SMB space faster than ever before, so maybe the wait won't be too long!

If you want more info on using GP to deploy software, let me know and I'll point you to some resources.

cheers

bud
0
 
Ron MalmsteadInformation Services ManagerCommented:
Just to comment on the local administrator permissions.....

I find it best to make users a local admin, but then I have applied a group policy which denies the use of windows installer for workstations.  I have a serperate OU that has a GPO that allows windows installer.  So when a user want to install something...they have to come to me to do it.  I place their machine in the other OU, and run GPUPDATE /FORCE...then install the software for them.  Then put the machine back in the windows installer denied OU.

Also, you might be experiencing problems due to the fact that users cannot write to certain registry keys that are required for normal operation of your software.  You can fix some of this issue probably just by giving them more permissions to the HKEY\LOCAL MACHINE\SOFTARE\ name of your software\ Key...   Do this in regedit or regedt32.exe

Also the program files folder that where this specific software resides...you should give them full control over that folder.

I've found that the best way to deal with workstations is to give users' full control over the workstation, then lock down all the specific things I don't want them to be able to do using Group Policy.  Without at least "power user" level permissions....they can't even install a printer.  That's an administrative nightmare.
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.