Logic Apps automatiza workflows de integración con 400+ conectores (Office 365, Salesforce, SAP, Twitter, SQL). Visual designer, triggers, actions, conditions, loops. En este post verás diseño de workflows, conectores críticos, error handling, y deployment con Bicep/ARM.
API Management (APIM) centraliza gestión de APIs, aplica políticas (rate limiting, caching, transformations), maneja autenticación OAuth/JWT, y publica documentación. En este post verás setup de APIM, policies críticas, OAuth integration, backends, y monitoring.
Esta entrada explica de forma práctica qué es el Power BI On-Premises Data Gateway Standard, su arquitectura básica, y cómo realizar una instalación estándar y configurarlo para refrescos y conexiones seguras desde el servicio de Power BI. Está orientada a administradores y responsables de plataforma que necesiten conectar fuentes de datos locales a Power BI sin usar soluciones de red avanzadas (no cubre la instalación en Virtual Network Data Gateway ni escenarios sovereign).
El On-Premises Data Gateway es un componente que actúa como puente entre los servicios cloud de Microsoft (por ejemplo, Power BI, Power Automate, Power Apps) y tus datos que residen en la red local o en entornos no accesibles públicamente. Proporciona un canal saliente seguro (TLS) para permitir conexiones desde la nube hacia los orígenes de datos on‑premises sin abrir puertos entrantes en tu red.
Principales funciones:
flowchart LR
PB["Power BI Service"]
AZ["Azure Relay / Service Bus"]
GW["On-Premises Gateway"]
DB["Origen de datos"]
DB --> GW
GW --> | TLS saliente | AZ
AZ --> PB
flowchart LR
subgraph Cloud["Servicio Cloud"]
PB["Power BI Service"]
end
subgraph Cluster["Cluster de Gateways (HA)"]
GW1["Gateway - Nodo 1"]
GW2["Gateway - Nodo 2"]
GW3["Gateway - Nodo N"]
end
subgraph OnPrem["Red On-Premises"]
DB["(Origen de datos)"]
end
AZ["Azure Relay / Service Bus"]
GW1 --- GW2
GW2 --- GW3
AZ --> PB
Cluster --> | TLS saliente | AZ
DB --> Cluster
Note
Físicamente el Gateway establece conexiones salientes TLS hacia los servicios de Azure (Azure Service Bus / Azure Relay). Las solicitudes brokered se mantienen gracias a las conexiones salientes iniciadas por el gateway.
Los pasos siguientes describen una instalación típica y segura de un Gateway estándar:
Descargar el instalador del gateway desde el sitio oficial de Microsoft.
Ejecutar el instalador en el servidor destinado
Acepta los términos y elige la instalación estándar cuando se solicite.
Iniciar sesión y registrar el gateway
Registra el gateway en tu tenant y proporciona un nombre descriptivo para el gateway.
Definir la clave de recuperación
El asistente pedirá que crees una "recovery key". Guárdala en un lugar seguro: es necesaria para migrar o restaurar el gateway.
Elegir cuenta de servicio (opcional)
Puedes ejecutar el servicio con la cuenta de sistema local por defecto o configurar una cuenta de dominio/service account con los permisos mínimos necesarios para acceder a los orígenes de datos.
Verificar conectividad
Asegúrate de que el servidor puede establecer conexiones TLS salientes a los endpoints de Microsoft (comprobar reglas de firewall/proxy si existen).
(Opcional) Agregar nodos al cluster
Consejos prácticos:
Azure Virtual Desktop (AVD) ofrece escritorios Windows 10/11 y aplicaciones RemoteApp desde Azure. Multiusuario, FSLogix profiles, autoscaling, integration con Entra ID. En este post verás setup de host pools, session hosts, FSLogix storage, autoscale, y monitoring.
EPAC tiene una opción muy útil llamada "Document All Assignments" que genera Markdown y CSV con todas las asignaciones de policy. Pero hay dos detalles importantes que conviene saber:
1) Antes no se podían excluir tipos enteros de scope (por ejemplo: todas las
subscriptions o resourceGroups) desde la configuración.
2) He subido una PR para solucionarlo: https://github.com/Azure/enterprise-azure-policy-as-code/pull/1056
Aquí lo que cambia, rápido y claro.
Si usas documentAllAssignments y quieres evitar documentar todo lo que hay a
nivel de suscripción o de resource groups, la versión anterior obligaba a
listar cada id con skipPolicyAssignments o a procesar el CSV resultante.
En entornos grandes eso resulta muy tedioso y genera mucho ruido en los
informes.
Añade excludeScopeTypes en la configuración de documentAllAssignments.
Con esto se puede indicar que no se documenten assignments que estén en
subscriptions o en resourceGroups.
Añade StrictMode (switch) en los scripts. Por defecto está activado. Si lo
desactivas (-StrictMode:$false) el script no aborta cuando falta alguna
definición; registra avisos y continúa. Útil en pipelines de prueba.
Mejora el parsing y el manejo de skipPolicyAssignments/skipPolicyDefinitions
(funcionan mejor con arrays u objetos) y corrige bugs menores (p. ej.
convertir markdownMaxParameterLength a entero).
PR: https://github.com/Azure/enterprise-azure-policy-as-code/pull/1056
Antes tenías que usar algo así:
{
"documentAssignments": {
"documentAllAssignments": [
{
"pacEnvironment": "EPAC-Prod",
"skipPolicyAssignments": [],
"skipPolicyDefinitions": ["/providers/.../policySetDefinitions/..."]
}
]
}
}
Después basta con añadir excludeScopeTypes:
{
"documentAssignments": {
"documentAllAssignments": [
{
"pacEnvironment": "EPAC-Prod",
"excludeScopeTypes": ["subscriptions", "resourceGroups"],
"skipPolicyAssignments": [],
"skipPolicyDefinitions": ["/providers/.../policySetDefinitions/..."]
}
]
}
}
Y si quieres pruebas rápidas sin que el pipeline falle por referencias rotas:
excludeScopeTypes para reducir ruido cuando necesites una vista global.No confundas excludeScopeTypes con exemptions: esto solo evita que se
documente; no evita que la policy se aplique. Para eso usa exemptions.
Mantén StrictMode activado en producción (ayuda a detectar referencias rotas).
skipPolicyAssignments para exclusiones puntuales que conozcas por id.La mejora es pequeña pero práctica: menos limpieza manual, informes más útiles. Si quieres puedo:
PR de referencia: https://github.com/Azure/enterprise-azure-policy-as-code/pull/1056
Azure Cosmos DB for MongoDB vCore es MongoDB real en Azure, con arquitectura vCore (CPU + RAM) que escala vertical y horizontalmente sin downtime. Soporte nativo para vector search (DiskANN), sharding automático y 99.99% SLA con HA activado. Ideal para lift & shift de aplicaciones MongoDB existentes o nuevas apps que necesiten queries complejas, aggregations y transacciones distribuidas.
Azure Virtual Desktop ahora soporta Ephemeral OS Disks (Public Preview desde octubre 2025), una característica que mejora significativamente el rendimiento y velocidad de aprovisionamiento en entornos de escritorios virtuales. Los discos efímeros almacenan el sistema operativo en el almacenamiento local de la VM en lugar de en Azure Storage remoto, proporcionando latencias más bajas y tiempos de reimagen más rápidos, ideales para cargas de trabajo stateless.
Los Ephemeral OS Disks son discos de sistema operativo creados en el almacenamiento local de la máquina virtual (SSD local, cache o disco temporal) en lugar de almacenarse en Azure Storage remoto. Esta arquitectura ofrece ventajas clave para entornos AVD donde la persistencia del sistema operativo no es crítica.
Características principales:
Beneficios concretos:
flowchart LR
A[Session Host VM] -->|OS Disk| B[Local SSD/Cache]
A -->|User Profiles| C[FSLogix Container]
C -->|Storage| D[Azure Files/NetApp]
style B fill:#2ecc71
style D fill:#3498db
Diferencia clave con discos persistentes:
| Aspecto | Ephemeral OS Disk | Managed OS Disk |
|---|---|---|
| Ubicación | Almacenamiento local VM | Azure Storage remoto |
| Latencia I/O | Muy baja | Mayor (red) |
| Persistencia | No persistente | Persistente |
| Operaciones | Restart/Reimage/Delete | Start/Stop/Deallocate/Snapshot |
| Coste | Incluido en VM | Coste adicional storage |
Placement options:
No soporta:
Configuración de autoscaling:
# Configuración requerida en Azure Portal
Host Pool Type: Pooled
Management Type: Automated
Session Host Configuration: Enabled
# En la pestaña Virtual Machines:
Image: Windows 11 Enterprise multi-session
Virtual Machine Size: Standard_D8s_v3 (temp disk 200 GiB)
OS Disk Type: Standard SSD (auto-selected)
Ephemeral OS Disk: Enabled
Placement: Temp Disk
# Variables del entorno
$resourceGroup = "avd-rg"
$hostPoolName = "avd-ephemeral-pool"
$location = "westeurope"
$vmPrefix = "avd-eph"
$vmSize = "Standard_D8s_v3"
$subnetId = "/subscriptions/<SUB_ID>/resourceGroups/<RG>/providers/Microsoft.Network/virtualNetworks/<VNET>/subnets/<SUBNET>"
# Crear session host configuration con ephemeral disk
$parameters = @{
FriendlyName = "Ephemeral Session Hosts"
HostPoolName = $hostPoolName
ResourceGroupName = $resourceGroup
VMNamePrefix = $vmPrefix
VMLocation = $location
ImageInfoType = "Marketplace"
MarketplaceInfoPublisher = "MicrosoftWindowsDesktop"
MarketplaceInfoOffer = "Windows-11"
MarketplaceInfoSku = "win11-22h2-avd"
MarketplaceInfoExactVersion = "latest"
VMSizeId = $vmSize
DiskInfoType = "Standard_LRS" # Standard SSD requerido en preview
NetworkInfoSubnetId = $subnetId
DomainInfoJoinType = "AzureActiveDirectory"
VMAdminCredentialsUsernameKeyVaultSecretUri = "https://<VAULT>.vault.azure.net/secrets/<SECRET>/..."
VMAdminCredentialsPasswordKeyVaultSecretUri = "https://<VAULT>.vault.azure.net/secrets/<SECRET>/..."
}
New-AzWvdSessionHostConfiguration @parameters
# Listar VM sizes con soporte ephemeral disk
$location = "westeurope"
$vmSizes = Get-AzComputeResourceSku -Location $location |
Where-Object {$_.ResourceType -eq 'virtualMachines'}
foreach ($vmSize in $vmSizes) {
foreach ($capability in $vmSize.Capabilities) {
if ($capability.Name -eq "EphemeralOSDiskSupported" -and $capability.Value -eq "True") {
[PSCustomObject]@{
VMSize = $vmSize.Name
EphemeralSupported = $capability.Value
CacheSize = ($vmSize.Capabilities | Where-Object {$_.Name -eq "CachedDiskBytes"}).Value
TempDiskSize = ($vmSize.Capabilities | Where-Object {$_.Name -eq "MaxResourceVolumeMB"}).Value
}
}
}
}
# Crear scaling plan con configuración específica para ephemeral
$scalingParams = @{
HostPoolName = $hostPoolName
ResourceGroupName = $resourceGroup
ScheduledDateTimeZone = "W. Europe Standard Time"
UpdateLogOffDelayMinute = 15
UpdateMaxVmsRemoved = 10
UpdateDeleteOriginalVM = $true # Importante: eliminar VMs en lugar de deallocate
UpdateLogOffMessage = "El sistema se reiniciará para mantenimiento en 15 minutos"
}
New-AzWvdSessionHostManagement @scalingParams
Para migrar un host pool con managed disks a ephemeral:
# 1. Actualizar session host configuration
$updateParams = @{
HostPoolName = $hostPoolName
ResourceGroupName = $resourceGroup
VMSizeId = "Standard_D8s_v3" # VM size con temp disk suficiente
DiskInfoType = "Standard_LRS"
}
Update-AzWvdSessionHostConfiguration @updateParams
# 2. Programar update para aplicar cambios (reemplaza session hosts)
# Nota: Esto recreará los session hosts con ephemeral disks
# 3. Monitorizar progreso
$progress = Get-AzWvdSessionHostManagementsUpdateStatus @updateParams |
Format-List PercentComplete, ProgressSessionHostsCompleted, EndTime
$progress
Persistencia de datos:
Gestión de ciclo de vida:
Sizing correcto:
Monitorización:
Error: "Insufficient local storage"
# Causa: VM size sin suficiente cache/temp disk
# Solución: Cambiar a VM size mayor o con temp disk adecuado
# Verificar tamaño requerido
$imageSize = 127 # GiB para Windows 11 multi-session
Get-AzComputeResourceSku -Location $location |
Where-Object {$_.Name -eq "Standard_D8s_v3"} |
Select-Object Name, @{N="TempDiskGB";E={[math]::Round(($_.Capabilities |
Where-Object {$_.Name -eq "MaxResourceVolumeMB"}).Value / 1024)}}
Error: "NVMe placement not supported"
Causa: Selección de NVMe como placement durante preview
Solución: Usar Temp Disk o Cache placement en Azure Portal
Pérdida de datos tras deallocate:
Causa: Operación stop/deallocate borra OS state en ephemeral disks
Solución: Configurar autoscaling con UpdateDeleteOriginalVM = $true
Usar restart en lugar de deallocate para operaciones manuales
Añadir usuarios (internos y externos) uno a uno en canales compartidos de Teams es tedioso. Este post muestra cómo automatizar el proceso usando PowerShell, Microsoft Graph y un archivo CSV como origen de datos para añadir múltiples usuarios de forma eficiente.
En este post explico qué son los VNet flow logs (logs de flujo de red de Azure), cómo habilitarlos y cómo analizarlos con un pequeño script PowerShell que desarrollé para facilitar la detección de anomalías y la generación de reportes.
Documentación oficial (Microsoft):
https://learn.microsoft.com/azure/network-watcher/vnet-flow-logs-overview
records con campos que describen cada flujo y sus métricas (bytes, paquetes, acción,
puertos, etc.).He incluido un script llamado Analyze-VNETFlowLogs.ps1 que procesa archivos JSON con VNet flow logs
y genera un análisis en consola. Además puede exportar dos ficheros CSV con el detalle y el resumen del
análisis.
Si tus logs están aún en la cuenta de almacenamiento, puedes usar el script de apoyo
Download-FlowLogs.ps1 para:
insights-logs-flowlogflowevent).-AutoShorten).YYYY-MM-DD/HH/FlowLog_<timestamp>_*.json.Parámetros clave:
- -StorageAccount (obligatorio): Nombre de la storage account.
- -ContainerName: Contenedor (default: insights-logs-flowlogflowevent).
- -DownloadPath: Carpeta destino local (default: ./FlowLogs).
- -AutoShorten: Acorta automáticamente rutas demasiado largas mediante hashing.
- -Force: Omite confirmaciones interactivas.
Variables de entorno soportadas:
- AZ_STORAGE_KEY: Si está definida se usa esa clave directamente.
- AZ_RESOURCE_GROUP: Permite intentar descubrir la key si no se pasó manualmente.
Si no hay clave disponible o el intento de descubrimiento falla, se intentará usar automáticamente --auth-mode login para la autenticación.
Ejemplo de uso completo (descarga + análisis):
# 1. Descargar y organizar
pwsh -File ./Download-FlowLogs.ps1 -StorageAccount mystorageacct -DownloadPath ./FlowLogs -AutoShorten -Force
# 2. Analizar todos los logs resultantes
pwsh -File ./Analyze-VNETFlowLogs.ps1 -LogFiles "./FlowLogs/**/*.json" -ExportCSV -OutputPath ./reports -ShowGraphs
Si ya tienes los JSON en local (por AzCopy u otro método), puedes saltarte el paso 1.
pwsh -File "./Analyze-VNETFlowLogs.ps1" -LogFiles "./samples/*.json" -ExportCSV -OutputPath "./reports" -ShowGraphs
-LogFiles: rutas a los JSON (acepta wildcards).-ExportCSV: exporta VNetFlowAnalysis_Details_<timestamp>.csv y VNetFlowAnalysis_Summary_<timestamp>.csv.-OutputPath: directorio para los CSV.-SpecificIPs: array de IPs para análisis centrado en hosts concretos.-ShowGraphs: muestra gráficas de barras simples en la consola.samples/sample-flowlog.json con varios flujos que cubren casos típicos (permitidos, denegados,
varios BEGIN para simular reintentos/posible escaneo).reports/ y se muestra
un resumen en consola.Parse-FlowTuple del script espera un orden concreto de campos, que puedes
adaptar si es necesario.Analyze-VNETFlowLogs.ps1 — script principal.Download-FlowLogs.ps1 — utilidad para descargar y normalizar logs desde la cuenta de almacenamiento.README.md — instrucciones y referencia a la doc oficial.samples/sample-flowlog.json — ejemplo para pruebas.Espero que esto te ayude a analizar flujos en tus VNets.
Azure Monitor Alerts detecta problemas antes de que los usuarios los reporten. Con Action Groups automatizas la respuesta (email, SMS, webhook, runbook, Logic App). En este post verás cómo configurar alertas de métricas y logs, action groups, y KQL queries para monitoring efectivo.