ADFS won't Start - Can't long into Office 356! - Urgent

[Stuart_C]

We had ADSF running yesterday fine. Re-booted the server for testing and it's failed to start ADFS and people can't long in.

 

The AD FS service won't start and generally it's a massive problem.

 

Event log Shows

Event ID 7023 - The ADFS Windows Service terminated with the following error: An exception occurred in the service when handling the control request

Event ID 684 (source ADFS) the ADFS web agent was unable to update the trust information from the federation service. Federation service secure sockets layer (SSL) server certificate may not be validated. Federation service URL: http://Http://localhost/adfs/fs/FederationServerServices.asmx

 

Now the last one makes sense as the SSL certificate wouldn't mach LocalHost. But I can't find how to stop it looking as local host and get it to look at the servers FQDN!

 

There are also a load of errors in the AD FS Event log

 

help!

Edited February 26, 2015 by Stuart_C

[ellsandell]

In the interest of time. You might be better contacting Microsoft support directly?

 

 

Eliot

[Stuart_C]

Possibly, but I've no idea what that would cost. As we are not fully live it's not 100% the end of the world however we have a few people using it in test and my boss it not happy and wants it sorted.

[Michael]

I'd agree - it does look like a cert/trust issue. Contacting Microsoft for Office 365 support should be free, but can take a day or two. To be honest, look at it as a positive - the system isn't live, you're migrating from (probably) an existing Exchange or other e-mail solution, there are inevitably going to be issues that crop up.

[apearce]

first, rerun - Update-MsolFederatedDomain for your domain

then just work on ADFS, don't worry about proxy. ensure the website is up and running and all dependencies ar working.

[Stuart_C]

i've just found the MS support bit and logged a case. Interestingly you can't upload event viewer files, which I would have thought would have been really useful.

 

Found one solution that exactly discusses the issue on technet then says look for this information in the web.config file. However what it says to look for isn't there, so if it's getting the information from that file I've no idea how it is.

[Stuart_C]

OK - Just looking at fallbacks - I can't use convert-MSOLDomainToStandard in powershell as the server isn't running.

 

Given DirSync is running I can presumably use Set-MsolDomainAuthentication to "get out of jail" as per this. Wait for the next dir sync/force a password re-sync and away I go. If I take this second route what, if any, problems am I likely to encounter?

 

For example having to convert all the users back using the Convert-MsolFederatedUser command to convert all the users?

Edited February 26, 2015 by Stuart_C

[Stuart_C]

Just an update:

Issue seems to be that the windows database vanished. (???!!!?!?!)

Microsoft gave me a ring and went through a few bits, tried re-installing it and generally failed. Recommendation was to use a new server and go from there. Not helpful as I didn't have one to hand. No real explanation as to why this happened.

 

We used Set-MsolDomainAuthentication to change the authentication to Managed and as I'm already using DirSync the passwords seem to be working OK and I can log in. I Need to do some more testing to be sure. One concern is over the fact that now I've used this method to change the domain, do I need to run Convert-MsolFederatedUser against all the users... I've seen one website say yes. But MS said no and I'm not 100% sure either way.

[EduTech]

Just an update:

Issue seems to be that the windows database vanished. (???!!!?!?!)

Microsoft gave me a ring and went through a few bits, tried re-installing it and generally failed. Recommendation was to use a new server and go from there. Not helpful as I didn't have one to hand. No real explanation as to why this happened.

 

We used Set-MsolDomainAuthentication to change the authentication to Managed and as I'm already using DirSync the passwords seem to be working OK and I can log in. I Need to do some more testing to be sure. One concern is over the fact that now I've used this method to change the domain, do I need to run Convert-MsolFederatedUser against all the users... I've seen one website say yes. But MS said no and I'm not 100% sure either way.

 

If you still have a problem tomorrow and are not making any progress, drop me an PM and I shall fix it for you and get you unblocked. if you could also give me Service incident Number that you have provided that will be helpful.

 

Furthermore, when you create the Relying Party you should use the Convert-MsolDomainToFederated -DomainName contoso.com when using AD FS you should not use the Set-MsolDomainAuthentication option, this is generally used when using 3rd Party Identity Providers such as Shibboleth, Ping etc. If you plan to use Multiple Domains then you should also use the -SupportMultipleDomain parameter in that command.

 

It would seem that you may have configured AD FS to use localhost as the Federation Service Name which is why it is returning that error message. Is that what you used when you went through the wizard to setup ADFS or did you use something like sts.contoso.com.

 

James.