About a month ago we moved all of the SLX Library documents, and switched the Library location in SLX Administrator.  After doing so, the folder permissions were all messed up.  First, everyone could modify documents through the SLX LAN Client.  Then, after restricting the folders, no-one can modify them even through SLX Administrator.

Last week, we switched the service to run as a service account per the instructions to do so, in the hope that then the user would be accessing through the service account which has access to the folders, but we are still having the same issue.  Users cannot modify documents, even when logged into Administrator as a legitimate user who should be able to make changes to the Library. 

Anyone seen this or have any ideas?

The library (on Network users and Administrator) is accessed directly by the User running the program, so you need to ensure that such users have the correct Credential.

Also, keep in mind that you are dealing with both File and Share Permissions.

That said, before anything, access the Share folder directly as one of your Users and make sure that they have the correct level of access (test with a Normal User and an Administrator User).

Once you have properly setup the Access directly on the Share, then go ahead and log into SalesLogix (Network Client or Administrator) and verify that you still have the Desired level of access for each user type.

Raul,

It seems to me that this would mean that we would have to maintain the file/share permissions based on users that legitimately have access to make changes to the Library using the 'Administrator' program?

One issue we run into if we give those users access to the documents, is that if the users pull open documents in the network client, they can make changes directly there, instead of having to go through administrator.

Yes, that would be one of the side effects.

It becomes a Training Issue. A user with "Administrative" Rights to the Library should not make changes to documents directly in the Library if the documents are open the SalesLogix Network Client.

Also, keep in mind (if you have remotes) that even changes made to the documents from the Administrator may not sync unless you properly flag as updated.

The idea with the Service account was the hope that we would not have to maintain these permissions, that when a user signed into 'Administrator' (using their own login info), they would be able to make changes as the Service account has the permissions while the user does not. 

This idea clearly isn't working, as I wouldn't have posted if it did work, but i'm wondering if there is another such work around that would bypass the windows 'user-based' security and use another user instead, so the share security wouldn't have to be maintained.  Something that perhaps needs building...

There are a few things that I could think of, but in general, what that entails is running the Adminstrator under a Different Windows Account.

One way could be by having a Script that clears all Connections and Remaps the Share for the Administrativ User permissions to Make Changes to the Library.

The problem with this approach is that at some point those permissions need to be revoked, and that may require another Script.

In this situation, it is easier to remember to run the Script for Additional permissions, but easy to forget to remove the additional permissions....

The other alternative is to give the SLX Administrative User a separate Windows Login to be used when making changes to the Library.

I must be from the stone age (February 1997, day 0 for SLX). The Folder security is set to read only for everyone....and a couple of marketing people (SLX Marketing User's Group?) are allowed to bring in files, etc. with appropriate permissions. This is on the Windows side. Their isn't any share security maintenance involved, unless you have to move the folders to a different machine or a SAN, etc.

Have had lot's of requests for changes to the Library....even more to Attachments\Documents.....but mucking withWindows Active Directory permissions through SLX is not one of them....

Quote: Originally posted by RJ Samp This is on the Windows side. Their isn't any share security maintenance involved, unless you have to move the folders to a different machine or a SAN, etc.

RJ:

  Remember that for Network Users, the Library is stored on the SALESLIBRARYPATH, which is Network Share, and this is why we have to deal with both File Level ACLS and Share Level ACLs.

  However, as you correctly stated, this is all done at "the Windows side".

  I know that for Remote Clients this is a completely different animal as the files are copied locally, and not only that, but if Remote Users have Admin Rights on their Machine they can make any changes they want, however the advantage here is that any changes they made are not pushed to other users, and if the Admin pushes an Update their changes would get lost.....

  That said, you are right, we don't want to mess with Windows permissions from within SLX, and we don't have to.

  My advice is similar to yours, only a few users should have R/W permissions to the SALESLIBRARY path. But, in order to avoid confusion (since their issue is that these users are making changes from within the SLX Client), he may want to consider giving them a separate Windows Login (that only includes a Shortcut to the SLX Admin) to use when Working on Changes to the Library.

RJ,

You are correct.  We moved the files/folders from a server that was 10+ years old onto a SAN, and in doing so, the share security was stripped.  It was first set to read/write for all users (which allowed all users to modify documents directly from the SLX LAN Client).  Then we restricted the write capability just to domain admins (which allows no users to modify documents/folders through LAN Client or SLX Administrator). 

So it appears I have to "rebuild" the share security to attempt to emulate what we had before.  Although I thought previously that users who could legitimately modify documents, could not do so through the LAN Client, and only through Administrator.  If this was the case, it doesn't look like we can return to this type of environment, and may have to settle for allowing them to modify through both programs.