Jump to content


This is a ready-only archive of the InstallSite Forum. You cannot post any new content here. / Dies ist ein Archiv des InstallSite Forums. Hier können keine neuen Beiträge veröffentlicht werden.
Photo

non-Admin issues


5 replies to this topic

spdygnlz

spdygnlz
  • Full Members
  • 106 posts

Posted 03 October 2007 - 01:21

In our install, I find the MSSQL Server data directory and install a database (.mdf/.ldf) file there. After that I attach it and everything is hunky-dory. When a non-Admin user tries to run the software and access that database, the installer freaks out because it can't find that file. Come to find out, non-Admin users don't have access to the Program Files\Microsoft SQL Server\MSSQL.1\MSSQL dir (which is where the data dir is). It keeps trying to install the feature with the database files in it and failing.

Short of moving the .mdf files to another location where any user has access or opening the permissions on that dir wide open, what can I do to make sure the installer sees (or at least doesn't try to reinstall) that directory?

-- spdygnlz --

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 03 October 2007 - 08:55

Firstly, MS guidelines state that data files don't belong beneath PF. A good chunk of vendors ignore that, of course, but that's their (sorry, our) look-out.

So, move the d/b somewhere else. What would be wrong with using a folder in the ALLUSERSPROFILE tree somewhere?

Anyhow, even if you leave the d/b where it is, you don't need to set the permissions "wide open". Use SetACL or your chosen permissioning tool to assign *appropriate* rights to a group created for this purpose (better to use groups, rather than users - they have a habit of leaving!)
- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

spdygnlz

spdygnlz
  • Full Members
  • 106 posts

Posted 03 October 2007 - 16:21

Moving the DB really does make the most sense... Now all I gotta do is convince the developers of that too. Do you happen to have a link to those MS guidelines? It would probably go a long way if I were able to show them that it's not just me who thinks we should move those files.

The only problem that I see with the permissions suggestion is that they want anybody that logs onto the machine to be able to access this stuff. I guess I could use Authenticated Users group or something, but that still seems pretty open. (Do local user accounts, as opposed to domain accounts, fall into that group?)

Thanks

-- spdygnlz --

Stefan Krueger

Stefan Krueger

    InstallSite.org

  • Administrators
  • 13,269 posts

Posted 05 October 2007 - 13:06

QUOTE
but that still seems pretty open

Read access might be sufficient.

VBScab

VBScab
  • Full Members
  • 436 posts

Posted 08 October 2007 - 11:51

QUOTE (spdygnlz @ 2007-10-03 16:21)
Now all I gotta do is convince the developers of that too.

Any developer who isn't aware of that needs educating with something heavy which will leave a permanent mark. Sorry, but in this day and age, it's unforgiveable. Next you'll be telling us that the app requires its install location to be added to the system PATH...

Edited by VBScab, 08 October 2007 - 11:51.

- Don't know why 'x' happened? Want to know why 'y' happened? ProcMon will tell you.
- Try using http://www.google.com before posting.
- I answer questions only via forums. Please appreciate the time I give here and don't send me personal emails.

spdygnlz

spdygnlz
  • Full Members
  • 106 posts

Posted 08 October 2007 - 20:44

Oh, I can't even tell you the number of horrible decisions they are making on this thing. I've fought a few of them, but since I'm the new guy, I obviously don't know what I'm talking about. I mean, they've been doing the same thing for years now, so it has to be the right way, right?

I get so frustrated with the silly things they do sometimes. Unfortunately, I think a lot of the bad decisions are based on overly optimistic schedules placed on us by higher-ups that don't understand the software process. That's another topic, though.

-- spdygnlz --