Over the past several years, FileMaker has entered the cloud computing landscape. FileMaker Server can be run in the cloud through a cloud services provider such as Amazon Web Services (AWS) or Microsoft Azure. And in late 2016, FileMaker unveiled FileMaker Cloud, a new AWS-based service that allows you to deploy a FileMaker server without having to spend the time and resources normally required to build out and manage a server machine. The benefits of cloud computing are many. Reliability, availability, redundancy, scalability, security, and cost optimization are all reasons to consider employing cloud services for your computing infrastructure needs. The fact that you can provision a FileMaker Cloud server and not have to worry about hardware failure or replacement, disaster recovery, or managing the server OS, makes the prospect of running a local server machine much less attractive (though there might still be valid reasons to do so). Even with all these benefits, running FileMaker Server in AWS does have its drawbacks. Chief among these is performance: If you’re connecting from your office to a FileMaker database hosted in AWS, you’re doing so over the WAN. There are ways to optimize FileMaker for WAN performance, but if your database is sufficiently complicated, performance over the WAN simply might not be workable. Enter AppStream. Amazon’s AppStream 2.0 is an application streaming service that allows you to stream desktop applications from AWS to a user through a web browser. Because AppStream instances live in AWS, you can configure a fleet to run in the same AWS region as your FileMaker server, effectively putting them in the same local network and giving you the speed of a LAN connection. Moreover, since AppStream applications are delivered through a web browser, users don’t actually have to install FileMaker Pro on their local machines. You also get the benefit of elastic pricing with AWS; you only pay running instance fees when there are active user sessions. These factors make AppStream worthy of consideration for anyone hosting their FileMaker solution(s) in AWS. Skeleton Key recently had a project that involved an AppStream deployment. Since this was our first time working with the service, we thought we’d share our findings. We’ll start with an overview of the AppStream architecture and then dive into specifics on how running FileMaker Pro inside AppStream differs from the standard FileMaker experience.

How it works

AWS account

AppStream runs in AWS, so if you’re interested in setting up an AppStream environment, the first thing you’ll need is an AWS account. If you’re already running a FileMaker Cloud server, or a regular FileMaker Server in AWS, you’ll already have this set up, but if not, it’s pretty straightforward. Do bear in mind that there are costs associated with most AppStream resources, so any testing you want to do will incur some cost.

Setup

Using the AppStream image builder, you create an image that contains the application(s) you want to make available for streaming, such as FileMaker Pro. You then configure a fleet, or a set of instances running this image. Fleet options include AWS instance type (to meet your particular performance requirements), capacity (minimum and maximum number of running instances), and scaling policies (to dynamically create or reduce available instances based on user demand). Finally, you create a stack, which controls access to your fleet. Note that currently the only OS platform available in AppStream that is supported by FileMaker Pro is Windows Server 20xx. This has several implications that we’ll get into shortly.

In the AppStream image builder, use the Image Assistant to select the applications you want to make available to your streaming users.

Users and access

With your base image, fleet, and stack in place, it’s time to get your users connected. Through the AppStream user pool, you add your users and assign them to your stack. Each user gets a welcome email and a link to your AppStream URL. This URL is the same for everyone in your user pool, so it’s easy to keep track of, and while the URL itself is a bit ugly, you can use a URL shortening service like Bitly to create a custom link that’s easy to remember. Note that AppStream sessions can only be run on browsers with full HTML 5 support, including Google Chrome, Mozilla Firefox, Microsoft Internet Explorer, and Microsoft Edge. It will not currently run on Safari.

User Experience

After logging into AppStream, you land on the catalog screen which displays icons for each streaming application defined for your image. You then simply click on an icon to launch the application. While working in AppStream is similar to a remote desktop experience, the remote machine is not fully exposed to you; you only have access to the applications that are configured for streaming and listed on the catalog screen. The first thing you’ll notice after opening a FileMaker database via AppStream is that you’re getting the FileMaker Pro client experience. You’re working in a web browser, but it’s not WebDirect, it’s FileMaker Pro. That’s pretty slick! You’ll also see that you’re getting the Windows flavor of FileMaker Pro. This will be a bit of a change for folks who are used to running FileMaker Pro directly on their Mac. However, with the release of FileMaker Pro 16, the Windows interface has been significantly improved and now works more like the Mac OS version, so this is less of an issue than it might have been for earlier versions. While AppStream gives you the FileMaker Pro experience, there are several peculiarities to the AppStream interface that make it its own animal.

Home Folders

During an AppStream session, FileMaker can only access data that is local to the Windows instance you’re connected to. This means that, for example, anytime you want to insert or download a container file, or import from or export to an Excel file, you need to take additional steps to move the associated file between your local machine and AppStream (or vice versa). This is done using the Home Folders feature, which is an extension of Amazon S3 bucket storage. A user’s Home Folder behaves like a normal Windows folder, but it is specific to the user and cannot be accessed by other users. To move files between your machine and AppStream, use the My Files menu from the web view session toolbar. From there, you can upload to or download from your Home Folder. To access your Home Folder within FileMaker Pro, it appears as a folder under This PC in the file browser. One oddity with the Home Folders feature is that while you can save and rename files in your Home Folder, there isn’t currently a way to delete a file within AppStream. The only way this can be done at present is through the Amazon S3 dashboard in the AWS Console, which is probably not something you would want to grant access to for your users. Hopefully Amazon will address this at some point.

An AppStream user’s Home Folder is available under the My Files menu.

Printing

Printing from FileMaker in AppStream is, for the most part, surprisingly seamless. The native print command opens the standard Windows print dialog box. Amazon’s “DCV Printer” is the default selected printer, and clicking OK will generate a PDF of the current layout in a new browser tab or window (based on your browser’s settings). From there you use your native browser’s options for printing to a local printer or downloading the PDF. Because the user will always need to choose what to do with the PDF in the new browser tab, you can save them an extra mouse click with any scripted print by turning off the user dialog in the Print script step. In our testing we found that the Amazon print driver’s minimum print margins are larger than expected, resulting in content of PDF’s getting cut off for some layouts. Your mileage may vary; be sure to test every report your users might access via AppStream and adjust the layouts as necessary. You can also use FileMaker’s Save as PDF function. This works as expected and avoids the minimum page margin issues noted above. However, it utilizes the Home Folders feature, so it requires an extra step to move a PDF all the way down to your local machine.

Clipboard

Working with the clipboard is one of the more awkward tasks with AppStream, since AppStream’s clipboard is separate from your local machine’s clipboard. If you are logged into a FileMaker database and want to copy a value from one field and paste it to another, that all happens within AppStream’s clipboard and is fairly straightforward. Just keep in mind that you are working in a Windows environment, so you need to use the Windows keyboard shortcuts (control key instead of the command key) even if you’re working on a Mac. On the other hand, say you want to copy a value from a message in your local email client and paste it into FileMaker running in an AppStream session. This requires moving the value from your local clipboard to AppStream’s clipboard. To do this, open AppStream’s clipboard menu in the web view session toolbar, and select the Paste to Remote Session option. Then use your local machine’s keyboard shortcut to paste the value to the remote AppStream session. You would finally use the Windows keyboard shortcut to paste the value into FileMaker. To copy from an AppStream session to your local machine, just reverse the sequence: Copy the value in AppStream using the Windows shortcut, open the AppStream clipboard menu and choose Copy to Local Device, use your local machine’s keyboard shortcut to copy the value to your local clipboard, and then finally paste the value as you normally would into your local application. It takes a bit of practice to make these tasks routine.

AppStream’s clipboard menu.

Be sure to test!

One strange issue we encountered was an apparent errant record locking behavior with a simple scripted action. Our database has a layout with web viewer running a data URL (more on this below). Clicking a particular button in the web viewer runs a script via FileMaker URL that opens a new window, goes to a layout, finds a record, and modifies it. The layout in the new window is configured to run a triggered script on layout load which also sets a few fields. This process worked fine for years, but when using the database via AppStream, the Set Fields initiated by the triggered action intermittently failed with a record locking error. After a lot of testing, it turned out that the initial new window action was sometimes opening two windows, and the first window was causing the record lock. We simply attributed this to slight behavioral differences with AppStream (in our case with triggering a script from a web viewer using a FileMaker URL), and we were able to script around it. More generally, though, it’s an indication that one should plan for unexpected quirks when deploying AppStream environments for use with FileMaker, and it’s important to perform a full test of your FileMaker app within Appstream to identify and address any issues as early as possible.

AppStream Persistence Considerations

Beyond these basic differences in FileMaker’s behavior between a standard client experience and an AppStream session, there are more fundamental aspects of AppStream’s architecture that will impact your FileMaker AppStream deployment. When a user launches an AppStream session, they connect to an instance of your base image that is running as part of your fleet. This instance does not persist over time; it is dynamically created and later eliminated, all based on how you configured your fleet. As a result, any changes to the machine or to local user settings during a user’s session are lost when the user’s session ends. The only exception to this is files stored in Home Folders as described above. Below are some specific persistence-related issues to be aware of.

FileMaker Pro updates and other application patches

When FileMaker releases a new patch for FileMaker Pro, users will get a software update prompt the next time FileMaker Pro launches, and this is no different for FileMaker Pro running on AppStream. However, any software updates run on an AppStream instance are temporary, since the instance does not persist. This behavior will not be intuitive to users, so you will need to advise your users to ignore any software update prompts. The solution is to run FileMaker Pro and other software patches in the AppStream image builder instance. You then create a new image and associate your fleet with the new image.

FileMaker Pro settings

For FileMaker Pro, the lack of persistence with local user settings impacts very basic things like favorite hosts, favorite files, default account name, file cache size, and more. The most impactful of these limitations is the inability to save favorite hosts and files. If we don’t want users to have to browse for their FileMaker server and hosted files each time they want to open a database while connected to AppStream, the solution is to create a dedicated AppStream “App” for each database your users will need to access. When you create an App in the AppStream Image Assistant, you select the FileMaker Pro executable file as the application launch path, but you can also specify a custom display name and launch parameter. To customize the App for a particular database, enter an appropriate display name, and then create and specify a launcher file as the launch parameter. The launcher file is a traditional FileMaker Pro “opener” file which has a single script configured to run on open that opens the remote database and then closes itself. AppStream allows you to create multiple application instances for the same underlying application, so you can just repeat this process for each database. The only catch is that the underlying App name, in addition to the display name, needs to be unique. The name defaults to “FileMaker_Pro,” so you can simply append a different sequential number (or some other value) to the end of the name for each App definition. With your AppStream Apps created in this way, the user’s AppStream catalog screen functions in much the same way as the Favorites section of the FileMaker Pro Launch Center. The user will see icons for each of their databases, and clicking on an icon will open FileMaker Pro and run the launcher file to open the remote database.

AppStream catalog screen with FileMaker databases configured as individual Apps.

At present we haven’t figured out a way to configure AppStream to set and remember a user’s default account name. It may be possible to accomplish this through Local Group Policy and a Windows startup script (similar to how we handle the time zone below), but that’s a future exploration.

Time zone

By default, Windows Server 2012 and higher resets its time zone to UTC time after a restart. If you try to update the time zone in the image builder instance, it doesn’t persist into the image you create with it. When users run FileMaker in an AppStream session, FileMaker uses the AppStream instance’s time zone for time considerations such as auto-enter timestamps. If your FileMaker solution requires this information to be accurate, you’ll need to take additional steps to ensure time zone accuracy. The solution is to configure the Local Group Policy in the image builder instance to run a startup script that changes the time zone. Local Group Policy persists into the base image and hence into AppStream instances, so with this in place, as each AppStream instance is created, the time zone is set at startup.

Internet security settings

Another case where local user settings can come into play with AppStream and FileMaker is internet security. By default, Windows Server 20xx comes with Internet Explorer Enhanced Security Configuration enabled. This can cause certain websites to not display properly (or function at all), block downloads, and cause other potentially undesirable behavior. For FileMaker, this obviously comes into play when running an Open URL script step, but it also impacts use of the web viewer object. Web viewers use the operating system’s built-in web browser technology, so for Windows Server, that means Internet Explorer, and IE’s security settings are in play. Internet Explorer security settings can even interfere with data URL’s in the web viewer. For example, our particular client’s application uses the Reactor plug-in to render a calendar in a web viewer. Reactor constructs elements of the data URL using the loopback IP address (127.0.0.1), and since IE Enhanced Security Configuration blocks this, the web viewer displayed an IE security message instead of the calendar. Normally, the fix would be to simply have the user open IE and add 127.0.0.1 to their intranet zone trusted sites list, but in AppStream, such a change would not persist beyond the user’s current session. As with the time zone, this must be dealt with in the image builder. And similar to the time zone setting, simply changing Internet Explorer’s security settings directly through IE’s interface will not persist into the fleet instances running the base image. This is because IE security settings are stored at the user level. Work done in the image builder happens under the Administrator user profile, but when regular users connect to an AppStream instance, the Windows instance builds them a new user profile when they log in. This user profile is based on the Windows default user profile, so the fix is to update the IE settings for the default user profile. This involves working in the Windows Registry Editor, which is a little complicated, especially if you’re not familiar with how the Windows registry works.

Conclusion

As you can see, AppStream’s architecture introduces many complications when used to stream FileMaker database connections. Some of these are more problematic than others. In our experience, though, none of these were deal breakers, and AppStream solved the primary need for our particular project, which was LAN-level performance for a database running on FileMaker Cloud. This demonstrated to us that AppStream is a viable tool for use with FileMaker and that it should be considered for use with any FileMaker deployment in AWS where performance is a top priority. One last note: in the interest of keeping the flow of this post as smooth as possible, we left out details on many of the tasks described, such as setting the time zone through local group policy, configuring FileMaker launcher files for use with AppStream, and modifying Internet Explorer security settings in the registry. If you’d like to see any of these fleshed out in a follow-up article, please comment below!

Resources

Amazon AppStream 2.0 Homepage AppStream 2.o Developer Guide For additional information on FileMaker, AWS, and AppStream, see this excellent post from Mike Duncan at Soliant Consulting.   Stu Dietz is a FileMaker 16 Certified Developer at Skeleton Key in St. Louis, MO.

About Skeleton Key

Skeleton Key helps turn complex, complicated, and outdated systems into true information platforms. Our team of consultants and developers do this by developing custom-fit software tools and reporting dashboards that help businesses find, use, and understand their data, freeing them to focus on and grow their core business. In addition to custom databases and applications, we also provide training and coaching for getting the most out of your existing systems and understanding your unruly data. Skeleton Key is an open-book management company and active player of the Great Game of Business.