Different scheme for different channelsIntranet HTTPExtranet HTTPSProtecting access from different channelsPreventing employees log in from home except Sales divisionDedicate Extranet to vendors onlyPreferred choice for solutions that require separate environmentsPublishing Portal authored by employees and consumed by customers
Same experience for different class of usersSingle URLSame experience for same users no matter where they access content from:A la’ Outlook Web AccessPreferred choice for cross company collaboration solutions
The user tries to access an Office 365 Service (like OWA Exchange from IE)The service tells the client that it needs a service ticket signed by the Office 365 Microsoft Federation Gateway, so go get a ticket from thereThe client goes to the Office 365 Federation Gateway (FG) asking for a service ticket. The FG says it can’t sign you in, it needs a login token signed by your on-premise STS (security token services). In this case this is Active Directory Federation Services 2.0The client goes to the AD FS 2.0 Server to request a login token. AD FS 2.0 server contacts your AD, getting an NTLM token or Kerberos ticket for you, and then transforms this into a login SAML token (containing claims about the logged in user – their username/UPN and their userSourceID) which it then signsThe client presents this signed SAML token to the FG which it opens. The FG checks that the token is indeed signed by the trusted authority for the federated domain through the public key that was shared during the trust establishment. The FG then transforms the userSourceID into a unique identifier or NetID; and then the FG creates a new transformed token, which it signs – which forms the service ticketThe client presents the service ticket to the relying party service. The relying party service opens the ticket, checking that it is signed by the trusted party (the FG) based on a shared public key. It looks at the NetID claim and searches for a user in its directory with that NetID. [The NetID was set as part of provisioning/creating the user, and synchronized to the service.] Once found, the service can apply the necessary access control checks before allowing the user access to services.
The user logs on to their client desktop machine on their corporate network. The client service (Microsoft Online Services Sign in assistant service) starts up and gets the logged on user’s domain by looking at the domain suffix of their UPN.The client service calls a home realm discovery service on the federation gateway (FG). The FG checks to see if that domain is a registered federated domain. If not it returns nothing; if it is, the FG returns the Meta-data Exchange endpoint (MEX endpoint) on the registered federation server (the org’s AD FS 2.0 server).If nothing is returned the client service is done. If a MEX endpoint is returned the client service contacts the MEX endpoint, which returns a list of WS-Trust endpoints exposed by the AD FS 2.0 server. The client service chooses the most appropriate authentication endpoint type and requests a SAML1.1 token.The AD FS 2.0 server gets the logged on user’s NTLM token or Kerb ticket and transforms it into a SAML1.1 token (containing claims/assertions about the logged in user – their username/UPN and their userSourceID) which it then signsThe SAML token is returned to the client service, which now requests a service token from the federation server, providing the SAML1.1 token it received from AD FS 2.0.The FG checks that the token is indeed signed by the trusted authority for the federated domain through the public key that was shared during the trust establishment. The FG then transforms the userSourceID into a unique identifier or NetID; and then the FG creates a new transformed ticket granting token (TGT) which is sent back to the clientThe client service now caches this TGT ready for use by the client applications.The user now starts up OutlookOutlook attempts to connect to Exchange Online (via Windows Integrated Auth and the SSPI layer using Negotiate), but Exchange Online challenges for a service ticket (that was signed by the federation gateway).Outlook (via the negotiated SSP in the SSPI layer) requests the a service ticket from the client service. The client service contacts the FG presenting the TGT to get a service specific signed ticket and then presents it to the SSP, which then sends the service ticket over secure channel to Exchange Online. Exchange Online opens the ticket, checking that it is signed by the trusted party (the FG) based on a shared public key. It looks at the NetID claim and searches for a user in its directory with that NetID. [The NetID was set as part of provisioning/creating the user, and synchronized to the service.] Once found, the service can apply the necessary access control checks before allowing the user access to services.
Business Data Catalog evolucionahaciaBusiness Connection Service + Business Data ConnectivityLa herramienta de off-line, pasa a convertirse en ClientedesconectadopuroLa estructura de Services se consolida en la estructura de Foundations
Mayor número de servicios en servidor de plataforma y másutilidades no-code en la base de la plataformaIntegraciónnativa conlasherramientas OfficeMayor soporte de navegadores
The SharePoint Diagnostic tool (SPDiag) version 1.0 was included with the SharePoint Administration Toolkit v3.0
Esposiblemonitorizarcódigopersonalizado y web parts, unavez se ha encapsuladocon SPMonitoredScopes
Microsoft® SharePoint® Server 2010 provides a broad range of levels for performing backups, including the entire farm, farm configuration information, site collections, subsites, or lists. Backups can be done by using the Central Administration pages or Windows PowerShell™. Note Stsadm is still available to perform backups to maintain backward compatibility. It is recommended that all new backup plans incorporate Windows PowerShell in place of Stsadm.
Clicking the Backup and Restore link displays another new set of features. Previously the ability to perform granular backups such as backing up a site collection, site, or list was only possible by using the Stsadm command line tool. New in SharePoint Server 2010 is the ability to perform these granular backups directly from the Backup and Restore page in Central Administration.A complete disaster recovery plan not only includes the ability to restore servers and databases but also how to recover smaller units of data like a single document.SharePoint Server 2010 has added the ability to recover data from an unattached content database: In other words, if you need to restore data from a backed-up content database, you can browse the content of that content database as long as it is attached to a computer running SQL Server, even if it is not necessarily associated with SharePoint Server.
One of the parameters of the Windows PowerShell command will cause a SQL snapshot to be generated, and then Windows PowerShell will run the action against the snapshot instead of the production database. This will reduce the resource impact of the backup operation on the production environment.
SharePoint Server 2010 provides several new features that provide a granular level of backup for various components of site content. This includes content at the site, subsite, and list level. When backing up the site collection through Central Administration, a SharePoint administrator identifies the site collection and provides a destination for the storage of the backup file.
Es posible determinar el uso de SQL Snapshots, la compresión y el registro del proceso.
SharePoint administrators can simply do a SQL Server restore of the content database to any computer running SQL Server, then tell SharePoint to connect to it. Click:Now they can browse the contents of the database and then back up or export the content they need. This eliminates the need to build a second farm for granular recovery. After you point to the unattached content database you will be able to browse, back up, or export the content. The same level of backup granularity is available for both attached and unattached content databases.
Regular label-callout textMulti-AuthenticationMixed AuthenticationSharePointFarmWeb ApplicationExtended Web ApplicationExtended Web ApplicationExtended Web ApplicationExtended Web ApplicationZone: CustomZone: ExtranetZone: IntranetZone: InternetZone: DefaultWindowsAuthenticationFBAAuthentication.........SharePointFarmWeb ApplicationExtended Web ApplicationExtended Web ApplicationExtended Web ApplicationExtended Web ApplicationZone: CustomZone: ExtranetZone: IntranetZone: InternetZone: DefaultWindows AuthenticationFBA AuthenticationSAML Based AuthenticationFBA AuthenticationWindows Authentication......
• Leer la documentación de actualizaciónAprender• Utilizar el comando de comprobación de actualización, entodos los entornosPreparar• PoC (proof of concept) con las personalizaciones actualesy actualizadasTestear• Mejorar MOSS 2007 con SP2• Mover a 64 bit el hardware, los sistemas operativos y SQLImplementar• Resolver incidenciasValidar
Aprender• Requerimientos yrequisitos• Métodos de actualización• Pérdida servicio• Incidencias comunesPreparar• Documentar entorno• Gestionarpersonalizaciones• Planear estrategia• Elementos actualizablesTestear• Granjas de prueba• Datos reales• Evaluar las técnicas• Determinar incidenciasImplementar• Crear/actualizar granjas• Desplegarpersonalizaciones• Minimizar perdida servicio• MonitorizaciónValidar• Actualizar eventos de fallo• UI/UX incidencias• Incidencias Datos
WSS v3/MOSS 2007 SP2BD Read-onlyActualización en paralelo deGranjasActualización GradualSharePoint 2010BD Read-onlyActualización en paralelo deGranjasUnica granja, multiplessesiones de actualizaciónEnlace de BD de contenido,con redireccionamientoAAM