Bug 125489 - Slow start with AD users
Summary: Slow start with AD users
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: LibreOffice (show other bugs)
(earliest affected) release
Hardware: x86-64 (AMD64) Windows (All)
: medium normal
Assignee: Not Assigned
Depends on:
Reported: 2019-05-25 12:35 UTC by Vincent
Modified: 2021-11-25 05:22 UTC (History)
1 user (show)

See Also:
Crash report or crash signature:


Note You need to log in before you can comment on or make changes to this bug.
Description Vincent 2019-05-25 12:35:47 UTC
Hi team

When I log in windows (7 or 10) with a local admin user, LO starts immediatly.

When I log with an AD user with or without admin rights, LO takes 20 seconds to start. Once started, other documents open normally fast. This happens on our 10 test pc's.

In LO 6.0.7 no problems at all!

I'm in contact with IT managers and we all stays at 6.0.7, where this behaviour is not visible, because users do not accept to wait 20 seconds.

Thanks to all the team for your job !!!


Comment 1 Julien Nabet 2019-05-25 17:45:14 UTC Comment hidden (obsolete)
Comment 2 Vincent 2019-05-27 09:38:49 UTC

Same problem in

Comment 3 Julien Nabet 2019-05-27 09:45:19 UTC
Have you got specific extension?
Do you reproduce this if you rename your LO directory profile and give a new try? (see https://wiki.documentfoundation.org/QA/FirstSteps)

Just for the record, on the company where I work, on Win10 with LO 6.2.3 by using an AD user, I don't reproduce this.
Comment 4 Vincent 2019-05-27 10:00:23 UTC

Every week we install about 10 new computers with 10 brand new profiles.
I've just test it on a brand new computer with a brand new installetion of LO 6.2.4. and I have the same problem.

This behaviour occurs on all our 10 test computers in win7 or win10 with a domain user. Not with a local user. 

This does not occurs with version 6.0.7.

I don't see any slow process with procmon during the 20 seconds of starting LO.

Really strange! Is there somethinh new in the startup process after LO 6.0.7 ?

Comment 5 Julien Nabet 2019-05-27 10:23:33 UTC
Is the user profile on local hard disk or put on shared network?
If on shared network, this could be the explanation.

Also, if you have lots of fonts, LO may take more time to start.
Comment 6 Vincent 2019-05-27 10:40:51 UTC

Profile is allways stored locally .
Standard fonts of windows. No add-ons installed.
With or without antivirus started.
Standard windows 10 installation with only LO 6.2.4 to test.

Strange behaviour!

What is LO looking for at startup?

Thanks to help us.

Comment 7 Julien Nabet 2019-05-27 12:34:12 UTC
I can't tell what's done at LO startup, I suppose it loads rendering, fonts, Java, ...
I don't know if it checks LO or extensions updates existence on network.

Do you use quickstart? (if yes, could you try without?)
Do you reproduce with each LO module (Writer, Calc, Impress...)
Just to be sure, do you reproduce this each time you shutdown LO and reopen it or once by Windows session?

Do you have only 1 Java installed or several? If just 1, is it 32 or 64 bits?

What rendering do you use? (see https://wiki.documentfoundation.org/QA/FirstSteps#Graphics-related_issues_.28OpenGL.29)

You can also try to reproduce this in safe mode.

About procmon, you can try https://docs.microsoft.com/en-us/sysinternals/downloads/procmon, it gives a lot of details (you must filter to focus on what interests you).
The idea would be to save a session with local admin user and with AD user and try to compare.
For networking test, you can give a try to Wireshark.
Comment 8 Vincent 2019-05-27 13:47:34 UTC
Hi, here my answers :

Do you use quickstart? (if yes, could you try without?)

- No quickstart

Do you reproduce with each LO module (Writer, Calc, Impress...)

- Each module has the same behaviour

Just to be sure, do you reproduce this each time you shutdown LO and reopen it or once by Windows session?

- Each time I shut down LO and reopen it

Do you have only 1 Java installed or several? If just 1, is it 32 or 64 bits?

- 1 Java 32bits (Tried also with java 64 bits) same behaviour. Same in LO 32 or 64bits

In safe mode > same issue ...

Thanks for fast replies!
Comment 9 Vincent 2019-05-27 13:49:15 UTC
Same problem for this user

Comment 10 Vincent 2019-05-27 13:52:35 UTC

 UI render: default;

Comment 11 Julien Nabet 2019-05-27 13:58:29 UTC Comment hidden (obsolete)
Comment 12 Vincent 2019-05-27 14:23:23 UTC Comment hidden (obsolete)
Comment 13 Vincent 2019-05-28 13:33:24 UTC

It's the first time I introduce a bug, so What happens now?

Comment 14 Julien Nabet 2019-05-28 14:56:22 UTC
Vincent: AFAIK, I don't have more ideas. So either QA or dev people may intervene and bring some ideas to tests or to fix this or it may stay like this.

You must know that most of people are benevolent (it's my case for example) so depending on the bug, the availability of people, the interest of them for this issue, the difficulty to reproduce this, to solve this, etc.  the bug may stay years like this.
If QA and dev people have no idea, it can also happen that a new LO version may help. Indeed, sometimes a fix or an evolution present in a new version may impact positively a bug.
If it's urgent, you may also contact and pay professional support (see https://www.libreoffice.org/get-help/professional-support/).
Comment 15 Alex Thurgood 2019-05-28 15:31:55 UTC
I don't have anything like the setup causing the issue, but a first suggestion from me would be to sniff the network packets and try and find out if it is some kind of host resolution or lookup that is causing that 20s delay.

For example, it has been quite common in the past, at least on and off, for various versions of LO to exhibit lookup delays with certain types of network storage/acess. Perhaps the problem lies here.

For example, searching for templates in a network share might cause a slowdown...
Comment 16 QA Administrators 2021-05-28 04:50:35 UTC
Dear Vincent,

To make sure we're focusing on the bugs that affect our users today, LibreOffice QA is asking bug reporters and confirmers to retest open, confirmed bugs which have not been touched for over a year.

There have been thousands of bug fixes and commits since anyone checked on this bug report. During that time, it's possible that the bug has been fixed, or the details of the problem have changed. We'd really appreciate your help in getting confirmation that the bug is still present.

If you have time, please do the following:

Test to see if the bug is still present with the latest version of LibreOffice from https://www.libreoffice.org/download/

If the bug is present, please leave a comment that includes the information from Help - About LibreOffice.
If the bug is NOT present, please set the bug's Status field to RESOLVED-WORKSFORME and leave a comment that includes the information from Help - About LibreOffice.

Please DO NOT

Update the version field
Reply via email (please reply directly on the bug tracker)
Set the bug's Status field to RESOLVED - FIXED (this status has a particular meaning that is not 
appropriate in this case)

If you want to do more to help you can test to see if your issue is a REGRESSION. To do so:
1. Download and install oldest version of LibreOffice (usually 3.3 unless your bug pertains to a feature added after 3.3) from https://downloadarchive.documentfoundation.org/libreoffice/old/

2. Test your bug
3. Leave a comment with your results.
4a. If the bug was present with 3.3 - set version to 'inherited from OOo';
4b. If the bug was not present in 3.3 - add 'regression' to keyword

Feel free to come ask questions or to say hello in our QA chat: https://kiwiirc.com/nextclient/irc.freenode.net/#libreoffice-qa

Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team

Comment 17 Timur 2021-05-28 07:55:38 UTC
There are multiple similar reports. 
I suspect relation to bug 46014 and bug 33697.
Please write your Options-Internet-Proxy server and try to change and write Options-Online Update-Check status (try to turn off all there).
Comment 18 QA Administrators 2021-11-25 05:22:27 UTC
Dear Vincent,

This bug has been in NEEDINFO status with no change for at least
6 months. Please provide the requested information as soon as
possible and mark the bug as UNCONFIRMED. Due to regular bug
tracker maintenance, if the bug is still in NEEDINFO status with
no change in 30 days the QA team will close the bug as INSUFFICIENTDATA
due to lack of needed information.

For more information about our NEEDINFO policy please read the
wiki located here:

If you have already provided the requested information, please
mark the bug as UNCONFIRMED so that the QA team knows that the
bug is ready to be confirmed.
Thank you for helping us make LibreOffice even better for everyone!

Warm Regards,
QA Team