Jump to content

Recommended Posts

Posted

Trying to debug this one and it's driving me bonkers.

 

Staff are trying to login to iam.pearson.com and it's consistently crashing when they try to login.

 

It doesn't happen on an unmanaged device, so it's clearly something to do with the settings we're pushing to Windows or browsers.

It doesn't happen for admin accounts, or accounts outside of the typical scope, so that infers it's something to do with user settings/policies.

 

But now I'm hitting a roadblock. How do I drill into this more?

 

It happens in Chrome, Edge and FireFox. The browser will hang for ages, before Chrome and Edge complain and give you the option to terminate.

chrome://crashes and edge://crashes don't give me any useful information. Annoyingly, Firefox seems to handle this issue better and eventually recovers, so nothing at all in about:crashes.

Nothing in event logs.

 

Kinda stuck now.

Posted
I was having a similar issue recently with pearson, our issue was related to filtering, whitelisted the site and all has been good since!
Posted (edited)

We had the same issue with it timing out with very similar symptoms. It was our firewall/filter which needed tweaking:

https://edexcelonline.pearson.com

https://userportal.pqs.pearsonprd.tech/

https://iam.pearson.com

 

All needed whitelisting. I think we were missing the second one.

I recall there was also an issue where the link sent to exams officers to the login page was wrong and an issue where if they had logged into the Edexcelonline site in the same session it tried to get back into there rather than the new page on the iam pearson domain. Fixed by clearing cache.

 

Doesn't help with the many other issues with the Pearson sites and the authentication process. Their online presence is truly dreadful.

Edited by Linfit
  • Thanks 1
Posted
... It doesn't happen on an unmanaged device, so it's clearly something to do with the settings we're pushing to Windows or browsers ...

 

Does it happen on all devices? (all AD OUs) Can you narrow it by finding an OU, or OUs where it doesn't happen?

 

What about Windows event logs? Is there anything helpful in there?

Posted
Pull off a Netsweeper report for a timed test from 2 mins before to 2 mins after, just the person or policy group, find the entry where they access the site and see what follows as denied. Sorry if this akin to sucking eggs.
Posted
We had a similar issue. It tuned out that the Pearson sign-in uses port 8443, rather than standard 443. This seems to be used by Tom Cat servers. We had to add a rule on our Firewall to allow this.

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now



×
×
  • Create New...