نکاتی شرپوینتی (sharepoint tips)
سلام اینجا بهتره هرکی نکاتی که باهاش مواجه میشه رو بذاره.
اینم یه سری نکات:
[LEFT]Have the ratio of 5 Web Front Ends per 1 SQL Server
If you have user who use SharePoint – page hopping for more than 20 minutes at a time – you need to look at Kerberos authentication
1 Domain Controller per 3 Web Front Ends – ensure they are in the same subnet mask as well
No more than 10 Web Applications per Farm
A good quota for uploading documents 50MB.
User RAID 10 for SQL Server – but yes it is expensive
Pre-grow your SQL data file to the maximum size you want it
Content DB size limitation – 100GB
64bit – in case you hadn't heard – the next version of SharePoint is 64bit only
If you are patching your server – disconnect your ContentDB as it will save time on the patching. Almost save 3/4 of the time
defrag your ContentDBs
Ensure your farm is on at least Infrastructure update
No CNames[/LEFT]
چه فایل هایی را در شرپوینت ذخیره نکنیم!
[LEFT][LTR]Purpose
The purpose of this document is to provide prescriptive guidance around what doesn't work well for storing in SharePoint Server, SQL Content databases.
In general terms, SharePoint is an excellent data repository upon which users can store their data, whether for personal or shared use. There are, however, specific scenarios in which SharePoint is not the optimal storage location.
Large Files and Files with Dependencies
SharePoint is designed to be a collaboration platform and is not designed to be a replacement for local file servers as a pure storage platform. To that end, you can store any type of files on SharePoint as long as the files are each smaller than 2GB hard limit and 50MB by default (this can be configured to be changed up to 2GB). The remote blob storage API mentioned in a hotfix won't support files larger than 2GB either. It is still possible to create links to wherever the file might live to make it a common interface which is commonly the goal.
File types scenarios that do not work well in SharePoint listed below.
Linked Files and Documents
Linked documents and files cannot be run from a SharePoint site, as the dependency on an external sources isn’t captured in SharePoint. For example, the URL references created in a linked Excel file when it is uploaded to a SharePoint site are not translated by Excel, and the links will not work. The creator of an AutoCad file would be responsible for ensuring the file was either not linked to other files or are consistently created in the appropriate file format (*.dwf). In all situations, SharePoint is unable to resolve embedded links in documents/files.
Common examples include: Linked Excel worksheets, inclusions or links within AutoCad drawings. Some newer linked excel worksheets do work. If there are SMB based links they likely won't. Some great workarounds exist now by creating workbooks that generate reports in web parts. Linked web parts are another great work around for many scenario. Published excel worksheets often maintain links, but this is a scenario I recommend validating your scenario.
Database, Configuration, and Log Files and files which require locks
In order to properly use database files, configuration files and log files, they need to be open and in a locked (writable) state. For example, in a normal file server scenario, shared MS Access databases need have several instances of the database open and locked to allow for users to update it. Similarly, log files and configuration files must be locked and in a writable state. Outlook *.pst files are designed to be used locally, as they have a one to one relationship with the *.pst file owner. SharePoint is not designed to manage locked files (.lck)and therefore it would not be a best use of the platform to run these types of files from a SharePoint site. They can, however, be stored in SharePoint, but would need to be downloaded to the local machine to work effectively. For more examples of the file types that are not designed for use on SharePoint, see the Incompatible File Types section below.
Common examples include: Windows configuration files, application log files, Outlook personal stores and archive stores (.pst) and offline stores (.ost).
Exceptions: Email enabled lists are a work around for mail storage. Access database tables can now be easily published or linked with read or read/write to SharePoint lists. Building applications in Access 2007 and using SharePoint lists is a very powerful scenario and not to be dismissed. I do hear a lot of corporations moving their Access Dbs to SharePoint, but there are some still very powerful scenarios performed by power users via the the Access UI.
With email when you're getting into the millions or even hundreds of thousands of archived mails it really becomes very difficult to manage in a single list without special design work. The search interface is nice, but when you need to do anything major around updates or moves or deletes it can be difficult.
Application Developer Resources and Source Control (i.e. files commonly generated by Visual Studio)
Visual Studio and similar application development suites are designed so that developers can build applications and deploy them to others. This application work is often broken up into project files during development, with the goal of compiling the project files into a final executable file.
Visual Studio requires that all the project files associated with a development project be local to the machine in order to work. While the project files can be uploaded to SharePoint to be shared with other developers, the best practice is to use a file compression utility (i.e. WinZip) to collect and upload the *.zip file to SharePoint.
While SharePoint is an excellent document control/document versioning tool, it is not designed to be replacement for a Source Code Control solutions similar to Visual Source Safe. The Visual Studio Foundation Server for team or project collaboration is an example of integration, and I'm in these scenarios the source is stored in the databases. (Thanks to the comments.)
Application Distribution
SharePoint is not designed to be a host for Product or Application distribution similar to the functionality provided in Microsoft Systems Management Server (SMS), or as a replacement for a network server that is used to distribute application packages.. The recommended application here would be to create a SharePoint site and provide hyperlinks to the server location where the application packages are stored. Microsofts own [url]http://productsweb[/url] and [url]http://toolbox[/url] are both internal corporate examples of SharePoint Server as the UI for a file share for official product and tool distrubution. The Storage is file servers and DFS and the Frontend including a rich search UI. These tools and products are outside the ones normally advertised via SMS designed for the developers, testers and engineers which are admins on their own boxes and provides a facility to share their code promoting community and reusability with each other.
Server Side Scripts
It is not recommended that any server-side scripts be uploaded to SharePoint doc libraries as they will be rendered as text on the screen, and will not run from within a SharePoint site. They are also blocked by default. I think it's with good reason. Sure they aren't executable by default, but who knows what might happen if they are downloaded or if the mime types get associated... Server side script outside of the _layouts or outside an inclusion is a bad idea.
Examples: ASP, ASA, DLLs, etc...
Backup
SharePoint is not designed to act as a backup (i.e. *.bak, *.iso, etc) resource. IT recommends no more than 10GB for a site collection in a shared database. I've mentioned 15GB without dedicated database. It doesn't really make sense as a backup server, but even as an archive special attention has to be made to appropriately scale the servers and to consider what makes sense when the data is in SQL transactional storage.
Large Media
Storing movies or streaming content is better served on media servers. Small sound files or small clips less than 100MB (the current limit on YouTube also around 10 minutes) is a good limit for this type of media. You may find reasons to increase your timeouts and increase the maximum capacity, but high quaility long wmv is much better served with Media server integration. Some great work has been done in the space of using SharePoint in digial asset media management. Have you seen the solution Interactive Media Manager with SharePoint player and workflow manager? Rich SharePoint UI for workflows and file management, but the large files is what pushes a solution that tries to store the super large files.
More than once I've heard people using SharePoint's search inteface the rich links list with required metadata and properties with integrated players as web parts.
Careful with Non "Web Friendly" Characters and Long File and Long Site Names
More data on this topic at the post referenced in the first paragrpah. SharePoint sites may not include the following characters:
\ / : * ? " < > | # { } % & <TAB>”.
Additionally, the following characters cannot be used in the naming of files to be uploaded to SharePoint:
" # % & * : < > ? \ { | } ~ .
SharePoint file names cannot exceed 128 characters in length. Filename + folder structure + site structure + hostname should not exceed 260 characters. I'd say avoid pushing 200 characters total if you can. That way you aren't up against the edge of this hard limit at 256-260. I'm not saying to use numbers for filenames or sites, though some have used this for shortening URLs. I'm saying keep your host names tight, limit depth to about 4 sites at a near max. It's possible to go out really deep with short site names, but if you try to set guidance at less than 5. Lower than that you'll find it becomes pretty unusable from a usability and worse with things like truncation in email or link lists (SharePoint link list limit 256) becoming more common.
<update>
A couple of comments asked questions...
Would I ever support .exe in SharePoint Deployments? Yes, I have found customers that don't want to support both file server and SharePoint. My recommendation was to remove all blocked file types (and to run Forefront security for SharePoint) and then manage apps that have issues by having them request exceptions and pay for consolidated file servers that are strictly managed with charge back to the department/division.
What about Content Database sizes when you're storing tons of content? My rule of thumb is 100GB for the huge environments, but for single super large site collections I would make exceptions where disaster recovery and backup is taken care of. Snapshots and mirrored environments would be other examples where I'd make exceptions to going beyond 100GB per db. In medium and smaller environments 25 and 50GB databases are totally realistic and more manageable.[/LTR][/LEFT]
