Correct setup on a server

[janaboo33]

Greetings!
I'm trying to set up Everything on a web server that can create a db of some network drives. I'm struggling with the setup and need some help.

I've installed Everything on the server (Drive D: where my mediawiki install resides) using a service account since that is always logged on. I chose to originally run as administrator and selected to create the db in installation folder. Is this the preferable method OR should it have been created in the %APPDATA%\Everything folder?

What other settings should I set for multi-user access?

I also enabled HTTP server (Port 81) so we don't have to install the software on computers. I've then created a link from my mediawiki site to search. While this works the first time, it seems to be hit and miss.

Obviously I'm so confused...I've read as much as I can find on this forum, but must be missing something. Can you help?
Thanks, Jan

[void]

I chose to originally run as administrator and selected to create the db in installation folder. Is this the preferable method OR should it have been created in the %APPDATA%\Everything folder?

Yes, storing settings and data in the same location as Everything is the preferred method.
There shouldn't be any issue as long as Everything has write access to this folder.

What other settings should I set for multi-user access?

None, Everything should be able to handle up to 1000+ concurrent connections (WSAAsyncSelect).

While this works the first time, it seems to be hit and miss.

What happens when its a miss? does a page load at all, is it slow to load? etc.
Hope I can help.

[jbarcher13]

Thank you so much for getting back to me! And thanks for the confirmation that I did things correctly!

Now, I have some questions:
This morning, a user complained that the web-based search was not working. I logged onto the server, and I got the "Everything stopped working unexpectedly" error message. I had to restart the program and now it's scanning. Why is a scan happening? Is this normal? Apparently, the program stopped running after a reboot (which can happen by IS and/or me) and didn't scan for changes overnight which I set up in the Options. Is there a way to make sure that if a reboot happens, the program will definitely restart? Do I have to create a script to make sure that happens? If the program restarts, will a new index be created instead of incrementing? If I stop the scan, will Everything go back to the index created yesterday?

Additional information:
I have an admin service account that I used to install the program on my web server (all files and indexes in the installation folder). This account auto logs on when a reboot happens. Yesterday I built the indexes (wow that took a long time) including three network drives that are huge!

I honestly LOVE this program and since I'll be the admin, I really need to understand how this really works. Any help would be greatly appreciated...I'm under scrutiny by management and really need this to work.

I'm also attaching my everything.ini file for you to look at just in case there is something there that needs tweaking. Also, if you have any additional questions or info from me, let me know!

Thanks, again
Jan

[jbarcher13]

Hi again!
Sorry, but I forgot to answer your question about the "hit or miss" question. It seemed that when indexing is being done, nothing is displayed in web-search. I've been doing some more reading in the forum and have seen comments that lead me to believe that that is the behavior. So if I've set my Indexing Options to "Index recent changes", it doesn't allow you to see the most recent index during this time. Is that correct? Because it can take 24+ hours to index a couple of our network drives, this could interrupt using search if that updating were being done during the day. Do I have that right?

The ideal scenario, then, would be to do the update scans in the middle of the night, correct? If so, I set up my Options to run updates at midnight. BUT as I mentioned before, Everything stopped at some time during after-hours and did not restart -- could have been after a reboot, but not sure. In this case, how might I keep a rescan from happening after these events and go back to the most current index?

If I turn off all updates, it seems I would have to do a manual update, correct? If so, what's the best way to do that without changing the options?

Hope all this makes sense...any and all help would be greatly appreciated!
Jan

[void]

This morning, a user complained that the web-based search was not working. I logged onto the server, and I got the "Everything stopped working unexpectedly" error message.

Could you please send me your HTTP_Server_Log.txt

If the crash keeps occurring please send me your debug logs.

Why is a scan happening? Is this normal?

Too many changes occurred while Everything wasn't running.
Everything 1.3 must rebuild the entire database.
Everything 1.4 must reindex the out of date volume.

Is there a way to make sure that if a reboot happens, the program will definitely restart?

How are you running Everything on your Server? are you using the client service?
If your not using the client service, try enabling run on system startup from Tools -> Options -> General.

If the program restarts, will a new index be created instead of incrementing?

The database will update from the last successful index, if possible. If too many changes occur Everything must reindex.

If I stop the scan, will Everything go back to the index created yesterday?

The updating can not be interrupted.
There is a read only command line option: -read-only
This will load the previous index without updating, although this defeats the purpose of using Everything here:
Everything.exe -read-only

Sorry, but I forgot to answer your question about the "hit or miss" question. It seemed that when indexing is being done, nothing is displayed in web-search.

Correct, while the database is loading and the initial update is being performed, the HTTP client will see an empty result list.
Ideally, Everything should only have to load once. After the database has loaded this should never occur.

So if I've set my Indexing Options to "Index recent changes", it doesn't allow you to see the most recent index during this time. Is that correct?

Yes, you will not be able to see recent changes while Everything is loading.

Because it can take 24+ hours to index a couple of our network drives

If its taking 24+ hours for Everything to index a network drive then Everything might not be the best solution here. How many files is Everything indexing?

this could interrupt using search if that updating were being done during the day

Folder index updating is done in the background and will not interrupt searches.

The ideal scenario, then, would be to do the update scans in the middle of the night, correct?

Yes, as processing the folder indexes updates may cause the searches to take a little longer.

If so, I set up my Options to run updates at midnight. BUT as I mentioned before, Everything stopped at some time during after-hours and did not restart -- could have been after a reboot, but not sure.

Please enable debug logging, it will help find the issue.

In this case, how might I keep a rescan from happening after these events and go back to the most current index?

If I turn off all updates, it seems I would have to do a manual update, correct? If so, what's the best way to do that without changing the options?

Please make sure you are using the Everything 1.4 beta.
The Everything 1.4 beta will not reindex folder indexes when rebuilding the database.

[jbarcher13]

Greetings! Thank you so much for all your help with this issue. Since your response, we've installed Everything on a different cloud web server (located on the West coast instead of the East Coast) and the indexing of all three network drives that we need went from 3.5+ days to about 6 hours! It's working fine now and we're testing it. I think that most of my issues were due to the original server we used and other processes running on that server. Not sure, but so far, so good now! LOVE this tool.
Thanks again, Jan