Version: 2024.1.1

Troubleshooting

WebDav​

Webdav is not working with FQDN​

If the full DNS name of the server is not in the same domain as the client (e.g. abc.fake.net and userpc.domain.local), an entry must be made in the registry for the Windows client to send its credentials.

On each client PC, open the Registry and browse to this key:
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\WebClient\Parameters

Edit the Multi-String value AuthForwardServerList (REG_MULTI_SZ) and for example insert this values:

https://abc.fake.net
http://abc.fake.net

This causes Windows authentication to be used even if the name is a full-qualified domain name!
See: Prompt for credentials when you access WebDav-based FQDN sites in Windows

After this change, the WebClient service must be restarted!

First open of any document fails​

This could be a problem on the client side, when the WebClient service which is used to process webdav requests takes too long to start. The second request will succeed, because the service is then already running.

To resolve this, change the start-up type of the WebClient service to automatic.

How to re-enable office plugins after being disabled on startup​

When Outlook is opened and the inPoint.OutlookAddin loading took too long, it can happen that Outlook is showing a Question Dialog (Enable OR disable the inPoint.OutlookAddin). If the User once clicked "disable", the inPoint.OutlookAddin gets disabled forever!

Outlook creates a new registry value in the current users registry and sets the loadbehaviour=0, which means the Addin is not loaded anymore.

Remove this key completely and restart Outlook.

See: Registry entries for VSTO Add-ins

Upgrade process fails in the case of invalid user ids in the archive unit's DESC table​

The upgrade process from inPoint server 2020.1.3 or earlier version will fail in the case there are invalid user ids in the DOCCREATORID or DOCLASTMODIFIEDID fields in the archive unit's DESC table. The setup log will contain the following error message: The ALTER TABLE statement conflicted with the FOREIGN KEY constraint ... The conflict occured in database ..., table: PAM_USERREFERENCE, column: USER_ID. The invalid user ids are causing the foreign key constraint to fail because of broken referential integrity.

This conflict might occur when:

  • User has been removed from the PAM_USERREFERENCE table.
  • Archive unit was migrated from an older version.

Solution:

The invalid user ids in the DOCCREATORID or DOCLASTMODIFIEDID fields must be corrected manually in each archive unit's DESC table. Run the following queries for each archive unit's DESC table to retrieve the invalid user ids.

SELECT DISTINCT DOCCREATORID FROM <owner>.<archive unit's DESC table>
WHERE NOT DOCCREATORID IN (SELECT USER_ID FROM <owner>.PAM_USERREFERENCE)
SELECT DISTINCT DOCLASTMODIFIEDID FROM <owner>.<archive unit's DESC table>
WHERE NOT DOCLASTMODIFIEDID IN (SELECT USER_ID FROM <owner>.PAM_USERREFERENCE)

After fixing the user ids run the wizard again.

inPoint.Wizard: Warning dialog is shown if JAVA_HOME environment variable is set​

The inPoint.Wizard will show a warning dialog to inform the user to make sure that the JAVA_HOME environment variable contains a correct value.