El monstruito no soy yo, es el SharePoint

El Blog de Luis Mañez, dedicado a tecnologías MS, principalmente SharePoint y Office 365

October 2011 - Artículos

Office365: Opciones de soporte técnico en el panel de administración (II)

Además de lo comentado en el post anterior Microsoft nos ofrece una potente herramienta para diagnóstico de los servicios de Office 365. Se trata del Microsoft Online Services Diagnostics and Logging que tenemos disponible desde el mismo panel de administración:

image

El instalable viene acompañado de un documento con información detallada de cómo usar la herramienta.

La aplicación nos pide el usuario y contraseña de nuestra cuenta de Office 365 (no será necesario si no queremos hacer pruebas de autenticación)

image

Podemos ejecutar la app en modo avanzado (seleccionando las opciones que más nos interesen)

image

Y arranca el generador de informe:

image

Cuando termina, la aplicación nos abre un explorador de archivos donde podemos ver los resultados del análisis.

image

En las carpetas, tenemos varios ficheros log con información sobre versiones de SW, claves del Registry, operaciones realizadas, resultados…

image

Obviamente, toda esta información, está destinada al equipo de soporte técnico de MS ante casos concretos. No obstante, en algunos casos, sobre todo en temas de conectividad, nos puede dar alguna pista del problema.

Espero que os sirva!!

Un saludo.

Posted: 27/10/2011 19:00 por Luis Mañez | con no comments
Archivado en:
Office365: Opciones de soporte técnico en el panel de administración

En Office 365 tenemos varias opciones para asuntos relacionados con el soporte técnico y la monitorización del servicio ofrecido.

Para ello, desde el panel de control disponemos de una zona en el menú de la izquierda, destinada a Soporte técnico.

image

Desde esa sección, podemos abrir un caso de soporte técnico. En este post del gran Juan Carlos González, tenéis detallado cómo proceder.

La opción de “Estado del servicio”, nos ofrece una tabla de todos los servicios de office 365, subdividida por varias funcionales, con el estado del servicio en la última semana.

image

Desde esta tabla, si alguno de los iconos no marca “ok”, podemos ver el detalle del problema, como muestra esta imagen:

image

La última opción nos mostrará las acciones de mantenimiento planeadas por Microsoft. Así seremos conscientes de en qué momento podría verse afectado alguno de nuestros servicios de Office 365.

image

Para acabar, una última pantalla que hasta ahora no había visto. Se trata de un mensaje de error del servicio.

image

Como veis, además del mensaje, nos ofrece el famoso ID de correlación de SharePoint, con el que podremos acudir al soporte técnico, y ayudará al equipo de MS a determinar el problema.

Espero que os sirva!

Saludos.

Posted: 25/10/2011 8:15 por Luis Mañez | con no comments
Archivado en:
SharePoint: Plantilla para Visual Studio SharePoint SW Factory

Hace ya un tiempo que conocí esta herramienta, la SharePoint Software Factory. Sin embargo, entre las prisas, que no vi el video que hay en la web, y que los pantallazos no parecían aportar mucho más que las plantillas por defecto de Visual Studio para SharePoint, no le hice mucho caso.

Ahora, a pesar de las mismas prisas de siempre Sonrisa, he decidido probarlo con algo más de detalle, y la verdad, me parece una herramienta estupenda para la gente que desarrolla sobre SharePoint, y más aún si hace desarrollos grandes, con muchas componentes (webparts, listas, tipos contenido, etc) que necesita paquetizar y mover de entorno en entorno.

Os recomiendo que invirtáis 7 mins de vuestro tiempo en ver el video de la web, ya que en el video se ve bastante bien el enorme potencial de la herramienta.

Además, os dejo algún pantallazo y apunte.

Para empezar, la instalación es sencillísima, y el instalador se encargará de deciros qué pre-requisitos necesita (obligatorios y opcionales), descargarlos e instalarlo.

Tras la instalación tendremos una plantilla más en VS para SPSF:

 

Pasamos por el asistente para crear el proyecto, y tenemos una estructura de solución como la siguiente:

Fijaros en la carpeta “ApplicationConfiguration”, donde tiene archivos comunes a toda la solución, como por ejm, una clave (.snk) compartida para todos los artefactos SP, el fichero de configuración del FxCop y StyleCop, que nos va a servir para validar nuestro código en tiempo de compilación (internamente también hace uso de SPDisposeCheck)

A partir de este momento, ya podemos añadir items a nuestra solución. Para empezar, vemos los tipos de proyectos que podemos añadir:

image

Y como quedan en la solución si añadimos una .dll y uno de PowerShell:

image Ordenadito, verdad!! Sonrisa

Si nos centramos en las soluciones de SharePoint, tenemos un abanico enorme.

image

Plantillas para la Ribbon!! con ejemplos y todo!

image

Webparts de todo tipo, incluido un ejemplo de webpart con AJAX

image

Fijaros que genialidad. Dentro de la sección de asp.net, tenemos:

image

Si elegimos crear un Http Module, no solo nos crea el típico fichero de código al igual que hace Visual Studio, sino que también nos crea una feature, con todo el código necesario para instalar el Module dentro de SharePoint. Es decir, el código para editar el web.config de la app web, y meter la línea del <httpmodules /> Tomaaaa!

Si después de esto, no os ha convencido, pues veros el video leñe! Sonrisa

¿Y tiene alguna cosilla para Sandbox y Office 365?

Pues algo tiene. Para empezar, al crear un proyecto de .wsp, tiene la misma opción de modo sandbox que las plantillas de Visual Studio:

image

Otra cosa es que en proyectos sandbox, los tipos de items que se pueden agregar al proyecto tb disminuyen:

image

Y para acabar, también tiene la opción de hacer deploy de soluciones Sandbox:

image

Y nada más, espero que os sirva.

Saludos!!

Office 365: Cómo estar al día de todo lo que se publica alrededor de Office 365

En esta ocasión os paso un listado de recursos muy interesantes para mantenerse al día de todo lo que se publica sobre Office 365. Espero que entre todos vayamos ampliando el listado.

Lo he ordenado en algunas categorías: blogs oficiales MS, MVPs Office 365, cuentas de Twitter, Webs oficiales, Foros, y materiales de formación.

Blogs oficiales de Microsoft sobre Office 365:

MS MVPs en Office 365:

Cuentas de twitter:

Comunidad Office 365:

Formación y otros enlaces de interés:

Saludos!!

Posted: 16/10/2011 20:06 por Luis Mañez | con 2 comment(s)
Archivado en:
Office 365: No es posible usar los controles de Telerik en soluciones Sandbox, y cómo hacerlo en desarrollos On Premise

Introducción

En este post vamos a ver cómo podemos usar los controles de Telerik asp.net AJAX dentro de nuestros propios desarrollos de SharePoint 2010. Y como el propio título del post indica, veremos que eso mismo no es viable dentro de soluciones sandbox, así que no podremos ayudarnos de estos controles para nuestros desarrollo en Office 365.

Respecto a los controles de Telerik, creo que a estas alturas todo el mundo los conoce, lo que quizá no sea tan conocido, es que también disponen de una suite de controles para SharePoint, pero que todavía están en CTP. De todas formas, por lo que he leído, estos controles son webparts visuales, que internamente hacen uso de los mismos controles asp.net de Telerik (lo cual es muy lógico). Eso sí, tienen una configuración muy potente, y habrá que estar atento a sus versiones finales.

Cómo hacer uso de los controles de Telerik en SharePoint

Partimos de un proyecto SharePoint con un visual webpart.

Primero de todo, añadimos la referencia a la dll de Telerik: Telerik.Web.UI.dll. Como Telerik tiene controles para varias versiones del .NET Framework, tenemos que tener cuidado de seleccionar la versión 3.5 (por defecto en: C:\Program Files (x86)\Telerik\RadControls for ASP.NET AJAX Q2 2011\Bin35)

Seguidamente, al .ascx del visual webpart, le añadimos también la referencia:

<%@ Register Assembly="Telerik.Web.UI, Version=2011.2.712.35, Culture=neutral, PublicKeyToken=121fae78165ba3d4" Namespace="Telerik.Web.UI" TagPrefix="telerik" %>

En el paso anterior, es necesario indicar el nombre FQN del Assembly (con versión, culture, etc).

Ahora ya podemos añadir algún control de Telerik al visual webpart, por ejemplo el RadGrid.

<telerik:RadGrid ID="SuperGrid" runat="server" AutoGenerateColumns="false">
<MasterTableView>
<Columns>
<telerik:GridBoundColumn DataField="Title" HeaderText="Title" />
</Columns>
<NoRecordsTemplate>List with no items</NoRecordsTemplate>
</MasterTableView>
</telerik:RadGrid>

Antes de hacer el deploy, hará falta preparar el paquete de la solución para que los controles de Telerik se marquen como seguros. Para ello, vamos a la pestaña “Advanced” del editor del Package, y añadimos la dll de Telerik, y marcamos como SafeControls los namespaces de Telerik.Web.UI y Telerik.Web.Design.

image

Nota: Los controles de Telerik asp.net AJAX, necesitan de al menos un ScriptManager para que funcionen. Como en SharePoint 2010 ya tenemos ese control por defecto en la MasterPage, pues no tenemos que hacer nada en especial.

Con esto, ya podemos desplegar el paquete y veremos el grid de Telerik dentro de nuestro webpart.

Como esto de sacar un grid vacío, no tiene mucha gracia, vamos a intentar mapearlo a una lista de nuestro Site. Para ello, lo ideal sería hacer uso del control SPDataSource, con algo como esto:

<SharePoint:SPDataSource ID="ListDataSource" runat="server" DataSourceMode="List" SelectCommand="&lt;Query></Query>" UseInternalName="true">
<SelectParameters>
<asp:Parameter Name="WebUrl" DefaultValue="/" />
<asp:Parameter Name="ListName" DefaultValue="Questions" />
</SelectParameters>
</SharePoint:SPDataSource>

Sin embargo, si ese SPDataSource lo asignamos tal cual al Grid de Telerik, tendremos un error cuando la lista tiene elementos (curiosamente, el grid funciona bien cuando no hay elementos en la lista).

No he podido averiguar el motivo por el que no funciona enlazado directamente al SPDataSource, pero bueno, podemos hacerlo funcionar de varios motivos, como convirtiendo la lista de SharePoint a DataTable.

protected void Page_Load(object sender, EventArgs e)
{
SPList list = SPContext.Current.Web.Lists["Questions"];
this.SuperGrid.DataSource = list.Items.GetDataTable();
this.SuperGrid.DataBind();

}

Y aquí vemos el resultado al insertar nuestro webpart en una página:

image

Y a partir de aquí, ya podemos explotar todas las ventajas de los controles de Telerik en nuestros desarrollos.

No funciona en modo Sandbox

Si intentamos hacer el deploy en modo sandbox sobre nuestro Office 365, obtenemos el siguiente error:

image

Como veis en el error, el grid deTelerik intenta hacer alguna operación no permitida en modo Sandbox. En el mismo foro de Telerik, confirman que sus controles no funcionan en modo sandbox, al parecer por algún problema del modo Sandbox con la interfaz IScriptControl. Al parecer, Telerik está intentando que Microsoft solucione el problema, tal como indica este enlace:

http://www.telerik.com/community/forums/sharepoint-2010/integrate-ajax-controls/visualwebpart-sandbox-solution-radgrid.aspx

Pues nada más, a pesar de no disponer de momento de los controles en modo Sandbox, poderlos utilizar en nuestras soluciones OnPremise, nos puede ahorrar mucho tiempo de desarrollo.

Espero que os sirva!!

Un saludo.

Office365: Llamando a componentes externos desde soluciones Sandbox

Hola a todos,

A estas alturas, seguramente conoceremos más o menos las limitaciones del desarrollo en modo sandbox (y por tanto de SharePoint Online). Aquí tenemos un buen resumen del que empezar a tirar del hilo.

Una de las limitaciones que más llama la atención es la de no poder desplegar dlls en la GAC al estilo que estamos acostumbrados en nuestro despliegues en granja. Además de no poder meter mano a nuestro querido 14 “hive”.

Esto hace que nos preguntemos, cómo podemos desplegar soluciones en sandbox, que tienen referencias a componentes externas.

Lo podemos hacer con los siguientes pasos:

  • Antes de nada, recalcar que, el código del componente externo, no puede violar ninguna de las restricciones Sandbox.
  • Nuestro componente externo (.dll) debe estar firmado con un strong name. Esto no es nuevo, pasa lo mismo en On premise.
  • Pero además, la dll debe permitir: AllowPartiallyTrustedCallers Esto lo podemos hacer con el siguiente código dentro del fichero “AssemblyInfo”
[assembly: AllowPartiallyTrustedCallers]

  • Incluimos la .dll externa dentro del Package de SharePoint. Para ello, desde Visual Studio abrimos el Package, nos vamos a la pestaña de avanzadas y añadimos el componente.

image

image

  • También podemos añadir SafeControls, si lo necesitamos.

Estos pasos, son además una restricción cuando se trata de componentes de terceros sobre los que no tenemos ningún control (no podemos tocar su código fuente, recompilar, etc).

Y ya está! en la siguiente imagen, he creado un webpart (los webpart visuales son posibles en SharePoint Online, pero utilizando otra plantilla) que al cargarse hace una llamada a una dll que está fuera del webpart y que devuelve un simple string.

image

Office 365: Migrando reglas de Outlook a Office 365

Siguiendo con el post anterior, os dejo un pequeño “tip” por si alguien no se ha dado cuenta. Seguimos en el escenario de migrar el correo a Office 365 haciendo uso de Outlook y teniendo las 2 cuentas configuradas.

Para migrar las reglas de outllok de la cuenta antigua a la nueva de Office 365, podemos hacer lo siguiente:

Abrimos la administración de reglas y alertas:

image

Seleccionamos la cuenta antigua, y pulsamos el botón de “copiar”

image

Nos pide la cuenta sobre la que copiaremos la regla, así que elegimos la cuenta de Office 365:

image

y ya está!! en unos instantes las reglas ya estarán disponible desde OWA.

OJO: Aunque la regla se copia, las referencias a las carpetas, seguirán apuntado a carpetas de la cuenta antigua, así que habrá que editar la regla para actualizar las referencias a las carpetas (Inbox, Elementos eliminados, etc…).

Saludos.

Office 365: Migrando elementos de correo a Office 365 desde Outlook 2010

Escenario

Partimos de una cuenta POP3 o Exchange 2007 configurada en un cliente Outlook 2010 (Mails, Tareas, Calendarios…) y queremos migrar esos elementos a nuestra nueva cuenta de Exchange Online en Office 365. Además, la nueva cuenta de Office 365 también la hemos configurado en nuestro Outlook cliente.

image

En la figura superior, la primera cuenta es la de POP3, y la de abajo, la cuenta de Office 365.

Solución

Para el caso de los emails, como es muy posible que tengáis muchos emails archivados en carpetas, que seguramente no vayáis a usar en la vida (no todos), yo os recomiendo que aprovechéis la migración para hacer limpieza de los mismos. En mi caso, para migrar los emails, yo lo que he hecho ha sido copiar y pegar las carpetas y mails que me interesaban, directamente de la cuenta POP3 a la de Office 365.

No obstante, el proceso que os voy a contar para el resto de items, debería funcionar también con los mails.

Paso 1: Exportar los elementos de Outlook a un fichero .PST

En el menú “Archivo” entramos en la opción de Avanzado y pinchamos en el botón de Exportar

image

Exportamos a un archivo .PST

image

image

Seleccionamos la carpeta que queremos exportar, en este caso, el calendario.

image

Podemos añadir una contraseña el PST generado.

image

Paso 2: Importar fichero .PST a Outlook

Volvemos al menú “Archivo- Avanzado” y seleccionamos esta vez la opción de Importar, desde fichero PST.

image

image

Seleccionamos el PST que hemos generado en el paso 1.

image

Elegimos los elementos a exportar (el pantallazo es de un PST que he generado con las Notas. En el caso del calendario es lo mismo)

image

Llegado este paso, seleccionaremos la cuenta de Office 365. Ahora bien, haciéndolo así, yo he tenido un problema con el idioma de la cuenta. No sé por qué, mi Office 365 tiene las carpetas nombradas en Inglés, mientras que mi cuenta POP, estaba en Castellano. Esto significa que en POP3 tenía una carpeta “Calendario”, mientras que en Office 365, era “Calendar”, esto ha hecho que en lugar de importar los elementos del calendario en la carpeta “Calendar”, me ha creado un 2o calendario en la cuenta de Office 365.

Para evitar esto, os recomiendo que, antes de empezar el proceso de Importación, nos situemos en el calendario de Office 365, así, llegado al último punto, seleccionamos el check de “Importar elementos en la carpeta actual”. De esta forma, los elementos del calendario se crearán en el calendario por defecto de Office 365.

Otro efecto de la migración, es que los items del calendario, llevan insertado en el título: “Copia de: titulo original…”

Espero que os sirva!

Saludos.