jump to navigation

Best Practice : SharePoint Database Access March 11, 2010

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

Specifies any addition, modification, or deletion of the data within any SharePoint database by using database access commands. This includes bulk loading of data into a database, exporting data, or directly querying or modifying data.

Real World Example
A list aggregation Web Part that pulls information from a variety of sites in a server farm is designed to directly query the SharePoint database for information and present it to a user.

Technical Details
Directly querying or modifying the database can place extra load on a server, or can expose information to users in a way that violates security policies or personal information management policies. If server-side code must query data, then the process for acquiring that data should be through the built-in SharePoint object model, and not by using any type of query to the database. Client-side code that must modify or query data in SharePoint Products and Technologies can do this by using calls to the built-in SharePoint Web services that in turn call the object model.

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

Direct modification of the SharePoint database or its data is not recommended because it puts the environment in an unsupported state.

If a server component requires information from the database, it must get that data by using the appropriate items in the SharePoint object model, and not by trying to get the items from the data structures in the database through some query mechanism.

Versión en espeañol:: Buenas Prácticas: Acceso a base de datos

Buenas Prácticas: Acceso a base de datos March 11, 2010

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

Específicamente la inserción, modificación o borrado de los datos en cualquier base de datos de sharepoint utilizando comandos de acceso a datos. Incluyendo cargas por el comando bulk, exportacion de datos o directamente realizando busquedas o modificaciones sobre los datos.

El desarrollador creó una WEbPart que despliega informacióny esta siendo utilizada en  una variedad de sitios dentro de la granja de servidores y está diseñada para buscar información directamente en la base de datos de Sharepoint para presentarla al usuario.

Porque no se debe hacer.

Si se ejecutan directamente consultas a la base de datos puede causar una carga adicional al sistema en general, y puede exponer información a los usuario y podría llegar a presentarse que violenten las políticas de seguridad o la información personal de los usuarios. Si el código al lado del servidor debe ejecutar consultas, entonces es necesario que ese proceso  se haga a través del mapa de objetos de sharepoint, y no con SQL Code hacia la base de datos. El código al lado del cliente que deba modificar o traer datos de las base de datos de sharepoint deberá hacerlo a través de los Web services de sharepoint y entonces llamar al modelo de objetos.

Es importante tener en cuenta que este tipo de personalización no es soportada. La modificación directa de la base de datos de sharepoint no es recomendada debido a que pone el ambiente en un estado de no soporte por parte del área de ayuda de Microsoft.

Versión en Ingles : Best Practice : SharePoint Database Access

SharePoint no replica los cambios entre los servidores de la granja March 11, 2010

Posted by juanpablo1manrique in Alta Disponibilidad, Alto Desempeño, Best Practices, Cluster, Developer, IIS 7.0, Install, NLB, SharePoint.
1 comment so far

Bueno hace días me encontré con que después de instalar los nodos de mi granja de servidores, veo que al crear los WEBSites aplication estos no son replicados en los diferentes servers. Con lo cual estoy diciendo que si SharePoint está bien instalado y el NLB está correctamente configurado, el administrador de sharepoint puede crear WEBApplications desde el CentralAdministrator y olvidarse completamente si se replican correctamente en todos los servidores.

Esta maravilla se logra gracias a que uno de los servicios de SharePoint llamado Application Server Administration Service Timer Job el cual podrán encontrar en el tab operations y luego en Timer Job Definitions. Esta maravilla de servicio corre con permisos de administración, entonces de manera obligatoria es necesario que los servicios de Windows SharePoint se ejecuten con un usuario que tenga permisos de administración sobre todas las máquinas.

Dicho lo anterior un consejo importante antes de instalar los nodos en cada servidor es que en el momento de instalar SharePoint el ingeniero que realiza la instalación se encuentre logeado con la cuenta con la que van a correr los servicios de SharePoint “domain\SHPservice”  si esto no sucede y no se le replican los sitios puede realizar lo siguiente.

Desinstale SharePoint Server, panel de control y luego en agregar y quitar y programas se desinstala y se vuelve a instalar en las condiciones ideales mencionadas anteriormente, y se aprovisiona de nuevo.  :: Todos los programas y se ejecuta el asistente de SharePoint Products And Technologies configuration wizard. Se corre todo de nuevo y se verifica que el servicio de Application Server Administration Service Timer Job  haya corrido correctamente si esto no sucede tenemos problemas. Pero en letrasandnumeros has dado con el lugar correcto para solucionarlo.

Lo primero que se hace es actualizar los permisos del registro de windows que SharePoint necesita acceso. Esto se logra utilizando el psconfig que se encuentra en %COMMONPROGRAMFILES%\Microsoft Shared\web server extensions\12\bin y es una nota porque lo hace todo él solo.

psconfig -cmd secureresources

Luego de esto es necesario ejecutar algunos comandos que permiten modificar los permisos de los servicios de sharepoint, utilizando el stdadm  (%commonprogramfiles%\Microsoft Shared\Web server extensions\12\Bin) los cuales son:

stsadm -o updatefarmcredentials -userlogin ****** -password *****
iisreset %Este es necesario antes de continuar
stsadm -o updateaccountpassword -userlogin ******** -password ******** -noadmin
stsadm.exe -o spsearch -farmserviceaccount ********  -farmservicepassword ********
stsadm.exe -o spsearch -farmcontentaccessaccount ******** -farmcontentaccesspassword ********
stsadm.exe -o editssp -title ‘[ShareServiceProviderName]’ -ssplogin ******** -ssppassword ********
stsadm.exe -o osearch -farmserviceaccount ******** -farmservicepassword ********

Y nuevamente nuestro amigo
iisreset

Las líneas de comandos anteriores les puede servir para construir un .bat o .cmd y utilizarlo el día que al señor administrador del dominio le dé porque es necesario cambiarle el password al usuario de servicio.

Espero que les sea de ayuda

Saludos

Versión en Ingles

SharePoint can’t replicated the WEB Applications in different servers  

Download AdventureWorks 2008 R2 November CTP February 23, 2010

Posted by juanpablo1manrique in Best Practices, BI, Business Inteligent, Developer, Install, OLAP, SQL SERVER, SQL SERVER 2008, Windows 2008.
add a comment

Recordando que en el isntalador de SQL 2008 no viene incluida la base de datos de AdventureWorks para realizar pruebas y para carga los ejemplos como los de BI con los proyectos de Analysis Services listos para ejecutar me encontre este link donde lo pueden desacargar.

http://msftdbprodsamples.codeplex.com/releases/view/24854#DownloadId=91938

El instalador incluye

AdventureWorks OLTP 2008 R2
AdventureWorks Data Warehouse 2008 R2
AdventureWorks LT 2008 R2
AdventureWorks OLAP Standard 2008 R2
AdventureWorks OLAP Enterprise 2008 R2
AdventureWorks OLTP

AdventureWorks Data Warehouse
AdventureWorks LT
AdventureWorks OLAP Standard
AdventureWorks OLAP Enterprise

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

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 – 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.