Crear un AppService PHP y una BD MySQL en Azure
Hola a todos, espero se encuentren bien, hoy les enseñaré como aprovisionar un App Services PHP y una Base de datos MySQL en azure. No subiré ninguna aplicación por el momento sólo prepararé el ambiente para que luego puedan ser subidas las aplicaciones web por diferentes métodos como onedrive, Github, azure devops, etc.
En el panel de control ingresamos a App Services, damos clic en agregar y seleccionamos php.
Damos clic en crear.
Colocamos un nombre nuestra app services, seleccionamos el Plan de nuestro APP.
En mi caso crearé uno nuevo.
Colocamos un nombre al Plan, la ubicación y la tarifa.
Nos muestra 03 Planes generales, en mi caso crearé un S1, dichas características se muestran en la parte inferior, como que soporta dominios personalizados, si acepta certificados y demás recursos.
Damos clic en aplicar, aceptar y creamos el App Services.
Ahora para conectarnos por FTP (Filezilla), ingresamos a la APP y obtenemos el perfil de publicación.
No es más que un TXT. Los Datos importantes para la conexión son los siguientes:
Por otro lado podemos colocarle un dominio personalizado agregando un nombre Host.
Colocamos el nombre de host y validamos. Antes ya debimos crear el CNAME en nuestra zona DNS apuntando a proveedores.a zurewebsites.net.
Una vez validado, agregamos el nombre de host.
Ahora creamos la Base de datos: para ello buscamos el recurso Azure Database for MySQL.
Colocamos un nombre, el origen, datos del servidor, usuario y contraseña.
Seleccionamos el Plan.
En mi caso será básico; al igual que en la App, nos muestra el detalle de los recursos y los precios de acuerdo al plan.
Damos clic en aceptar y luego en crear.
Los datos necesarios para conexión a la BD son el nombre del server, usuario, contraseña y la cadena de conexión.
También será necesario permitir la conexión a la BD, en mi caso he creado una regla como se muestra en la imagen que permite la conexión desde cualquier IP origen.
Para probar la conexión a la BD, descargamos el workbench, ingresamos los datos y realizamos la conexión.
Vemos que estamos dentro de la BD.
También hice una prueba de conexión con Filezilla hacia la AppService.
En conclusión los datos que necesitamos para subir una aplicación a un AppServices y esta se pueda conectar a una BD es la siguiente:
Espero les ayude.
Hasta pronto.
Implementación de Azure Site Recovery
Bueno señores, hoy quiero compartir con ustedes la implementación de Azure Site Recovery, una forma de prepararnos en caso suceda algún desastre en nuestro Data Center on-premise.
Primero debemos crear el recurso Backup and Site Recovery.
Colocamos un nombre y demás información que realmente se repite en azure y damos clic en crear.
Una vez creado, nos vamos al recurso, en Site Recovery seleccionamos Preparar infraestructura.
En el paso número uno, seleccionamos dónde se encuentran las máquinas virtuales, hacia donde replicarlas y en mi caso estoy usando Hyper-v sin System Center.
En el paso 02 seleccionamos que ya hicimos el planeamiento con la herramienta de azure Site recovery.
Ahora agregamos un SItio de Hyper-v.
Luego agregamos un Servidor Hyper-v.
Descargamos el agente de ASR y la clave de registro.
Los guardamos en el servidor Hyper-v.
Ejecutamos e instalamos el agente.
Damos clic en Registro y seleccionamos la clave descargada.
Observamos que se agregó el Servidor Hyper-v. Si no se muestra debemos actualizar yendo al paso anterior y regresar al paso 3.
En el paso 04 debemos crear una cuenta de almacenamiento y una Vnet, esto se podría hacer también al inicio.
En mi caso lo crearé como se muestra en las capturas.
Lo mismo con la red virtual.
Aceptamos.
Para finalizar la preparación debemos crear y asociar una directiva de replicación.
Seleccionamos los valores como se muestran en las capturas como el origen, destino, frecuencia de copia, retención de puntos de recuperación.
Aceptamos y aceptamos.
Ahora para iniciar con la replicación nos vamos al Paso 1: Replicar la aplicación.
Seleccionamos origen.
El destino, al cuenta de almacenamiento y red.
Seleccionamos las VMs a replicar.
Aquí podemos verificar que la VM se cree con el respectivo sistema operativo y que tenga los discos correctos.
Observamos un pequeño resumen y la directiva a usar.
Habilitamos la replicación.
Empezará la replicación de la VM, en elementos replicados podemos ver el avance. La máquina estará replicada cuando en su estado muestre como Protegido.
Prueba de conmutación por error: Ahora debemos realizar una prueba para ver que realmente nuestras VM estén siendo replicadas correctamente.
Como requisito y recomendación se debe crear una nueva Vnet para poder realizar la conmutación por error. Para mi caso crearé la Vnet como se muestra en la imagen.
Ahora nos dirigimos a elementos replicados, ingresamos a la VM replicada, podríamos ver los puntos de recuperación más recientes, pero en mi caso haré clic en Conmutación por error de prueba.
Seleccionamos el punto de recuperación recomendado y la red virtual creada últimamente.
Aceptamos y veremos que empezará el proceso de conmutación.
Ojo: Es de prueba, quiere decir que no apagará la VM que se encuentra en on-premise.
Una vez finalizada veremos que se ha creado una VM con recursos similares a los que tenía en on-premise.
Si queremos probar la conexión al server, debemos agregar a la tarjeta del server una IP pública y además antes de replicar debimos haber abierto el puerto 3389 en el firewall de windows.
Aquí cómo agregar una IP pública a la tarjeta de la VM.
Probamos la conexión remota con el administrador local.
Ojo: Si queremos realizarlo con un usuario de dominio posiblemente nos muestre un error y es porque el server no tiene comunicación con el domain controller, es por ello que en un ambiente de ASR es importante tener en azure un DC replicado.
Una vez probado que funcionó la configuración de ASR, debemos limpiar esta prueba para que Azure no nos cobre por el recurso aprovisionado. Para ello nos dirigimos a elementos replicados y en los tres puntitos le damos en Limpiar conmutación por error.
Colocamos un comentario y damos clic en aceptar.
Con esta configuración estamos preparados para actuar en caso de desastre de nuestro datacenter on-premise.
Sinceramente no es un plan de desastres perfecto, pero nos ayudaría a recuperarnos en algunas horas .
Estoy seguro que muchos dirán, el datacenter se destruye pero en caso la red on-premise siga funcionando los clientes cómo se conectarían a este servidor?, pues hay que configurar una VPN sitio a sitio y además cuando surja el desastre tendríamos que hacer cambios en nuestro DNS on-premise para que apunten a la nueva IP que tomará el servidor en azure.
Espero les sirva como una introducción a la recuperación ante desastres que ofrece azure.
Nos vemos pronto.
Eliminar un controlador de dominio fuera de línea
Hay situaciones en que tenemos algún controlador de dominio en una sede remota, y por cosas del destino ya no es posible recuperarlo, en conclusión el servidor queda inservible y sin acceso para poder hacer una despromoción de manera correcta.
De ser este el caso, debemos forzar la eliminación, en mi caso el servidor a eliminar será el DC008.
Importante: Estos pasos sólo han sido probados para ambientes de dominio de 2008R2 hacia delante, para 2003 se tienen que seguir otros pasos.
Primero: Ingresamos a la consola Active Directory Users and Computers de otro DC activo, buscamos el controlador de dominio, damos clic derecho Eliminar y eliminamos como se muestra en la imagen.
Segundo: Abrimos la consola Active Directory Sites and Services, buscamos el servidor en el sitio correspondiente y procedemos con la eliminación.
Con esto hemos logrado forzar la elimincación de un controlador de dominio dañado o fuera de línea.
Espero les sea de utilidad.
Configurar VPN Cliente a Sitio en Azure ARM
Buenas noches a todos, hoy comparto con ustedes, cómo configurar fácilmente una conexión VPN cliente sitio en Azure RM.
El primer requisito es utilizar certificado, ya sea empresariales o autofirmados, en mi caso lo haré mediante autofirmados, estos últimos me han funcionado muy bien a nivel productivo.
Para la creación de mis certificados autofirmados utilizaré powershell, en mi caso tengo Windows 10.
Con el primer comando crearemos el certificado raiz y con el segundo crearemos el certificado que luego será exportado para instalar en los equipos que usaran la VPN cliente a sitio.
Crear el certificado raíz: podrían cambiar el nombre P2SRootCert por uno de su preferencia:
$cert = New-SelfSignedCertificate -Type Custom -KeySpec Signature -Subject «CN=P2SRootCert» -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation «Cert:\CurrentUser\My» -KeyUsageProperty Sign -KeyUsage CertSign
Crear el certificado para clientes: podrían cambiar el nombre P2SChildCert por uno de su preferencia:
New-SelfSignedCertificate -Type Custom -DnsName P2SChildCert -KeySpec Signature -Subject «CN=P2SChildCert» -KeyExportPolicy Exportable -HashAlgorithm sha256 -KeyLength 2048 -CertStoreLocation «Cert:\CurrentUser\My» -Signer $cert -TextExtension @(«2.5.29.37={text}1.3.6.1.5.5.7.3.2»)
Después de la instalación, abrimos una consola mmc con el usuario actual (ojo no como equipo), luego en Personal-Certificados para exportar el certificado Raiz:
Clic en siguiente.
Seleccionamos el tipo X.509
Ahora exportamos el certificado que será instalado en cada equipo que se conecte hacia azure.
Seleccionamos que sí exporte la clave privada:
Colocamos una contraseña, colocamos un nombre y finalizamos la exportación.
Los dos certificados los guardé en mi escritorio:
Abrimos con un Notepad el certificado raiz (certvpnclientdesarrollo.cer), seleccionamos sólo el texto tal como se muestra en la imagen.
Ahora vamos a Azure, en la Puerta de enlace Virtual, Configuración de punto a sitio, colocamos el rango de direcciones que serán asignados a los clientes cuando se conecten a la VPN, además de un nombre al certificado y pegamos los datos del certificado copiados.
Finalmente guardamos la configuración.
Con esto hemos terminado la configuración, ahora queda instalar el certificado cliente en los equipos que se conectarán hacia azure.
Para ello damos doble clic en el archivo installcertificadoencliente.pfx, seleccionamos Usuario actual
Colocamos la contraseña:
Seleccionamos el almacén automáticamente y finalizamos.
Ahora lo que queda es descargar el cliente desde la Puerta de enlace Virtual, Configuración de apunto a sitio.
Instalaremos el cliente según nuestro sistema operativo, en mi caso instalaré el de 64 bits para windows:
Una vez instalado, si damos clic en la tarjeta de red se mostrará una conexión:
Le damos conectar
Nuevamente conectar.
Y observaremos que ya tenemos lograda la conexión hacia azure.
Espero les sea de utilidad, cualquier duda me comentan, espero poder responderle rápido.
Configurar Ambiente Híbrido Exchange 2010 y Office 365
Hoy en día las empresa tienden a migrar sus servicios hacia la nube de Microsoft, ya sea como Plataforma como servicio (PaaS), Infraestructura como servicio (IaaS) o Software como servicio (SaaS).
Lo que haremos en esta oportunidad es realizar una configuración híbrida de un servicio de correo electrónico, entre un servidor onpremise Exchange 2010 SP3 y un servicio Exchange Online (Office365).
En esta oportunidad para lograr este ambiente, debo de inatalar un servidor Exchange 2013, que servirá como puente entre mi ambiente onpremise y office365, para ello seguiremos los siguientes pasos:
01. Instalar Exchange 2013 híbrido (debe ser un nuevo servidor)
-Abrimos un powershell y ejecutamos los siguientes pre-requisitos:
Install-WindowsFeature AS-HTTP-Activation, Desktop-Experience, NET-Framework-45-Features, RPC-over-HTTP-proxy, RSAT-Clustering, RSAT-Clustering-CmdInterface, RSAT-Clustering-Mgmt, RSAT-Clustering-PowerShell, Web-Mgmt-Console, WAS-Process-Model, Web-Asp-Net45, Web-Basic-Auth, Web-Client-Auth, Web-Digest-Auth, Web-Dir-Browsing, Web-Dyn-Compression, Web-Http-Errors, Web-Http-Logging, Web-Http-Redirect, Web-Http-Tracing, Web-ISAPI-Ext, Web-ISAPI-Filter, Web-Lgcy-Mgmt-Console, Web-Metabase, Web-Mgmt-Console, Web-Mgmt-Service, Web-Net-Ext45, Web-Request-Monitor, Web-Server, Web-Stat-Compression, Web-Static-Content, Web-Windows-Auth, Web-WMI, Windows-Identity-Foundation, RSAT-ADDS -restart
-Instalamos el Unified Communications Managed API 4.0 Runtime 
Nota: no olviden reiniciar después de los prerequisitos.
-Ejecución e instalación de Exchange 2013.
Para instalar Exchange sólo ejecutamos el instalador y seguimos los siguientes pasos: 
Una introducción al producto.
Aceptamos los términos de licencia. 
Podemos seleccionar una configuración predeterminada o personalizada. 
Verificamos que estén seleccionados los Roles de Mailbox y Client Access. 
Seleccionamos la ruta donde se instalarán los binarios de Exchange 2013. 
Seleccionamos que No deshabilite el Escaneo de Malware. 
Una vez comprobado los requisitos, damos clic en instalar.
Advertencia: Igual que en exchange 2010, nos indica que al extender el esquema, ya no podremos instalar un exchange 2003 o 2007.
Nos tomamos un café.
Después de unos largos minutos, tenemos la instalación completa.
Podemos abrir la consola de Exchange.
02. Instalar actualizaciones de Exchange 2013
Es importante instalar los últimos Cumulative Update Exchange para 2013, de lo contrario tendremos errores a la hora de realizar la configuración del ambiente híbrido.
03. Instalar rollups y ultimas actualizaciones de exchange 2010
Para que la migración de los cliente outlook y móviles sea transparente, se recomienda instalar el último rollup para exchange 2010
04. Sincronizar AD onpremise hacia la nube
Para sincronizar el nuestro AD onpremise, usaremos una herramienta que hará todo el trabajo, lo podemos instalar en el mismo servidor Exchange 2013 híbrido o en servidor diferente.
Descargamos e instalamos el Microsoft Azure Active Directory Connect.
La instalación es simple, por lo que no colocaré las capturas.
Una vez instalado, ejecutamos ADConnect.
05. Configurar Exchange 2013 híbrido
Ingresamos a la consola de administración de exchange 2013.
Nos dirigimos a Servidores, en la parte de Directorios virtuales debemos filtrar por el nombre de nuestro servidor Exchange 2013 híbrido.
Luego editamos EWS (Default Web Site) y cambiamos la dirección URL externa, tal como se muestra en la imagen.
Esta URL será la que dará la cará hacia el ambiente nube, y al cuál más adelante hay que generar un certificado digital.
También en la misma ventana debemos fijarnos que esté seleccionada los dos tipos de autenticación, como se muestra en la imagen. Guardamos y salimos.
Ahora nos dirigimos a la sección híbrido para ejecutar la configuración híbrida.
Descargamos el asistente.
Instalamos.
Clic en siguiente.
Detecta automáticamente nuestro servidor exchange 2013 híbrido. Le damos clic en siguiente.
Colocamos las credenciales de administrador de exchange onpremise y del administrador global de nuestra suscripción de Office365. Y seguimos.
Veremos que valida y todo es satisfactorio.
Nos muestra un registro TXT para comprobar que somos propietarios del dominio a configurar. Debemos copiarlo y crearlo en nuestro panel DNS externo.
Una vez que tengamos creado el TXT, marcamos la casilla, verificamos que somos propietarios y damos clic en siguiente.
Realizamos la configuración típica, ya que en mi caso no tengo un Edge Transport.
Seleccionamos nuestro conector de recepción.
Lo mismo con el conector de envío.
Seleccionamos nuestro certificado digital.
Colocamos el FQDN de nuestra organización de exchange híbrido.
Damos clic siguiente.
Observamos que ha terminado la configuración de manera satisfactoria, con esto hemos logrado la conexión hacia híbrida entre nuestro exchange 2010 y office365. Ahora estamos listos para migrar buzones.
06. Realizar pruebas de migración:
Para poder mover usuarios de exchange onpremise a enchange online, lo podemos hacer desde la consola de administración de exchange 2013 híbrido o desde la configuración de exchange en office365.
Seleccionamos destinatarios/Buzones, buscamos los usuarios a migrar y en la parte derecha damos clic en A exchange Online.
Damos clic en siguiente.
Colocamos un nombre al lote de migración, y clic en siguiente.
Observamos que existen opciones de sólo mover buzones o también el archivo, en caso tenga el usuario onpremise.
Seleccionamos un usuario, para que nos notifique cuando haya terminado la migración, mediante un correo, así también podemos seleccionar si queremos que el lote termine automáticamente o queremos hacerlo manual. (Ahora se puede hacer programado).
Podemos ver el avance de la migración.
Una vez terminado, los clientes que tienen el correo en el outlook o móvil, se les desconectará por un lapso de 10 minutos y luego se conectará automáticamente.
Con esto, hemos terminado la configuración de nuestro ambiente híbrido.
Cualquier duda, me comentan.
Saludos desde Lima-Perú.
El Deza 