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.
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 https://phonefactor.net 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 https://pfweb.phonefactor.net/
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.
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
Two new attributes have been implemented with CU9 in Exchange 2013 to manage Shared Mailboxes.
These attributes are not enabled by default, then the default behavior when a user with “Send us” or “Send on Behalf” permissions to a shared mailbox send a message, the Sent Item goes to the User Mailbox and not to the Shared Mailbox.
It means another user with permissions on the Shared Mailbox cannot see the email sent on behalf of the mailbox.The new shared mailbox attributes allow to copy a message on a Shared Mailbox sent by a User Mailbox.
To enable this feature in the way to modify the Shared Mailbox behavior run the following cmdlet:
set-mailbox -id xxx -MessageCopyForSentAsEnabled $True
set-mailbox -id xxx -MessageCopyForSendOnBehalfEnabled $True
You may get the following error when you try to enable this feature:
“A parameter cannot be found that matches parameter name ‘MessageCopyForSentAsEnabled’.”
To solve this you can run the setup.exe /PrepareAD /IAcceptExchangeServerLicenseTerms command from the CU9 installation media.
I tryed today to add a new subdomain in Office 365 and I get the following error:
“i.in.com is a subdomain of a domain that was added by using the Microsoft Online Services
Module for Windows PowerShell so you´ll need to also use Windows PowerShell to add i.in.com
To Microsoft Online Services”
When I try to add i.in.com subdomain from Windows Powershell i get the following error.
“Unable to add this domain. It is a subdomain and its authentication type is different from
the authentication type of the root domain”
New-MsolDomain -Name i.in.com
New-MSOLFederatedDomain -DomainName i.in.com
“Failed to connect to Active Directory Federation Services 2.0 on the local machine.
Please try running Set-MsolADFSContext before running this command again”
I ran the following cmdlet from my ADFS server on premises.
Set-MsolADFSContext –Computer (FQDN of my ADFS server)
Then I ran the following cmdlet
New-MSOLFederatedDomain -DomainName i.in.com
Under a Coexistence scenario with Exchange 2007-Exchange 2013
Some users are reporting they cannot access OWA.
When a user tries to log on to Outlook Web Access (OWA) 2013 and the user mailbox is stored in an Exchange 2007 Database the browser displays the following message and user is not able to access to his mailbox.
After investigation I found it´s a client side caching issue.
Clear the Internet Explorer cache (cookies and web site data) and restart the browser.
El rol de HUB TRANSPORT de versiones anteriores (Exchange 2007 y Exchange 2010) ha sido segmentado y separado en diferentes servicios que ahora se encuentran repartidos entre los roles de CAS y MAILBOX.
- Front End Transport Service
- Transport Service
- Mailbox Transport Service
Este cambio en el modelo de arquitectura de Exchange 2013 ha provocado cambios en el servicio de transporte que afectan a las decisiones de enrutamiento que determinan que hacer con un mensaje en función de la información acerca de su destino.
Este nuevo modelo sigue la lógica que se detalla en el siguiente diagrama.