Ir al contenido principal

Configurar un registro de aplicación de Azure para migraciones de SharePoint con PowerShell

Cómo configurar un registro de aplicación de Azure para ejecutar migraciones de SharePoint y Teams con PowerShell en ShareGate Migrate sin una cuenta de usuario con la sesión iniciada.

Note: PowerShell integration requires a Suscripción Pro o Enterprise de ShareGate Migrate. It is not available on the Essentials plan.

Este artículo es solo para la PowerShell integration de ShareGate Migrate.

La autenticación solo de aplicación te permite ejecutar migraciones de SharePoint y Teams desde PowerShell sin una cuenta de usuario con la sesión iniciada. En lugar de credenciales de usuario, ShareGate Migrate se autentica mediante un registro de aplicación de Azure.

Durante la configuración, crearás un registro de aplicación, subirás una credencial de certificado y concederás los permisos de API necesarios.

Luego usarás el Application (client) ID y el certificado para autenticarte desde PowerShell.

Antes de comenzar

  • Suscripción Pro o Enterprise de ShareGate Migrate

  • Se necesita acceso de Global Administrator en el inquilino de Microsoft 365 para crear el registro de aplicación y conceder el consentimiento del administrador

Configura el registro de la aplicación

Haz esto en cada inquilino desde o hacia el que migres.

Para una single-tenant app (usada solo dentro de un único inquilino), repite la configuración completa para cada inquilino.

Para una multi-tenant app (donde un mismo registro se reutiliza en varios inquilinos), completa los pasos en tu inquilino principal y luego concede el consentimiento del administrador en cada inquilino adicional.

Paso 1: genera un certificado

ShareGate usa un certificado para autenticarse como tu aplicación. Ejecuta el siguiente script de PowerShell para generar un certificado autofirmado en tu almacén de usuario local y exportarlo a tu escritorio.

# Generate a self-signed certificate in your local user store
$certName = "AzureAppAuthCert"
$cert = New-SelfSignedCertificate -Subject "CN=$certName" -CertStoreLocation "Cert:\CurrentUser\My" -KeyExportPolicy Exportable -KeySpec Signature -KeyLength 2048 -KeyAlgorithm RSA -HashAlgorithm SHA256

# Export the public key (.cer) - upload this to Azure in Step 3
Export-Certificate -Cert $cert -FilePath "$home\Desktop\$certName.cer"

# Export the private key as a .pfx - required if connecting via Option B
$pfxPassword = ConvertTo-SecureString -String "choose-a-strong-password" -Force -AsPlainText
Export-PfxCertificate -Cert $cert -FilePath "$home\Desktop\$certName.pfx" -Password $pfxPassword

# Copy this value for use with New-AzureApplication
Write-Host "Thumbprint: $($cert.Thumbprint)"

Ambos archivos se guardan en tu escritorio. Sube el archivo .cer a Azure en el paso 3. Si planeas conectarte mediante la opción B, también necesitarás el archivo .pfx.

Anota la huella digital que aparece en la consola. La usarás con New-AzureApplication en el paso de conexión.

Paso 2: registra la aplicación en Microsoft Entra ID

  1. Inicia sesión en el Centro de administración de Microsoft Entra como Global Administrator.

  2. Ve a Entra ID > App registrations > New registration.

  3. Asigna un nombre a la aplicación (por ejemplo, ShareGate Migration).

  4. En Supported account types, elige My organization only para una single-tenant app, o Multiple Entra ID tenants para una multi-tenant app usada en varios inquilinos.

  5. Deja vacío el campo Redirect URI.

  6. Haz clic en Register.

  7. En la página Overview, copia el Application (client) ID. Lo usarás con New-AzureApplication.

Paso 3: sube el certificado

  1. En tu registro de aplicación, ve a Certificates & secrets > Certificates y luego selecciona Upload certificate.

  2. Sube el archivo .cer desde tu escritorio.

  3. Haz clic en Add.

Paso 4: agrega permisos de API

  1. En tu registro de aplicación, ve a API permissions > Add a permission.

  2. Agrega cada Application permission que se indica a continuación. Agrega los permisos de Microsoft Graph y los de SharePoint como entradas separadas. No selecciones Delegated permissions.

  3. Haz clic en Grant admin consent for [your tenant] y confirma.

Permisos de Microsoft Graph:

ChannelMember.ReadWrite.All

Pertenencia a canales de Teams

ChannelSettings.ReadWrite.All

Configuración de canales de Teams

Directory.ReadWrite.All

Objetos de directorio

Files.ReadWrite.All

Archivos en todas las colecciones de sitios

Group.ReadWrite.All

Grupos de Microsoft 365

InformationProtectionPolicy.Read.All

Directivas de protección de la información

SensitivityLabels.Read.All

Etiquetas de confidencialidad

Notes.ReadWrite.All

Blocs de notas de OneNote

Sites.FullControl.All

Control total de todas las colecciones de sitios

Sites.Manage.All

Crear, editar y eliminar elementos en todas las colecciones de sitios

Sites.ReadWrite.All

Leer y escribir elementos en todas las colecciones de sitios

Tasks.ReadWrite.All

Tareas de Planner

Team.Create

Crear equipos

TeamMember.ReadWrite.All

Pertenencia a equipos

TeamsAppInstallation.ReadWriteForUser.All

Instalaciones de aplicaciones de Teams

TeamSettings.ReadWrite.All

Configuración de equipos

TeamsTab.ReadWrite.All

Pestañas en canales de Teams

TermStore.ReadWrite.All

Almacén de términos

User.Read.All

Perfiles de usuario

Permisos de SharePoint:

Nota: Los permisos de SharePoint se encuentran en SharePoint dentro de la lista de API, no en Microsoft Graph.

Sites.FullControl.All

Control total de todas las colecciones de sitios

Sites.Manage.All

Crear, editar y eliminar elementos en todas las colecciones de sitios

Sites.Read.All

Leer elementos en todas las colecciones de sitios

Sites.ReadWrite.All

Leer y escribir elementos en todas las colecciones de sitios

TermStore.Read.All

Almacén de términos (lectura)

TermStore.ReadWrite.All

Almacén de términos (lectura y escritura)

User.Read.All

Perfiles de usuario (lectura)

User.ReadWrite.All

Perfiles de usuario (lectura y escritura)

Conéctate desde ShareGate

Crea un objeto de credencial con New-AzureApplication y luego pásalo a Connect-Site o Connect-Tenant.

Opción A: huella digital del certificado (del script de generación)

Si usaste el script del paso 1, el certificado está en Cert:\CurrentUser\My. Pasa la huella digital directamente:

# Build a credential object from the certificate thumbprint
$app = New-AzureApplication -ClientId "<application-client-id>" -Thumbprint "<certificate-thumbprint>"

# Connect to a specific site
Connect-Site -Url "https://contoso.sharepoint.com/sites/Marketing" -AzureApplication $app

# Or connect at the tenant level
Connect-Tenant -Domain "contoso" -AzureApplication $app

Opción B: certificado desde un archivo .pfx

Si tienes el certificado como archivo .pfx, cárgalo directamente:

# Load the certificate from a .pfx file
$certificate = [System.Security.Cryptography.X509Certificates.X509Certificate2]::new(
    "C:\certs\sharegate-app.pfx",
    "your-pfx-password")

# Build a credential object
$app = New-AzureApplication -ClientId "<application-client-id>" -Certificate $certificate

# Connect to a site
Connect-Site -Url "https://contoso.sharepoint.com/sites/Marketing" -AzureApplication $app

Un solo objeto de aplicación puede autenticar varias conexiones en la misma sesión. Reutiliza la misma variable $app en varias llamadas a Connect-Site o Connect-Tenant.

Nota: Si tu directiva de seguridad impide conceder uno de los permisos requeridos, agrega -AllowMissingPermissions a Connect-Site o Connect-Tenant para conectarte de todos modos.

Las operaciones que dependen del permiso faltante fallarán con errores Forbidden.

Este modificador solo flexibiliza la verificación de permisos después de que la autenticación se realiza correctamente. No resuelve un inicio de sesión fallido.

Guarda y reutiliza una aplicación

Puedes guardar un objeto de registro de aplicación y recuperarlo en sesiones posteriores, así no necesitas volver a crearlo cada vez. Usa Save-AzureApplication para guardarlo y Get-AzureApplication para recuperarlo.

Limitaciones conocidas

  • Modified By y Created By no se conservan durante la migración. Los elementos muestran la identidad de servicio de la aplicación en lugar del autor original.

  • User alerts se omiten. La autenticación solo de aplicación no tiene un contexto de usuario para enviar alertas.

  • Classic web parts no se migran.

  • Classic SharePoint workflows no se migran.

  • InfoPath forms se migran parcialmente. Es posible que aparezcan advertencias.

  • Publishing approval workflows requieren un contexto de usuario. Es posible que aparezcan errores o advertencias.

  • Sensitivity labels aún no se aplican durante la migración. Está previsto agregar compatibilidad en una futura actualización.

Este artículo fue traducido con inteligencia artificial. En caso de duda, consulta la versión original en inglés.

¿Ha quedado contestada tu pregunta?