This browser is no longer supported.
Upgrade to Microsoft Edge to take advantage of the latest features, security updates, and technical support.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(115.19999999999999, 15%, 21%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3EBR%3C/text%3E%3C/svg%3E)
Last week i've updated the Active Directory Federation Services 2016 and above mp to the latest version 10.0.3.1.
Since then one of our adfs servers has a flapping monitor:
Microsoft.ActiveDirectoryFederationServices.2016.TokenIssuanceFederationServerMEXEndpointMonitor (UnitMonitor)
I've investigated the differences between 10.0.3.1 and 10.0.3.0 and i see that the powershell script that is ran by the monitor never worked in the previous version, so that explains why we now have an alert and previously did not.
But now, why do we get this alert? I do not have any adfs knowledge and discussed this with the adfs admin. He sais it's working fine functionally so no reason for this alert.
We extracted the script and ran it on the primary computer it always runs successfully, the variable $script:mexOK always returns true when we run it manually.
This is the error in the alert:
The WS-Metadata Exchange (MEX) endpoint 'https://<our fqdn>/adfs/services/trust/mex' that is used for authentication over SOAP and HTTP protocols is not reachable.
The uri is a load balanced address and when tested in a browser from the adfs node it also works fine.
![](data:image/svg+xml, %3Csvg xmlns='http://www.w3.org/2000/svg' height='64' class='font-weight-bold' style='font: 600 30.11764705882353px "SegoeUI", Arial' width='64'%3E%3Ccircle fill='hsl(233.6, 30%, 32%)' cx='32' cy='32' r='32' /%3E%3Ctext x='50%25' y='55%25' dominant-baseline='middle' text-anchor='middle' fill='%23FFF' %3ECM%3C/text%3E%3C/svg%3E)
@Berg, Ronald van den , Research for the error and find one link mentioned, it can be caused that the AD FS Windows Service is stopped on the federation server computer. We can verify that the AD FS Windows service is started on the remote federation server computer.
https://systemcenter.wiki/?GetElement=Microsoft.ActiveDirectoryFederationServices20.TokenIssuanceFederationServerMEXEndpointMonitor&Type=UnitMonitor&ManagementPack=Microsoft.ActiveDirectoryFederationServices.2.0&Version=7.0.8560.0
Note: Non-Microsoft link, just for the reference.
Hope it can help.
If the response is helpful, please click "Accept Answer" and upvote it.
Note: Please follow the steps in our documentation to enable e-mail notifications if you want to receive the related email notification for this thread.
I verified that the service is running for 3 days now without stopping, meanwhile these alerts are created regularly so that is not the cause.
@Berg, Ronald van den , Thanks for the response. From your description, I know the service is running without any issue. And the ADFS is working well confirmed by ADFS admin. It seems the issue is on MP side. Would you mind to disable the rule to avoid the alert?
In previous reply, I notice the address "https://<our fqdn>/adfs/services/trust/mex" is a load balance address and can access via the browser and we can get the xml mentioned in the following link:
https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/troubleshooting/ad-fs-tshoot-endpoints#ws-mex-test-active-test
Also, we have run the script manually and the $script:mexOK returns true. Could you try to output the $uriString to confirm if the URL we get when we manually run the script is the same one with load balance address?
Indeed the value of that variable contains the same url as we get in the error.
Btw, i think i've mentioned yesterday that i also added the load balance address to our url monitor, it didn't have a single state change since then while the mex alerts keep coming in so it's not the unavailability of the url that is causing the issue.
@Berg, Ronald van den , Thanks for the reply. From your description, I know the url is the same and the ADFS seems working well. But we still get alert. for this issue, I think it needs deep log analysis. With Q&A limitation, for such kind of issue, we suggest to open case to handle. Here is a link with the Phone number we can call.
https://support.microsoft.com/en-au/topic/global-customer-service-phone-numbers-c0389ade-5640-e588-8b0e-28de8afeb3f2
@everyone, if anyone else has met the same situation, we appreciate your help to share it here.
Thanks for the understanding.