jump to navigation

Manual Install of sharePoint with NLB Windows 2008 February 21, 2010

Posted by juanpablo1manrique in Best Practices, Cluster, Developer, Install, IT, Manual, NLB, SharePoint, Windows 2008.
1 comment so far

For my followers, I publish this excelent manual to Install Microsoft SharePoint Server 2007, the subject than you can find here.

1. Install Share Point Process
2. Configuration Process of Share Point
3. Install NLB Windows server 2008
4. Install Second Node of SharePoint
5. Administration of MOSS 

Happy coding

Best reguards

Version en Español

Advertisements

Buenas Prácticas SharePoint – Rutas Manejadas February 20, 2010

Posted by juanpablo1manrique in Best Practices, Developer, SharePoint.
add a comment

Las Maneged Path (rutas manejadas) permiten a los productos y tencnologias de sharepoint ayudar al sistema a interpretar las URL que determinan donde las colecciones de sitios fueron creadas.

Ejemplo Mundo Real

Usted como administrador de SharePoint de su compañía, necesita crear un grupo de colecciones de sitios en un nuevo grupo de rutas administradas (path named). Los administradores acostumbran crear nuevas wildcard path (rutas comodin) para lograr este objetivo.

Detalles Técnicos

SharePoint utiliza las Rutas Manejadas para determinar si una URL dada debe ser manejada por el sistema. MOSS 2007 o WSS 3.0 permiten crear rutas sencillas (single path) o rutas comodín (wildcard path). Lo cual se entiende que permiten el manejo de una colección de sitios sencilla en un sigle path o manejar múltiples colecciones de sitios en paralelo bajo un wildcard path.

Por defecto las rutas manejadas en MOSS 2007 y WSS 3.0 son rutas sencillas incluidas en el sitio de nivel más alto de la colección de sitios para hospedar el sitio de nivel más alto y las wildcard path se utilizan para  los sitios adicionales en la colección de sitios.

En el siguiente ejemplo se observa cómo crear una wildcard path desde la consola de comandos con STSADM para la colección de sitios

STSADM -o addpath –url http://localhost/projects -type wildcardinclusion

En versiones anteriores de SharePoint, se utilizaban unas rutas llamadas custom excluded managed paths para soportar nuevas aplicaciones que no eran basadas en SharePoint, pero que eran hosteadas en la misma aplicación WEB que los sitios de sharepoint. sin embargo, esto no es posible en MOSS 2007 y WSS 3.0. En vez de esto cualquier path que no está incluida dentro de un wildcard path o en un single path se excluye definitivamente. Típicamente las rutas excluidas eran creadas  para hostear un nuevo directorio virtual debajo de un servidor virtual de sharepoint, por lo tanto anteriormente era posible que código ASP.NET pudiera ser ejecutado en un WEB Aplication de sharepoint o en un directorio virtual de SharePoint. Con las versiones actuales de SharePoint se requiere que usted defina un directorio virtual o físico en el IIS debajo de la aplicación WEB, con su apropiado archivo de configuración web.config especificando apropiadamente los handlers y componentes en el directorio. MOSS 2007 y WSS 3.0 verifica  si el nuevo directorio no superpone una ruta manejada, entonces esta es considerada excluida.

Detalles de Soporte

Adicionalmente las nuevas rutas manejadas conducen directamente a una nueva colección de sitios y serán dispersadas sobre una variedad de localizaciones y hace del ambiente de despliegue algo más difícil de mantener. Por lo tanto solo se recomienda utilizar wildcard paths en circunstancias excepcionales.

Si usted crea una ruta manejada para hostear una colección de sitios, y la ruta es borrada posteriormente, el contenido existente de la colección de sitios se convierte en no disponible para los usuarios y las operaciones que se realicen con STSADM pueden fallar. Para hacerlas disponibles nuevamente es necesario recrear la ruta manejada.

Cada ruta manejada adicional que se configure puede reducir el desempeño de  ruteo del sitio. Si usted agrega un número excesivo de rutas manejadas es posible que experimente una reducción en el desempeño.

Tomado de SharePoint server SDK

versión en Ingles

Best Practices SharePoint – Managed Path February 20, 2010

Posted by juanpablo1manrique in Best Practices, SharePoint.
1 comment so far

Enables SharePoint Products and Technologies to determine where site collections can be created, and to help the system interpret URLs to determine site paths.

Real World Example
You need to create a set of site collections in a new path named teams. A custom managed wildcard path for teams provides the creation capability for the new location for site collections.

Technical Details
SharePoint Products and Technologies use managed paths to determine if a given URL should be handled by the system. Microsoft Office SharePoint Server 2007 and Windows SharePoint Services 3.0 allow single path or wildcard inclusions, which as the names imply allow the creation of a single site collection in a single path or multiple site collections in parallel under a wildcard path.

The default managed paths in Office SharePoint Server 2007 and Windows SharePoint Services 3.0 installations are a single path inclusion at the top-level site of the Web application to host the top-level site collection, and a sites wildcard path to host additional site collections.

Following is an example of the STSADM command used to add a new wildcard managed path for the creation of site collections:

STSADM -o addpath –url http://localhost/projects -type wildcardinclusion

In earlier versions of SharePoint Products and Technologies, custom excluded managed paths were required to support new applications not based on SharePoint Products and Technologies but that were hosted in the same Web application as SharePoint sites. However, this is no longer a requirement or even possible in Office SharePoint Server 2007 and Windows SharePoint Server 3.0. Instead, any path that is not included under a specific wildcard or single managed path is considered excluded. Typically, excluded managed paths were created to host a new virtual directory under a given virtual server so that non–SharePoint ASP.NET code in earlier versions of SharePoint Products and Technologies could be hosted. The current process would require you to define a virtual or physical directory in Internet Information Services (IIS) under the Web application, with the appropriate web.config file specifying the necessary ASP.NET handlers and components in the directory. In Office SharePoint Server 2007 and Windows SharePoint Server 3.0 processing, if the new directory does not overlap with a managed path, then it is considered excluded.

Support Details
Addition of new managed paths directly leads to new site collections being scattered over a variety of locations and makes the hosted environment more complex to support. Therefore, add new wildcard managed paths only in exceptional circumstances.

If you create a managed path to host a site collection, and the path is deleted at a later time, the existing content of the site collection becomes unavailable to users and STSADM operations can fail to work on the site collection. To make it available again, you would have to recreate the managed path.

Each additional configured managed path can reduce the performance of site collection determination. If you add an excessive number of managed paths, you can experience a severe reduction in performance.

Extract to SharePoint SDK

Spanish Version

Best Practices SharePoint – Database Schema Change February 20, 2010

Posted by juanpablo1manrique in Best Practices, Developer, SharePoint, SQL SERVER.
Tags: ,
add a comment

Indicates any change made to the structure or object types associated with a SharePoint database or to the tables included in it. This includes any change to the SQL processing of data, such as triggers or adding new user-defined functions.

Real World Example
A developer wants to store additional data in the SharePoint database by adding new tables or new columns to an existing table.

Technical Details
You can perform a schema change by using a SQL script, by making the change manually, or by using code that has appropriate permissions to access the SharePoint databases. Always scrutinize any custom code or installation script for the possibility that it modifies the SharePoint database.

Support Details
Important:
This type of customization is not supported.

Application of any schema change to the SharePoint database, except as part of a Microsoft-supplied service pack or hot fix, will make the SharePoint environment unsupportable. This type of change should never be applied.

Be sure to give special attention to any custom code you apply so that is does not introduce a database schema change into the environment.