Sharepoint General

Why Sharepoint is not a viable solution for enterprise wide deployments?

Planning an enterprise deployment using SharePoint features is a very difficult task unless you can establish a Service Oriented Architecture, using AD for managing security with well defined roles based information access(EISA). Sounds reasonable, although it seems difficult to deploy with the tools limitations in document storage.

Document management does not scale beyond a single server, but scales great within a single server. For example, a quad Xeon machine with 4GB of RAM works great for a document management server that has about 900,000 - 1,000,000 document, but if you need to store 50,000,000 document and want to have them all in one single workspace then it does not scale at all. If you need a scenario like this, you need to plan your deployment right and it should scale for you, it just does not right out of the box. If you are using your server as a portal and search server most for the most part it scales great. You can have many different servers crawl content sources and have separate servers

searching and serving the content.

If you have < 750,000 documents per server and fewer than 4 content sources and fewer than 50,000 users, SPS should scale just fine for your needs with the proper planning.

What are the actual advantages of SharePoint Portal Services (SPS) over SharePoint Team Services (STS)?

SharePoint Portal Services (SPS) has MUCH better document management. It has check-in, check-out, versioning, approval, publishing, subscriptions, categories, etc. STS does not have these features, or they are very scaled back. SharePoint team Services (SPS) has a better search engine, and can crawl multiple content sources. STS cannot. STS is easier to manage and much better for a team environment where there is not much Document Management going on. SPS is better for an organization, or where Document Management is crucial.

How Does SharePoint work?

The browser sends a DAV packet to IIS asking to perform a document check in. PKMDASL.DLL, an ISAPI DLL, parses the packet and sees that it has the proprietary INVOKE command. Because of the existence of this command, the packet is passed off to msdmserv.exe, who in turn processes the packet and uses EXOLEDB to access the WSS, perform the operation and send the results back to the user in the form of XML.

 

Why Sharepoint is not a viable solution for enterprise wide deployments?

Planning an enterprise deployment using SharePoint features is a very difficult task unless you can establish a Service Oriented Architecture, using AD for managing security with well defined roles based information access(EISA). Sounds reasonable, although it seems difficult to deploy with the tools limitations in document storage.

Document management does not scale beyond a single server, but scales great within a single server. For example, a quad Xeon machine with 4GB of RAM works great for a document management server that has about 900,000 - 1,000,000 document, but if you need to store 50,000,000 document and want to have them all in one single workspace then it does not scale at all. If you need a scenario like this, you need to plan your deployment right and it should scale for you, it just does not right out of the box. If you are using your server as a portal and search server most for the most part it scales great. You can have many different servers crawl content sources and have separate servers

searching and serving the content.

If you have < 750,000 documents per server and fewer than 4 content sources and fewer than 50,000 users, SPS should scale just fine for your needs with the proper planning.

Why Sharepoint is not a viable solution for enterprise wide deployments?

Planning an enterprise deployment using SharePoint features is a very difficult task unless you can establish a Service Oriented Architecture, using AD for managing security with well defined roles based information access(EISA). Sounds reasonable, although it seems difficult to deploy with the tools limitations in document storage.

Document management does not scale beyond a single server, but scales great within a single server. For example, a quad Xeon machine with 4GB of RAM works great for a document management server that has about 900,000 - 1,000,000 document, but if you need to store 50,000,000 document and want to have them all in one single workspace then it does not scale at all. If you need a scenario like this, you need to plan your deployment right and it should scale for you, it just does not right out of the box. If you are using your server as a portal and search server most for the most part it scales great. You can have many different servers crawl content sources and have separate servers

searching and serving the content.

If you have < 750,000 documents per server and fewer than 4 content sources and fewer than 50,000 users, SPS should scale just fine for your needs with the proper planning.

What are the integration differences between SPS 2003 and the various Office versions?

SPS webpage can detect you have installed the Office 2003 and run local dll to implement some SPS function, e.g. multi-file upload only works when you have office 2003 installed.

Integration with Office XP is gone.

You will get guys telling you that you can integrate with SPSv2 if you install a backwards compatible document library – but that’s really just putting a bit of SPS 2001 on the server.

Believe me, check-in, check-out, which are themselves very basic, are not available from inside Office XP, or even from the context menu in Windows Explorer.

What does partial trust mean the Web Part developer?

If you install assemblies into the BIN directory, you must ensure your code provides error handling in the event that required permissions are not available. Otherwise, unhandled security exceptions may cause your Web Part to fail and may affect page rendering on the page where the Web Part appears.

The following is a typical example of a security exception:

Request for the permission of type 

  Microsoft.SharePoint.Security.SharePointPermission, 

  Microsoft.SharePoint.Security, Version=11.0.0.0, Culture=neutral, 

  PublicKeyToken=71e9bce111e9429c failed

As stated previously, the WSS_Minimal trust level does not grant permission to the SharePointPermission.ObjectModel to assemblies in the BIN directory for an application. Therefore, if your code attempts to use the Microsoft SharePoint object model, the common language runtime (CLR) throws an exception.

Since the minimal permission set provides the smallest set of permissions required for code to execute, the likelihood of additional security exceptions is increased.

Recommendation   Try-catch critical areas to address situations where you may not have the necessary permissions to accomplish a specified objective.