Configuration for specific types of websites is contained in various kinds of XML files, such as the Onet. In addition, several classes in the SharePoint object model have property bags that can be used to store custom configuration information for specific objects, such as objects that represent websites, Features, alerts, and files.
NET HttpContext object of the request. The SharePoint object model adds an SPContext class that does not inherit HttpContext ; however, it gets many of its property values from the current HttpContext object and adds other properties to represent SharePoint-specific context information, such as the current website, list, and list item. Some exceptions are noted later.
SharePoint has its own installation system. These are CAB files that have a special extension:. SharePoint solution package files can contain several kinds of elements, including assemblies, user controls, custom ASP. JavaScript files and Silverlight.
There are two kinds of solutions in SharePoint: farm solutions and sandboxed solutions. The differences between them are discussed in this section and in Worker Processes, Farm Solutions, and Sandboxed Solutions later in this article. The terms "solution" and "feature" are familiar in software development. The first thing to note about the SharePoint deployment model is that these terms are names of formal components of SharePoint that are defined in this section.
By convention, "Feature" is capitalized when it refers to the SharePoint component of that name. Throughout this article, I will follow the additional convention of italicizing "farm solution," "sandboxed solution," and "solution" when the SharePoint component is being referenced. When either "solution" or "feature" is lowercase and not italic, it is being used in its ordinary sense. Farm solutions are deployed by farm administrators to the farm's solution store, which is in the farm's configuration database.
This is done by using either the SharePoint Management Shell or the object model. Sandboxed solutions are deployed to a specific site collection's Solution Gallery by a site collection administrator. The gallery is a special SharePoint list, so it is in the content database.
For information about the difference between site collections and websites, see Middle Level Object Model later in this article. Thus, SharePoint Solution Package files are never installed to the file system of any server, although elements of a farm solution may be installed to the file system when the solution is deployed. Deploying : The solution package is unpacked and its elements are deployed to their appropriate places.
For a farm solution , this step also requires a farm administrator and can be done by using either Central Administration or SharePoint Management Shell, or the object model. Some examples of how elements are deployed: user control files.
For sandboxed solutions , the deployment step is taken by a site collection administrator. There are limits on what kinds of elements can be in sandboxed solutions and where they can be deployed. For example, nothing can be deployed to the file system of the servers from a sandboxed solution. Features in sandboxed solutions are deployed to the content database. It is also in this second step that any Features in the solution are installed in the Feature Gallery of the farm, web application, site collection, or website, depending on the scope of the Feature.
For more information about the relations of farm, web applications, site collections, and websites to one another, see Content Hierarchy later in this article.
Within a SharePoint solution package, there can be an additional level of encapsulation because a solution can have one or more SharePoint Features. A Feature can be installed at the scope of the farm, the web application, the site collection, or the website. After it is installed, a Feature must be activated by owners of any website within the scope; so Activating becomes a third step of installation for Features.
Features can contain content types, controls, custom actions, custom fields, files, workflows, list instances, list templates, event receivers, and document converters; although some of these cannot be included in certain scopes. Features that are deployed in sandboxed solutions can be scoped only to a site collection or website. For site collection-scoped features in sandboxed solutions , the second and third steps are combined.
The Features are activated when the solution is deployed. SharePoint is not consistent in its terminology with regard to installation. The terms adding , deploying , and activating are the most frequently used to refer to the three steps of installation; but depending on what tool is used to complete a step and whether the solution is farm or sandboxed, you will see a variety of terminology.
The first step may be called adding , installing , or uploading. The second step may be called deploying , activating or installing. There is a similar inconsistency in the terms for reversing these steps; but most commonly, reversing the second step is called retracting and reversing the first step is called removing.
The third step, which applies only to Features, is always called activating , and its reversal is always called deactivating. Some SharePoint solutions target one of the client object models, either exclusively or in addition to targeting the server object model: the JavaScript, Silverlight, and Microsoft. NET Framework client object models. For more information about the client object models, see Client Object Models in SharePoint later in this article.
There is nothing unusual about the installation of the client portion of such solutions. The script files that define the JavaScript object model are downloaded to a client computer when a page that references them is opened.
Similarly, a Silverlight. The SharePoint assemblies that contain the Silverlight client object model are encased in the. Those assemblies are Microsoft. It is also possible to cache these assemblies on the front-end web server. The assemblies that contain this client object model, Microsoft. NET application; but in SharePoint, the distinction between farm solutions and sandboxed solutions entails some more complex scenarios.
SYS, detects the request and routes it to the application pool that is handling requests for the targeted IIS website, and thus, the targeted SharePoint web application. Every application pool has an IIS worker process w3wp.
For more information about the IIS 7. On a SharePoint server, the IIS worker process runs in the application pool account, which gives the process read and write permissions to SharePoint resources. This should be a different account from the farm administration account. The latter is also not a local machine administrator on any farm server. An exception is made for the application pool of the Central Administration web application: its application pool account is the farm account.
Also, the SharePoint Timer Service executes in the context of the farm account. For more information about the accounts needed in a SharePoint farm, see Plan for administrative and service accounts Office SharePoint Server. However, unlike a standard ASP. NET application, SharePoint makes a distinction between sandboxed solutions and farm solutions. NET application. Sandboxed solutions run in a specially restricted execution environment. This is necessary because sandboxed solutions are installed on and scoped to SharePoint site collections without the intervention of the IT professionals that are managing the SharePoint farm.
To prevent rogue or poorly performing code from slowing or crashing the application pool, SharePoint imposes restrictions on what the code in a sandboxed solution can do. As a crucial part of the implementation of this system, sandboxed solutions must run in a special sandboxed worker process SPUCWorkerProcess.
When a request attempts to access a sandboxed solution , a SharePoint execution manager that runs in the IIS worker process finds a sandbox worker process or starts one, if none is running in which the code of the sandboxed solution will run.
The server that is running the SharePoint User Code Host service can be, but does not have to be, the front-end web server on which the IIS worker process is running. Which server is used is configurable in the Central Administration application: Administrators can choose to have each sandboxed process run in "local mode," which means that each request for a sandboxed solution is processed on the same front-end web server on which the IIS worker process is running; or they can have the execution manager start each sandboxed process in "remote mode," also known as "affinity mode.
This would be the case if that same sandboxed solution was requested before, possibly by another user on another site collection. If there is a matching application domain, the request is sent to that same application domain for handling.
If none of the servers that are running the SharePoint User Code Host service already has an application domain for the sandboxed solution , the execution manager assigns the request to the least busy of those servers. The server then creates the needed application domain and processes the request for the sandboxed solution.
The application domain stays alive after the request is processed and is reused if there is another request for the same sandboxed solution. By default, all sandboxed solutions that are handled by a given server run in the same sandbox worker process, but this is configurable through the object model.
Each sandboxed solution gets its own application domain within the common process, and this, too, is configurable through the object model. The SharePoint User Code Host service runs in an account that has the same rights as a typical application pool account.
All code that runs in this sandbox worker process is subject to execution and access constraints. There are two systems of constraints: One applies to all and only calls to any assembly, except Microsoft. The other applies to all and only calls made to the parts of the SharePoint Foundation object model that are in the assembly Microsoft. The calls that this second system applies to are not just calls in custom SharePoint solutions. Calls to Microsoft. A highly restrictive code access security CAS policy significantly limits what code in the sandboxed worker process can do.
Among the restrictions imposed by the CAS policy are the following:. Code in the sandbox can call only the. This blocks access to about two-thirds of all the.
Printing , for example. These are granted full trust. The token denies the process the right to call to the network. Therefore, only resources available on the server that is running the sandboxed worker process may be accessed. An external database, for example, cannot be accessed.
The token denies the right to call to any assembly that is not in the general assembly cache, even if it has the AllowPartiallyTrustedCallersAttribute attribute and would otherwise be eligible to be called from the sandboxed worker process. As noted, a second system of constraints imposes restrictions on what APIs in Microsoft. The implementation of these restrictions is accomplished by a pair of specially restricted versions of the Microsoft.
One of the two assemblies is loaded by the sandboxed worker process. The standard Microsoft. The main job of the two shim assemblies is to filter out forbidden SharePoint classes and members.
When the sandboxed solution calls an approved API, the first shim assembly passes it to the second in the proxy process, which in turn passes it to the standard Microsoft. Any returned results are passed back to the original calling code.
This cross-process interaction is possible through. NET Framework remoting. A sandboxed worker process and a full-trust proxy process are always started together and paired with one another. If either process crashes, the other is also stopped. The shim assemblies also have a secondary job. Some SharePoint APIs are available to sandboxed solutions , but only with special restrictions on the parameters that are passed to them.
It is the shim assemblies that enforce these input restrictions and ensure that an exception is thrown when there is a violation. These constructors can be called in sandboxed solutions , but only URLs or GUIDs that refer to the site collection in which the sandboxed solution is running can be passed to them. Because the second shim assembly and the standard Microsoft. For example, the GetLocalizedString method can read.
However, a file cannot be deployed to disk in sandboxed solution , so the. The SPWebApplication class cannot be accessed. Among other things, this means that a sandboxed solution cannot access anything outside its hosting site collection. Almost all classes in the Microsoft. WebControls namespace cannot be accessed, which means that you are mainly restricted to ASP. NET controls in sandboxed solutions. For a complete list of APIs in Microsoft. The deployment stage of a sandboxed solution itself runs in a sandboxed worker process and is subject to the same execution constraints.
For example, you cannot deploy a file to the disk when you are deploying a sandboxed solution. This is the main reason why a user control ASCX file cannot be in a sandboxed solution. See SharePoint Deployment Models for information about the deployment stage.
Sandboxed solutions are also subject to three kinds of resource usage restrictions that can be organized based on the kind of entity to which the restriction applies and the kind of entity on which the penalty for exceeding the restriction is imposed. Per Request with the Request Penalized: There is a hard limit to how long a sandboxed solution can take to finish. By default, this is 30 seconds. If a sandboxed solution exceeds the limit, the request but not the sandboxed worker process is terminated.
This limit is configurable, but only through custom code against the object model. The relevant parts of the object model cannot be accessed by sandboxed solutions , so no sandboxed solution can change the limit.
Per Request with the Process Penalized: A set of 15 resource limits apply to requests. If a request exceeds one of them, the process and all the sandboxed solutions that are running in it is terminated. These points accumulate based on an algorithm that takes into account the use of resources in the 15 resource categories by the sandboxed solutions that are installed in the site collection. When a site collection exceeds its maximum allowed points, all sandboxed solutions in the site collection are terminated and no more can run for the rest of the day.
SharePoint provides a solution validator framework that can be used to develop custom solution validators, such as a validator that verifies whether a solution is signed with a specific certificate. The validators in a site collection run when a sandboxed solution is activated that is, deployed, in the terminology used earlier in this article. The activation of any invalid solution is blocked. If a validator is updated or a new validator is added, each activated solution is rechecked by the validators the next time it is executed.
Invalid solutions are deactivated. For more information about the sandbox restrictions, see Sandboxed Solutions in SharePoint and its child topics and the Microsoft patterns and practices guidelines for Sandboxed Solutions. A solution that is designed to run in the sandbox can be deployed by a farm administrator as a farm solution.
It might perform better if it is, because it would run in the IIS worker process instead of the sandboxed worker process. Not all SharePoint execution is in an IIS worker process, a sandboxed worker process, or the proxy process.
The following are some examples:. The SharePoint Timer Service owstimer. It runs under the farm account. Within the category of farm solutions , a further distinction can be made when the requested resource is an. If the requested page is what SharePoint calls an application page , the returned page is passed to the regular ASP.
NET page parser; but if the requested page is what SharePoint calls a site page , the returned page is routed through a special safe mode parser. The distinction between the two kinds of parsing is best understood in light of the distinction between the two kinds of pages. For more information about both subjects, see Pages, Parsing, and Safe Mode later in this article.
Application pages cannot be included in sandboxed solutions. All pages installed as part of a sandboxed solution use safe mode parsing. Farm solutions divide into two types depending on where their assemblies are deployed and the trust level of the assemblies' execution:. They are callable from any SharePoint web application on the farm. They have to be separately deployed to every SharePoint web application that needs to call them.
Sandboxed solutions are deployed inside a SharePoint solution package. Thus, they are deployed and persisted in the site collection's content database. As noted earlier, they do not run in full trust: Instead, they run within a highly restricted CAS policy and can only call a restricted subset of the SharePoint object model.
A sandboxed solution can be accessed only in site collections to which it is deployed. When a sandboxed solution is accessed for the first time, such as when a user navigates to a page that contains a Web Part from a sandboxed solution , any assemblies in the solution are unpacked from the solution package and copied to the file system of the server that is handling the sandbox request. Recall that the server that handles the sandbox request is not necessarily the front-end web server that is handling the initial HTTP request.
The User Code Host Service can be run on back-end application servers in the farm instead. Because the sandboxed worker process cannot copy anything to the file system, the copying is done by the User Code Host Service. The assemblies do not stay in the file cache perpetually. When the user session that accessed the assemblies finishes, the assemblies stay in the cache for only a short time, and they may be reloaded from there if another user session accesses them.
Eventually, if they are not accessed, they are removed according to a proprietary algorithm that takes into account how busy the server is and how much time has gone by since the assemblies were last accessed. If the sandboxed solution is used after that time, the assemblies are unpacked again and copied to the UCCache. Administrators, developers, and third-party code should not add, remove, or load anything from the UCCache. It should be accessed only by the SharePoint infrastructure.
The SharePoint solutions architecture includes a technique by which a sandboxed solution can call custom operations that run in full trust. The technique requires that a farm solution be developed that includes one or more classes that derive from SPProxyOperation. Each of these defines an operation that will run in full trust and can be called from sandboxed solutions by using the ExecuteRegisteredProxyOperation method. The proxy operations can return data to the sandboxed solution.
Like all farm solutions , the assembly with the proxy operations can be deployed only if it is from a trusted source. Figure 6 shows how a request that accesses a sandboxed solution is processed when the sandboxed solution makes a call to a full-trust proxy. The preceding description might give the impression that, with the hybrid technique, a farm solution and a sandboxed solution are always developed together by the same development team.
In fact, the farm solution may be developed specifically to provide certain operations to any and all sandboxed solutions that need those services, including sandboxed solutions that are developed by other teams. For example, because a sandboxed solution cannot write to the SharePoint Unified Logging Service ULS logs, a farm solution that opened proxy logging operations to sandboxed solutions would be very useful.
Another hybrid technique uses client-side code to access the resources that cannot be accessed from a sandboxed solution. For example, a sandboxed solution could include a custom site page with JavaScript that makes calls to the SharePoint JavaScript client object model.
Also, a sandboxed solution could include a Web Part that hosts a Silverlight application. The latter application can make calls to the SharePoint Silverlight client object model. Both of these kinds of pages can be mergers of master and content pages and, indeed, every ASCX page that is built into SharePoint, whether it is an application page or a site page, is a combination of a master and content page.
Typical purpose : Application pages tend to be function-oriented, especially functionality that is needed by many kinds of websites within a given web application; for example, the standard form for creating a new list item is an application page.
Site pages tend to be content-oriented; for example, the list-of-lists page of a standard team site. However, exceptions to both tendencies are possible. Indeed, we currently recommend that third-party developers develop custom Web Parts, which can be added to site pages, to handle their solution's functionality whenever possible, rather than develop custom application pages.
Customizablility : Site owners and other users who have appropriate permissions can customize site pages, but not application pages.
Users can also add an entirely new ASCX page to a website's Site Pages gallery, but only web application administrators can install a new application page. All of these classes derive from the ASP.
NET Page class. They can have static Web Parts, but there is little point to using a static Web Part instead of an ordinary control on an application page because end users cannot customize application pages anyway. See later in this section for more information. A site page that has been customized, such as with Microsoft SharePoint Designer, is stored in the content database of the website for which it was customized.
New site pages that have been added to the Site Pages gallery are stored just as customized pages. Even an uncustomized site page has an entry in the content database; but whereas the entry of a customized page contains the ASPX markup that constitutes the page, the entry for an uncustomized page contains the path of the. An uncustomized page can be shared by many websites. If it is, it is referenced in each website's content database, with all the entries pointing to the same physical file.
For example, every Team Site has a content database entry pointing to the default Team Site home page. Rights-managed documents that are downloaded before the specified stop date stay rights-managed in the client application, even after the specified date, because the document itself does not include this setting. After the user checks the document back in after the specified date, however, the document protection is removed.
For example, a financial institution may be required to make certain information public on a quarterly basis. Before such a date, however, the institution might want to restrict access to the files containing that information, to prevent premature disclosure.
Because companies often have restrictions that require their files to be stored in nonencrypted formats, SharePoint Foundation does not store files in encrypted, rights-managed file formats. However, SharePoint Foundation calls an IRM protector to convert the stored file to an encrypted format each time a user downloads the file.
Similarly, when a user uploads a rights-managed copy of a file, SharePoint Foundation calls the appropriate IRM protector to convert that copy to a nonencrypted format before it is stored. As a result, you do not need to create custom solutions to enable searching or archiving of document libraries where IRM is enabled.
Storing the files in nonencrypted format ensures that the current Search indexing service is able to crawl content stored on the servers. Search results are already scoped to user permissions, so the user never sees search results that include content to which they do not have some level of access. SharePoint Foundation determines the access privileges to grant a user based on the access control list ACL entry of that user.
The permissions listed are additive; each permission level includes the access rights of the permission level below it. Full control of the documents, as defined by the client application. This generally permits the user to read, edit, copy, save, and modify permissions of the document.
Edit, copy, and save permissions. The user can print the document only if the document library IRM settings are configured to allow document printing. Read permissions. In both cases, you must manually install any prerequisites and configure Exchange, SharePoint, and File Classification Infrastructure to use Rights Management. For most organizations, automatic configuration by using the server configuration tool for Microsoft RMS connector will be the better option, because it provides greater efficiency and reliability than manual configuration.
After making the configuration changes on these servers, you must restart them if they are running Exchange or SharePoint, and were previously configured to use AD RMS. There is no need to restart these servers if you are configuring them for Rights Management for the first time. You must always restart the file server that is configured to use File Classification Infrastructure after you make these configuration changes.
Edit your registry settings automatically, by using the server configuration tool for Microsoft RMS connector. The prerequisites are automatically checked for you but not automatically remediated if you run it locally. Disadvantages include : When you run the tool, you must make a connection to a server that is already running the RMS connector. Advantages include : No connectivity to a server running the RMS connector is required. Save the GenConnectorConfig.
If you will run the tool locally, this must be the server that you want to configure to communicate with the RMS connector.
Otherwise, you can save it on any computer. This tool configures the servers that will communicate with the RMS connector and that are listed at the beginning of this section. Do not run this tool on the servers that run the RMS connector. Start Windows PowerShell with the Run as an administrator option, and use the Get-help command to read instructions how to the use the tool for your chosen configuration method:.
The tool then uses that URL to contact the servers running the RMS connector and obtain other parameters that are used to create the required configurations.
When you run this tool, make sure that you specify the name of the load-balanced RMS connector for your organization and not the name of a single server that runs the RMS connector service.
Configuring an Exchange server to use the connector. Configuring a SharePoint server to use the connector. Configuring a file server for File Classification Infrastructure to use the connector.
When to install client applications on separate computers, which are not configured to use the connector. After these servers are configured to use the connector, client applications that are installed locally on these servers might not work with RMS. When this happens, it is because the applications try to use the connector rather than use RMS directly, which is not supported. In addition, if Office is installed locally on an Exchange server, the client app's IRM features might work from that computer after the server is configured to use the connector, but this is not supported.
In both scenarios, you must install the client applications on separate computers that are not configured to use the connector. They will then correctly use RMS directly. Office extended support ended on October 13, To use the RMS connector, these servers running Exchange must be running one of the following software versions:.
0コメント