Foldr search lets people search across many storage locations at once, or one at a time: file servers over SMB alongside OneDrive, SharePoint, Teams, Google Drive, Box and Dropbox. Search is switched off until an administrator sets it up.
This article covers the service side, which you do once: deciding where the search role runs, connecting it to your configuration, and creating a core for the index to live in. Configuring an individual share (what gets indexed, OCR, running a crawl) is covered separately in Indexing a share for search.
Written against Foldr 11.1.
Where does search run?
Results for SMB shares come from an index that Foldr builds and holds itself. Building that index means opening and reading every file once, which is demanding on both processor and memory, so we strongly recommend a separate virtual server dedicated to the search role. Run search on the same server your people use for file access and they’ll feel it, even on a well-specified machine.
For a dedicated search server, the recommended minimum is:
- 2 vCPU
- 4 GB RAM
Give it more and the crawl will, within reason, use most of what it’s given. The specification above is the minimum for search to work properly rather than a target to aim at.
Cloud locations are different: OneDrive, SharePoint, Teams, Google Drive and Dropbox can be searched through the provider’s own search instead, with no index and no crawl. If that’s all you need, you don’t need a search server at all, and you can skip to Indexing a share for search to switch it on per share.
Running both roles on one server
It isn’t ideal, but you can run client access and the search role on a single server. If you do, raise the minimum specification to 4 vCPU and 8 GB RAM, and raise the memory Foldr holds back for everything that isn’t search.
That reserve defaults to 2 GB, which is fine on a dedicated search server but tight when people are also using the machine for file access. Set it to 4 GB in Foldr Settings under Search, on the Service page, in the System reserve memory box. You don’t need to touch it on a dedicated search server.
Connecting the search server to your configuration
The search server has to read the same configuration database as the server your people use, so it can see your shares, licence and service accounts. This is a pair of settings, one on each machine, plus two keys that have to match.
On the client access server, go to Infrastructure, then Configuration, and set Server mode to Provide database services to other servers. Enter the search server’s address in Trusted servers.
Then open the Keys page on the same server and note the hashing salt and the encryption key. Revealing the encryption key asks for the administrator password.
On the search server, set Server mode to Connected to other server(s) for database services and enter the client access server’s address for database services. Then, on its Keys page, paste in the hashing salt and save, and paste in the encryption key and save.
Save those two separately. Changing the hashing salt and the encryption key in a single save doesn’t work, and the encryption key won’t be stored.
Checking it worked
Two quick tests, both worth doing before you go further.
Open Shares on the search server. If your shares, licence and service accounts are all there, it’s reading the configuration from the client access server, and changes made on either machine show up on the other straight away.
Then search for a user or group anywhere in Foldr Settings (the Crawl as box on any share is a good spot). If directory users and groups come back, the encryption keys match. If they don’t, the keys are the first thing to check.
Switching the index service on
On the search server, go to Search and turn on the Indexing service.
The same page holds the trusted servers list for search. Enter the address of every Foldr server that will use search, including the search server itself, one per line. This opens the built-in firewall to those addresses, so a server missing from the list simply won’t be able to reach the index.
The rest of the page you can usually leave alone. The commit settings control how quickly new files become searchable and how often the index is written to disk, and both carry an explanation on the page. The queue settings control how many files are processed at once, and are worth revisiting only if crawls are slower than you’d like on a machine with resources to spare.
Creating a core
A core is the container that holds the index and its configuration. On the Cores page, choose Add new and give it a name.
Search can hold several cores with many shares in each, but one core holding all your shares is the usual arrangement and the one to pick unless you have a reason not to.
Once shares are being indexed, this page is a useful thing to come back to: each core lists its size, how many records it holds, and which shares those records came from, so a share indexing far fewer files than you expected is visible at a glance.
Pointing shares at the index
With the service running and a core created, each share has to be told where its index lives. That’s on the share’s own Search page, under Show advanced settings: enter the search server’s address in Host, and the core you just made in Core name. Everything else about what gets indexed is in Indexing a share for search.
Two more things belong here though, because they’re about permissions and timing rather than content.
Every share being indexed needs a service account with at least read permission to the share and everything in it, set on the share’s Access page. Without one, the crawler can’t read the files.
Scheduling crawls
A share can be crawled on a schedule from its Settings page: daily, weekly or monthly with a time of day, or a cron expression when you need something more specific (0 2 * * * for two o’clock every morning). The default is never, which means the index only updates when someone runs a crawl by hand.
Exclusions
The Exclusions box on the same page keeps files out of the index. Foldr comes with sensible defaults for temporary and system files, and you can add your own, one per line:
temp.docxexcludes any file with that name*.pngexcludes all PNG files*temp*excludes any file with “temp” in its name*Temp*/*excludes any folder called Temp, and everything inside it
An entry containing a / is treated as a folder rather than a file.
Crawl as, or Index ACLs?
This is the part worth reading twice, because the two options solve different problems and they’re mutually exclusive on an SMB share.
Crawl as builds the index from a particular person’s point of view. The crawler impersonates each user in turn and indexes what that user can see, so results are naturally limited to files they have permission to open. It’s the right choice for personal shares such as home folders, where the storage address uses a variable like %homefolder% and every person has their own separate area.
The cost is repetition. Point Crawl as at a group of fifty people and the crawler works through the location fifty times, once each. On a home folders share that’s exactly what you want, since each pass covers a different person’s files. On a large shared SharePoint site it can take a very long time to get through, so think about the size of the group before you set it.
Index ACLs applies to SMB shares and reads the permissions on the files themselves, so one crawl serves everybody and results are filtered per person at search time. It’s the right choice for common shares with granular subfolder permissions.
If a share is flat, in that everyone with access to it can see all of it, you need neither.
Show results to all users with Read permissions
There’s a third option for the awkward middle case: a SharePoint site or Teams location with no granular permissions inside it, where crawling once per person would be pure waste. Switch on Show results to all users with Read permissions and you can crawl the location as a single user, once, with the results shown to everyone who has read access to it in Foldr.
Recommended settings
For home folders (%homefolder%):
- Crawl as: one or more directory security groups containing the people the share applies to. Don’t use Domain Users or other built-in groups.
- Index ACLs: off.
For common shares with a flat permission structure:
- Crawl as: unset.
- Index ACLs: off.
For common shares with granular permissions:
- Crawl as: unset.
- Index ACLs: on.
All three want a service account that can read the data being indexed.
For OneDrive, SharePoint or Teams locations you’ve chosen to index with Foldr rather than search through the provider, use Crawl as with a group containing the relevant people, and leave Index ACLs off. Service accounts aren’t needed where manual account linking is in use. Foldr can also track changes made outside Foldr efficiently rather than re-reading everything: see Indexing cloud storage with delta queries.
Where people actually search
Search is available in the web app, the mobile apps, and the desktop apps for Windows and macOS.
The desktop apps present search in a web view rather than as a native window, so it looks and behaves exactly as it does in a browser. It opens from the Foldr icon in the system tray or menu bar, or with a keyboard shortcut: Win + Shift + F on Windows, and Alt + Space on macOS, where the shortcut can also be changed under App Settings, on the Drive tab. Either way it needs search enabled on the server first. For the app releases and their settings, see Foldr for Windows and Foldr app for macOS.
Search isn’t available from the search box in Windows Explorer or the macOS Finder, which is worth mentioning to people before they go looking for it there.