Office365: Invitar usuarios Externos

Desde SharePoint Online podemos colaborar con usuarios externos a Office365 sin consumo de licencias, se podría asemejar al concepto de Extranet. Mediante esta funcionalidad el administrador de la colección puede enviar invitaciones al site a usuarios externos pudiendo incluirse éstos incluso en los grupos de visitantes o miembros. A estos usuarios les llegará un mail indicando que han sido invitados al site junto con la url de acceso. Para poder acceder los usuarios externos deben disponer de un mail registrado como cuenta en Windows Live ID o en Microsoft Online Service.

De momento existe un máximo de 50 usuarios externos aunque puede que en siguientes versiones podamos ampliar el número de usuarios externos comprándolos por paquetes.

Para utilizar esta funcionalidad hay que habilitar la feature a nivel de colección de sitios “External users invitations”. Para enviar una invitación a un usuario, desde el botón de “Acciones del sitio” aparecerá la opción “Share Site”, al seleccionarla aparecerá una pantalla desde la que introduciremos todos los mails que queremos invitar a nuestra colección. Los usuarios recibirán un mail como se muestra en la imagen, de forma que cuando pulsen en “Aceptar la invitación” navegarán a la url del site desde el que se les ha invitado.

 

Mail de invitación de los usuarios externos:

Pantalla de logon para usuarios externos en Office365:

WebCast Beneficios de vender con Microsoft Online Services

Hoy a las 12 se realizará este WebCast donde mostraremos los servicios online que Microsoft ofrece actualmente en modo SaaS, las características y modo de licenciamiento de Office365 y Windows Intune. También veremos los beneficios que tienen los partners al vender servicios de Microsoft Online Services y explicaremos las ventajas de participar en el Microsoft Cloud Essentials Pack.

 

Podéis acceder desde el Link de registro para partners: REGISTRO

O bien si no disponéis de usuario en la MPN: https://www.livemeeting.com/cc/microsoft/join?id=GNG8RD&role=attend&pw=F%7E8%29%3Dwwdk

Modelos de integración remota con SharePoint Online

Ya hemos adquirido Office365 y tenemos que subir a SharePoint Online los documentos que ya tenemos en nuestra empresa o bien queremos mostrar desde nuestras aplicaciones datos almacenados en SharePoint Online, pero ¿Cómo lo hacemos?.

Entre las opciones de integración con SharePoint Online disponibles podemos utilizar las siguientes:

• Sin desarrollo
• Mediante WebDav
• Microsoft SharePoint Workspace 2010
• SharePoint Designer 2010
• Con desarrollo
• Mediante el modelo de objetos cliente
• A través de los servicios web y REST de SharePoint Online

 

WebDav

Nos permite explorar las bibliotecas de SharePoint desde la ventana de explorador de Windows, pudiendo subir o descargar documentos como si fuera una carpeta de red.

Microsoft SharePoint WorkSpace 2010

Consiste en una aplicación cliente que podemos adquirir con Microsoft Office Professional Plus 2010, mediante WorkSpace podemos trabajar con sitios de SharePoint de forma conectada y en modo Offline, encargándose WorkSpace de toda la gestión de concurrencia de modificaciones. Además WorkSpace está pensado para optimizar la subida de documentos y nos notifica ante nuevas modificaciones y conflictos encontrados.

 

SharePoint Designer 2010

Es una herramienta cliente que nos permite personalizar SharePoint sin necesidad de escribir código. También podremos subir y descargar documentos desde sus opciones de navegación:

 

Modelo de objetos cliente

Consiste en un API que permite interactuar con elementos de SharePoint desde aplicaciones que se ejecutan fuera del servidor, en concreto: Silverlight, ECMASCRIPT y aplicaciones de escritorio. La ventaja de utilizar el MO cliente es que el código necesario es parecido al utilizado en código del servidor.

El MO cliente es la interfaz recomendada a la hora de realizar desarrollo externos a SharePoint. Cuando estemos realizando una aplicación Silverlight o ECMASCRIPT que no esté alojada en Office365 tendremos que validarnos primero contra Office365 y utilizar los token de seguridad asignados en las llamadas del MO cliente (excepto si utilizamos la federación de identidades). Esto se debe a que Office365 utiliza autenticación basada en claims consumiendo su propio servicio de autenticación.

Para autenticarnos en Office 365 aconsejo utilizar el ejemplo de Wictor Wilén, How to do active authentication to Office 365 and SharePoint Online, en el que podréis encontrar una implementación de un Helper para obtener un CookieContainer con el token de seguridad para luego utilizarlo en las llamadas del MO cliente.

Desde el post “Autenticación remota en SharePoint Online mediante la autenticación basada en notificaciones” describe cómo utilizar la clase ClaimClientContext con SharePoint Online, pero en este caso el usuario tendrá que especificar las credenciales manualmente.

 

Servicios web y REST de SharePoint Online

SharePoint Online dispone de una serie de servicios web WCF y REST con los que podremos comunicarnos. En este caso para autenticarnos utilizaremos el sistema mencionado en el punto anterior. Para poder manejar fácilmente la propiedad CookieContaniener utilizaremos la opción de compatibilidad al crear la clase Proxy desde Visual Studio.

Cómo conseguir el logotipo Powered by Windows Azure

El programa logotipo Powered by Windows Azure permite ayudar a los clientes y partners promocionar sus productos y servicios Azure, además de poder incluirse en el catálogo de casos de éxito de Azure. Desde el portal Microsoft Platform Ready podremos conseguir un logotipo que podremos añadir a nuestro portal indicando que nuestro servicio ha sido certificado. Para conseguir el logotipo se debe asegurar que pasa un test en el que se comprueba:

• Que la solución se ejecuta sobre una IP válida de Windows Azure
• Que el contenido y funcionalidad no viola ninguna de las leyes
• Que cumple con los requisitos mínimos de rendimiento

 

Para conseguir el logotipo Powered Windows Azure debemos logarnos con una cuenta Windows Live ID en el sitio de Microsoft Platform Ready, desde aquí registraremos una aplicación indicando una breve descripción y la plataforma sobra la que se ejecuta (para Azure seleccionaremos “Plataformas de la nube” y “Windows Azure Platform”).

Una vez registrada comenzaremos la ejecución de un test descargándonos e instalando en nuestro equipo la herramienta “Microsoft Platform Ready Test Tool”. Desde esta herramienta realizaremos un test acerca del estado de nuestra aplicación sobre Azure, por lo que necesitaremos que nuestra aplicación o servicio esté ejecutándose en ese momento sobre Azure. Al ejecutar la aplicación nos solicitará el nombre del test y la plataforma a testear (en este caso “Windows Azure”). A continuación introduciremos los datos identificativos de nuestra aplicación sobre Azure:

• Susbscription ID: Identificador de la suscripción de Azure.
• Certification File: Fichero *.cer configurado en Azure para tareas de administración.
• Physical server Address:: Url de la aplicación en Azure, por ejemplo http://estoyenlanube.cloudapp.net.

En ocasiones podremos encontrarnos un error del tipo “The subscription id or the certification provided is invalid” ahún siendo correctos los datos. Esto se debe a que o bien el certificado que estamos utilizando no es un certificado de configuración válido o bien no lo hemos agregado como certificado válido para nuestra suscripción. Para generar el certificado desde la consola de comandos de visual Studio ejecutamos el siguiente comando: makecert -r -pe -a sha1 -n CN=AzureMgmt -ss My “AzureMgmt.cer” . A continuación debemos instalar localmente el certificado generado en la ubicación “Personal”.

Registraremos el certificado en Azure entrando a la página de administración de Azure y seleccionándolo desde “Management Certificates”. Si aún siguiera dando errores debemos comprobar que al navegar desde IEXplorer a una url del tipo “https://management.core.windows.net/{SuscriptionID}/services/storageservices” accedemos correctamente y disponemos de “Storage Account”.

 

Una vez finalizado el proceso de registro, continuamos con el test hasta finalizarlo. Al completarse crearemos un report del test Seleccionando la opción “Report”. Esta opción nos creará un paquete de test que deberemos subir al portal de Microsoft Platform Ready. Entre los datos que nos solicitará tendremos que indicar el “Application ID” que obtendremos desde el portal Microsoft Platform Ready en la opción “Prueba de mis aplicaciones”.

Cuando se haya subido el paquete de test, se generará un job de análisis, una vez completado ya podremos descargar el logotipo Powered by Windows Azure.

Transición de BPOS a Office365

BPOS (Business Productivity Online Suite) es la plataforma de Microsoft de servicios de productividad en la nube previa a Office 365. Con la aparición de Office 365 en Junio de 2011 los usuarios de BPOS pueden programar la  fecha de transición de sus servicios y datos desde BPOS a Office 365. Esta transición es gratuita y para todos las suscripciones de BPOS. Microsoft se encargará de todas las actualizaciones de infraestructura de servidores y de migración de datos, garantizando que la transición sea un proceso sencillo para los clientes.

El motivo de realizar esta transición es que BPOS está construido sobre servidores dedicados adaptados a los requisitos en la nube, mientras que la nueva arquitectura de Office 365 está diseñada para soportar servicios facilitando su gestión y flexibilidad.

Al pasar a Office 365 las suscripciones de BPOS se transformarán en otras de Office 365:

Suscripción de BPOS actual	Suscripción nueva
BPOS Standard Suite	Office 365 (plan E1)
BPOS Deskless Worker Suite	Office 365 (plan K1)
Exchange Online	Exchange Online (plan 1)
Exchange Online Deskless Worker	Quiosco de Exchange Online
SharePoint Online	SharePoint Online (plan 1)
SharePoint Online Deskless Worker	Quiosco de SharePoint Online (K1)
Live Meeting Standard	Lync Online (plan 2)
Office Communications Online	Lync Online (plan 1)

Consulta los planes de Office 365 office365.microsoft.com/office365-plans.aspx.

Las transiciones programadas empezarán a partir de Septiembre de 2011 y se prevé que todos los clientes de BPOS hayan cambiado a Office365 como máximo antes de Septiembre de 2012. Microsoft irá informando de la transición a los clientes entre 60 y 90 días antes de su fecha programada. Aunque Microsoft le puede fijar una fecha, usted puede proponer otra fecha desde el portal de Administración de BPOS.

Una vez fijada la fecha de transición, unas semanas antes irá recibiendo mensajes recordatorios para que vaya preparándose para la transición. Los clientes tendrán que formarse por su cuenta en Office 365 y serán responsables de actualizar en sus equipos locales el software cliente necesario, consulte los requisitos en  http://onlinehelp.microsoft.com/office365-enterprises/es-es/ff652534.aspx.

El proceso de sincronización dura unas 48 horas y se realizará por la noche o durante un fin de semana. Durante el proceso sufrirá cortes en los servicios, podrá estar en contacto frecuente con el equipo de soporte a la transición que le ayudará y escuchará los posibles problemas que encuentre.

Durante el proceso de transición no podrá realizar cambios en los servicios y el administrador recibirá información acerca de las siguientes acciones después de la transición.

Después de la transición, el administrador tendrá que abrir una nueva sesión del portal de administración de BPOS, en ese momento se le redirigirá a la nueva Url de administración en Office 365. Las credenciales del administrador no cambiarán, al iniciar sesión en Office 365 tendrá que validar los datos de facturación y que se han migrado las suscripciones de BPOS a Office365.

Los usuarios finales accederán con su usuario y password de BPOS habitual, Outlook se reconfigurará automáticamente, pero tendrán que cambiar manualmente la url de OWA.

 

Más información en:

Centro de transición a Microsoft Office 365

Guía de transición para ayudarlo a planificarse y prepararse

Making the transition from BPOS to Office 365

SharePoint 2010: Control de actualizaciones

Una de las nuevas funcionalidades de SharePoint 2010 es el control de las actualizaciones, ya que ahora SharePoint es capaz de controlar las actualizaciones instaladas por cada uno de los productos. Desde la administración Central > Upgrade and Migration > check product and patch installation status encontraréis las versiones y hotfix de cada uno de los módulos instalados. Cuando Tengamos una granja con varios servidores podremos ver por cada uno de los servidores los productos instalados y si es necesario realizar alguna actualización.

Pero no solo se hace la comprobación con los servidores instalados sino también cuando vamos a agregar nuevos servidores. En el momento de ejecutar el asistente de configuración si el nuevo servidor a agregar a la granja no dispone de las mismas actualizaciones que el resto de servidores aparecerá un mensaje indicando cada una de las actualizaciones necesarias junto con su enlace al KB correspondiente para su descarga. En ese caso tendremos que realizar un windowsupdate o descargar e instalar manualmente el hotfix o kb que corresponda.

 

Error Access denied by Business Data Connectivity

Al intentar realizar cualquier operación con el servicio de BCS (Business Data conectivity Services) de SharePoint 2010 me aparecía el error “Access denied by Business Data Connectivity”. Al mirar el correlation Toke en el log de SharePoint, me encontré con esta entrada:

SPSecurityContext.WindowsIdentity: Could not retrieve a valid windows identity for NTName='midominio\Administrator', UPN='administrator@'midominio.COM'. UPN is required when Kerberos constrained delegation is used. …

 

La solución consistió en activar la instancia de servicio “Claims to Windows Token services”.

Para verificar el funcionamiento de BCS verificar los siguientes pasos:

• Que tenéis permisos de administrador sobre BCS para crear ECt: desde la administración de aplicaciones de servicio, seleccionar la aplicación de servicio de BCS > Administrators y agregar un usuario administrador del servicio.
• Que tenéis activa la instancia de servicio “Business Data conectivity Services”.
• Que tenéis activa la instancia de servicio “Claims to Windows Token services”.
• Que habéis instalado el hotfix de WCF para Windows 7 or Windows Server 2008 R2