ndOffice requires a database to keep track of user- and machine-specific settings. This database is called "EchoingStorage.sdf" and it relies upon a Microsoft technology which does not support connecting via SMB protocol (Network Windows shares).
On virtual systems, this poses two problems we are aware of:
1) Persistence of data - in XenApp and other solutions the instance of Windows may be destroyed after use. ndOffice requires a persistent store for this user.
2) Aggregate footprint gets larger - this can be dangerous, especially in XenApp configurations of Citrix, where a single Windows session on the server hosts many instances of the applications which are streamed. This leads to unpredictable footprint issues for the users, since the ndOffice echo locations are stored in folders underneath the database and are limited only by retention time policy.
There are many ways to set up Citrix. For the best results when using NetDocuments ndOffice, we recommend you use the following guidelines:
- Keep the ndOffice echo folder local to the ndoffice software. This typically means migrating the echo folder, and it's contents, with the user profile. This is especially important if your virtual environment utilizes more than one server. This is the solution that we know works with the highest reported degree of regularity.
- Pointing the ndOffice echo folder to a network share will cause errors to be generated. This is because the Microsoft technology for the ndOffice database doesn’t support using SMB connections to access the database, and it’s not good practice even without this limitation to Microsoft Compact Direct SQL.
- With ndOffice, there is not an option to not use the echo folder. You can reduce the footprint of the aggregate of echo locations, but the files and database need to be stored locally. You can place them on a share drive, but you must handle the copying down to the C drive before allowing the user to work, and then copy that data back to the share drive after the user session is ended.
ndOffice’s correct functioning depends upon this data being persistent. It cannot access the location via Windows share.
You could also consider using NAS storage and some other non-SMB method of accessing the drive as a locus for the ndOffice echo location (and therefore the EchoingStorage.sdf file).