All Answers
That’s pretty much just a standard-issue warning message. The feature isn’t “officially” supported because it involves a (very tiny) modification made to a single system file (amongst other things). As such, there is always a very slight possibility that Microsoft could drastically change something in the operating system that would prevent it from working properly in the future (hence the warning so you know that up front). And of course having a backup of your server (especially before making any changes to it) is always a good practice.
That being said… The feature is pretty much rock solid. It has been in use in nearly all of my products for well over a decade now (i.e. since the early days of Windows Server 2003 at least!). On very rare occasions (i.e. less than a handful of times in the long history of my products), an operating system update has disrupted the feature. But in all of those cases its functionality was completely restored within a few hours of discovery. Therefore, there could be times when you would need to install the latest version of the product in order to resume full functionality of some of its features. In general, it’s very rare that a Windows Update ever disrupts/breaks any of my products, but in full disclosure, it has happened a few times over the years. Hence, the reason I have renewable (or lifetime) updates and support offerings for my products.
All of my products receive regular updates (with improvements, enhancements, bug fixes, security enhancements, brand new features, feature changes, etc., etc.). In fact, some may argue that they are updated maybe too frequently. However, I am fully committed to the products and I am constantly updating them (as I have been for many, many, years now).
As for other considerations or benefits… The quality and usefulness of my products speak for themselves. That’s why I offer a long 21-day evaluation period, and then a further 30-day no-questions-asked refund policy after your initial purchase, on all of my products. Therefore, I suggest that you install it and give it a go to see how well it works for you. As always, I more than welcome feedback on my products (both good and bad).
Thanks for your interest in my software.
- Mike answered 8 years ago
- last active 8 years ago
This still did not help. Still dont see icons…
- JASON answered 8 years ago
- last active 8 years ago
Thank you for your answer.
Now it works. I have found out, that there are no apps visible when I connect as administrator. Now I have switched to a “normal” user and can see the apps.
Great work mike.
Thank you very much.
best regards
heuby
- heuby answered 8 years ago
- last active 8 years ago
@heuby,
Glad to hear that you got it working. WSE RemoteApp is designed to work with Standard user accounts (although it will work with Administrator accounts if you really want/need it to, but I certainly don’t recommend doing that unless you have some specific app that absolutely must be run as an administrator). Additionally, the published RemoteApp programs that appear within the WSE RemoteApp Launcher window are specific to the user that is currently signed in. If the signed in user has no RemoteApp programs that have been published for them, then the window will indeed be blank/empty (although, in such a case, they should see a notification telling them to contact their network administrator to have him/her publish some apps for them).
@JASON,
So you tried my above suggestions and none of them worked for you? You say that you “still don’t see icons”. Does that mean that you are able to add the feed to the Microsoft Remote Desktop client app, but that no published RemoteApp programs show up within the app when the feed is added? Or, does the Microsoft Remote Desktop client app simply give you an error stating that it cannot find the feed (i.e. is it a discoverability issue)?
I believe that I sent you a separate email message on this one asking some additional details about your set up (i.e. what edition and version of the client you are using, etc.). I’ll need answers to those questions so that I can look into this further for you (i.e. so that I can try to replicate what you’re using and doing in order to reproduce the issue here).
Also, have you made changes to any of the settings that are listed on the “Security” tab of the “Remote Desktop Session Settings” task that’s available on the “WSE REMOTEAPP” page of the server Dashboard (as some of those settings will affect some RADC client’s ability to be able to connect to the RADC web feed (although they typically will not affect the feed’s discoverability).
- Mike answered 8 years ago
- last active 8 years ago
This is how I would approach this one:
1. Start the server Dashboard, go to the “WSE REMOTEAPP” page, and click on the “RemoteApp Programs” subtab.
2. Click on the “Publish RemoteApp programs” task.
3. Click on the “Add Another Program” button, and then locate and open your Acomba.exe program.
4. When you are prompted to add a shortcut to the program click on the “Yes” button.
5. Repeat steps 2-4 above for each different user who needs to use a specific config with Acomba.exe.
6. Complete the remainder of the Publish RemoteApp Programs wizard.
You will now have multiple published shortcuts for the Acomba.exe program (e.g. “Acomba“, “Acomba – Shortcut (2)“, “Acomba – Shortcut (3)“, etc.).
Double-click on the first shortcut (e.g. “Acomba“), in order to open the RemoteApp Properties wizard for it, and then do the following:
1. On the first panel of the wizard, change the shortcut’s name so that it represents one of your Acomba users (e.g. “Acomba – Mike“).
2. Click on the “Properties” button, and on the Acomba Properties window that opens, adjust the Target value of the shortcut so that it has the proper exe parameters/config that you desire (e.g. “C:\Acomba\Acomba.exe” /config1).
3. Once you have set the required exe parameters/config for the user’s Acomba shortcut, click on the OK button in order to save your changes.
4. On the second panel of the wizard, choose the “Only specified users and groups” option, and then check the checkbox for only the user who the shortcut is specific for (e.g. “Mike“).
5. Complete the remainder of the RemoteApp Properties wizard.
6. Repeat steps 1-5 above for each different Acomba shortcut/user.
In the end, you will have an Acomba shortcut that is specific for each different user (e.g “Acomba – Mike“, “Acomba – Marc“, etc.). Then, when the specific user signs in to WSE RemoteApp, they will only see the Acomba shortcut that is specific for them, and that runs their specific config in the Acomba.exe application.
Alternatively, you could also manually create a separate Acomba.BAT file for each specific Acomba user (that simply runs the command line for Acomba.exe with the specific exe parameters/config for the specific user), and then publish each separate Acomba.BAT file as a separate RemoteApp program in WSE RemoteApp. It’s pretty much the same result either way though.
I hope that helps you out some.
- Mike answered 8 years ago
- last active 8 years ago
Thanks that was the way i was thinking to use. That mean it not possible to edit shortcut directly on each computer for set info. thanks.
- Marc Baril answered 8 years ago
- last active 8 years ago
When a user signs in to WSE RemoteApp and opens up its main “WSE RemoteApp Launcher” window, they should only ever see their very own list of published RemoteApp programs.
Unfortunately, there is no way to prevent individual published RemoteApp programs from showing up within the Launchpad (or on the Desktop or Start menu/screen) for a specific user. However, that being said, if a user attempts to run one of the published RemoteApp programs that isn’t theirs, then WSE RemoteApp will not allow them to do so (i.e. it will alert them that they have not been granted permission to use that particular published RemoteApp program).
The reason it works like this is because there can be multiple users signing in to WSE RemoteApp from a single client computer (and not just the user that is currently signed in to Windows at the time – i.e. it acts like a kiosk). Since WSE RemoteApp always prompts the user for sign in credentials when they first launch a published RemoteApp program from the client computer, it will accept any “allowed” user’s credentials. Therefore, WSE RemoteApp cannot hide any of the published RemoteApp programs on the client computer (on a per-user basis) seeing as it never knows which user will be signing in.
If you don’t want this happening, then the best way to approach it is as follows:
1. Open the server Dashboard, go to the “WSE REMOTEAPP” page, and click on the “RemoteApp Programs” subtab.
2. Click on the “RemoteApp program client settings” task.
3. Under the “Launchpad” section, uncheck the “Add RemoteApp programs to Launchpad” checkbox.
4. Under the “Shortcuts” section, uncheck the “Add RemoteApp programs to Start menu/screen” checkbox (which will also automatically uncheck the “Add RemoteApp programs to Desktop” checkbox).
5. Click on the “Save” button in order to save your changes.
Now, the very next time a user signs in to WSE RemoteApp from the client PC, all of the published RemoteApp programs will be removed from the Launchpad, Desktop, and Start menu/screen.
From then on, they can just use the main “WSE RemoteApp Launcher” (or “Launcher“) item in order to sign in to WSE RemoteApp. Then, when the main Launcher window appears, they will only ever see their very own specific RemoteApp programs, and they can open them directly from there instead.
I hope that helps you out some.
BTW, if anyone has a better way to approach this one, I’m all ears.
- Mike answered 8 years ago
- last active 8 years ago
I’m not able to replicate this one here on any of our in-house Essentials servers.
Please take a look at the Dashboard.log file on your Essentials server to see if it offers any hints as to why the crash is happening. Simply open the Dashboard.log file in Notepad, scroll down to the very bottom of the file, and then work your way upwards to see if it shows anything related to the crash (such as a fatal exception, etc.).
NOTE: You can find the Dashboard.log file in the following location over on your Essentials server:
C:\ProgramData\Microsoft\Windows Server\Logs
Lastly, do you happen to have any other add-ins installed on your server? If so, then you can start the server Dashboard in “Safe Mode” (using the “Windows Server Essentials Dashboard (Safe mode)” shortcut that is located within the “Windows Server Essentials” group on the server’s Start menu/screen), and temporarily disable them just to see if they are interfering with WSE RemoteApp.
- Mike answered 8 years ago
The server is a brand new installation of windows 2012r2 essential edition fully patched (inside a vmware VM). Anywhere access is up and running and works good.
Wse remote access is the only add-in installed.
After installing the add-in, I’m able to use all the function and correctly publish all the application I need.
Right after enabling the first user to access published applications, the dashboard close. Since then, dashboard open successfully and all original features works good, but dashboard close itself every time i click on wse remote access tab.
Safe mode start is unnecessary because dashboard has no problem to open.
The applications published during the first configuration are working correctly and the user that I enabled prior to crash is able to access them. Anyhow, I cannot enable a second or third user, because is impossible to open wse remote access tab.
Here the dashboard.log excerpt.
Thank you for your support
[2928] 180528.223057.7083: Dashboard.Forms: !!!!FATAL: Dashboard shutting down due to unhandled exception: Could not load type ‘Microsoft.WindowsServerSolutions.Common.ProductRegistry’ from assembly ‘Common, Version=6.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’.
[2928] 180528.223057.8027: Dashboard.Forms: System.TypeLoadException: Could not load type ‘Microsoft.WindowsServerSolutions.Common.ProductRegistry’ from assembly ‘Common, Version=6.3.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35’.
at .(Boolean )
at .(Boolean , String& , String& )
at ..(User )
at Microsoft.WindowsServerSolutions.Administration.ObjectModel.ListColumn`1.<>c__DisplayClassa.<Microsoft.WindowsServerSolutions.Administration.ObjectModel.Internal.IListColumn.GetIcon>b__8()
at Microsoft.WindowsServerSolutions.Administration.ObjectModel.Internal.ExceptionHandler.Run[T](ProtectedCallback`1 action)
at Microsoft.WindowsServerSolutions.Dashboard.Forms.Controls.PresentationRecordColumn.Format(Object value)
at Microsoft.MidMarketServer.UI.ConsoleListView.GetFormattedValue(IFormatTemplate formatter, Object value)
at Microsoft.MidMarketServer.UI.ConsoleListView.HandleReflectionNotify(tagNMHDR* pnmh, Int32& result)
at Microsoft.MidMarketServer.UI.ConsoleListView.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.SendMessage(HandleRef hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at System.Windows.Forms.Control.SendMessage(Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.Control.WmNotify(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
at System.Windows.Forms.UnsafeNativeMethods.CallWindowProc(IntPtr wndProc, IntPtr hWnd, Int32 msg, IntPtr wParam, IntPtr lParam)
at System.Windows.Forms.NativeWindow.DefWndProc(Message& m)
at System.Windows.Forms.Control.WndProc(Message& m)
at Microsoft.MidMarketServer.UI.ConsoleListView.WndProc(Message& m)
at System.Windows.Forms.NativeWindow.DebuggableCallback(IntPtr hWnd, Int32 msg, IntPtr wparam, IntPtr lparam)
- tonyrid answered 8 years ago
I get able to make it half work… I removed outlook 2016 for add outlook 2013 and extented mapi appear now in the app and instead of getting unreadable error I get: Not default email programme for sending email error(in french). Directly from server on admin account that work.
- XGuarden answered 8 years ago
I’m afraid this is a strange one…
Again, I’m not able to reproduce the problem here on any of our in-house Windows Server 2012 R2 Essentials servers, and to date, no one else has reported a similar issue that I am currently aware of.
According to the log file information that you’ve provided (and the really nice video too!), the Dashboard is crashing because it is unable to load a specific Type from a file that is installed by default into the GAC on the Essentials server.
Since this is a native Essentials-provided file, and has nothing to do WSE RemoteApp, I’m not exactly sure what’s going on there. The file it is complaining about is named “Common.dll” and in should be found in the GAC of your Essentials server in the following location:
C:\Windows\Microsoft.NET\assembly\GAC_MSIL\Common\v4.0_6.3.0.0__31bf3856ad364e35
Does that file exist on your Essentials server? And if so, what version is currently installed (I’m seeing Version 6.3.9600.17238)?
Also, do you have all of the latest Windows Updates installed on your Essentials server?
Lastly, what version of WSE RemoteApp 2012 R2 is currently installed on your Essentials server? The latest release (as of this writing) is: Version 1.255.1528.0
- Mike answered 8 years ago
- last active 8 years ago
Seems there was a bunch of updates pending ( manually forced an update). Strange because last updates were checked and applied two days ago. Maybe new OS installation takes a few updates instances to install all the security patch needed.
Now wse add-in open successfully after the first configuration.
Thank you for your support.
- tonyrid answered 8 years ago
Apparently for no reason extended mapi appeared in the program. So it’s work now. Still got no idea why but probably not related directly to wse then.
- XGuarden answered 8 years ago
Alas, I’m afraid not. The program was never intended to be used in that way, and so that type of functionality has not been built into it.
- Mike answered 8 years ago
UPDATE #1: According to the following post from Ron Stock (a Microsoft “Sr. Escalation Engineer” in the Support Engineering group), Microsoft has resolved the RemoteApp window z-order and focus bugs in Windows 10 1803, but won’t be releasing the fix until the last week of June:
NOTE: The thread linked above is HUGE, and so it will take quite some time for Ron’s post to actually appear after you click on the link.
Also, here’s a link to a page showing Ron Stock’s other posts (on this subject and others) if you’re interested in reading them (and if you find Microsoft’s lackadaisical response to this issue just as sad and pathetic as the hundreds of others posting in that original thread do):
https://social.technet.microsoft.com/Profile/ron%20stock/activity
- Mike answered 8 years ago
- last active 8 years ago
UPDATE #2: According to the following post from Ron Stock (a Microsoft “Sr. Escalation Engineer” in the Support Engineering group), the fix that addresses the “right-click context menu (e.g. pop-up windows)” issue with RemoteApps in Windows 10 1803 will be included in KB4284848 that is (still) scheduled for release in the last week of June:
NOTE: The thread linked above is HUGE, and so it will take quite some time for Ron’s post to actually appear after you click on the link.
- Mike answered 8 years ago
- last active 8 years ago
You are confusing two completely separate things here…
The number of users that your product license covers has nothing at all to do with the number of simultaneous connections that your server allows. A 10 user product license allows up to 10 different users to be able to access WSE RemoteApp. However, out-of-the-box the Essentials server only allows two simultaneous connections with the server.
That being said, WSE RemoteApp has a (unsupported) feature that you can (optionally) enable in order to allow more than two of your users to be able to connect to WSE RemoteApp at exactly the same time (assuming that your server has the resources to support doing that). However, on very rare occasions, a Windows Update will disrupt that functionality and require that you install a newer version of the product in order to get things work again. This has nothing to do with your license (seeing as it is still completely valid for 10 users being able to access WSE RemoteApp), but you will need to have a valid “Updates and Support” option on your license in order to be able to install a newer release of the product (and/or receive any technical support for it).
To the best of my knowledge, this has only ever happened once with Essentials 2016, and that particular Windows Update was released way back in September of 2017. If for whatever reason, your server only just recently got that Windows Update installed (and it disrupted WSE RemoteApp 2016’s multiple simultaneous connections functionality), then you will need to install the latest release of the product in order to correct that issue. And, if the “Updates and Support” option on your WSE RemoteApp 2016 license is no longer valid, then you will need to purchase a license renewal for your existing 10 user license in order to be able to install the latest release of the product. License renewals (which renew the Updates and Support option on an existing valid license) are available for purchase in one year, two year, or lifetime timeframes.
- Mike answered 8 years ago
Alas, those are both bugs in Windows 10 and have nothing at all to do with WSE RemoteApp I’m afraid. Microsoft really buggered up the latest Windows 10 1803 release (especially when it comes to making RemoteApp connections from it). Hopefully the problems you’re seeing will get resolved when the upcomming KB4284848 Windows Update becomes available in the last week of June. For more info on that see:
Remote apps slow after client’s upgrade to Windows 10 1803
Also, if your Windows 10 client is still running the older 1709 release, then make sure that it has KB4103714 installed on it seeing as that Windows Update addresses similar RemoteApp connection issues in that older release of Windows 10.
- Mike answered 8 years ago
Hi
We are having the same issue with WSE 2012 R2
one user to our knowledge has the apps available via the RADC feed, the others with exactly the same setup on the server (same apps published etc) have nothing?
I am trying to find a source of information as to how we find what is in the RADC feed, as I suspect this is an MS issue and not the remote app program as such.
Any ideas or link to MS documents on how it works on Srv 2012 R2 would be greatly appreciated!!
- Michael Robinson answered 8 years ago
- last active 8 years ago
Thanks for letting me know about the submit problem with the email support form. It should be fixed now.
- Mike answered 8 years ago
