Exchange 2016 CU7 hybrid bug

After deploying a fresh install of Exchange 2016 CU7 to setup a Hybrid deployment to Office 365 I could not federate to Office 365 using the HCW.

HCW is trying to use the cmdlet “Set-FederatedOrganizationIdentifier” but the command “Set-FederatedOrganizationIdentifier” is broken in CU7.

Opening a ticket with MS support they too try the command in their lab environment and confirmed that with the install of CU7 this command does not work.

At this moment, the official Microsoft answer is the following:

For a hybrid scenario, deploy another Exchange 2016 server with CU6 to run the HCW or wait for Exchange 2016 CU8 release.

Exchange 2016 CU7 Mail Flow bug

Hace un par de días hemos desplegado en un entorno de coexistencia con Exchange 2010 un Exchange 2016 con el CU7.
Nada más desplegarlo hemos empezado a tener problemas de flujo de correo con el nuevo servidor Exchange 2016 que  hemos desplegado.
No aceptaba ninguna conexión smtp.
El proceso de  instalación, no dió ningún problema pero el servicio de transporte (Mailbox Transport Delivery) entraba en un loop y se reiniciaba constantemente generando los siguientes errors en el registro de eventos:

Despues de realizar varias pruebas, revisar los eventos de sistema y analizar logs, hemos encontrado un artículo que habla de un bug en la CU7 y nos da la solución:
El problema parece ser que el proceso de instalación no añade los permisos al grupo NETWORK SERVICE en la siguiente clave de registro:

Añadiendo el permiso Full Control al grupo NETWORK SERVICE en la clave de registro de nivel superior ha permitido solucionar los problemas de reinicio del servicio de transporte y restablecer el flujo de correo entre los servidores de Exchange 2010 y Exchange 2016 desplegados en el entorno de laboratorio.

Nota: El usuario Creator Owner debe tener también permisos “Full Control” en la misma clave de registro.

Monitoring ADFS 3.0

When monitoring Active Directory Federation Services, one part to be considered is the AD FS Diagnostics PowerShell module, which is deployed to the AD FS Servers as part of Azure Active Directory Connect Health agent has cmdlets that are executed by the health agent on a regular basis and uploads the results to the cloud for visualization in the Azure Portal and alert generation.

Although this module is used by the Azure AD Connect Health Agent, it is published in the Script Center, thus if you are not using the Azure AD Connect Health service, you have a way to run this locally on your AD FS servers.

The module is available for download at the Script Center in the following site:

The module file name is ADFSDiagnostics.psm1, and is located under “%programfiles%\Azure Ad Connect Health Adfs Agent\Diagnostics\”. Note that it requires elevated access, and PowerShell 4.0 to run and may you need to install the module first in your Powershell modules path.
Below are the cmdlets available in the module:

The Test-ADFSServerHealth cmdlet contains a series of health checks for the most common AD FS issues and it´s perhaps the most useful during troubleshooting. However, there are some other cmdlets that will help you to verifies configuration, certificate properties, retrieve federation metadata, and get a token from the STS (STS using the actual server where the cmdlet is running), and also to verify that endpoints required for office 365 to work are enabled and Relying Party trusts are configured.