All Answers
Windows Server Essentials must either be or see a domain controller.
If you want your Windows Server 2019 with WSEE installed server to be your primary domain controller, then just let WSEE create the domain for you automatically when installing it. Otherwise, if you want your Windows Server 2019 with WSEE installed server to be a member server (i.e. if you want it joined to a completely different server that’s acting as the primary domain controller), then you’ll need to join it to that domain controller (using the native tools in Windows) BEFORE you install WSEE on it.
All that being said… If your end goal is to simply have your Windows Server 2019 with WSEE installed server be your domain controller, then it really doesn’t matter if you manually configure Windows Server 2019 as your domain controller (i.e. before installing WSEE), or if you let WSEE do it for you (i.e. during the install of WSEE). However, the easiest way is of course to just let WSEE handle all of the domain stuff for you when you configure it.
- Mike answered 6 years ago
- last active 6 years ago
Alas, I’m afraid that Windows Server 2019 Essentials is an abomination! Not only did Microsoft remove the (beloved) Windows Server Essentials Experience (WSEE) server role from it, but they also removed all of the Remote Desktop Services (RDS) server roles from it as well. As a result, there is no way to make the Anywhere Access/Remote Web Access functionality of Essentials work on it (seeing as it is missing the required Remote Desktop Gateway server role). Therefore, if you want to have that feature work on your 2019-based Essentials server, then you MUST use the Standard or Datacenter edition of Windows Server 2019 instead.
That being said… If I were you, I’d simply return my copy of Windows Server 2019 Essentials and purchase a copy of Windows Server 2016 Essentials instead (which is fully supported by Microsoft for many years to come). Seeing as that’s probably the best route for you to take here.
Other than that… If you don’t need/want the Anywhere Access/Remote Web Access functionality on your 2019-based Essentials server, then you can indeed still manually install WSEE on Windows Server 2019 Essentials by following the instructions I’ve provided here.
Lastly, we DO NOT sell the WSEE Installer. It is only made available (free of charge) to our existing customers. If you’d like to use the WSEE Installer to automatically install WSEE on Windows Server 2019, then you can purchase ANY of our products, and then request the download password for the WSEE Installer by simply contacting us with the User Name from the license of your newly (or previously) purchased product.
- Mike answered 6 years ago
- last active 6 years ago
Alas, I’m afraid not…
Windows Server Essentials (both the stand-alone SKU and the WSEE server role) are NOT compatible with Remote Desktop Services (RDS). When you install RDS on an Essentials server, it completely trashes the Anywhere Access/Remote Web Access (i.e. Remote Desktop Gateway), etc. configuration, and will end up causing you nothing but grief in the long run.
WSE RemoteApp is designed to run with your Essentials server configured just as it comes straight out-of-the-box (i.e. in Remote Desktop administration mode and without RDS installed). If you happened to have installed RDS on your Essentials server (e.g. the Remote Desktop Session Host server role, or the Remote Desktop Web Access server role) then the add-in will actually alert you to that and refuse to install/run.
I’m not sure it’s as simple as just removing the RDS server roles (as I think the damage has already been done at that point), but you can try it and see what happens (just make sure that you have a good server backup before proceeding). Without the RDS server roles installed, WSE RemoteApp will at least install and run. I just don’t know (off the top of my head) if you’ll also need to reconfigure your Anywhere Access/Remote web Access configuration on the server as well.
And yes, WSE RemoteApp will indeed allow you to publish proprietary programs that have been installed directly on your Essentials server. The add-in’s “Publish RemoteApp Programs” wizard will show you a list of all the applications currently installed on your server, or you can click on the wizard’s “Add Another Program” button to browse for any other program that’s on your server (i.e. one that’s not installed in the Start Menu).
I hope that helps you out some, and thanks for your interest in my software.
- Mike answered 6 years ago
- Paul Erickson answered 6 years ago
- last active 6 years ago
Simply contact us with the name of your existing product (e.g. WSE RemoteApp 2016, WSE WorkFolders 2016, etc.), the User Name from your existing license, and which higher edition it is that you would like to move up to (e.g. “Basic Edition”, etc.), and we’ll then send you back an email message with a direct PayPal payment link that you can use in order to submit your payment for the price difference between the two editions.
- Mike answered 6 years ago
Just a quick update…
It’s going on close to a year now and Microsoft still refuses to fix this nasty bug in the native Work Folders client on Windows 10 v1903, v1909, and (most likely) v2004. I’m absolutely flabbergasted and don’t know what else to say (other than shame on them).
If you’re setting up a new Windows 10 client machine, and you want to use the native Work Folders client on it, then I suggest that you install Windows 10 v1809 on it, set up the native Work Folders client, and then update it to Windows 10 v1903 (or greater).
Other than that, if you absolutely need to use the native Work Folders client on Windows 10 v1903 (or greater), and you can’t start off with v1809 (or older), then all you can do at this point is turn off the (at rest) file encryption feature on your Work Folders sync server, and then just use Work Folders without (at rest) file encryption.
Obviously, that’s a pretty crappy solution, but until Microsoft gets around to fixing the file encryption bug in their native Work Folders client, there’s not a whole lot that I can do about it I’m afraid. The only thing I can tell you is, if you’re going to disable (at rest) file encryption for your Work Folders, to make sure that all of your devices have encryption enabled at the device level (such as by turning on BitLocker in Windows 10, enabling device encryption on your mobile devices, etc.).
Here’s how to turn off Work Folders file encryption on your Essentials server:
1. Sign in to your Essentials server as an administrator.
2. Open the Server Manager (i.e. Control Panel -> Administrative Tools -> Server Manager) and go to:
File and Storage Services -> Work Folders
3. Right-click on the existing “WseSyncShare” sync share and then choose “Properties“.
4. In the “WseSyncShare Properties” window that opens, click on “PC Security Policies“.
5. Uncheck the “Encrypt Work Folders” check box and click on the “OK” button to save your changes.
After doing that, you “should” then be able to set up a brand new Work Folders connection using the native Work Folders client on your Windows 10 v1903, v1909, or v2004 computer(s). Just be aware that if your ever happen to re-run the “Enable Work Folders” task on the “WORK FOLDERS” page of the server Dashboard, then the encryption feature will automatically get turned back on again for your server (seeing as WSE WorkFolders is designed to always force encryption in your Work Folders clients).
Once (if) Microsoft gets around to fixing the problem, then you can turn client-side encryption back on again by simply reversing the steps given above.
Ya gotta love Microsoft! If it doesn’t involve emoji, colorful app icons, dark themes, or ninja cats, then they just don’t care about it in Windows 10. Oy!
- Mike answered 6 years ago
- last active 6 years ago
If you have a script that automatically creates your mapped network drives when you log into your VM desktop, then you should just be able to publish that script as a RemoteApp program in WSE RemoteApp and have it run automatically when your user’s RemoteApp sessions first start. Here’s how I’d approach it:
1. Open the server Dashboard and go to the main “WSE REMOTEAPP” page.
2. Click on the “RemoteApp Programs” subtab, and then click on the “Publish RemoteApp Programs” task.
3. Click on the “Add Another Program” button in the Publish RemoteApp Programs wizard that opens, locate/open your script file, and finish out the rest of the wizard in order to publish the script file as a RemoteApp program in WSE RemoteApp.
NOTE: I don’t know what format your script file is in (as you didn’t say), but I’ll assume that it’s in a standard “Windows Batch File (.BAT)” format here. If it’s not, then you can try typing “*.*” (without the quotes) into the “File name” field and hitting the enter key so that the File Open dialog box now shows all file types (instead of it only showing the file types that WSE RemoteApp supports by default), and then select your script file from there. That “should” work as long as the server itself supports the file type of your script file (i.e. as long as it can be successfully executed on the server). Otherwise, you should just be able to open up Notepad, type in the command for executing your script, and save it as a .BAT file (while making sure that Notepad doesn’t append a “.txt” file extension onto the end of the batch file name).
NOTE: The script/batch file will need to be placed within a folder on the server that the users (who are going to be running it) have read permission to access. If only one of your users needs access to the script/batch file, then I recommend placing it in their specific “Users” shared folder on the server (e.g. “\\YOURSERVERNAME\Shared Folders\Users\Mike“, etc.). Otherwise, you can place it in the server’s “Company” shared folder (e.g. “\\YOURSERVERNAME\Shared Folders\Company“), or create a new “Scripts” shared folder on your server (via the server Dashboard’s “STORAGE” page), and grant read-only access to the new shared folder for your required users.
4. Once the script/batch file has been published, locate it in the list of published RemoteApp programs and double-click on it (or select it and click on the “View the RemoteApp program properties” task) in order to open the RemoteApp Properties wizard for it.
5. On the first panel of the wizard that opens, choose the “Yes” option under “Auto-start this RemoteApp program“, and then click the “Hide RemoteApp program from users” checkbox.
NOTE: You can skip this step if you’d rather have the scrip/batch file show up as a RemoteApp program in the main WSE RmeoteApp Launcher window. That way your users can manually execute it only when they require the mapped drives to appear in their RemoteApp session. If you go that route, then you can also give the script/batch file a more friendly name on this panel of the wizard, and change the icon for it to something different as well.
NOTE: If the script/batch file pops up a command window when it’s executed, and you’d rather not see that window flash on the screen, then you can create a shortcut to the script/batch file, and publish the shortcut to it instead of publishing the script/batch file directly. When you use a shortcut, you can then click on the “Properties” button on the first panel of the wizard, and in the Shortcut Properties dialog box that opens, you can choose to run it minimized.
6. Click “Next” and then on the second panel of the wizard, choose the “Only specific users and groups” option, and then check the boxes in front of the users who you want to have the script/batch file automatically execute for when they first start their RemoteApp sessions. Otherwise, if you want the script/batch file to execute for all of your users, then leave the default “All users that have been allowed access to WSE RemoteApp” option selected.
7. Click “Save” to save your changes.
That’s it… Now anytime your users start a RemoteApp session, the script/batch file will automatically get executed, and the network drives should get mapped.
Lastly… I’ll just mention that a better way of handing this in Essentials is to add new shared folders for your drives (via the “STORAGE” page of the server Dashboard), and then grant access for your users to the shared folders as required. I personally don’t mess around with using mapped network drives in Essentials seeing as going the shared folder route is a MUCH better option IMHO.
I hope that helps you out some.
- Mike answered 6 years ago
- last active 6 years ago
Typically, you should always match the language edition of the WSEE Installer to the base language of the Windows Server 2019 installation media that you are using. Therefore, if you are using the English evaluation edition of Windows Server 2019 Standard as your installation media, then you should request access to the English edition of the WSEE Installer.
If your end result needs to be in a language other than English, then you really should use that specific language as your starting point for installing Windows Server 2019 on the server (Microsoft offers many language editions for the installation media of the Windows Server 2019 Standard evaluation), and then request access to the exact same language edition of the WSEE Installer.
That being said… You could try starting with an English install of Windows Server 2019, and then request access to a different language of the WSEE Installer, but I cannot guarantee that it will work (seeing as I haven’t spent any time testing mismatching language editions like that). Just note that you can only request one language edition of the WSEE Installer per license of one of our products (i.e. you cannot purchase one product and then request access to multiple different language editions of the WSEE Installer).
Other than that… The WSEE Installer is 100% plug-n-play. It provides everything you need, and handles everything for you. All you need to do is install a new/clean/fresh instance of Windows Server 2019 Standard (with Desktop Experience) on your server, with no other server roles, features, or applications installed on it, and the WSEE Installer (and Microsoft’s “Configure Windows Server Essentials” wizard) handles everything else from there.
For all the details, check out the main how to guide for installing WSEE on Windows Server 2019 here.
- Mike answered 6 years ago
Another quick update…
I can now confirm that Microsoft has finally fixed this atrocity of a bug in their upcoming Windows 10 v2004, Build 19041 release (i.e. the “May 2020 Update“) that’s currently scheduled to be released on the 12th of this month (I believe).
It’s a real shame that it has taken Microsoft more than a year to get around to fixing this bug, but I’m glad that they finally have. Now it only remains to be seen if they will back port the fix to the older Windows 10 v1903 and v1909 releases (I’m certainly not holding my breath for that though).
So… If you want to use the native Work Folders client (with at rest encryption of your work files) in Windows 10, then you’ll need to go ahead and install the “May 2020 Update” once it becomes available via Windows Update.
- Mike answered 6 years ago
- last active 6 years ago
Alas, I’m afraid that we’re unable to replicate this one over here on our end (i.e. license renewal orders are working just fine for us here). Do you happen to have any ad/popup blockers enabled within your web browser? If so, then you may want to try temporarily disabling them just to see if that resolves the issue for you. If not, then you may also want to try using a completely different web browser (or perhaps even a completely different PC/device) when placing your order.
Other than that, if you’d like to contact us via our email support page with the User Name from your existing license, then we can try providing you with a direct PayPal link for submitting your license renewal payment. Although, I’m not sure that will make much of a difference seeing as you’ll still be going through the main PayPal user interface (and that seems to be where you’re having the issue).
- Mike answered 6 years ago
Thanks Mike, all makes sense and works well.
- Brad answered 6 years ago
- last active 6 years ago
Alas, I’m afraid that I haven’t seen this one crop up before (and I can’t currently reproduce it in my limited testing scenarios). Admittedly, I don’t use Storage Spaces too much though (and so I don’t have a lot of experience with it).
As you’re well aware, Windows Server doesn’t natively include a “Storage Spaces” applet in its Control Panel. However, Microsoft includes one with the Windows Server Essentials Experience (WSEE) server role in all of the (prior) versions of Essentials. With Windows Server 2019 Essentials being the complete and utter abomination that it is (and having nothing whatsoever to do with all prior versions of Essentials), it doesn’t include a “Storage Spaces” applet in its Control Panel either.
However, since Windows Server 2019 is based upon the UI of Windows 10 v1809, I went ahead and excised the “Storage Spaces” Control Panel applet from it and then stitched it into Windows Server 2019 (with WSEE installed) via the WSEE Installer. Therefore, the issue that you’re seeing here could well be an incompatibility (or possibly a bug) between the server and client editions of Windows as far as the applet is concerned. I’ll certainly look into it a bit more, but I’m not sure that there will be too much that I can do about it at this point I’m afraid. It may just be something that we’ll need to live with. And, as you’ve mentioned, since the core functionality of the applet appears to be working (i.e. it’s just the information that’s not showing up properly in the applet), it’s probably not all that big of an issue in the larger scheme of things.
Thanks for the heads up on this one.
EDIT: I found the following article on the web, which briefly mentions the “Inaccessible by user action” issue. Can you take a look at it just to see if anything it says happens to correct the issue for you (seeing as you’ll know way better than me I’m sure):
From Windows Server 2012 to 2012 R2: A storage pool nightmare
- Mike answered 6 years ago
- last active 6 years ago
Nice catch on that link, that was indeed the issue, all is looking good now. Thanks for the help!
- DavidK answered 6 years ago
That’s great news! I’m very glad to hear that the fix within the article resolved the issue for you, and that it isn’t a problem with the way I’ve implemented the Storage Spaces applet in 2019. Thanks for the follow up.
- Mike answered 6 years ago
When Essentials is running as a member server in another AD domain (i.e. when it’s domain-joined to a completely separate server that’s acting as your primary domain controller), then you do indeed still need to set up Anywhere Access/Remote Web Access on the Essentials server in order to use WSE RemoteApp remotely (either via the hooks (i.e. gadget and web page) that it integrates into the server’s built-in Remote Web Access website, or via its RADC web feed features).
When you configure Anywhere Access/Remote Web Access on an Essentials server, it will automatically set up its very own secure RD Gateway on the server that will then be used by all of its Anywhere Access/Remote Web Access features (i.e. it cannot use another server in your network that is already configured as a RD Gateway server).
- Mike answered 6 years ago
- last active 6 years ago
Sadly, WHS RemoteApp 2011 has now reached end of life (since all Windows Server 2008 R2 based server operating systems are no longer being supported/updated by Microsoft). Therefore, I strongly recommend that you upgrade your server to something newer and more secure (such as Windows Server 2016 Essentials). While I myself still absolutely love Windows Home Server 2011, it’s just not worth the security risk of running an unsupported operating system on any server IMHO.
That being said… It’s been a long time since I’ve looked at any of the old SharePoint stuff. I do recall that it used to work just fine with WHS RemoteApp 2011 years ago, but I can no longer say that for certain. You’ll just need to publish it as a RemoteApp program and see how it goes.
As for our older legacy products (such as WHS Office 2011, WHS Outlook 2011, WHS QuickBooks 2011, and WHS Quicken 2011)… They have all been discontinued (a long time ago), and are no longer available for download/purchase seeing as they were all superseded by WHS RmeoteApp 2011. WHS RemoteApp 2011 can do everything those legacy products could do plus a whole lot more. Basically, instead of needing a separate add-in/product for each specific application, WHS RmeoteApp 2011 allows you to publish multiple applications as RemoteApp programs instead (and so there’s no need for the legacy products any longer). Hope that makes sense.
- Mike answered 6 years ago
- last active 6 years ago
Thanks Mike.
Appreciate the response. 2011 app is working well. I will investigate migrating everything to 2016.
Thanks again and stay safe
- Clay answered 6 years ago
- last active 6 years ago
First off… A revoked SSL certificate has nothing whatsoever to do with WSE RemoteApp 2016. If you’re using a Microsoft personalized domain name (e.g. YourHostName.remotewebaccess.com), then all of that stuff is handled by the Anywhere Access/Remote Web Access functionality of Essentials itself (and GoDaddy is indeed the domain registrar and certificate provider that is used by Microsoft, behind the scenes, for their personalized domain names).
That being said… If the SSL certificate for your Microsoft personalized domain name has been revoked (for whatever reason), then you will need to open the server Dashboard, click on “Settings“, go to the “Anywhere Access” tab, and click on the “Repair” button. The Anywhere Access repair wizard will then automatically issue your server a new (and valid) SSL certificate for your Microsoft personalized domain name.
Lastly, please be aware that there was a really nasty bug in Windows Server Essentials that caused the GoDaddy-provided SSL certificates to be automatically revoked on a daily basis. It took Microsoft well over a year to fix the issue, but they finally did so via a Windows Update (i.e. KB4512495). Therefore, you should also make sure that your Essentials server has all of the latest Windows Updates installed on it so that this particular bug isn’t what’s causing the issue of your SSL certificate being revoked.
BTW, here’s how the KB article describes the fix:
Addresses an issue that may cause a new domain certificate to stop working after a day. This issue occurs when you set up the domain using a live account and the virtual private network (VPN) is configured using the Anywhere Access wizard. The error is, "Error 619: A connection to the remote computer could not be established, so the port used for this communication was closed". After more connection attempts, the following error appears, "Link to VPN connection failed. Reconnecting pending ..."
- Mike answered 6 years ago
- last active 6 years ago
Open your web browser, go to your server’s built-in Remote Web Access website (e.g. https://yourhostname.remotewebaccess.com/remote), click the lock button/image within the address bar, and view the SSL certificate the website is using. Is the proper certificate being shown, and is it valid (i.e. not showing as revoked or expired when you view it)?
If the proper SSL certificate is being used, but it’s not valid (i.e. if it’s revoked, expired, etc.), then open the server Dashboard, click on “Settings“, click on the “Anywhere Access” tab, click the “Set up…” button, and try setting up your domain name all over again. Just don’t release your current domain name from the server or you’ll lose it. Simply opt to set up a new Microsoft personalized domain name and then once you sign in to your Microsoft account, you’ll be able to select your existing domain name again from the drop-down list provided (i.e. the one that you’re currently using). Hopefully doing that will get you a new SSL certificate issued for the domain name.
As for the Windows Updates… If you run Windows Update on the server and it tells you that it’s fully up-to-date, then I’m sure you’re fine. However, if you want to be sure, then perform a standard Remote Desktop Connection to your server and sign in as an administrator. Then, from the administrator’s desktop open File Explorer, and go to the following folder:
C:\Windows\System32\Essentials
Locate the file named “Wssg.Web.DomainManagerObjectModel.dll“, right-click on it, click on “Properties“, go to the “Details” tab, and check to see if it is version 10.0.14393.3179. If it is, then you have the latest version installed via the Windows Update I mentioned and you’re good to go.
- Mike answered 6 years ago
- last active 6 years ago
First off, don’t fret about the silly CALs.
Secondly, it’s not that I “prefer” you to use Windows Server 2019 Standard (or Datacenter) over (the abomination that is) the Windows Server 2019 Essentials SKU, it’s more because Microsoft has completely removed all of the Remote Desktop Services (RDS) server roles from the 2019 Essentials SKU, and so the Remote Desktop Gateway server role isn’t available for use by the Anywhere Access/Remote Web Access features of Essentials.
When I attempt to run the WSEE Installer on the 2019 Essentials SKU, the Windows Server Essentials Configuration wizard ultimately fails with a fatal error (which is most likely due to the missing RD Gateway server role on the SKU). I can work around the fatal error with some trickery, but the Dashboard runs super slow, and a lot of its main functionality just doesn’t work at all (such as the Anywhere Access/Remote Web Access/Virtual Private Network features, server backup, etc.). It’s a big mess IMHO, and so I have now physically blocked the WSEE Installer from being able to run on the Essentials SKU.
Of course you can still attempt to install WSEE manually on the Essentials SKU (and deal with all of the issues that pop up along the way), but it just doesn’t work well enough for me to feel comfortable letting the WSEE Installer run on it I’m afraid.
I’m sorry that I don’t have a better answer for you on this one.
- Mike answered 6 years ago
