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.

Advertisements

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:
https://blogs.technet.microsoft.com/rmilne/2017/09/19/exchange-2016-cu7-released/
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:
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\ExchangeServer\v15\WorkerTaskFramework\IdStore\ProbeDefinitionIDConflicts

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.


How to create a custom DLP rule in Office365

Yesterday, I was helping to a customer in order to create a new custom DLP policy to protect Spanish Identity Card Number (DNI) across the email communications.
I could not find any help in internet, so that´s why I decided to post how I did it.

  • First I created a custom policy using an XML unicode file
  • I use the script “Create-XML-1.3.ps1″ downloaded from Technet here:

https://gallery.technet.microsoft.com/office/Custom-DLP-XML-Generation-43846c75

The script will create the entire file, top to bottom, but you can use the code listed below as a XML template

The Regular Expression match pattern used to catch DNI on email communications was: ([0-9]{8,8}[A-Za-z])

You can use the following tools if you are not familiar with regular expressions:

https://regexr.com/
https://regex101.com/

  • I keep the file “demo.xml” in the path “C:\temp” in my computer
  • Then I connect to “Office 365 Security & Compliance Center” from a PowerShell using the following instructions

$cred= get-credential
$Session = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.compliance.protection.outlook.com/powershell-liveid/ -Credential $cred -Authentication Basic -AllowRedirection
Import-PSSession $Session

  • Then I use the following cmdlet to import my custom xml file to Office 365:

New-DlpSensitiveInformationTypeRulePackage -FileData ([Byte[]]$(Get-Content -Path “C:\temp\demo.xml” -EncodingByte -ReadCount 0))


Aditionally you can use the following cmdlets to manage Data Loss Prevetions Rule Packages using PowerShell.

  • New-DlpSensitiveInformationRulePackage
  • Get-DlpSensitiveInformationRulePackage
  • Set-DlpSensitiveInformationRulePackage
  • Remove-DlpSensitiveInformationRulePackage

Note this cmdlets are only available in the Office 365 Security & Compliance Center.
XML File used to Match DNI:


How to move the MFA Service Provider from one Azure subscription to another

Be in mind the following procedure in case you may need to do it.
A couple of days ago a customer decided to create a new Azure subscription and move the MFA service provider from one Azure subscription to the new one.
After hearing this request, the first thing that came to my mind was scary.
But after a few minutes of calm this is what I did.

1- I create a new MFA Provider in a new Azure subscription

2- In each one of MFA server, I delete all files in the following path C:\Program Files\Multi-Factor Authentication Server\Data” except database named Phonefactor.pfdata

3- Note when you delete those files you will lose the MFA provider and subscription association, thus Activation credentials will be required next time you open MFA Manager Console.

4- Generate new Activation credentials from the new subscription. 

 

5- Activate the license using the new Activation credentials.

6- Activation process will recreate the previous deleted files and will associate the MFA servers with the new Azure Subscription

7- Once the service has been activated you can delete the old MFA provider.

Note that users who are enrolled for phone call or text authentication will not be impacted by this change, but the mobile app push notifications may will stop working for some users that are using the app. If this happened users will need to reactivate the mobile app after the change to start using it again.

Under my scenario, using SMS (one-way) and OATH token , the experience was great and no re-enroll process was required.


Cmdlets to be in mind in O365

When you are managing mailboxes in Office 365 you need to keep in mind some cmdlets that can help you to manage some tasks. Here above you have some examples:

When “UserprincipalName” attribute has been changed onprem but changes are not being applied in Azure Active Directory this cmdlet will help you to force the change:
Set-MsolUserPrincipalName -UserPrincipalName example@mydomain.es -NewUserPrincipalName example@mynewdomain.es

When you need to remove deleted users:
GetMsolUser –ReturnDeletedUsers
GetMsolUser –ReturnDeletedUsers | Remove-MsolUser –RemoveFromRecycleBin -force


When you need to add permissions to a Shared Mailbox and disable Automapping:
Add-MailboxPermission -Identity example@mydomain.es -User example@mynewdomain.es -AccessRights FullAccess -InheritanceType All -AutoMapping $false

When you need to change language in a Shared Mailbox:
get-mailbox example@mydomain.es | fl *lan*
get-mailbox example@mydomain.es | Set-Mailbox -Languages es-ES
get-mailbox example@mydomain.es | Set-MailboxRegionalConfiguration -LocalizeDefaultFolderName


Display all Values in a multi-valued property from PowerShell

Sometimes there are some multi-value properties that can not be displayed from powershell, what can be a bit frustrating.
In the image below there´s an example of it:

Fortunately, there´s a simple way to deal with this situation, and I am sure you will never forget this tip as soon as you know it.
By default the $FormatEnumerationLimit preference variable has a value of 4, and it determines how many items are displayed when a property contains more than a single item.

Keep in mind you can change this variable to get all properties be displayed. It is simple and easy.
You can set this variable to 20, 50 whatever you need, or my favorite: (-1) (it means show me all with no limit)
voilà !!!
Simple and quick.


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:
https://gallery.technet.microsoft.com/scriptcenter/AD-FS-Diagnostics-Module-8269de31#content

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.