February 2011 - Artículos
Con todo el mundo hablando de la nube en cada esquina y en cada momento, y con SharePoint como producto estrella de Microsoft junto con la versión del mismo en la nube que viene como parte de Office 365, hay una cierta inquietud y ganas de ver las posibilidades de la integración de ambos entornos…por suerte, ya comenzamos a tener los primeros ejemplos al respecto disponibles:
-
-
Un par de artículos de Steve Fox y Paul Stubbs al respecto y en el que se mete “la tercera pata” que es Windows Phone
:
Recientemente una de las dudas que ha surgido en torno a las soluciones Sandbox que permiten desplegar artefactos para SharePoint 2010 sin “tocar físicamente" el servidor es si es posible llamar a servicios externos desde una solución sandbox pura, es decir, desde una WebPart o un manejador de eventos por ejemplo…lamentablemente, y como podéis consultar en este enlace, la respuesta es que por defecto no es posible para este escenario, aunque más allá de la alternativa por defecto podríamos superar esta limitación:
-
Creando un proxy “full trust” que actúe como pasarela para interactuar con ese servicio externo.
-
Crear una lista externa que apoyándose en el servicio de BCS actúe como esa pasarela y podamos usar la API de SharePoint para interactuar con el servicio.
Como alguno ya habrá deducido, estas dos aproximaciones solucionan el problema para una solución Sandbox en un escenario On-Premise…¿y con Office 365? Pues en este caso, no podemos usar estas aproximaciones ya que no tenemos la posibilidad de usarlas. Esto en el caso de una solución Sandbox pura, ya que si es cierto que podemos llamar a un servicio externo a través de:
En ambos cosas, el código que ejecuta las llamadas al servicio externo no reside en el servicio de Sandbox por lo que la limitación desaparece y no es necesario recurrir a crear el proxy full-trust o el workaround con las listas externas. La desventaja es que esta aproximación no es una solución Sandbox pura 
.
Como ya he comentado en este blog, cuando trabajamos con SharePoint 2010 es fundamental tener muy claros los bloques fundamentales de su arquitectura. Uno de estos bloques o piezas clave es el modelo de seguridad que protege el sistema tanto de errores en código como de errores de los usuarios. Los elementos del modelo de seguridad en SharePoint son los siguientes:
-
Seguridad de usuario, SharePoint soporta de acceso a nivel de sitio, lista, carpeta y elemento. La gestión de la seguridad se basa en un sistema de roles y niveles de permisos que determinan que puede hacer cada usuario autenticado en función del rol y sistema de permisos asignado. En cuanto a la autenticación del usuario, SharePoint confía en sistemas externos, ya sea para autenticación Windows o no, es decir, no implementa un mecanismo de autenticación per-se.
-
Autenticación, se soportan varias formas de autenticación. El mecanismo por defecto es autenticación Windows basada en Claims (aunque por compatibilidad con SharePoint 2007 también tenemos la opción de autenticación de Windows en modo clásico o legacy). El modelo de identidad basado en Claims de SharePoint está construido sobre
Windows Identity Foundation (WIF) e identifica a un usuario en SharePoint como una identidad que tiene asociada un conjunto de “Claims” representando el nombre del usuario, su e-mail, etc. El modelo de Claims implica que se ha configurado un sistema de identidades externo que proporciona a SharePoint toda la información necesaria sobre el usuario que accede. Para más información sobre el modelo de autenticación basado en Claims en SharePoint:
-
Autorización, el acceso a sitios listas, carpetas y elementos de lista se controla mediante el sistema de roles comentado que permite asignar usuarios o grupos de usuario a uno o varios niveles de permisos (o definición de rol) que determinan que puede hacer el usuario a estos niveles. Por defecto, SharePoint utiliza un sistema de permisos heredable, es decir, los permisos se heredan de forma jerárquica desde el nivel más alto (sitio) al nivel más bajo (elemento) en la jerarquía de objetos de SharePoint a nivel de sitio…esta herencia se puede romper en cualquiera de estos niveles dando lugar a situaciones de exclusividad de permisos. A nivel de grupos de usuarios, se soportan dos tipos:
-
Grupos de SharePoint, definidos en el ámbito de una colección de sitios y por lo tanto no re-utilizables fuera de este ámbito.
-
Grupos de dominio, definidos fuera del ámbito y control de SharePoint y completamente re-utilizables.
Y hasta aquí llega este post sobre el modelo de seguridad en SharePoint.
Una pregunta que surge con frecuencia cuando se habla de los Business Connectivity Services (BCS) en SharePoint 2010 es la de que características están presentes en SharePoint Foundation y cuales en SharePoint Server. Por suerte, la respuesta a esta cuestión la tenemos en este enlace y se resumen en la siguiente figura.
Además, la tabla que viene en el artículo al que hago referencia permite conocer en detalle las características del BCS por versión de SharePoint, además de proporcionar el detalle al final del mismo (clientes Office incluidos):
| Business Connectivity Services Feature | SharePoint Foundation 2010 | SharePoint Server 2010 Standard Edition | SharePoint Server 2010 Enterprise Edition |
| External List | √ | √ | √ |
| External Data column | √ | √ | √ |
| Business Data Connectivity (BDC) service | √ | √ | √ |
| Connector Framework | √ | √ | √ |
| Secure Store Service | | √ | √ |
| External Data Search | | √ | √ |
| Profile Pages | | √ | √ |
| Business Data Web Parts | | | √ |
| Rich Client Integration | | | √ |
Esta semana ha concluido la tercera sesión de los SharePoint Camps que hemos celebrado en Santander y que ha sido la continuación de las ediciones de Madrid y Barcelona. La experiencia ha sido muy buena y espero que se repita en años venideros gracias al apoyo de Microsoft Corporation que ha sido el origen de estos Camps…por hacer un pequeño resumen de como han ido los Camps:
-
-
En la parte de pruebas de concepto, los resultados han sido muy buenos: las empresas participantes han desarrollado una serie de funcionalidades que demuestran las posibilidades de extensibilidad de la plataforma y además tendrán la oportunidad de mostrar sus soluciones al equipo de METRO en DPE EE.UU con lo que tendrán una alta visibilidad al otro lado del charco de lo que se sabe de SharePoint en España
, y no sólo eso, seguro que alguna de las pruebas que se presente dará que hablar y les dejará asombrados.
A nivel particular, los Camps me han servido para conocer a gente que está muy metida en el mundillo de SharePoint y que no tenía controlada 
y sobre todo para demostrarme una vez más que pretender saber de todo de SharePoint es una tarea imposible, pero que con este tipo de trainings aprendemos tanto los ponentes como los asistentes, vemos los problemas reales que el uso de la plataforma ocasiona, carencias, etc. Finalmente, quería agradecer a todos los que habéis participado en los Camps vuestra presencia en los mismos y sobre todo vuestra pasión por SharePoint…algo está cambiando en el sector de nuestro servidor favorito en España y ese cambio es gracias a la comunidad tan fuerte que estamos formando…a seguir así. Y como no, aquí van las fotos resumen de los Camps:
- SharePoint Camps en Madrid:
- SharePoint Camps en Barcelona:
- SharePoint Camps en Santander:
Otros posts relacionados:
Como sabéis, en SharePoint 2010 tenemos la posibilidad de crear flujos de trabajo en tres entornos diferentes: Visio, SharePoint Designer 2010 (SPD 2010) o Visual Studio 2010. Además, podemos pasar los flujos de trabajo creados de uno a otro entorno:
-
Podemos crear un flujo de Visio e importarlo en SPD 2010 para completarlo y a la inversa.
-
A su vez, un flujo de trabajo creado en Visio y completado con SPD 2010 se puede importar en VS 2010.
Cada entorno de creación y en función de si estamos con SharePoint Foundation o Server, tiene sus particularidades. Una de ellas la tenemos en la posibilidad de disponer la visualización de un diagrama Visio que muestre en tiempo de ejecución un workflow que se ha creado con SPD 2010 (para que esto sea posible, necesitamos Visio Services y por tanto disponer de la versión Enterprise de SharePoint 2010)…¿Y con VS 2010? Pues por defecto, los flujos creados con VS 2010 no se muestran renderizados en un diagrama Visio…ahora bien, gracias a Manuel Guadarrama de STPNET, conocí el siguiente workaround que os dejo como referencia:
Algo que últimamente está en boca de todos es si el concepto de ALM (Application Lifecycle Management) aplica en el desarrollo para SharePoint. La respuesta es que sí, otra cosa es que se parezca más o menos al ciclo de vida de aplicaciones software convencionales. En SharePoint 2010 frente a SharePoint 2010 contamos con una mejor soporte para ALM gracias a la mejor integración de Visual Studio 2010 (a través de las herramientas de desarrollo para SharePoint) y TFS en el desarrollo para SharePoint. En este sentido, hay una serie de recursos que reflejan esta idea y que es importante tener siempre a mano cuando hablamos de ALM y SharePoint:
Como continuación al primer post sobre limitaciones en las soluciones SandBox en cuanto a que tipo de artefactos se pueden crear y el ámbito a nivel de desarrollo en el que nos podemos mover (Colección de Sitios hacia abajo), en esta ocasión quería entrar en un poco más de detalle en estas limitaciones teniendo en cuenta el modelo de ejecución de las soluciones SandBox. Básicamente, todo el código que corre dentro del servicio de SandBox está sujeto a una serie de restricciones tanto de ejecución como de acceso. Hay dos sistemas de restricciones:
-
Uno que se aplica únicamente a toda llamada que se realice a cualquier ensamblado exceptuando Microsoft.SharePoint.dll.
-
Otra que se aplica únicamente a toda llamada que se realice al modelo de objetos SharePoint incluido en Microsoft.SharePoint.dll y otros ensamblados como Microsoft.SharePoint.Linq.dll.
¿Cómo se aplican estas restricciones? Para el primer tipo de llamadas a ensamblados, se definen dos mecanismos:
-
Una política muy restrictiva de seguridad de acceso a código (CAS) que se encarga de limitar lo que el código ejecutándose en el proceso de SandBox puede hacer (Nota: Esta política si permite acceder a ensamblados de Microsoft Office con un “strong-named”). Esta política se encuentra definida en el archivo web.config bajo la ruta %ProgramFiles%\Common Files\Microsoft Shared\web server extensions\14\CONFIG, impone restricciones como:
-
-
La imposibilidad de llamar a código no manejado desde el código de una solución SandBox.
-
La imposibilidad de llamar a las APIS de reflexión de .NET Framework 3.5 desde el código de una solución SandBox.
-
1: <?xml version="1.0" encoding="UTF-8" standalone="yes"?>
2: <configuration>
3: <system.web>
4: <httpModules>
5: <clear/>
6: </httpModules>
7: <httpHandlers>
8: <add path="WebResource.axd" verb="GET" type="System.Web.Handlers.AssemblyResourceLoader" validate="true"/>
9: </httpHandlers>
10: <securityPolicy>
11: <trustLevel name="WSS_Sandbox" policyFile="..\config\wss_usercode.config" />
12: </securityPolicy>
13: <trust level="WSS_Sandbox" originUrl="" />
14: </system.web>
15: <runtime>
16: <assemblyBinding xmlns="urn:schemas-microsoft-com:asm.v1">
17: <probing privatePath="assemblies" />
18: <dependentAssembly>
19: <assemblyIdentity name="Microsoft.SharePoint" publicKeyToken="71e9bce111e9429c" culture="neutral" />
20: <bindingRedirect oldVersion="0.0.0.0-14.900.0.0" newVersion="14.900.0.0" />
21: </dependentAssembly>
22: </assemblyBinding>
23: </runtime>
24: </configuration>
Para el segundo sistema de restricciones, se define una versión “shim” del MO de servidor de SharePoint que junto con el MO completo son cargados por uno de los dos procesos que constituyen el servicio de SandBox (en concreto por SPUCWorkerProcessProxy.exe) que impiden que se llamen a objetos de la API no permitidos desde una solución SandBox. Además, existen otros dos ensamblados que son usados por este sistema y que se cargan en el Worker Process del servicio de SandBox (Microsoft.SharePoint.UserCode.dll) y en el proxy comentado (Microsoft.SharePoint.SubsetProxy.dll). El mecanismo de uso de estos ensamblados “shim” por los procesos del servicio de SandBox es el siguiente:
-
Cuando una solución SandBox hace uso de un parte permitida de la API de SharePoint, el primero de los ensamblados pasa la llamada al segundo en el proceso de proxy, que a su vez la pasa a la API estándar en Microsoft.SharePoint.dll.
-
Los resultados de la llamada realizad se pasan al código original que la realizó.
Como ejemplo de restricción en cuanto al uso del MO de SharePoint tenemos:
- No se puede acceder a la clase SPWebApplication ni a cualquiera definida bajo Microsoft.SharePoint.Administration.
- No es posible realizar una elevación de privilegios en el código que se ejecute en modo SandBox.
- No se pueden usar los controles definidos en Microsoft.SharePoint.WebControls de manera que estamos restringidos al uso de controles ASP.NET.
- …
El listado completo de APIs dentro de Microsoft.SharePoint.dll que se pueden usar lo podéis encontrar aquí Microsoft.SharePoint.dll APIs Available from Sandboxed Solutions. Finalmente, otra limitación ya comentada en este blog es que a nivel de despliegue de una solución SadnBox está prohibido incluir cualquier tipo de archivo que se tenga que copiar en el servidor físico como controles de usuario, páginas de aplicación, o imágenes. Para más información recomendable ver SharePoint Deployment Models.
Siguiendo con la serie de post sobre alternativas para montar el entorno de desarrollo para SharePoint 2010, en esta ocasión voy a comentar otra posibilidad que tenemos dentro del movimiento de irnos “todos a la nube” 
…esta alternativa implica que nuestro entorno de desarrollo esté disponible en algún proveedor de servicios en la nube como puede ser Arsys en España, Amazon como ya nos ha explicado Mario Cortes o en la propia plataforma Azure de Microsoft …aunque en este post no voy a tratar este caso, sino que voy a hablaros de Cloudshare que es plataforma de cloud computing en modo autoservicio que facilita la creación de entornos virtuales para realizar demostraciones, pruebas de concepto o incluso formaciones…todo depende del tipo de suscripción adquirida. En mi caso, he tenido la suerte de poder contar con una invitación para usar Cloudshare Pro que facilita la creación rápida de estos entornos virtuales ya sean limpios o en base a plantillas predefinidas:
-
Crear un entorno es tan sencillo como pulsar el botón “Create new environment”. La licencia Pro sólo permite crear un entorno, pero en él podemos disponer de varias máquinas virtuales y crear snapshots del entorno para compartir con terceros…de hecho, disponemos de nada menos que 1.000 invitaciones que permiten usar los snapshots creados por un período de 48 horas…cool.
-
A la hora de crear una máquina virtual en el entorno, tenemos varias plantillas disponibles. Entre ellas una para SharePoint 2010
.
-
Una vez definido el entorno, basta con pulsar el botón View Environment para que las máquinas virtuales se arranquen. Estas máquinas las podremos acceder desde el explorador o bien por escritorio remoto
Por supuesto, podremos editar el entorno en todo momento y añadirle nuevas máquinas virtuales.
El otro día planteaban en los foros de SharePoint un problema sobre la integración entre SharePoint 2007 (WSS 3.0 & MOSS) y Office 2010…la verdad, cuando ví el thread tampoco me sorprendí mucho en cuanto a que Office 2010 es una versión superior a las que soporta SharePoint 2007, aunque no debería dar ningún problema en cuanto a que Office 2010 es una evolución de Office 2007. Sin embargo, la integración es diferente como podéis ver en este thread. Por eso, cuando surja la duda sobre como se integra Office 2010 con SharePoint 2007 lo mejor es bajarse el siguiente documento creado por Microsoft en el que podemos ver que se soporta y que no en SharePoint 2010 en función de si trabajamos con Office 2010 u Office 2007 y extrapolarlo al uso de Office 2010 en SharePoint 2007.
Siguiendo con la serie de posts en torno a como añadir acciones personalizadas a la interfaz de usuario, en esta ocasión os quería mostrar las posibilidades que tenemos a la hora de extender las distintas partes que constituyen la Ribbon mediante nuevas pestañas, grupos de acciones, acciones y controles, así como la lógica necesaria para dotar de funcionalidad a estas extensiones. En este sentido, y mejor que repetir lo que ya se ha comentado en torno a este tema en la red, os recomiendo este excelente artículo de MSDN escrito por Andrew Connell:Customizing and Extending the SharePoint 2010 Server Ribbon. Finalmente, os dejo el resto de posts de la serie:
Como sabéis, una de las novedades que incorpora SharePoint 2010 es la posibilidad de hacer Joins en las consultas que hagamos a listas que están relacionadas mediante campos de lookup con otras listas. Este soporte es posible gracias a la actualización del esquema CAML subyacente, de forma que podemos incorporar Joins a nuestras consultas ya sea en CAML o utilizando LINQ To SharePoint (el proveedor se encarga de generar el código correspondinte). Así por ejemplo:
1: using (SPSite siteCollection = new SPSite("http://demo2010a:100"))
2: {
3: SPList list = siteCollection.RootWeb.Lists["Projects"];
4:
5: SPQuery query = new SPQuery();
6: query.Joins =
7: @"
8: <Join Type='LEFT' ListAlias='Primary_x0020_Contact'><!--List Name: Employees-->
9: <Eq>
10: <FieldRef Name='Primary_x0020_Contact' RefType='ID' />
11: <FieldRef List='Primary_x0020_Contact' Name='ID' />
12: </Eq>
13: </Join>
14: ";
15: query.ProjectedFields =
16: @"
17: <Field Name='Primary_x0020_ContactTitle' Type='Lookup' List='Primary_x0020_Contact' ShowField='Title' />
18: <Field Name='Primary_x0020_ContactJobTitle' Type='Lookup' List='Primary_x0020_Contact' ShowField='JobTitle' />
19: ";
20: query.ViewFields =
21: @"
22: <FieldRef Name='Title' />
23: <FieldRef Name='Primary_x0020_ContactTitle' />
24: <FieldRef Name='Primary_x0020_ContactJobTitle' />
25: ";
26: query.Query =
27: @"
28: <Where>
29: <Eq>
30: <FieldRef Name='Primary_x0020_ContactTitle' /><Value Type='Lookup'>Contact1</Value>
31: </Eq>
32: </Where>
33: ";
34: Console.WriteLine("CAML Query sent");
35: Console.WriteLine(query.ViewXml.ToString());
36: Console.ReadLine();
37: Console.WriteLine("Query results");
38: SPListItemCollection results = list.GetItems(query);
39: foreach (SPListItem item in results)
40: {
41: Console.WriteLine("{0} - {1} - {2}",
42: item["Title"].ToString(),
43: item["Primary_x0020_ContactTitle"].ToString(),
44: item["Primary_x0020_ContactJobTitle"].ToString());
45: }
46: }
-
Como veis, el objeto SPQuery incorpora dos nuevas propiedades:
-
Joins, que permite definir el join o joins en la consulta.
-
ProjectedFields, que permite incorporar en los resultados devueltos campos proyectados, es decir, campos que están en la lista relacionada con la lista principal. En este caso estamos devolviendo dos campos de la lista Employees.
-
En el caso de usar LINQ To SharePoint, el uso de Joins es mucho más intuitivo. Por ejemplo:
1: try
2: {
3: SPLINQProxySiteDataContext ctx =
4: new SPLINQProxySiteDataContext(SPContext.Current.Web.Url);
5: var productsList = from p in ctx.Productos
6: select new
7: {
8: Producto = p.Título,
9: Descripcion = p.Descripción,
10: Fabricante = p.Fabricante.Título
11: };
12: ctx.Log = swWriter;
13: grdProductos.DataSource = productsList;
14: grdProductos.DataBind();
15: txtConsultaCAML.Text = "Consulta: " +
16: swWriter.ToString();
17: }
18: catch (Exception ex)
19: {
20: txtError.Text = ex.Message;
21: }
-
En este caso, tras definir una instancia del objeto DataContext correspondiente, estamos haciendo una consulta a la lista Productos que está relacionada con la lista Empresas mediante el campo de lookup Fabricante. En el select realizado estamos consultando dos campos de la lista Productos y uno de la lista Empresas por lo que el proveedor de LINQ To SharePoint generará por nosotros el correspondiente Join (lo podemos ver con ctx.log=swWriter):
1: <View>
2: <Query>
3: <Where>
4: <BeginsWith>
5: <FieldRef Name="ContentTypeId" />
6: <Value Type="ContentTypeId">0x0100</Value>
7: </BeginsWith>
8: </Where>
9: </Query>
10: <ViewFields>
11: <FieldRef Name="Title" />
12: <FieldRef Name="Descripci_x00f3_n" />
13: <FieldRef Name="FabricanteTitle" />
14: </ViewFields>
15: <ProjectedFields>
16: <Field Name="FabricanteTitle" Type="Lookup" List="Fabricante" ShowField="Title" />
17: </ProjectedFields>
18: <Joins>
19: <Join Type="LEFT" ListAlias="Fabricante">
20: <!--List Name: Empresas-->
21: <Eq>
22: <FieldRef Name="Fabricante" RefType="ID" />
23: <FieldRef List="Fabricante" Name="ID" />
24: </Eq>
25: </Join>
26: </Joins>
27: <RowLimit Paged="TRUE">2147483647</RowLimit>
28: </View>
Últimamente en los foros de SharePoint se están planteando bastantes dudas en torno a la publicación de formularios InfoPath en SharePoint por lo que me ha parecido adecuado recoger los posts al respecto publicados en este blog:
Siguiendo con la serie de posts sobre la personalización de sitios de SharePoint 2010 usando el nuevo motor de temas que incorpora la plataforma y las posibilidades para crear y aplicar temas, en esta ocasión os voy a presentar otra alternativa para crear temas para SharePoint 2010. Pero antes, os recuerdo los posts publicados en torno a esta temática hasta ahora:
Como decía, una alternativa interesante que me he encontrado hace poco para crear estos temas la podéis ver en este post: Working with SharePoint 2010 Themes (Anweshi Deverasetty). Lo interesante de este post es el uso de la utilidad Theme Builder para crear esos temas y por supuesto el despliegue y aplicación de temas usando Visual Studio 2010:
Como sabéis, cada vez que cargamos un documento o creamos un elemento en una lista de SharePoint aparece un icono ¡Nuevo! o New! (en función de si el idioma es castellano o inglés). El caso es que como casi todo en SharePoint, podemos configurar este icono para que se muestre en base a nuestras necesidades (o incluso no se muestre) como ya explicamos para SharePoint 2007 ¿Y para SharePoint 2010? Pues nos vale lo mismo:
-
Por una parte, la imagen de este icono se encuentra localizada en: Drive:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\LAYOUTS\<Idioma>\IMAGES.
-
Para cambiar como se tiene que mostrar el icono para una cierta Aplicación Web (aplica por lo tanto a todas las colecciones de sitios y sitios definidos bajo la misma) basta con ejecutar la siguiente opción de STSADM (En este ejemplo estaríamos configurando que el icono no apareciese ya que estamos especificando un valor 0 para la propiedad days-to-show-new-icon):
1: stsadm.exe –o setproperty –propertyname days-to-show-new-icon –propertyvalue 0 –url http://Sitio
SharePoint 2010, al igual que su predecesor, usa una página de procesamiento intermedia en el caso en el que se vaya a realizar una operación larga y como forma de indicarle al usuario que tras un cierto tiempo aparecerá el resultado esperado. Esta página tiene el siguiente aspecto:
La pregunta es: ¿Podemos usar esta página de procesamiento en nuestros desarrollos para SharePoint? La respuesta como casi siempre es que sí y podéis encontrar un ejemplo en este enlace.
Pues eso, este error tan majo, descriptivo e inesperado fue el que me encontré el otro día al desplegar un modelo de BDC (Business Data Catalog) en uno de mis entornos de pruebas de SharePoint 2010...la primera reacción fue de perplejidad y de pensar “que mi madre…” porque era la primera vez que me encontraba con dicho error y mira que he desplegado modelos de BDC en los últimos meses (ni en la beta tuve este problema). Por suerte, este error es conocido y documentado y tiene fácil solución como podéis ver en este par de posts de Jan Tielens y de Paul Andrew:
Como se comenta en estos posts, la solución pasa por editar el archivo Feature.Template.xml y añadirle la siguiente propiedad que específica justamente la Url de la aplicación web por defecto:
1: <Properties>
2: <Property Key="GloballyAvailable" Value="true" />
3: <Property Key="SiteUrl" Value="http://intranet.contoso.com/" />
4: </Properties>
De esta forma, dicho archivo quedaría de la forma:
1: <?xml version="1.0" encoding="utf-8" ?>
2: <Feature xmlns="http://schemas.microsoft.com/sharepoint/">
3: <Properties>
4: <Property Key="GloballyAvailable" Value="true" />
5: <Property Key="SiteUrl" Value="http://intranet.contoso.com/" />
6: </Properties>
7: </Feature>
Y con esto, solucionado este curioso error.
Hace un tiempo os comentaba en este post sobre la disponibilidad de una serie de virtual labs en TechNet sobre cuestiones de administración. El caso es que en MSDN podréis encontrar virtual labs sobre desarrollo algunos de los cuáles son nuevos. Podéis acceder a estos laboratorios desde este enlace. El listado completo de laboratorios es el siguiente:
Si realizamos una instalación por defecto de WSS 3.0 o de MOSS, nos encontramos con que las distintas BD’s que se crean durante el proceso de instalación se crean en la instancia del motor de BD de Windows o lo que es lo mismo la Windows Internal Database (Microsoft#SSEE). Seguramente muchos os habréis encontrado con el problema de que administrar las BD’s creadas en esta instancia no es posible inicialmente usando SQL Server Management Studio Express…por suerte, aquí podéis encontrar el workaround necesario para poder hacer que la instancia de Windows Internal Dabase dónde residen nuestras BD’s de SharePoint se puedan administrar con SQL Server Management Studio Express.
Porque no todo es SharePoint, en esta ocasión os voy a hablar del Microsoft Platform Ready de Microsoft. El día 29 de Octubre se lanzo Microsoft Partner Network (MPN). Después de más de un año en transición, los nuevos niveles y los nuevos requisitos por competencias se exigirán a partir de esa fecha para los partners nuevos y para aquellos que tengan que renovar a partir de la fecha de lanzamiento del nuevo Partner Network (hasta la fecha de renovación se mantendrá el nivel y beneficios que se ostentará en el MSPP). MPN sustituye al antiguo Micrososft Partner Program (MSPP) que se lanzó hace 8 años. Este cambio potencia la especialización de nuestro canal y la diferenciación, y responde a la demanda de nuestros clientes y partners. El programa tiene los siguientes niveles: Gold, Silver, Subscription y Community, y 30 competencias (Virtualización, Business inteligence, Application Platform, ISVs…).
Hay cambios en cuanto a los requisitos de las competencias tanto para el nivel Silver (antiguo Certified) como para el nivel Gold. Desde el punto de vista de los ISVs supone la incorporación de nuevas certificaciones de productos válidas para los dos niveles.
Para conseguir la competencia ISVs en el nivel Silver se solicitará una aplicación certificada con uno de los siguientes test:
Los test que hasta ahora tuvierais hechos serán validos para la competencia hasta Mayo de 2011, pero es momento de ir alineándose con los nuevos requisitos. Ya puedes realizar los nuevos Test a través de Microsoft Platform Ready de forma rápida, sencilla y sin ningún coste para el partner.
http://www.microsoftplatformready.com/spain/home.aspx
Date de alta en Microsoft Platform Ready con tu usuario y contraseña del programa de partners, da de alta todas tus aplicaciones, independientemente de la fase en la que estén (desarrollo, pruebas, producción, etc) y aprovecha los recursos de MPR (recursos de desarrollo, realiza test de certificación, material de marketing, etc). Si realizas algunos de los test, estos automáticamente volcaran en MPN y podrás asociarlo a la competencia para la que sean válidos.
A parte de ISVs, hay otras competencias que permitirán la certificación de una aplicación para obtenerla en su nivel Silver.
-
Application Integration = Windows Server 2008 R2 Platform Ready
-
Data Platform = SQL Server 2008 R2 Platform Ready
-
Business Intelligent = SQL Server 2008 R2 Platform Ready
-
Content Management = Sharepoint Server 2010 Platform Ready (proximamente disponible)
-
Unified Communication = Unified Communicatios Platform Ready ( aun no disponible)
Para aquellos que queráis optar a la competencia Gold de ISVs los test que se solicitaran son:
Si ya realizasteis el Windows 7 Logo test y queréis optar a la competencia Gold ISVs, tendréis que enviar la información de la certificación, para poder solicitar su validación.
Más artículos
Página siguiente >