There are only a few things here to consider:
All application pool accounts and SharePoint services that touch content need access to two things:
1.StoragePoint DB (in roles db_reader, db_writer)
2.Blob Store (file-share permission create\read\write\delete)
By default the StoragePoint installer adds appropriate StoragePoint Database rights to all Application Pool identities that exist at that time.
Reminder: The same access rights are necessary for any SharePoint services which are configured with a specific identity like Office Web Applications or the Excel Calculations Service.
|
NOTE: When testing access to an Endpoint (fileshare) from within Central Administration, the Identity of the Application Pool hosting the Central Administration Site is the one that is being used for the test. If there are different Identities used for other Web Applications in the Farm then those identities will also need access but cannot be tested from within Central Admin itself. |
Example:
Consider the case where a new web-application is created in Central Administration to hold Sites for the HR department.
Creating the new web-application may optionally also create a new IIS application-pool using a new Identity.
For example, let's call this new identity "HR-SPAppPool."
The HR-SPAppPool account will need db_reader and db_writer in the StoragePoint database.
HR-SPAppPool will also need create\read\write\delete permission on the system cache location (if configured) and any endpoint file shares.
Ensure that the service accounts associated with the Windows SharePoint Services Web Application(s) and Windows SharePoint Services Timer service have the following access permissions: Read, Write, Modify, Delete (files and folders), and Create (files and folders). This assumes the FileSystem adapter is bieng used. Adapters that use REST-based interfaces typically pass a security token in the header of any request packets, so the service accounts associated with the SharePoint Web Applications or Timer service are not relevant.
1.Select Web application pool.
2.Select Windows SharePoint Services Web Application from the Web Service dropdown.
3.Select an application pool from the Application pool dropdown.
a.Note the service account associated with each application pool, as they can be different.
4.The configured service account will be displayed in the Predefined dropdown or the Configurable> User name box.
5.Click OK.
1.Select a Web Application Pool from the dropdown.
2.The configured service account will be displayed in the Select an account for this component box.
a.Note the service account associated with each application pool, as they can be different.
3.Click OK.
Determine the service account associated with the SharePoint Timer Service service by opening the Services manager under Administrative Tools on one of the WFE(s). Scroll down to the SharePoint Timer Service service entry and note the service account in the Log On As column.
Since a request to upload a new document or retrieve an existing document can be handled by any of the web frontends in the farm, it is a best practice to use a UNC for the Path parameter on the FileSystem adapter. Using a physical location (i.e. E:\blobstore) will produce unpredictable results, as it cannot be assured that the WFE that wrote the BLOB is the same WFE that will retrieve the BLOB, so the BLOB store must be a shared storage location that is uniformly accessible by all WFEs.
|
NOTE: Be sure the path plus file name plus any optional folder information doesn't exceed 260 characters. Consider an abbreviated UNC path to reduce characters. |
Some storage solutions have their own configuration properties, and the StoragePoint adapters are used to connect to these solutions. If the solution has a job for cleaning up content after a certain retention period, it is imperative to match this retention period with SharePoint retention policies.
For example, if the retention policy on the storage device is 4 years, but SharePoint is configured to keep content for 5 years, the BLOB will be cleaned off the endpoint, but the link in SharePoint will remain. Users will get a 404 error trying to retrieve this content.
This applies to all endpoints, keeping in mind batch files, archive policies, software retirement, etc. Performing regular backups and system health checks can help alleviate these errors.
© 2024 Quest Software Inc. ALL RIGHTS RESERVED. Feedback Términos de uso Privacidad Cookie Preference Center