Ask The Experts: Filr and Vibe (42)

Welcome to this edition of questions and answers for Micro Focus Filr and Vibe.  In Filr news support pack 3.4.2 has now been released. This upgrade is available through the online update channel.  The main things that it has added is the long awaited support for Windows long paths and roaming profiles.

The next major release of Filr, version 4, is due to be released in the first half of next year.

Vibe 4.0.5 has also been released since the last issue. This features a number of significant changes including:

  • Easier installation, there is no need to install Java separately
  • Keyview instead of the Stellent viewers
  • Replacing the Java workflow viewer with HTML5
  • File upload applet replaced

Let me take this opportunity to remind you of the ideas portal where you can enter enhancement requests and vote on requests others have put in.  You can access the portal at:

    https://ideas.microfocus.com/mfi/novell-filr
    https://ideas.microfocus.com/mfi/mf-vibe

If you wish to ask me any questions then please email them to qanda@open-horizons.net, but let’s move onto answering some of the questions that I have received since the last issue.

Q: How many users can I have in my Filr system?  We have a thousand or so employees but the plan is to share documents with our customers which number in the 10s of thousands.  Can Filr scale that big?

A:  I am not sure that there is a known maximum number that we can support.  Obviously, you need to think about the design of the system and ensure that it can scale that big.

The largest system in the UK that I have seen is a university with about 45,000 users, (running on a 5 web node cluster) though I know there are bigger environments elsewhere in the world.

A few months ago, just for a bit of fun I imported 1 million users into a single server Filr system.  This was by no means any test or validation that Filr would support that number of users.  After all it was only running on my laptop.

That said all the dialogs in Web, Mobile and Desktop performed as expected and as a user I saw no degradation in performance.  The initial import was a bit under 4 hours and subsequent synchronisations were a little under 1 hour.

Q: We are running Filr in a totally air gapped environment.  How can I patch the Filr appliances when they have no way to connect to the online update?

A: I have come across a number of organisations that have totally isolated environments, which, as you can imagine, can cause issues with the online update.  However, there is a way of doing it with a disconnected Subscription Management Tool (SMT) server.

You actually need two SMT servers, one that can communicate with the update server and one on the isolated network.  You can then use a mobile storage disk to move the patches to the isolated SMT server from where they can be distributed to your appliances.

For more information have a look at https://www.suse.com/support/kb/doc/?id=7017998

Q: I have been advised only to have two search appliances in my cluster, why is that?  Surely having more will make indexing quicker?

A: The indexers that we use are not clustered and load balanced as you might expect.  Each search appliance is an indexer in its own right and works independently of any others you may have in the system.

When there is something to be indexed the web appliance will send the data to be indexed to each of the indexers that you have defined on the system.  Thus, the more indexers you have the more traffic that is generated and there is no performance benefit in generating the index.  However, when doing a read of the index, the appliance will spread its load between the nodes that you have enabled for reading.

Q:  How do I import nested groups info Filr from Active Directory?  I have the filter set as per the documentation but canonly importing users that are at the top level. I need to import users in sub groups, and sub-sub groups.

A: Many organisations will use a group to import a limited number of users into Filr rather than all their users, which would then need to be licensed.  The issue is that the filter given in the documentation

((memberOf=cn=groupname,ou=organizational_unit,dc=domain_component))

will only import users that are an explicit member of the group, any users in nested groups are ignored.  If you add all users to the group then within a large organisation this can cause issues with the management of this group, and keeping it up to date.  However, there is one way that members of nested groups can be imported into Filr.

All that needs to be done is to modify the LDAP filter to Include a special operator (1.2.840.113556.1.4.1941) that tells AD to walk the whole tree to see if there is a match. So as shown in figure 1 replace the existing filter with:

 ((memberof:1.2.840.113556.1.4.1941:=CN=<group>,OU=<container>,DC=<domain component>))

qa-fv-42-1
Figure 1: Setting the filter to include AD nested groups

Q:  We recently installed Filr and have been running the desktop without issue.  Now a couple of our users who recently joined the rollout have found that their desktop randomly attempts to download all the files in the system.  We have removed and reinstalled the desktop, but after a few days the same thing happens.  What is going wrong?

A: By default, the desktop client uses a blacklist to prevent unwanted applications from downloading files through the ‘Files on Demand’ mechanism, for instance anti-virus checkers that will try opening every file it finds.  However, if there is an application that is not known about, and has not been added to the Blacklist, such as ransomware, then it will be allowed to access files and download them locally to access.

I prefer to set up any install I do with the Whitelist option, where only those applications explicitly enabled will be allowed to download files on demand.  These applications typically are the office apps, pdf reader, notepad and so on.  If the user wishes to open a file with an unknown application which is not in the list then they can always ‘make the file available offline’ then open it with the application.

To find out which application is accessing files you can always use the option for a ‘Whitelist and Blacklist’ with which any unknown application that is accessing a file will prompt the user with the file name and whether the application should be allowed to dynamically download the file.

This of course is not something I would recommend leaving long term, after all we all know how users will always select the wrong option, but it is useful for a discovery stage.  Once you have the applications you want in the allowed list switch to a Whitelist only (see figure 2).

In this case the issue actually turned out to be a file called ccmexec.exe which is part of Microsoft SCCM that a couple of users had running to scan the local drives.  This was not included in the default Blacklist.  Once they switched to Whitelist only the issue went away.

qa-fv-42-2
Figure 2: Desktop set to Blacklist

Q: When viewing a file, users are clicking on ‘Edit this file’, and are then are getting an error.  I assume this is because we need Java to be installed on the workstations in order to run this feature.  Is there a way of disabling this option?

A: If you need to disable the whole of the edit in place functionality then you need to manually edit one of the configuration files to remove the option.  The file to edit is ssf.properties which is in
  /opt/novell/filr/apache-tomcat/webapps/ssf/WEB-INF/classes/config
Find the lines
edit.in.place.windows.editor.<extension>
For each extension comment out the line.  Once the file has been saved restart Filr.  You can do this at the command line of the appliance with rcfilr restart.

There is a setting called edit.in.place=True but changing this to False does not appear to disable the option.  Neither does removing the extension from edit.in.place.file.applet.extensions.

Note that this file, and the ssf-ext.properties, and ssf-additional.properties files are likely to be overwritten when you upgrade to version 4 so you may need to redo this after upgrading.

 

This article was first published in OHM Issue 42, 2018/3, p35-37.

Add a Comment