Share Local Resources Between Users with Windows Remote Desktop Services

This new feature improves the local resources management of 4D Client merged applications executed with Windows Remote Desktop Services. Lets’ see how.

Windows Remote Desktop Services allows users to open a Windows session or a RemoteApp, inside and outside the company network. By doing this, users can connect to their applications from everywhere through an internet connection. When the application is not optimized for Internet bandwidth usage, Remote Desktop Services are often used to limit it: no data is exchanged between the application and the server but only screen changes.

The STANDARD architecture

When a 4D Client merged application connects to a 4D Server merged application, a check is performed to verify that the application source code (compiled code, forms, external resources, etc., usually called “local resources”) on the Client side is the same as the Server side. If needed, the application source code is then downloaded from the 4D Server by the 4D Client merged application and stored in the user folder:
\Users\{UserAccount}\AppData\Local\{ApplicationName}\{ServerInformation}_ClientFolderSignature\
E.g. C:\Users\John Doe\AppData\Local\myApp\myApp_192_168_2_134_19813_157\

So, when several users open the same 4D Client merged application on a Windows server with Remote Desktop Services, local resources are downloaded by each user in its own user folder. There is then a copy of the same files in each user folder.

A new architecture at your disposal

To improve local data storing and transferring, 4D has developed a new option for projects in the BuildApp process to allow local resources mutualization. It is activated by this new BuildApp XML key:
/Preferences4D/BuildApp/CS/ShareLocalResourcesOnWindowsClient

The legacy behavior prevails if the new key has a “False” value or is missing.
And if this new key has a “True” value, the 4D Client merged application will use the local resources placed in this common path:
\ProgramData\{ApplicationName}\{ServerInformation}_ClientFolderSignature\
e.g. C:\Program Data\myApp\myApp_192_168_2_134_19813_157\

blank

Note that the logs folder is still placed in the user folder to avoid concurrent writings.

Update process

Windows Remote Desktop Services administrators are often easy with the application update process, but we wanted to remind the best practices for performing updates. An Administrator shall:
1. Disconnect all users running the 4D Client merged application to update.
2. Forbid users access to the 4D Client merged application.
3. Update the 4D Server merged application.
4. If an automatic client update is activated: in the Administrator session, launch the 4D Client merged application and validate the automatic update process. At the end of the process, the 4D Client merged application will be launched, connected to the 4D Server merged application, and automatic local resources updates will be performed in the shared folder.
5. If automatic client update is deactivated: in the Administrator session, update manually the 4D Client merged application and launch it to connect to the 4D Server merged application and perform automatic local resources updates in the shared folder.
6. Allow users access to the 4D Client merged application.
This procedure will ensure that users are not launching several instances of the 4D Client merged application, avoiding concurrent writings to the shared local resources or writing rights errors.

Keep in mind

It was not a best practice to add/modify/delete files or folders in the local resources folder because of automatic updates from the Server. This is even more true with this new behavior because the local resources folder is shared between users and often read-only for standard users! Better use the user’s Documents folder or, eventually, the 4D User preferences folder.

Avatar
• Product Owner •Damien Fuzeau has joined the 4D Product team in February 2019. As a Product Owner, he is in charge of writing user stories, then translating them to functional specifications. His job also entails making sure that the feature implementations delivered are meeting the customer needs.Damien is graduated from the University of Nantes in software engineering. He spent more than 23 years in its former company, first as developer (discovering 4D in 1997), and later as engineering manager and software architect. This company is a 4D OEM partner and deployed 4D based business softwares for thousands users, on hundreds servers. So, Damien is used to 4D development and deployment in a multi-language context.