Microsoft Office 365 Federation Metadata Update Automation Installation Tool

This tool can be used to automate the update of the Microsoft Office 365 federation metadata regularly to ensure that changes in the case of the token signing certificate configured in Active Directory Federation Services 2.0 are replicated to the identity platform automaticall

 
 
 
 
 
4.3 Star
(23)
24,995 times
Add to favorites
Active Directory
6/17/2013
E-mail Twitter del.icio.us Digg Facebook
Sign in to ask a question


  • Not required for ADFS 3.0
    2 Posts | Last post June 09, 2016
    • if you follow that article:
      
      https://technet.microsoft.com/en-us/library/jj151809.aspx
      
      If you are using AD FS 2.0 or later, Office 365 and Azure AD will automatically update your certificate before it expires.  You do not need to perform any manual steps or run a script as a scheduled task.
      
      See also the requirements:
      
      * The AD FS property AutoCertificateRollover must be set to True
      * Your federation metadata must be available to the public internet.
    • Does this tool needs to be scheduled and run for ADFS 3.0?
      
      Thanks - M
  • ADFS WS2012 R2
    1 Posts | Last post April 21, 2015
    • tested in WS2012 R2 and works flawlessly
  • ADFS 3.0 / Server 2012 support
    1 Posts | Last post April 20, 2015
    • Any plans to update this to officially support ADFS 3.0 / Server 2012 R2?
  • ADFS v3?
    3 Posts | Last post December 11, 2014
    • Can this be configured to run on server 2012r2 as well?
      
      thanks!
    • They make it sound as if its supported according to this article:  http://technet.microsoft.com/en-us/library/jj151809.aspx, just would like to have a definitive nod from the product group.
      
      thanks!
    • tested first in lab then in production on 2012r2 and looks to be working great!
  • Multiple Office 365 Multiple Tenancies and MSOL Credentials
    1 Posts | Last post July 07, 2014
    • Hi ADFS Team,
      
      Firstly, thanks for putting this script together, it's greatly appreciated.
      
      My question is: We have multiple Office 365 tenancies supported by our ADFS farm. Each tenancy has a different TLD (e.g. fabrikam.com, contoso.com). Can I pass multiple MSOL Credentials into the script to facilitate connection to each tenancy? Or do I need to run a separate instance of the script for each tenancy?
      
      Thanks for you help in advance.
  • ADFS 2012 and ADFS 2012 R2
    1 Posts | Last post June 02, 2014
    • Hi ADFS Team,
      
      Is there anything stopping me from running this script on either Server 2012 (ADFS 2.1) or Server 2012 R2 (ADFS 3.0)?
      
      Noted that the article states that it won't work on Server 2012, only 2008 R2.
      
      Thanks!!
  • Please show $error[0] if something goes wrong
    1 Posts | Last post January 16, 2014
    • For instance, when logging on to MSOL goes wrong, I'd like to know why:
      
      Validating MSOL credentials
      
      	Failed MSOL credential validation. Exiting...
      
      Your password has expired. Contact your Office 365 administrator to reset your password.
  • Does this script also need to restart the ADFS service?
    1 Posts | Last post November 29, 2013
    • We have this script installed on our primary ADFS server, and auto-rollover set. A new  token-signing certificate has been created, and yesterday it became primary. The script updated the Office 365 servers fine, but during the day our ADFS servers started giving event ID 364 on every logon, with this error "An unsecured or incorrectly secured fault was received from the other party". Eventually I found this post: http://dloder.blogspot.co.uk/2012/10/adfs-20-event-id-248-and-364-unsecured.html, which pointed me to restarting the ADFS service on the servers (not the proxies). That fixed it. Given that the combination of auto-rollover and the script makes almost all of the certificate change automatic, wouldn't be a good idea  if the script did the restart itself?
  • Script hangs on update metadata
    2 Posts | Last post September 23, 2013
    • Since our cert expires in October, I thought I'd give this automation tool a try. Downloaded and installed the tool successfully. After starting the scheduled task manually, it stayed in a running state for well over an hour (even though the settings of the script say to stop if running longer than 1 hour). I ended the task from task scheduler.
      
      While the task was running, the script history log remained empty except for the start date/time, but now shows this after ending the task:
      
      #################################################################
      Attempting to update metadata for  without SupportMultipleDomain
      The argument is null or empty. Supply an argument that is not null or empty and then try the command again.
      Attempting to update metadata for  with SupportMultipleDomain
      The argument is null or empty. Supply an argument that is not null or empty and then try the command again.
      #################################################################
      
      I have 2 federated domains, neither of which is mentioned in the history log for the variable $FedDom.
      
      I get the expected result when I manually issue:
      Get-MsolDomain -Authentication Federated -Status Verified
      
      Does something with the [array] or the $FedDoms variable need to be changed for my environment?
      
    • ## Update ##
      
      Found the problem to be with the user account used to run the scheduled task. When I installed the tool, it initially registered my domain account to run the task. I changed the task to run as a different domain account, which is also a local admin on the server. Setting the task to run as me works without issue.
      
      Do I need to reinstall the tool as the user with which I want the task to run, or should I be able to change that user to more of a service account-type of user instead of myself?
  • Will this script renew the expired certificates automatically
    2 Posts | Last post July 27, 2013
    • Hi,
      on ADFS Server the token signing certificate will expire in 4 days and when contacted O365 tech support, I was informed that the certificates will be automatically renewed on the day of expiry if this tool is installed, is that correct
    • Yes, they are correct. It will update automatically but I would still keep an alert to confirm that all trusted relying parties are functional once the certificate is updated. In case of CRM, I figured that they go down and we have to manually update the metadata or reconfigure claims\IFD (this is known issue for CRM)
      But I have seen no problems with O365 services.
1 - 10 of 18 Items