Long wait time in queue for password resets

[Joakim K]

I am having an issue with the password reset feature. If I expire an password enabled for reset, it takes many hours in the queue before it gets reset.

In the debug log, it just says this every minute:

 

2020-05-20 11:18:08 - Starting processing CheckInPasswordResets.
2020-05-20 11:18:08 - Finished processing CheckInPasswordResets.
2020-05-20 11:19:08 - Starting processing of records already in the Password Reset Queue.
2020-05-20 11:19:08 - There are 0 records in the queue to process.
2020-05-20 11:19:08 - Finished processing of records already in the Password Reset Queue.

 

But if I check in the Webportal, it is sitting in the queue. Eventually, it will realise it has a queue item and handle it properly (It could be related to "kicking on things", as it worked directly after performing an upgrade of passwordstate after disabling maintaince mode - But not by just putting it in maintainence mode for a few minutes). 

 

Any ideas what the problem might be and how to further debug this?  

 

EDIT: Might be worth mentioning that the database is running on an Azure SQL instance and that nothing interesting shows up in the IIS Event viewer log

[support]

Hi Joakim,

The Passwordstate Windows Service checks if there is anything in the ResetTasksQueue table once per minute, and should process them straight away.

In your web.config file for your site, can you check the PassiveNode key is set to false? If it is, are there any errors being reported in the Windows Application Event log which might help us? If Passwordstate is in maintenance mode, then all processing like this will be halted, so please make sure you do not leave it in this state.

Regards

Click Studios

[Joakim K]

I have confirmed that the PassiveNode key is set to false. 

In the application error log, these two errors seem to occur every 10 minutes that might be related to this?

 

Application Error (1000)

Faulting application name: wmiprvse.exe, version: 10.0.17763.1, time stamp: 0xdd9b741c
Faulting module name: Microsoft.Management.Infrastructure.Native.ni.dll, version: 10.0.17763.1, time stamp: 0xb00293f9
Exception code: 0xc0000005
Fault offset: 0x0000000000068620
Faulting process id: *****
Faulting application start time: 0x01d632025977c9b5
Faulting application path: *\system32\wbem\wmiprvse.exe
Faulting module path:*\Windows\assembly\NativeImages_v4.0.30319_64\Microsoft.M870d558a#\21970153b91daa4f6910864f3eb49d43\Microsoft.Management.Infrastructure.Native.ni.dll
Report Id: 5b280a22-db8e-40bb-8428-88e280cc2457
Faulting package full name: 
Faulting package-relative application ID: 

 

.NET Runtime (1026)
Application: wmiprvse.exe
Framework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.AccessViolationException
   at Microsoft.Management.Infrastructure.Native.ClassHandle.ReleaseHandle()
   at System.Runtime.InteropServices.SafeHandle.InternalFinalize()
   at System.Runtime.InteropServices.SafeHandle.Finalize()

[support]

Hi Joakim,
 

I think we are going to need to see some screenshots and data to troubleshoot this further - and I don't think that event log error would cause this. Can you contact us via the following support page, and provide the following - https://www.clickstudios.com.au/support.aspx 
 

• What build Number of Passwordstate you are using?
• A screenshot of all the settings for your password record that you are expiring - basically all the tabs on the Edit Password screen
• Using the following article as a guide, provide us a copy of the data in the ResetTasksQueue and SystemSettings tables - https://www.clickstudios.com.au/documentation/query-data.aspx 

Regards

Click Studios

[Joakim K]

Done! Thank you. 

[Ralph K]

Hello Click Studios team

 

I have also to wait for the password reset. For me the password reset takes exactly 2 hours, every time. I analysed the log on the server and can't find any error. It says for 2 hours after I triggered the reset "There are 0 records in the queue to process". But I can see it in the queue on the website. Then, after 2 hours, the records will be found in the queue and the password reset executed.

The timestamp in the log file and on the website after the reset is the same except the hour, e.g. 11:41:12 (log) and  09:41:12 (website). So I think this is something related to a time zone configuration. Can this be the case?

I'm using the build 8951.

Thank you for your help.

 

Kind regards,

Ralph

[support]

Hi Ralph,

 

We've had a couple of instances where this issue is happening when the time on SQL Server is different to the web server, and we've corrected this for the next release. Can you check out if this is the case for you, and you will need to reboot one of your servers if you change the time.

Regards

Click Studios

[Ralph K]

Thank you for the explanation. Then we will wait for the next release.

We are using Amazon RDS and there you cannot change the time zone. We would have to recreate the instance to change the time zone.

 

Kind regards,

Ralph

[support]

Okay thanks Ralph - the next release should be available in about a week or two.

Regards

Click Studios

[HeDish]

It takes time for us as well.

Have approx 55 hosts imported at the moment.

Imported 5 new host last run and than run the reset job against the host list.

It took 3 hour and 20 minutes to reset the five new servers in the list...

 

Have approx 500 more servers to import and then run the reset job against....doesn't dare to think how many days that will take... 

[support]

Hello HeDish,

 

Can you confirm if you believe you are seeing the same issue because your web server time is different to your database server time?

 

If so, can you let us know what build number you are using, and there should have been a fix for this in the release below?

 

 

Regards

Click Studios

[HeDish]

Both servers have the exact same time and time zone (uct+1).

 

We're running 

Passwordstate 8.9 - Build 8989 (12th November 2020)

[support]

Hi HeDish,

 

That is very unusual behaviour, and we will need to investigate further with you.

 

Cann you please run the following script on your web server to gather some information https://www.clickstudios.com.au/community/index.php?/topic/2518-passwordstate-support-information-script/ and then log a support call via this page - providing the output of the script - https://www.clickstudios.com.au/support.aspx

Thanks very much.

Regards

Click Studios