Re: User Rights at Client Seem to Vary

From: Herb Martin (news_at_LearnQuick.com)
Date: 03/22/05 

Date: Tue, 22 Mar 2005 16:03:22 -0600

"TonyM" <tonym@southernwoodwork.com> wrote in message
news:el2wwKyLFHA.3616@TK2MSFTNGP09.phx.gbl...
> Herb thanks for the educating reply!
>
> Herb Martin wrote:
> > "TonyM" <tonym@southernwoodwork.com> wrote in message
> > news:##OhfixLFHA.576@TK2MSFTNGP15.phx.gbl...
> >
> > BTW, as a Novell Admin, do yourself a favor and
> > make a POINT of distinguishing between "Rights"
> > and "Permissions" in Windows.
> >
>
> You are correct, I am struggling a little bit with some of the
terminology.

Even experienced Windows people are sloppy on
this one, so many will let you continue without making
this clear distinction explicity.

> >>domain. 3 of these stations log on to both servers without a hitch. All
> >>software works correctly and the users have access to both servers
> >>logging on with their domain profiles. The other 2 stations is where I
> >>am having problems. When the user logs on, using the domain profile, I
> >>get pop-ups requesting the MS Office install CD-ROM.
> >
> >
> > This is usually caused by an attempt (by the user or even
> > through an update from Office Update) to update or add new
> > features to Office.
> >
> > Once in this state, you pretty much have to let Office see the
> > original CDRom or installation point to get it to stop (there
> > may be other ways, ask in an Office group but this is what I
> > know about such problems.)
>
>
> I have inserted the CD and thats when I get the error message below and
> the install stops.

How about the idea (I gave below) of just explicitly
choosing to do the updates as an Admin so that you
(can try to) update the status of the Office install....

> >
> >
> >>When I put the CD
> >>in the drive I get errors saying that the user does not have rights to
> >>modify the WIN.INI file. Nothing in the MS Office works, I get a lot of
> >>"Please reinstall" errors.
> >
> >
> > The Win.Ini file shouldn't even matter for modern Office
> > so I wonder if this is not something from an old version
> > or due to the Novell client (which has been known to cause
> > pretty strange problems).
>
> This is what confused me. It is an old version of Office (2000 I
> believe).

Evne that version is pretty old these days....

> Yes, I know that MS and Novell don't play well together at times.

> >
> >>Also the accounting package appears to start
> >>when you click the icon but doesn't come up. It just runs as a service.
> >
> >
> > "Service" is a specific term, but I suspect you mean
> > "runs without displaying a GUI" which is an ENTIRELY
> > different result.
>
> Yes, incorrect terminology again. The program runs without displaying a
> GUI. I then have to use task manager to end the process.

Ok, so this tends to imply some sort of DLL mismatch
problem (although it could be a lot of things.)

Is the accounting packing some 16 bit obsolete program
that you are just stuck with due to the functions it performs?

> >>If I log on to the station with the user's local profile all works
> >>correctly with no problems. If I log on to the station with my profile
> >>(local or domain) everything works correctly.
> >
> >
> > How about updating Office then? Both from the CDRom and
> > perhaps from the Office Update site to get everything straight?
>
> All MS Office products and Win2000 have been updated to the latest
> patches and security updates.

Office Update site?

> As I stated above, the system will not allow the user to update the
> program from the CD-ROM when logged on under the Domain Profile. When
> logged on under the local profile no problems.
>
>
> >
> >>One of the problem users has full Admin rights (he is the owner) and the
> >>other user is a Power User. Both users are in the Domain Users group on
> >>the server. The other 3 users are Power Users in the Domain Users Group
> >
> >
> > Probably doesn't matter -- it is likely something in
> > their user profile that is marked to update office.
> > Perhaps they tried to "add a feature" to office.
>
> Good point. I will look into this

But even this is just my impression (based on a lot of
experience but still a guess.)

> >>All 5 workstations were set up the same way. I basically logged on as
> >>the local user to create a new domain profile on the workstation then,
> >>as Admin, I copied the local profile to the Domain profile through the
> >>User Profiles in the System Properties dialog box.
> >
> >
> > I have never used nor liked that method. Preferring to
> > do it directly.
> >
> Thats a good idea. I will try recreating the profiles without copying
them.

Or just first VIEWING the permissions and perhaps
setting them manually with tools like:

  Share:
    Net Share SHARENAME
    Computer Manager
    Windows Explorer

  NTFS:
    cacls.exe (built-in)
    xcacls.exe (downloadedable from MS or in Support Tools)
    setacls (SourceForge but NOT for the faint of heart so let
                this one go until later.)
    Windows Explorer

Also, as a Novell guy, notice that SHARE permissions and
NTFS FILE permissions are distinct -- they interact when a user
much access an NTFS file over the Network -- the user must
'pass' both the Share AND the NTFS permissions on a file to
exercise that privilege ON THAT FILE.

> > Perhaps the permissions were mangled on the profile
> > location -- either the Share (usually should be Full Control)
> > or the File (NTFS permissions.)
> >
> >
> >>I'm sure I missing something in the rights category but since all 5 were
> >>done the same way I'm stumped. Any help would be greatly appreciated.
> >
> >
> > Go check the permissions (not rights) on both the Share
> > and the NTFS files.
>
> I will check this also.
>
>
> Again, thanks Herb. This is the kind of information I need to keep my
> hair intact.

We will try to help -- your skills as a troubleshooter
and problem solver on Novell and your general understanding
of networks will transfer directly and we will do our best
to help explain any misunderstandings or point you to shortcuts
in understanding the ESSENTIAL differences.

Relevant Pages

  • Re: Active Directory authentication / authorisation
    ... Programmatically Set NTFS File System Folder Permissions ... Use ADsSecurity.dll to Remotely Add Local Account ACEs to an NTFS File ... Tony Toews, Microsoft Access MVP ...
    (comp.databases.ms-access)
  • Re: Access 2003 and Active Directory
    ... Programmatically Set NTFS File System Folder Permissions ... How To Use ADSI to Set Automatic Inheritance of File/Folder ... Tony Toews, Microsoft Access MVP ...
    (microsoft.public.access.modulesdaovba)
  • Re: NTFS + Impersonation + Asp.Net
    ... permissions because you still have to give permissions to ... I thought since I'm using impersonation and that the ... that user account. ... as a test I set NTFS file permisions to refuse ...
    (microsoft.public.dotnet.framework.aspnet.security)
  • NTFS file auditing settings
    ... using Windows 2000 Domain Group Policy. ... permissions blank when I do this, it removes all permissions from the root ... What I would like is a way to roll out NTFS file auditing settings without ... Or maybe I'm doing something wrong with Group Policy. ...
    (microsoft.public.win2000.security)