نمایش نتایج: از شماره 1 تا 5 از مجموع 5
سپاس ها 5سپاس
  • 2 توسط mehdiiiii
  • 1 توسط mehdiiiii
  • 1 توسط mehdiiiii
  • 1 توسط mehdiiiii

موضوع: نکاتی شرپوینتی (sharepoint tips)

  
  1. #1
    نام حقيقي: مهدی هلاکویی

    عضو عادی
    تاریخ عضویت
    Oct 2009
    نوشته
    502
    سپاسگزاری شده
    231
    سپاسگزاری کرده
    130

    نکاتی شرپوینتی (sharepoint tips)

    سلام اینجا بهتره هرکی نکاتی که باهاش مواجه میشه رو بذاره.
    اینم یه سری نکات:

    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




    موضوعات مشابه:
    ARM و yeganeh_p سپاسگزاری کرده‌اند.

  2. #2
    نام حقيقي: مهدی هلاکویی

    عضو عادی
    تاریخ عضویت
    Oct 2009
    نوشته
    502
    سپاسگزاری شده
    231
    سپاسگزاری کرده
    130

    نکات ۲

    1. Configure Firewall Rules lock down to most restrictive w/ acceptable level of usability (i.e. outbound HTTP)
    2. Secure client communication with trusted SSL certificates (128bit HTTPS)
    3. Use IPSEC Require mode between servers (Policy) Especially for secure communication between servers and DCs * Be careful with NLB. You can do also this on your Intranet with request mode, I recommend not using client require mode for non windows and legacy clients (MAC/Unix/Win 98)
    4. Enable Kerberos Authentication (Intranet) *Careful with NLB
    5. SQL SSL encrypted Traffic + Non Standard Port
    6. Configure Central Admin on public internet facing servers on non routable IP (Index Server) Configure 2 factor and double hop access. i.e. 2 Factor auth VPN to TS to administration server to administer farm with specific IP rules to TS box.
    7. Restrict IP Traffic on Central Admin and SSP App Pools (IIS)
    8. Configure Deny Policies (Not Auth Users) on Content/Admin Web Apps for Applicable Groups/Domains, configure deny policy for Server Admins on all web apps (use Special non privileged accounts for administration of SharePoint farm)
    9. Configure ISA Secure Publishing (or reverse hosting) better than Router ACLs (Rejects Invalid Requests and Verbs)
    10. Configure at least 1 DMZ aka 2+ Firewalls/Interfaces between corp and publicly addressable Internet (ISA 2006 Recommended)
    11. Test/Run Windows R2 Server SCW (Security Configuration Wizard) (Custom Template)
    12. Consider Basic over SSL alternatives… SSL with FBA with Expiring Cookies
    13. Configure and enforce Auditing Policies on Site Collections (Solution Deployment & Timer job), Enable WSS & MOSS Usage Reporting
    14. Remove unused server side extensions (i.e. ASP, HTA, IDX, etc..) and unused .NET extensions and verbs (Debug)
    15. Disable the Web Services that are not used. i.e. SSP & Central Admin
    16. Ensure that Any Auth traffic is secured between DC & Servers (IPSEC)
    17. Ensure inbound email services are configured for auth users, and lock down SMTP/Outbound to allow only specific IPs
    18. Stop unused services (this will require testing)
    19. Configure Site Collection Quotas
    20. Increase blocked file types to include non approved content
    21. Install Antivirus Protection (Recommended FrontBridge with Inbound scanning and regular scan of all at a minimum, filter content as well)
    22. Monitor for suspicious activity & Review #Failed Login Attempts Security Logs – Use Black Ice or other intrusion Detection software on all servers in the farm with reporting and alerting
    23. Lock down SSC (Self Service Creation) to few trusted Support/Service groups
    24. Run service accounts with domain accounts, run SSP and Central admin with different service accounts (ensure these accounts have no special rights)
    25. Lock down SQL with relevant lockdown/hardening guides, remove server admin role and rights



    Configure and/or lock down Excel safe locations. This will give you more control over calc perf.
    Consider Extranet Mode (limited UI mode/prevents SOAP interaction and depricates UI)
    Remove people picker AD lookups on extranet (stsadm -o setproperty peoplepicker-nowindowsaccountsfornonwindowsauthenticationmode)
    Secure LDAPs (636) over SSL
    Lock down web services to the service accounts that need them (going to the files on the file system and changing file system security)
    Ensure outbound is restricted to only what is needed. Need to consume (outbound) XML web services or RSS feeds?
    Configure RPC DCOM server communication end points to static high ports
    Ensure Web Front Ends can talk to all Query boxes (even if they are on other web front ends)
    Disable Anonymous auth throughout the farm (off by default)
    Ensure policy against using authenticated users is well communicated and policed
    Thinking about email archiving and email enabled lists... I'd recommend not using it when internet/extranet facing. Configuration allowing anonymous email is in the site collection/list level.
    I'd also recommend against anonymous blog comments, there are way too many spammers out there. There isn't any approval mechanism without enabling workflows and there are a lot of potential opportunities for spammers. Overall anonymous contribution scenarios should be highly thought out.
    Web Based Forms and Forms Server does have some great scenarios, but if you aren't using it, lock down the anonymous posting services (disabled by default)
    Considering SQL auth to the SQL box in a separate locked down area? I'm a long time fan of getting the data/SQL in a separated isolated behind a firewall with no outbound holes and no service from the public DMZ accounts. I think I already mentioned it, but I'm a fan of non standard SQL ports even more than SQL traffic over SSL. If the traffic is bad who cares if it's encypted bad traffic. Maybe I'm not the only one who spent some time with slammer.
    Your SharePoint farm should be on Non Routable IPs, which goes to say... not directly in DNS.



    ویرایش توسط mehdiiiii : 2010-08-14 در ساعت 10:48 AM
    ARM سپاسگزاری کرده است.

  3. #3
    نام حقيقي: مهدی هلاکویی

    عضو عادی
    تاریخ عضویت
    Oct 2009
    نوشته
    502
    سپاسگزاری شده
    231
    سپاسگزاری کرده
    130

    چه فایل هایی را در شرپوینت ذخیره نکنیم!

    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 http://productsweb and http://toolbox 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.



    ARM سپاسگزاری کرده است.

  4. #4
    نام حقيقي: مهدی هلاکویی

    عضو عادی
    تاریخ عضویت
    Oct 2009
    نوشته
    502
    سپاسگزاری شده
    231
    سپاسگزاری کرده
    130

    1 — Design your Document Taxonomy

    Before you even start using SharePoint for your document-centric workflows, create content types for each type of document, taking care to define the meta-data that must also be captured with this document. Think about the full life-cycle of the document and what data will be needed at each step.
    2 — Scan your paper documents into SharePoint.

    Many transactions start as paper, so get them into SharePoint as soon as possible. Advanced image processing techniques, such as forms recognition and OMR, can detect the content type and kick off the correct workflow automatically.
    3 — Extract information with OCR, barcodes, and manually.

    Documents that start as paper need to have their meta-data extracted from the document image that results from the scan. This can be done automatically with OCR and barcodes or manually. Even if it’s done manually, OCR can assist the data entry.
    4 – Automate your workflows as much as possible.

    Building workflows can get complicated very quickly so start with simple processes first. As your workflows become more complex the key is to minimize the need for manual intervention as much as possible.
    5 — Use document viewers that are SharePoint-aware.

    When you do need view documents in a workflow, use a document viewer that is SharePoint-aware. When you open a file with Office in SharePoint, it knows that the document came from SharePoint and can save modifications and follow your checkout procedure. But, what about other types? There are third-party viewers that are SharePoint-aware, or even better, are integrated right into SharePoint’s web interface.
    6 — View documents in context.

    When working on a document, use viewers that can show you more than just the document. To efficiently work on a document you need to see its meta-data, its location in SharePoint, and any outstanding workflows.
    7 — Use side by side comparison.

    Many transactional workflows need to view two documents at the same time. For example, in accounts payable, you need to see the invoice and the purchase order simultaneously in order to pay the bill. Use document viewers that can support side-by-side viewing with some kind of page synchronization.
    8 — Plan for Archiving and Retention.

    The full lifecycle of a document includes its transition into a record. Design your content-types so that different policies are represented in the documents meta-data and use workflows to trigger the transition automatically.



    ویرایش توسط mehdiiiii : 2010-08-22 در ساعت 11:08 PM

  5. #5
    نام حقيقي: مهدی هلاکویی

    عضو عادی
    تاریخ عضویت
    Oct 2009
    نوشته
    502
    سپاسگزاری شده
    231
    سپاسگزاری کرده
    130
    داشتم داخل گوگل داک کار میکردم به این برخوردم که کلی لینک و نکته از شرپوینت گذاشته دیدم بدک نیست شماها هم استفاده کنید

    https://docs.google.com/previewtempl...Zy&mode=public


    SADEGH65 سپاسگزاری کرده است.

کلمات کلیدی در جستجوها:

sharepoint را

stsadm

sharepoint

stsadm peoplepicker 636

برچسب برای این موضوع

مجوز های ارسال و ویرایش

  • شما نمی توانید موضوع جدید ارسال کنید
  • شما نمی توانید به پست ها پاسخ دهید
  • شما نمی توانید فایل پیوست ضمیمه کنید
  • شما نمی توانید پست های خود را ویرایش کنید
  •