Renew token signin certificate for Office 365 and Azure Active Directory when you have a non windows federate service

A few days ago I had to renew the token signin certificate in the Security Token Service (non windows) deployed on premises.

In this case the Security Token Service was running under F5 BIG-IP Access Policy Manager: Authentication and Single Sign-On

Once I did it, the question was,

Should i do anything else in Azure and O365 to maintain the trust federation?

If you have a Windows Federation Service, typical Known as ADFS, you don´t need to do any extra task.

By default, ADFS includes an auto-renewal process called AutoCertificateRollover.

If you have ADFS 2.0 or later, Office 365 and Azure AD automatically update your certificate before it expires when AutoCertificateRollover is set to True.

You can check this value running the cmdlet Get-ADFSProperties

But in this case the answer to this question is YES.

I don´t have a Windows Federation Service, so I had to do an extra task to update my signin certificate in order to maintain the Trust Federation.

At this point I am going to explain what I did.

First at all, I saved the new certificate as pf-signing.crt in my computer in the following path: c:\temp

I opened a new file in notepad and added the following lines:

Note: Be in mind to put your Office 365 domain name first.

$certFile = “C:\temp\”

$cert = [IO.File]::ReadAllText($certFile)

$cert = $cert.replace(“—–BEGIN CERTIFICATE—–“,””)

$cert = $cert.replace(“—–END CERTIFICATE—–“,””)

$cert = $cert.replace(“`r”,””)

$cert = $cert.replace(“`n”,””)

$domainName = “myO365domain”

$protocol = “SAMLP”

Set-MsolDomainFederationSettings -DomainName “$domainName” -SigningCertificate “$cert” -PreferredAuthenticationProtocol $protocol

Then I saved it as a PowerShell script file cert-update.ps1 in C:\temp folder.

Then I opened Azure Active Directory Module for Windows PowerShell to connect to my Office 365 tenant with admin credentials

This can be done by running connect-msolservice

And finally I runned the PowerShell script created above in the local path: c:\temp


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.

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:

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:

  • 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 -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 -NewUserPrincipalName

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 -User -AccessRights FullAccess -InheritanceType All -AutoMapping $false

When you need to change language in a Shared Mailbox:
get-mailbox | fl *lan*
get-mailbox | Set-Mailbox -Languages es-ES
get-mailbox | 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:

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.

Error determining the current master Multi-Factor Authentication Server

This morning I have noticed an issue with a new Multi-Factor Authentication Server deployed yesterday.

When I try to open the MFA console I get the following error.

After spending a time trying to find the problem, I found what was going on.

1- An MFA server needs to connect to Azure MFA Cloud Service to query which server is the master of his replication group (whether itself or another server), the connection to Azure MFA Cloud Service is made over HTTPS protocol, on port 443, thus connectivity to from each MFA server is a requirement.

If an MFA Server can´t connect to the Azure MFA Cloud Service it can´t determine the master and fails with the mentioned error.

To solve the issue, ensure the following URLs are reachable from each server you have been deployed.

2- Once the Server get a response for that query, it knows if is the master or an slave. Slave servers initiate communications to the master database. If an Slave server can not comunicate to master server database when you open the Management Console it will prompt if you want to promote the slave to be the master.

When a Master Server is down or an Slave server can not comunicate to the master server database, the slave server can still perform authentications, because each slave server has a full READ copy of the data file locally to look up user’s authentication methods, phone numbers, and other settings but changes to the database needs to be made in a WRITE master database when be available.

Aditionally , If you need the communications from the slaves to the master to use a specific port, you can configure the master to use a static port. The static port needs to be set only on the master using the pfsvc_ncan_ip_tcp_port registry key, not on the slave.

You can do that by editing the registry on the master and creating a new DWORD registry key called “Pfsvc_ncan_ip_tcp_port” at HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Positive Networks\PhoneFactor on 64-bit servers or HKEY_LOCAL_MACHINE\SOFTWARE\Positive Networks\PhoneFactor on 32-bit servers. Set the value of the registry key to the port (decimal) you want the MultiFactorAuth service to run on, ensuring first that the port is available.

Then, ensure all your MFA Servers are able to connect to the Azure MFA cloud service over port 443, and slaves communicate to the master over the port that the master service is running on.

3- It may be helpful to turn on verbose logging. You can enable verbose logging by editing the registry, going to HKLM\Software\Wow6432Node\Positive Networks\PhoneFactor and creating a DWORD registry key called “pfisapi_verboseLog”. Set the value to decimal 100. Restart IIS. Clear the MultiFactorAuthIisNm.log located by default in the following path“C:\Program Files\Multi-Factor Authentication Server\Logs” and then sign-in only since a lot of data will be logged.

Note in a multi environment deployment, ensure your MFA server is member of the desired Replication Group. This point is really important because if your server is in a wrong replication group and cannot communicate with the master server for this Replication Group, you will be asking to promote the server every time you open the MFA Admin Console.

To check MFA Replication groups login with your account credentials (email address and password) that you used to activate the Multi-Factor Authentication Server to access the Management Portal on the website at

Select each MFA Servers group, select Server Status and check the members of each group. Each group should contain one Master Server and one or more Slave Servers. Only one Master server it´s allowed for each group. If this rule is not met may you experience strange server behaviors.

Task Scheduler has disappeared in AADCONNECT

The new version of the AADConnect has changed the way to configure the directory synchronization schedule and the manual start.
Don´t get crazy searching the task schedule from prior versions because in this new release has disappeared.
A new Powershell module has been set for this purpose.
Go to PowerShell and run Get-ADSyncScheduler.
It will show you something like this:

By default the synchronization period is 30 minutes and synchronization process is disabled (SyncCycleEnabled)
Run Set-ADSyncScheduler -MaintenanceEnabled $false -SyncCycleEnabled $true to enable the synchronization process cycle.
Run Set-ADSyncScheduler –CustomizedSyncCycleInterval if you want the scheduler to run at any other frequency than the default 30 minutes.
Run Start-ADSyncSyncCycle -PolicyType Initial to initiate a manual Initial synchronization.
Run Start-ADSyncSyncCycle -PolicyType Delta to initiate a manual Delta synchronization