Página principal Sobre mi Premios recibidos Links de Interés Contacto Blogs de referencia

Translate

lunes, 20 de julio de 2020

Textual description of firstImageUrl

VMware 7.0: Configuración de un nuevo servidor vCenter Appliance (VCSA) - Parte 1

 Una vez terminada la fase del despliegue del producto, pulsaremos el botón llamado continuar situado en la esquina inferior derecha de la ventana del asistente.

El asistente de despliegue de un servidor de vCenter Appliance está dividido en dos fases, la primera correspondiente al despliegue del nuevo servidor y la segunda dedicada a la configuración. Así que también hemos dividido el procedo en dos laboratorios distintos. Este es el primer laboratorio está dedicado a la primera fase del asistente Stage2 Configuración de un nuevo vCenter Server Appliance. (VCSA).

Hemos dividido este laboratorio en cuatro artículos, a los que podéis acceder directamente usando el menú que mostramos a continuación:

Fase 1 de Despliegue del asistente de instalación de vCenter Appliance 6.7.0

Fase 2 de Configuración del asistente de instalación de vCenter Appliance 7.0

Seguidamente, aparecerá una nueva ventana emergente con el asistente de Instalar el servidor de vCente Server Appliance (VCSA), el cual nos dará acceso a la fase de configuración de nuestro nuevo servidor de vCente Server Appliance (VCSA).

Pulsaremos el botón siguiente, para saltar la ventana llamada Introduction que nos situará en la fase del asistente que estamos cursando. Seguidamente, nos encontraremos en la sección llamada Configuración del Appliance, dónde se nos permitirá seleccionar la configuración de nuestros servidores de tiempo.

En nuestro laboratorio, hemos seleccionado que queremos sincronizar los servicios de tiempo con el propio servidor host de ESXi, pero podríamos definir cualquier otro servidor de tiempo.

También, podremos habilitar o desahabilitar el acceso mediante SSH, para las futuras configuraciones.


A continuación, nos aparecerá la sección llamada SSO Configuration, dónde encontraremos un formulario que nos permitirá configurar un nuevo dominio de Single Sign-on o agregar nuestro nuevo servidor de vCenter a un dominio existente.

Para crear un nuevo dominio SSO tendremos que proporcionar los datos siguientes:

·         Un nombre para nuestro nuevo dominio SSO.

·         Un nombre de usuario para el administrador.

·         Una contraseña para el usuario administrador.

Podéis configurar cada una de estas opciones, con los parámetros que más se adecuen a vuestras necesidades empresariales.

La contraseña predeterminada del administrador de vCenter Single Sign-On, se especifica en la directiva de contraseñas de vCenter Single Sign-On.

De manera predeterminada, esta contraseña debe cumplir con los siguientes requisitos:

Debe Tener al menos ocho caracteres, debe tener como mínimo un carácter en minúscula, al menos un carácter numérico, i finalmente debe Tener al menos un carácter especial.

La contraseña del usuario no puede superar los 20 caracteres. A partir de vSphere 6.0, se permiten caracteres que no son ASCII. Los administradores pueden cambiar la directiva de contraseñas predeterminada. Una vez tengamos definida la nueva contraseña, pulsaremos nuevamente el botón siguiente para continuar.

La siguiente sección será la configuración del programa Programa de mejora de la experiencia del cliente de VMware (CEIP) para facilitar información que ayudará a VMware a mejorar sus productos y servicios, a solucionar problemas y también a asesorar sobre la mejor forma de implementar y utilizar sus productos.

Podremos seleccionar si queremos unirnos al programa de mejora de VMware, o por lo contrario, queremos desactivarlo.


domingo, 19 de julio de 2020

Textual description of firstImageUrl

Windows Admin Center: Preparar equipos cliente (WINRM) - Parte 2

Hemos dividido este artículo en dos publicaciones distintas, a las que podéis acceder usando el indice que mostramos a continuación:
A continuación, podemos comprobar que nuestras configuraciones y restricciones son correctas.

Podemos usar el comando llamado Test-WSMan, para probar si nuestro equipo cliente Windows 10 está correctamente configurado para recibir comandos remotos a través del servicio WinRM.

También podemos usar el cmdled Enter-PSSession, para iniciar una sesión de Windows PowerShell interactiva con nuestro equipo cliente Windows 10 remoto.

Comprobaremos que si lanzamos cualquiera de estos comandos desde el servidor de Windows Admin Center, estos funcionaran, ya que la regla de firewall modificada por nosotros dará acceso a nuestro servidor.

PS C:\> Test-WSman -computername "XCN-VM"

wsmid           : http://schemas.dmtf.org/wbem/wsman/identity/1/wsmanidentity.xsd
ProtocolVersion : http://schemas.dmtf.org/wbem/wsman/1/wsman.xsd
ProductVendor   : Microsoft Corporation
ProductVersion  : OS: 0.0.0 SP: 0.0 Stack: 3.0

PS C:\> Enter-PSsession -computername "XCN-VM"
[XCN-VM]: PS C:\Users\Administrador\Documents>

Por lo contrario, si intentamos la conexión desde cualquier otro equipo de nuestra red, esta fallará.

PS C:\> Test-WSman -computername "XCN-VM"
Test-WSman : <f:WSManFault xmlns:f="http://schemas.microsoft.com/wbem/wsman/1/wsmanfault" Code="2150859046"
Machine="XCN-W10.dom.local"><f:Message>WinRM no puede completar la operación. Compruebe que el nombre del equipo es
válido, que se puede acceder al equipo a través de la red y que la excepción del firewall del servicio WinRM está
habilitada y permite el acceso desde este equipo. De manera predeterminada, la excepción de firewall de WinRM para
perfiles públicos limita el acceso a equipos remotos dentro de la misma subred local. </f:Message></f:WSManFault>
En línea: 1 Carácter: 1
+ Test-WSman -computername "XCN-VM"
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
    + CategoryInfo          : InvalidOperation: (XCN-VM:String) [Test-WSMan], InvalidOperationException
    + FullyQualifiedErrorId : WsManError,Microsoft.WSMan.Management.TestWSManCommand

Textual description of firstImageUrl

Windows Admin Center: Preparar equipos cliente (WINRM) - Parte 1

En el laboratorio de hoy, vamos a ver como tenemos que preparar nuestros equipos cliente Windows 10 para que sean accesibles desde nuestro servidor de Windows Admin Center.

Hemos dividido este artículo en dos publicaciones distintas, a las que podéis acceder usando el indice que mostramos a continuación:
Windows Admin Center es una potente consola, que nos permitirá administrar todos nuestros entornos de servidor y cliente Windows 10 usando herramientas que todos conocemos pero modernizadas, como puede ser el Administrador de Servidores y las consolas MMC.

De este modo, los administradores de sistemas podremos administrar instancias de Windows Server o Windows 10 en cualquier lugar, ya sean on-premises o en cualquier cloud.

Para descargar Windows Admin Center lo haremos desde Microsoft Evaluation Center. Aunque en el enlace de la descarga ponga "Iniciar la evaluación", la descarga es la versión disponible para su uso en producción.
Una vez tengamos instalada la consola de Windows Admin center en uno de nuestros servidores, si intentamos conectar con alguno de nuestros equipos cliente Windows 10, comprobaremos que esto no será posible y aparecerá el error de conexión que mostramos a continuación.

Para agregar un nuevo equipo a la consola de Windows Admin center, en primer lugar, presionaremos el enlace llamado +Agregar, situado en la parte superior izquierda de la ventana de la consola de Windows Admin center. 

Aparecerá una nueva ventana desplegable, seleccionaremos la opción Buscar en Active Directory y escribiremos el nombre del equipo cliente Wondows 10 en el recuadro de texto habilitado para Buscar.

Seguidamente, presionarnos el botón llamado Buscar. Una vez aparezcan los resultados de nuestra búsqueda, seleccionaremos el equipo cliente Windows 10 deseado y pulsaremos el botón Agregar

El error que aparecerá es el siguiente:

Error de conexión

Error de conexión al servidor remoto [NOMBRE_DEL_EQUIPO]. Mensaje de error: WinRM no puede completar la operación. Compruebe que el nombre del equipo es válida, que se puede acceder al equipo a través de la red y que la excepción del firewall del servicio WinRM está habilitada y permite el acceso desde este equipo. De manera predeterminada, la excepción de firewall de WinRM para perfiles públicos limita el acceso a equipos remotos de la misma subred local.Para obtener más información, consulte el tema de la Ayuda.

about_Remote_Troubleshooting.


miércoles, 8 de julio de 2020

Textual description of firstImageUrl

Microsoft Exchange: Configuración del nombre del certificado TLS para los conectores de recepción.

En el laboratorio de hoy, nos aseguráremos de que las conexiones de cliente SMTP autenticadas a nuestro servidor de correo electrónico Microsoft Exchange estén protegidas por el cifrado TLS.

Lo más común será usar conexiones de cliente SMTP autenticadas protegidas por el cifrado TLS, cuando tengamos clientes configurados en nuestro servidor Microsoft Exchange, que usen cuentas del tipo POP o IMAP. Este tipo de cuenta, como envió de correo electrónico usará nuestro servidor de correo electrónico Microsoft Exchange con el protocolo SMTP.

Si el cliente final, intenta autenticar a través de una conexión no segura, este recibirá un mensaje como el que mostramos a continuación:

El servidor saliente (SMTP) mail.dom.es no admite el método de autenticación seleccionado.

The outgoing server (SMTP) mail.dom.es does not support the selected authentication method.

Esto sucede porque nuestro cliente de correo electrónico SMTP debe estar configurado para usar STARTTLS usando el puerto 587, de este modo autenticará de forma segura. 

La siguiente vez que intentemos enviar un correo electrónico después de activar la autenticación segura, recibiremos un error distinto. Dependiendo del cliente de correo electrónico que estemos usando, puede ser una advertencia de confianza del certificado, un mensaje para agregar una excepción de seguridad para confiar en el certificado no confiable, o simplemente puede fallar completamente con un error de certificado. 

Aunque hayamos habilitado un certificado SSL válido para SMTP, el conector de recepción deberá ser configurado con el TLScertificatename que deseamos usar.

The TlsCertificateName parameter specifies the X.509 certificate to use with TLS sessions and secure mail. Valid input for this parameter is [I]Issuer[S]Subject. The Issuer value is found in the certificate’s Issuer field, and the Subject value is found in the certificate’s Subject field. You can find these values by running the Get-ExchangeCertificate cmdlet.

El parámetro TlsCertificateName, especifica el certificado X.509 que usaremos en las sesiones TLS y correo seguro. La entrada válida para este parámetro es [I] Issuer [S] Subject. El valor del emisor lo encontraremos en el campo Issuer del certificado, y el valor del asunto se encuentra en el campo Subject de nuestro certificado. Podemos ver estos dos valores ejecutando el cmdlet Get-ExchangeCertificate.

Para poder solucionar el problema, lo primero que tenemos que hacer será determinar el valor thumbnail que nuestro certificado necesita.

Get-ExchangeCertificate

Thumbprint                                Services   Subject
----------                                --------   -------
F777BD581ABC543C9E86BEA322CCE8363F67AF3A  ...WS..    CN=*.dom.es

A continuación, vamos a capturar nuestro certificado en una nueva variable que llamaremos $TLSCert. Usaremos la construcción que mostramos a continuación para conseguirlo.

$TLSCert = Get-ExchangeCertificate -Thumbprint F777BD581ABC543C9E86BEA322CCE8363F67AF3A

Seguidamente, vamos a declarar una nueva variable que llamaremos $TLSCertName en la que guardaremos el emisor del certificado y los valores de los sujetos. Usaremos la construcción que mostramos a continuación.

$TLSCertName = "<I>$($TLSCert.Issuer)<S>$($TLSCert.Subject)"

Si mostramos el contenido de la nueva variable $TLSCertName, tiene que ser algo parecido a lo que mostramos a continuación.

[PS] C:\>$TLSCertName

<I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited, L=Salford, S=Greater Manchester, C=GB<S>CN=*.dom.es

La constricción siguiente nos servirá para listar el conector Client Frontend que queremos modificar.

[PS] C:\>Get-ReceiveConnector -Identity "Client Frontend*"

Identity                                Bindings                                Enabled
--------                                --------                                -------
SRVMAIL01\Client Frontend SRVMAIL01     {[::]:587, 0.0.0.0:587}                 True

Seguidamente, estableceremos la propiedad llamada TlsCertificateName del conector de recepción Client Frontend usando la cadena larga que contenga nuestra variable $TLSCertName.

Get-ReceiveConnector -Identity "Client Frontend*" | Set-ReceiveConnector -TlsCertificateName $TLSCertName

Para poder ver los cambios que hemos realizado ejecutaremos la construcción que mostramos a continuación.

Get-ReceiveConnector -Identity "Client Frontend*" |fl

RunspaceId                              : ca80b7c5-2b26-475f-91e1-b39892f66417
AuthMechanism                           : Tls, Integrated, BasicAuth, BasicAuthRequireTLS
Banner                                  :
BinaryMimeEnabled                       : True
Bindings                                : {[::]:587, 0.0.0.0:587}
ChunkingEnabled                         : True
DefaultDomain                           :
DeliveryStatusNotificationEnabled       : True
EightBitMimeEnabled                     : True
SmtpUtf8Enabled                         : False
BareLinefeedRejectionEnabled            : False
DomainSecureEnabled                     : False
EnhancedStatusCodesEnabled              : True
LongAddressesEnabled                    : False
OrarEnabled                             : False
SuppressXAnonymousTls                   : False
ProxyEnabled                            : False
AdvertiseClientSettings                 : False
Fqdn                                    : mail.dom.es
ServiceDiscoveryFqdn                    :
TlsCertificateName                      : <I>CN=Sectigo RSA Domain Validation Secure Server CA, O=Sectigo Limited,
                                          L=Salford, S=Greater Manchester, C=GB<S>CN=*.dom.es
Comment                                 :
Enabled                                 : True
ConnectionTimeout                       : 00:10:00
ConnectionInactivityTimeout             : 00:05:00
MessageRateLimit                        : 5
MessageRateSource                       : User
MaxInboundConnection                    : 5000
MaxInboundConnectionPerSource           : 20
MaxInboundConnectionPercentagePerSource : 2
MaxHeaderSize                           : 128 KB (131,072 bytes)
MaxHopCount                             : 60
MaxLocalHopCount                        : 5
MaxLogonFailures                        : 3
MaxMessageSize                          : 35 MB (36,700,160 bytes)
MaxProtocolErrors                       : 5
MaxRecipientsPerMessage                 : 200
PermissionGroups                        : ExchangeUsers
PipeliningEnabled                       : True
ProtocolLoggingLevel                    : None
RemoteIPRanges                          : {::-ffff:ffff:ffff:ffff:ffff:ffff:ffff:ffff, 0.0.0.0-255.255.255.255}
RequireEHLODomain                       : False
RequireTLS                              : False
EnableAuthGSSAPI                        : True
ExtendedProtectionPolicy                : None
LiveCredentialEnabled                   : False
TlsDomainCapabilities                   : {}
Server                                  : SRVMAIL01
TransportRole                           : FrontendTransport
SizeEnabled                             : Enabled
TarpitInterval                          : 00:00:05
MaxAcknowledgementDelay                 : 00:00:30
AdminDisplayName                        :
ExchangeVersion                         : 0.1 (8.0.535.0)
Name                                    : Client Frontend SRVMAIL01
DistinguishedName                       : CN=Client Frontend SRVMAIL01,CN=SMTP Receive
                                          Connectors,CN=Protocols,CN=SRVMAIL01,CN=Servers,CN=Exchange Administrative
                                          Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=DOM,CN=Microsoft
                                          Exchange,CN=Services,CN=Configuration,DC=dom,DC=local
Identity                                : SRVMAIL01\Client Frontend SRVMAIL01
Guid                                    : eeeaf656-6287-4a0b-9ebc-c52e6fff789b
ObjectCategory                          : cudom.local/Configuration/Schema/ms-Exch-Smtp-Receive-Connector
ObjectClass                             : {top, msExchSmtpReceiveConnector}
WhenChanged                             : 01/07/2020 1:08:27
WhenCreated                             : 03/12/2018 18:46:31
WhenChangedUTC                          : 30/06/2020 23:08:27
WhenCreatedUTC                          : 03/12/2018 17:46:31
OrganizationId                          :
Id                                      : SRVMAIL01\Client Frontend SRVMAIL01
OriginatingServer                       : SRVDC01.dom.local
IsValid                                 : True
ObjectState                             : Unchanged





jueves, 2 de julio de 2020

Textual description of firstImageUrl

Most Valuable Professional - Cloud and Datacenter Management. 2020-2021

Acabo de recibir la fantástica noticia, de la renovación por tercer año consecutivo del galardón Microsoft® Most Valuable Professional (MVP) para 01/07/2020- 01/07/2021 en la categoría de Cloud and Datacenter Management.

Most Valuable Professional

Me hace muy feliz haber podido recibir nuevamente, el reconocimiento Most Valuable Professional por el trabajo que he realizado de difusión de documentos técnicos, siempre basados en las buenas prácticas que propone Microsoft, tanto en el blog Pantallazos.es como en nuestro canal de YouTube.

Microsoft otorga el galardón MVP a todos aquellos miembros de la comunidad técnica, que de forma activa comparten su experiencia con la tecnología con usuarios y profesionales de todo el mundo. Aquellas personas que han demostrado su voluntad de hacer llegar a los demás sus conocimientos y experiencia para ayudarles a optimizar el uso de la tecnología.

No encuentro palabras para describir la gran ilusión y el orgullo que supone para mi, haber podido obtener por tercera vez este gran reconocimiento a mi trabajo.

Me gustaría agradecer el nuevo nombramiento a Microsoft, y también agradecer el apoyo a todos los seguidores asiduos que leéis los artículos de nuestro Blog o veis nuestros vídeos de YouTube.


Most Valuable Professional - Cloud and Datacenter Management. 2020-2021


Podéis acceder y suscribiros al canal de Youtube de Pantallazos.es en el enlace que mostramos a continuación: