October 2011 - Artículos
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:
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)
Podemos ejecutar la app en modo avanzado (seleccionando las opciones que más nos interesen)
Y arranca el generador de informe:
Cuando termina, la aplicación nos abre un explorador de archivos donde podemos ver los resultados del análisis.
En las carpetas, tenemos varios ficheros log con información sobre versiones de SW, claves del Registry, operaciones realizadas, resultados…
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.
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.
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.
Desde esta tabla, si alguno de los iconos no marca “ok”, podemos ver el detalle del problema, como muestra esta imagen:
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.
Para acabar, una última pantalla que hasta ahora no había visto. Se trata de un mensaje de error del servicio.
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.
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 
, 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:
Y como quedan en la solución si añadimos una .dll y uno de PowerShell:
Ordenadito, verdad!!
Si nos centramos en las soluciones de SharePoint, tenemos un abanico enorme.
Plantillas para la Ribbon!! con ejemplos y todo!
Webparts de todo tipo, incluido un ejemplo de webpart con AJAX
Fijaros que genialidad. Dentro de la sección de asp.net, tenemos:
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!
¿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:
Otra cosa es que en proyectos sandbox, los tipos de items que se pueden agregar al proyecto tb disminuyen:
Y para acabar, también tiene la opción de hacer deploy de soluciones Sandbox:
Y nada más, espero que os sirva.
Saludos!!
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!!
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.
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="<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:
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:
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.
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.
- 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.
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:
Seleccionamos la cuenta antigua, y pulsamos el botón de “copiar”
Nos pide la cuenta sobre la que copiaremos la regla, así que elegimos la cuenta de Office 365:
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.
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.
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
Exportamos a un archivo .PST
Seleccionamos la carpeta que queremos exportar, en este caso, el calendario.
Podemos añadir una contraseña el PST generado.
Paso 2: Importar fichero .PST a Outlook
Volvemos al menú “Archivo- Avanzado” y seleccionamos esta vez la opción de Importar, desde fichero PST.
Seleccionamos el PST que hemos generado en el paso 1.
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)
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.