All Answers

Windows Server 2016 Essentials, or Windows Server 2016 Standard/Datacenter with the Windows Server Essentials Experience (WSEE) server role, MUST either be or see a DC. This limitation has nothing to do with my software (nor with RemoteApp per se), but is simply a requirement of the underlying “Essentials” features of the server operating system itself.

Basically, if you want to use WSE RemoteApp 2016 on Windows Server 2016 Standard/Datacenter (with the WSEE server role) without the server needing to be a domain controller, then you can join it to a second server that is acting as the primary domain controller. For more information, see the “Additional Information (Advanced)” section on the WSE RemoteApp 2016 home page.

EDIT: If you simply want to make a Windows Server Essentials server behave like Windows Home Server 2011 did (which was based on Windows Server 2008 R2 and wasn’t a DC), then you can always just use Microsoft’s “SkipDomainJoin” registry setting in order to prevent your client computers from having to join the Essentials server’s domain as described in the following articles:

How to make Windows Server 2012 R2 Essentials client connector install behave just like Windows Home Server

Connect computers to a Windows Server Essentials server without joining the domain

WSE RemoteApp 2016 is fully compatible with such a scenario, and would basically amount to you being able to run Windows Server 2016 Essentials, or Windows Server 2016 Standard/Datacenter (with the WSEE server role), as a domain controller, without requiring you to have any of your client computers joined to the domain. This is exactly how I run my own home and small business Essentials servers.

Thank you for alerting me to the problem with our email support form. I have corrected the issue, and it should be working properly now.

As for your Word automation problem… I’m not exactly sure what’s happening on that one as I haven’t experimented with using automation to open Microsoft Word documents from another application/program while it is being run under Windows Server (as a RemoteApp program or straight from a standard Remote Desktop Connection for that matter). Perhaps your question would be better off being asked in one of Microsoft’s Office, Windows Server, or Remote Desktop specific TechNet forums.

Please see: Microsoft Licensing

Alas, I’m afraid that the list of server folders that appear in the notification area context menu is fixed and cannot be modified. That being said, you can easily publish a shortcut to whatever folder(s) you want in WSE RemoteApp by doing the following:

• Open the server Dashboard and go to the “WSE RemoteApp” page.
• Click on the “RemoteApp Programs” subtab.
• Click on the “Publish RemoteApp Programs” task.
• Click on “Add Another Program…” and browse to/open: C:\Windows\explorer.exe
• When you are prompted to “Add a shortcut to the program?“, answer “Yes“.
• Click “Next” and finish publishing the new “Windows Explorer” shortcut.
• Select the newly published “Windows Explorer” shortcut in the list of published RemoteApp programs, and click on the “View the RemoteApp programs properties” task.
• In the RemoteApp Properties window that appears, click on “Properties“, and set the “Target” value of the shortcut to the folder that you wish to publish as a RemoteApp program (e.g. “\\SERVER\Shared Folders“, etc.), and click on “OK” to save your changes. NOTE: Make sure that the users have permission to access the folder that you are publishing.
• Complete the RemoteApp Properties wizard as desired. NOTE: You can change the name of the shortcut (e.g. to “Shared Folders“, etc.), change the folder’s icon, set its comment/tooltip, set its allowed users, etc. all from the RemoteApp Properties wizard as you see fit.

You can then repeat the above steps as many times as you’d like in order to publish multiple different folder shortcuts as RemoteApp programs.

EDIT: I’ll certainly look into adding a “Shared Folders” shortcut to the add-in’s context menu (Although I’m not sure if it’s really required seeing as the users should already have access to it from their client computer’s desktop [i.e. from the “Shared Folders” shortcut that gets added to their desktop when the Windows Server Essentials Connector software is installed on their client computers]. I suppose that there can be cases where the connector software, and hence the shortcut, is not installed on the user’s client computer though.).

Alas, WSE RemoteApp does not currently allow you to redirect (COM) ports into the established remote session. I’ll see if I can add a checkbox (within the add-in’s Remote Desktop Options dialog boxes and drop-down menu) that will allow you to do that in the next release of the program.

If the user is signed in to WSE RemoteApp from a Windows-based client computer, then the Taskbar should be there (i.e. down at the bottom of the screen where the system clock is located). When a WSE RemoteApp session is running on the client computer, WSE RemoteApp will add its very own icon to the notification area of the client computer’s Taskbar (note that you may need to click on the upward facing “Show hidden icons” arrow in order to see any notification area icons that are currently inactive and have been hidden from the main view of the Taskbar’s notification area). Once you’ve located WSE RemoteApp’s notification area icon, simply right-click on it, and then go to: Settings ->  Lock after

It doesn’t matter if your client computers are domain joined or not. The only thing that matters is if they have the Windows Server Essentials Connector software (i.e. the Launchpad, etc.) installed on them. Any client computer that has the server’s Launchpad application installed on it will automatically receive WSE RemoteApp’s client-side components (assuming that you choose the option to install the add-in on your network computers when you initially installed/updated it that is).

If your client computers are not connected to the server (i.e. if they don’t have the Windows Server Essentials Connector software installed on them), then you cannot take advantage of WSE RemoteApp’s local connections. Rather, you would need to remotely connect from those client computers instead using either the server’s built-in Remote Web Access website (for which WSE RemoteApp provides a gadget on its homepage), or the add-in’s RADC web feeds functionality.

Basically, WSE RemoteApp offers three ways for your users to connect to the RemoteApp programs that you have published:

1. Locally via the Launchpad (or desktop/Start menu shortcuts).
2. Remotely via the Remote Web Access website.
3. Remotely via the RADC web feeds.

WSE RemoteApp allows you to hide certain items (such as all of the local server drives [C:, D:, etc.], all of the Network drives, etc.) from the navigation pane of This PC / File Explorer (or Computer / Explorer) in your user’s RemoteApp sessions as follows:

1. Open the server Dashboard application and go to the “WSE RemoteApp” page.
2. Click on the “Server Access Settings” task.
3. Under the “Access Restrictions” section, check the checkboxes for the server items that you want to hide/block user access to.
4. Click on the “Save” button to save your changes.

Note that your users “may” need to actually sign out (or log off) of their current RemoteApp session (and not just disconnect it) in order for the changes to take place. Also, please make note of the informational tips that appear whenever you hover your mouse over the little thought bubble icons seeing as enabling some of the settings may affect compatibility with some services, applications, etc.

That “should” cover most of the common items. However, if you need to hide other select items (such as individual CD drives, Network drives, etc.), then you’ll most likely need to do some research on the Internet to see if it can be done (using Local Group Policy or Registry settings, etc.). I try to cover the more common ones, but it’s just not possible for me to do them all (especially those that vary from server to server).

Alas, I’m afraid that change logs are not available for update releases at this time. I’ve been meaning to address this (for quite some time now <gulp>), but it’s still on my “to do” list. Mea culpa!

Any version and/or edition of Microsoft Office (Home & Business 2016, etc., etc.) that you buy outright will work just fine with WSE RemoteApp (both 32-bit and 64-bit). Even the downloadable version of Office 2016 that’s included with an Office 365 subscription will work. Simply install Office directly on the Essentials server, and it will be available for you to use with WSE RemoteApp.

Alas, I’m not able to replicate this one here on any of our in-house test servers and/or clients. And to date, no one else has reported a similar issue that I am aware of. It doesn’t sound like an issue with WHS RemoteApp, but more of an issue with the underlying network connection from the client to your server (hence, restarting its Provider service will not make any difference).

Does it happen on all of your client computers, or just the one?

Are you certain that you have all of the latest Windows Updates installed on both your server and your client computers?

Is this something that only just recently started occurring, or has it been an issue for you since you very first started using WHS RemoteApp? If it only recently started happening, then do you recall doing anything to the server/client, or to your local network, router, firewall, etc. that may have triggered it? Have you tried restoring your server (from server backup) back to a point in time before you first started seeing the issue?

Lastly, that particular error message will be shown to the user (by the underlying Remote Desktop Connection functionality of the client computer, and not by WHS RemoteApp) if the client computer is unable to locate a valid IP address for the server. Is your server using a dynamically assigned private IP address (which is the default configuration in WHS 2011)? If so, then I’d try configuring static IP addressing on the server for more consistent results.

Alas, I’m afraid that WSE RemoteApp’s user interface (UI) cannot be (re)branded at this time. I’ve had other requests for doing this, so it is indeed on my list of product enhancements to be considered for a future release of the software.