This morning at a customer , I received the following mail in my mailbox , saying that my ADFS token would expire.
AD FS 2.0 or 2.1 and probably 3.0 generates each year by default a new self- signed certificate for token signing 20 days before the certificate expires . Rollover of the certificate , or generate a new certificate when the existing certificate is about to expire , and make them the primary certificate , applies only to self-signed certificates that are generated by AD FS 2.x . The token signing certificate is essential for the stability of the Federation Service . If this is changed, the change must be reported to Windows Azure AD . Otherwise fail applications for cloud services such as my Windows Intune Service.
When the token signing certificate of your home AD FS organization expires, then federation metadata between AD FS and Office 365 falls out of synch. Equally, when changes are made on the Office 365 or Windows Intune that require updating the metadata, a similar issue arises. The “Microsoft Office 365 Federation Metadata Update Automation Installation Tool” script provide by the AD FS team checks the that federation metadata is validated regularly and any changes replicated between the two federating parties.
You must have the Microsoft Federation Metadata Update Automation Installation Tool download and configure your primary federation server or another recordable federation server, the Windows Azure AD Federation Metadata regularly automatically checks and updates so that changes in the certificate token-signing in the AD FS 2.1 Federation service will be copied automatically onto Windows Azure AD.
You can download the script here : http://gallery.technet.microsoft.com/scriptcenter/Office-365-Federation-27410bdc
The script is called : O365-Fed-MetaData-Update-Task-Installation.ps1
To execute this tool successfully:
- You must make sure that you have installed the latest version of the Microsoft Online Services Module for Windows PowerShell
- You need to have a functioning AD FS 2.0 Federation Service (execute this on your primary ADFS server)
- You need to have access to Global Administrator credentials for your Office 365 tenant
- You need to have at least one verified domain in the Office 365 tenant must be of type ‘Federated’
- This tool must be executed on a writable Federation Server
- The currently logged on user must be a member of the local Administrators group
- The Microsoft Online Services Module for Windows PowerShell must be installed. You can download the module from http://onlinehelp.microsoft.com/en-us/office365-enterprises/ff652560.aspx0
When running the tool and you comply with the above prerequisites , the following screenshot appears as shown below :
It’s worth bearing in mind that the password policy will render the script unusable in the event of a password change on either the Windows Intune side with the MSOL account you specify and the Domain side with the user account used to initiate the scheduled task. It is possible to create service accounts to do this on both sides. However, I’d consider the security consequences of such a change before automatically doing so. This can be done on the O365 side with an Office 365 standard account via the Set-MSOLUser cmdlet.
For example: Set-MSOLUser –identity user@MyPreciousChosenDomain.onmicrosoft.com –PasswordNeverExpires $true –StrongPasswordRequired $true
The account could also technically be a federated account, but I don’t believe that’s a good idea. In the event that the trust is broken, then a federated account won’t be able to connect to MSOL to update the federated domain information and you would be in trouble big time!
To verify the scheduled task is executed correctly , open task scheduler and verify that the task is there :
;-
That’s again an automated task , without worrying that your infrastructure is in danger 
Hope it Helps ,
Kenny Buntinx
Enterprise Client Management MVP