I read through many articles and done much research, and I really thought that the AutomaticRolloverCertificate function would take up its work seamlessly but guess what it didn’t. Well, it did generate the new token correct and changing the new token to the Primary and append the changes to Office 365 federation but it wasn’t able to update the changes in Office 365 federation.
I am not sure whether is this got to do with a single domain environment.
Commands/PowerShell you can only run from Primary ADFS unless you had run some PowerShell to allow session establish from another computer. (Which is also fine to proceed, as long as you could establish the connection)
- Federated Users unable to login
Actions are taken:
- I have checked the event logs
- Noticed there is an error about Event ID 111 WS-Trust or Value is null unable to perform the update
- I have query the output via PowerShell from ADFS server
- Key in Your Office 365 Global Admin credential (the firstname.lastname@example.org)
- Get-MsolFederationProperty -DomainName domain.com
Based on the above 2 actions, I have noticed that it didn’t update the federation in Office 365. It was able to append the changes of the new tokens to the Office 365 but it didn’t update.
- Run the PowerShell command from primary ADFS to force the update of the new token for Office 365
#enter your onmicrosoft.com global admin credential
Update-MsolFederatedDomain -DomainName domain.com -SupportMultipleDomain
#Check whether the token in office 365 is updated
Get-MsolFederationProperty -DomainName domain.com
2. Then Restart ADFS services, restart from primary ADFS then to the secondary ADFS
3. Retry to access portal.office.com, then you should be able to access
I am trying to simplify this situation with PowerShell Scripting…so stay tuned!