Installing Windows Server Essentials Experience On Windows Server 2019 / 2022 / 2025
Posted by Mike 
Last updated: May 10, 2024 
As mentioned in my previous post, Microsoft has completely removed the Windows Server Essentials Experience (WSEE) server role from Windows Server 2019. However, since the entire Windows Server Essentials Experience is basically just an elaborate .NET application that is installed on top of the Windows Server operating system (and not some tightly integrated system component of the OS itself), it can quite readily be installed onto Windows Server 2019 and beyond.
Background Information And Proof Of Concept
Windows Server 2016 is built upon the Windows 10 version 1607 platform, and so it stands to reason that any .NET application that runs on it “should” run equally well on Windows Server 2019 (which is built upon the similar, but newer, Windows 10 version 1809 platform). This certainly holds true for the Windows Server Essentials Experience .NET application seeing as it runs exactly the same under Windows Server 2019 (and beyond) as it does under Windows Server 2016.
To install the Windows Server Essentials Experience on Windows Server 2019 / 2022 / 2025, all that needs to be done is for you to copy its required files and registry entries from Windows Server 2016 over to Windows Server 2019 / 2022 / 2025, add its prerequisite server roles and features, create its required services, and then complete its setup process by running the Configure Windows Server Essentials wizard. As you can see from the following screenshots, everything works quite nicely once it has been properly installed and configured.
• The “Configure Windows Server Essentials” wizard works perfectly when performing the initial configuration of Windows Server Essentials on Windows Server 2019 / 2022 / 2025…
• The configuration wizard even works when Windows Server 2019 / 2022 / 2025 is joined to an existing domain (i.e. when it is running as a member server, rather than acting as the primary domain controller)…
After Windows Server Essentials has been successfully configured you can then simply open up the server Dashboard (as usual) and start enjoying all the features of the Windows Server Essentials Experience server role on Windows Server 2019 / 2022 / 2025.
• Client Connect and Client Backup works…
• Server Backup works…
• Storage (Server Folders, Storage Spaces, etc.) works…
• Anywhere Access / Remote Web Access works…
• Add-ins work (including our very own WSE RemoteApp and WSE WorkFolders)…
Everything works exactly as it does under Windows Server 2016!
Obviously, doing this will never be sanctioned nor supported by Microsoft, and so you may be asking yourself why not just stick with using Windows Server 2016 since it is fully supported by Microsoft until January 12, 2027? While you certainly can (and should) do that, probably the best answer I can give you is… Because you can! That being said, it’s worth mentioning that since Windows Server 2019 and Windows Server 2022 have now reached general availability (A.K.A. RTM), there will most likely come a time in the not too distant future, when Microsoft will stop selling Windows Server 2016 licenses. Being able to do this will allow those folks who wish to set up a newer server with the Windows Server Essentials Experience to continue to be able to do so once those Windows Server 2016 licenses become hard (if not impossible) to find. It will also allow those folks who would like to enjoy the added security, and other benefits, that come along with using Windows Server 2019 / 2022 / 2025 to be able to continue using the Windows Server Essentials Experience on their Small Office / Home Office (SOHO) servers.
How To Get Started
The installation can be performed by grabbing the install.wim file from a Windows Server 2016 Essentials installation disc (or from a mounted ISO image), and then mounting and extracting it using the Deployment Image Servicing and Management (DISM) command-line tool by following the steps Microsoft provides here. After doing that, grab all of the required Windows Server Essentials files (including the ones in the GAC), extract the required registry entries, and copy them over to Windows Server 2019 / 2022 / 2025. Then use Server Manager to add the prerequisite server roles and features, create the required services, and use PowerShell to start the initial configuration of Windows Server Essentials.
ALTERNATIVELY, if you already own (or newly purchase) a license for one of our software products, then you can contact us with the User Name from the license of your purchased software product, and we’ll be more than happy to share (at no additional charge) a password that you can enter below in order to download the WSEE Installer package (i.e. MSI file) that we’ve built for our own use in installing (and uninstalling) the Windows Server Essentials Experience onto Windows Server 2019 / 2022 / 2025.
The WSEE Installer makes installing the Windows Server Essentials Experience (WSEE) from Windows Server 2016 on Windows Server 2019 / 2022 / 2025 super simple! You just install Windows Server 2019 / 2022 / 2025 Standard or Datacenter, with the Desktop Experience GUI in the language of your choice, onto your server and then run the WSEE Installer package’s MSI file directly from the server desktop (the Windows Server 2019 Essentials SKU can be used, but is NOT recommended!). The WSEE Installer will handle installing all required files, registry entries, prerequisite server roles/features, services, permissions, etc., and then launch the “Configure Windows Server Essentials” wizard to walk you through configuring Windows Server Essentials on your server (as shown in the images above). The WSEE Installer will even monitor your installation and alert you whenever updates become available (via a health alert that gets displayed within the server Dashboard, and optionally emailed to you via the Windows Server Essentials server’s built-in Health Report Add-In feature). Available updates can then be, quickly and easily, installed via our WSEE Updater program. 😎
❗ INFO: The WSEE Installer does so much more for you than can ever be achieved with a manual installation of WSEE, that we no longer recommend folks attempt to install WSEE manually. Using the WSEE Installer will net you a MUCH MORE complete / proper / secure (and hassle free) installation of WSEE (including alerts whenever updates become available, and a simple/easy means of installing the updates via our WSEE Updater program), and so we now STRONGLY RECOMMEND that everyone use it instead.
NOTE: We DO NOT SELL the WSEE Installer (seeing as the “Essentials bits” it installs are not ours to sell, and since we DO NOT officially provide support for it). It is ONLY made available, at no additional charge, as a convenience (and thank you) to purchasers of our software products. If you do not want to purchase any of our software products, then you will simply need to attempt a manual installation of WSEE onto Windows Server 2019.
NOTE: You may use the WSEE Installer to install WSEE on a single server only (i.e. it’s one WSEE installation per purchased software product). If you wish to use the WSEE Installer to install WSEE on multiple servers (for testing or migration purposes, for other clients, family members, friends, etc.), then each server installation MUST be associated with a unique licensee (i.e. User Name) from one of our software products. For additional information see the WSEE Installer policy.
NOTE: The WSEE Installer was built using Windows Server 2016 Standard OS Build 14393.4169 as its source. It is available in Dutch, English, French, German, Italian, Spanish, etc. Be sure to specify your language preference when requesting download access. The language of the WSEE Installer that you use should match the language of the installation media used to install Windows Server onto your server (i.e. don’t mismatch the languages).
😎 INFO: If you’ve installed WSEE on your server via any prior version of the WSEE Installer, use the WSEE Updater to bring your existing WSEE installation up-to-date.
INFO: Our WSE RemoteApp and WSE WorkFolders products run splendidly on Windows Server 2019 / 2022 / 2025 with WSEE installed. Your existing, or newly purchased, license covers the use of the product on Windows Server 2016, 2019, 2022, or 2025.
Suggestions, Limitations, and Known Issues
• While in-place upgrades and domain migrations from earlier versions of Windows Server (Essentials) work just fine, I myself highly recommend that you always start off with a brand new/clean (i.e. straight out-of-the-box) installation of Windows Server 2019 / 2022 / 2025 Standard or Datacenter (with the Desktop Experience GUI in the language of your choice), that has all of the latest Windows Updates installed. The server may be natively joined to a domain if desired, but make sure that no other server roles, features or applications have been installed.
• You should NOT attempt to install the Windows Server Essentials Experience on the Windows Server 2019 Essentials SKU (which, despite its name, has absolutely nothing whatsoever to do with “Essentials” as we currently know it). This is because Microsoft has removed all of the Remote Desktop Services roles from the SKU, and so the required Remote Desktop Gateway role will not be available for use by the Anywhere Access / Remote Web Access features of Windows Server Essentials. Save yourself the time and hassle, and just use Windows Server 2019 / 2022 / 2025 Standard or Datacenter instead (and don’t fret about silly CALs). If needed, you can convert the Windows Server 2019 Essentials SKU into Standard or Datacenter by running one of the DISM commands mentioned below…
NOTE: You can download an evaluation version of Windows Server 2019 (Standard or Datacenter), in ISO format, from the Microsoft Evaluation Center here. Or, you can download an evaluation version of Windows Server 2022 (Standard or Datacenter), in ISO format, from the Microsoft Evaluation Center here.
INFO: You can evaluate the product for up to 180 days, and you can extend the trial period for another full 180 days (up to six times for a grand total of 3 years) by running the following command from an elevated command prompt:
slmgr -rearm
INFO: You can run one of the following commands, from an elevated command prompt, in order to convert the evaluation version into a regular retail version (Standard or Datacenter) using a purchased retail Product Key:
DISM /online /Set-edition:ServerStandard /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
DISM /online /Set-edition:ServerDatacenter /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula
💡 HINT: You can use Windows Server 2019 / 2022 / 2025 for free by running one of the following commands, from an elevated command prompt, in order to convert the evaluation version into a volume-licensed version (Standard or Datacenter) using a Generic Volume License Key (GVLK) from Microsoft:
Windows Server 2019:
DISM /online /Set-edition:ServerStandard /ProductKey:N69G4-B89J2-4G8F4-WWYCC-J464C /AcceptEula
DISM /online /Set-edition:ServerDatacenter /ProductKey:WMDGN-G9PQG-XVVXX-R3X43-63DFG /AcceptEula
Windows Server 2022:
DISM /online /Set-edition:ServerStandard /ProductKey:VDYBN-27WPP-V4HQT-9VMD4-VMK7H /AcceptEula
DISM /online /Set-edition:ServerDatacenter /ProductKey:WX4NM-KYWYW-QJJR4-XV3QB-6VM33 /AcceptEula
Windows Server 2025:
DISM /online /Set-edition:ServerStandard /ProductKey:KC9Y2-GKNY8-4DPQC-BCXDK-6CT98 /AcceptEula
DISM /online /Set-edition:ServerDatacenter /ProductKey:NPX2K-GTW7W-FC9PW-6QRVJ-F3QKM /AcceptEula
After doing that, you can then automate activation of the volume-licensed version using abbodi’s KMS_VL_ALL script that sets up a local KMS server emulator on the server. 😎
• (8/25/2019): After configuring Windows Server Essentials, you may see a health alert stating that your “Active Directory domain names can’t be resolved“. If so, then change the adapter settings/options for the network connection on your Essentials server so that its preferred IPv4 DNS server address is set to the default 127.0.0.1 localhost/loopback address, and its alternate IPv4 DNS server address is set to the IP address of your network router (e.g. 192.168.1.1) or other DNS server (e.g. 8.8.8.8). You should also verify that the preferred IPv6 DNS server address is set to its default ::1 value.
NOTE: In addition, you should also change the adapter settings/options for the network connection on ALL of your client computers so that their preferred IPv4 DNS server address is set to the static IP address of your Essentials server, and their alternate IPv4 DNS server address is set to the IP address of your network router (e.g. 192.168.1.1) or other DNS server (e.g. 8.8.8.8). Doing so will allow the client-side Windows Server Essentials Connector software’s installer (which you can download from each of your client computers by browsing to http://<ServerName>/connect, where <ServerName> is the name of your Essentials server) to be able to successfully locate and connect the client computer to your Essentials server.
INFO: If the Windows Server Essentials Connector software (still) has trouble locating your Essentials server, then try adding the “SchUseStrongCrypto” and “SystemDefaultTlsVersions” .NET Framework security settings to the Windows Registry of BOTH your server and ALL of your client computers, and then reboot them. The settings allow the older v2 and v4 versions of Microsoft’s .NET Framework packages (used in Windows Server Essentials) to be able to utilize newer/stronger TLS 1.2 SSL connections whenever the clients attempt to communicate with the server.
INFO: If you do not want to join your connected client computers to the Windows Server Essentials domain, then you can use Microsoft’s SkipDomainJoin connection method instead.
• During (and after) the configuration of Anywhere Access / Remote Web Access, you may see a benign error about your firewall settings (e.g. “There is an error in your firewall settings – Your firewall may be blocking Anywhere Access to your server and the problem cannot be repaired automatically.“). You can safely ignore this error seeing as it is just a false-positive that is being caused by an issue where the localized names of the required firewall rules are not being properly read from their resource files.
NOTE: The accompanying health alert will automatically be disabled for you when using our WSEE Installer (but the error will still appear within the Configure/Repair Anywhere Access Wizard itself).
• (3/8/2021): The Microsoft Online Integration Services (such as Office 365 and Azure Active Directory) will work as designed when WSEE has been installed using our WSEE Installer (Version 10.0.14393.4169 (Revision 3) or greater).
NOTE: The online integration services in Windows Server Essentials are NOT compatible with multi-factor authentication (MFA) being enabled on your Office 365 / Azure Active Directory user accounts. Therefore, you should make sure that MFA is disabled by signing in to the Microsoft 365 admin center, clicking on Users → Active users, clicking on your admin user, and then clicking on the Manage multifactor authentication link located on the Account tab.
Microsoft has also implemented something called security defaults in Azure Active Directory, and since enforcing the enabling of MFA on all of your user accounts (within 14 days) is part of this security feature, you will need to disable it as follows:
• Sign in to the Azure portal as an administrator.
• Browse to Manage Azure Active Directory → Properties.
• Select Manage security defaults.
• Set the Enable security defaults toggle to No.
• Select Save.
• (3/15/2021): The Windows Server Essentials Best Practice Analyzer (BPA) tool works when WSEE has been installed using the WSEE Installer (Version 10.0.14393.4169 (Revision 4) or greater).
NOTE: To run the Windows Server Essentials Best Practice Analyzer (BPA) tool:
• Log on to the Essentials server as an administrator, and then open the Configure Windows Server Essentials wizard (click Start → type EssentialsRoleConfigWizard.exe).
• Close the configuration wizard after confirming that Windows Server Essentials has been successfully configured on the server.
• Open Server Manager, and then click the Windows Server Essentials Experience tab.
• In the details pane, scroll down to the BEST PRACTICES ANALYZER.
• If a filter is applied, click Clear All.
• Click TASKS, and then click Start BPA Scan.
• Review each BPA message, and follow the instructions to resolve issues, if necessary.
SEE: Rules used by the Windows Server Essentials Best Practices Analyzer (BPA) Tool
Closing Remarks
We’ve tested all of this quite extensively, and it consistently works great for us here. However, your results may vary. Please don’t blame us (nor Microsoft) if you can’t get it to work, or if something goes wrong on your server. None of this is officially supported by Microsoft (nor by us!), and so you should proceed at your own risk. You fully assume all risk, responsibility, and liability associated with the installation. And as always, make sure that you have a working backup of your server, and all of your data, before proceeding.
That being said, it works so well for us here, that we have now switched all of our SOHO servers over to running Windows Server 2019 / 2022 / 2025 with the Windows Server Essentials Experience installed.
That’s it! Enjoy using the Windows Server Essentials Experience on Windows Server 2019 / 2022 / 2025.
— MIKE (The Office Maven)
EDIT (6/26/2019): As the months keep flying on by, we’re finding that the longer we use the Windows Server Essentials Experience on Windows Server 2019, the more we’re coming to realize just how much better Windows Server 2019 is than Windows Server 2016. While the “Essentials” bits themselves are of course identical (seeing as they’re just being brought straight over, untouched, from 2016), they run MUCH BETTER under 2019. Windows Server 2019 is leaps-and-bounds faster than Windows Server 2016 is (it boots up faster, and everything, including the server Dashboard, etc., just runs faster/better under it). Lots of bugs that plague 2016 are fixed under 2019. Overall, we’re finding that using WSEE on 2019 is an all-around much better experience.
EDIT (9/1/2021): The Windows Server Essentials Experience also installs, and runs wonderfully, on Microsoft’s GA/RTM release of Windows Server 2022. Enjoy! 😎
EDIT (5/10/2024): The Windows Server Essentials Experience also installs, and runs wonderfully, on Microsoft’s preview release of Windows Server 2025 (i.e., the next version of Windows Server with the new Windows 11 style Graphical User Interface). Enjoy! 😎
Mike says:
WSEE Installer / WSEE Updater Release Notes
➡ (10/4/2018): Initial release of the WSEE Installer (Version 1.0.0.0).
➡ (1/1/2019): Changed the WSEE Installer version number to Version 10.0.14393.2641 in order to reflect the actual OS Build of Windows Server 2016 Essentials that’s currently being used as the source. SEE: KB4478877 — December 3, 2018 (OS Build 14393.2641)
➡ (8/27/2019): Quite astonishingly, Microsoft’s latest Windows Update for Windows Server 2016 (i.e., KB4512495 — August 17, 2019 (OS Build 14393.3181)) includes a fix for the long-standing issue where the SSL certificates issued to Microsoft personalized domain names (e.g. yourhostname.remotewebaccess.com), that are set up via Anywhere Access, get revoked / reissued on a daily basis. I’m totally amazed that Microsoft has finally fixed this one (but, at the same time, I’m completely flabbergasted as to why it took them so darn long to do so 😕 ).
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 ..."The fix consists of only a single updated Windows Server Solutions (WSS) assembly, which has been bumped up to version 10.0.14393.3179. In response to this, I have released a new version of the WSEE Installer (i.e., Version 10.0.14393.3181) that contains the updated assembly.
• (8/27/2019): I just realized that in all prior releases of the WSEE Installer, I neglected to grant required permissions for the Images folder that houses the cached file type icons that get displayed whenever you browse your Shared Folders from the Essentials server’s built-in RWA website. I’ve now corrected that issue in the latest release of the WSEE Installer.
• (9/2/2019): Required permissions have been set for the Remote Access “USERPROFILE” folder.
• (9/19/2019): I missed adding the online services module to all prior releases of the WSEE Installer, and so I’ve released an updated version of the WSEE Installer that now includes it.
• (11/16/2019): I just realized that I had the WSEE Installer package’s version number set to 10.0.14393.3179 instead of 10.0.14393.3181 as it should have been. No harm, no foul on that one, but I’ve now updated it just to keep things straight. Additionally, I’ve added a “Configure Windows Server Essentials” shortcut to the server desktop just in case the configuration wizard doesn’t happen to run after the installation completes (as mentioned here). The shortcut can safely be deleted once you’ve successfully completed the configuration of Windows Server Essentials.
• (2/6/2020): I have figured out how to get the “Manage Storage Spaces” task (i.e., the “Storage Spaces” Control Panel applet) working under Windows Server 2019, and I have updated the WSEE Installer to include the fix.
• (3/3/2020): The WSEE Installer now handles setting all required folder/file security permissions.
• (6/3/2020): I’ve added (back in) a block to the WSEE Installer that prevents it from working under (the abomination that is) the Windows Server 2019 Essentials SKU. I’ve spent some time looking into running the installer on the SKU, and it just doesn’t work well enough for me to feel comfortable letting it continue to do so.• (7/8/2020): I have fixed an issue where a “Remote Web Access customization service is not available.” error would be shown when attempting to customize or change any of the website settings (via: Dashboard → Settings → Anywhere Access → Customize).
➡ (8/21/2020): Version 10.0.14393.3866 → • All relevant Windows Server Essentials Experience assemblies have been updated to their latest version 10.0.14393.3866 releases, which were delivered via KB4571694 — August 11, 2020 (OS Build 14393.3866).
➡ (9/11/2020): Version 10.0.14393.3866 (Revision 1) → • I have built a proper updater program to compliment the WSEE Installer. The new “WSEE Updater” will update any previously installed instance of Windows Server Essentials Experience (that has been installed via the WSEE Installer) to the latest version. Simply download the WSEE Updater, and then run it on your server to bring your existing Windows Server Essentials Experience installation up to the latest release. 😉
• In addition, I have built a simple Health Add-In that will monitor your installed version of Windows Server Essentials Experience to see if it is up-to-date, and if it’s not, then it will show a health alert within the server Dashboard alerting you that a newer version is available, and prompting you to download and run the latest release of the WSEE Updater on your server. The Health Add-In is automatically installed by the latest release of the WSEE Installer, and by the WSEE Updater when updating a previously installed instance of the Windows Server Essentials Experience on your server. No more manual tracking and installing updates for you! 😀
💡 The “Windows Server Essentials Experience update available!” health alert is triggered as “Critical”, and is “escalated”, so that it will appear within the health reports that are generated (and optionally emailed to you) by the server’s Health Report Add-In feature. 😎
• (9/20/2020): While I still strongly suggest that folks start with a clean (out-of-the-box) install of Windows Server 2019 / 2022 / 2025, the WSEE Installer now supports installing WSEE on instances of Windows Server 2019 / 2022 / 2025 that have been in place upgraded from Windows Server 2016. The only real caveat is that the Configure Windows Server Essentials wizard will refuse to automatically start at the end of the WSEE Installer’s installation process, and so you will simply need to double-click on the “Configure Windows Server Essentials” shortcut on the server’s desktop in order to manually run the wizard (or you can just restart the server). The config wizard will then recognize the in place upgrade, and configure it accordingly.
➡ (11/13/2020): Version 10.0.14393.4046 (Revision 1) → • Microsoft’s latest Windows Update for Windows Server 2016 (i.e., November 10, 2020—KB4586830 (OS Build 14393.4046)) includes a HUGE number of changes to the underlying Essentials assemblies. Nearly every assembly has been recompiled and re-versioned to 10.0.14393.4046. I have absolutely no idea why Microsoft did this (i.e., recompiled most, but not all, of the assemblies), because there’s no information whatsoever provided within the Knowledge Base article about these changes (typical Microsoft!). On quick inspection, none of the file sizes appear to have changed, and so they seem to have simply been recompiled with a higher version number. Regardless, I’ve now built a new version of the WSEE Installer that includes all of the updated assemblies. I’m currently working on a new version of the WSEE Updater as well, but that’s going to take me a while to complete since there’s quite literally hundreds upon hundreds of updated assemblies that I now need to add to the updater.
➡ (11/16/2020): Version 10.0.14393.4046 (Revision 1) → • All relevant Windows Server Essentials Experience assemblies within the WSEE Updater have now been updated to their latest version 10.0.14393.4046 releases, which were delivered via KB4586830 — November 10, 2020 (OS Build 14393.4046).
• (12/7/2020): As a follow up to my 9/20/2020 bullet point shown above, in place upgrades from Windows Server 2019 to 2022 (or from older to newer preview builds) are now supported by the WSEE Installer. However, during the in place upgrade, Microsoft will forcefully remove all of the Windows Server Essentials assemblies, services, etc. (just as they do during the Windows Server 2016 to 2019 / 2022 / 2025 in place upgrades) leaving you with an orphaned Windows Server Essentials Experience instance. When you attempt to run the WSEE Installer again, it will refuse to run because another version of the product is already installed. To remedy this, I have built a small “WSEE Zapper” program that you can run in order to remove the orphaned WSEE instance from the server, and thereby allowing you to be able to run the WSEE Installer again.
➡ (1/12/2021): Version 10.0.14393.4169 (Revision 1) → • All relevant Windows Server Essentials Experience assemblies have been updated to their latest version 10.0.14393.4169 releases, which were delivered via KB4598243 — January 12, 2021 (OS Build 14393.4169).
• (1/22/2021): Removed the block that prevents the WSEE Installer from being used on the Windows Server 2019 Essentials SKU. NOTE: While I continue to insist that WSEE should NOT be installed on the Windows Server 2019 Essentials SKU (since it does not contain the Remote Desktop Gateway server role that is required by certain parts of the Anywhere Access / Remote Web Access feature), you can now proceed with the installation if you do not need to use the Anywhere Access / Remote Web Access feature. 🙄
• (1/22/2021): Removed support for builds of Windows Server Preview (i.e., Windows Server 2022) that were hard coded to expire on January 31, 2021 (i.e., all builds prior to Build 20282).
➡ (2/21/2021): Version 10.0.14393.4169 (Revision 2) → • The Dashboard.exe and InstallAddin.exe executable files have been digitally signed.
➡ (3/8/2021): Version 10.0.14393.4169 (Revision 3) → • Fixed issue where the Microsoft Cloud Integration Services (such as Office 365 and Azure Active Directory) would fail when configuring the integration. For more information, see the “• (3/8/2021)” bullet point within the “Suggestions, Limitations, and Known Issues” section of the main article.
➡ (3/15/2021): Version 10.0.14393.4169 (Revision 4) → • Added support for the Windows Server Essentials Best Practice Analyzer (BPA) tool. For information on how to run the BPA tool, see the “• (3/15/2021)” bullet point within the “Suggestions, Limitations, and Known Issues” section of the main article.
➡ (4/1/2021): Version 10.0.14393.4169 (Revision 5) → • Configures the .NET Framework to support strong cryptography (TLS 1.2). NOTE: It appears that sometime back in early March of 2021, Microsoft started requiring TLS 1.2 when signing in to their Microsoft (Live) accounts. This resulted in folks not being able to configure a new Microsoft personalized domain name (remotewebaccess.com) in Anywhere Access, nor being able to update the DNS information for an existing Microsoft personalized domain name via the Essentials dynamic DNS update service (since signing in to a Microsoft (Live) account is required for doing both).
• (5/25/2021): Removed support for builds of Windows Server Preview (i.e., Windows Server 2022) that were hard coded to expire on October 31, 2021 (i.e., all builds prior to Build 20344).
• (9/1/2021): Removed support for Windows Server 2022 Preview Build 20344.
• (9/1/2021): Added support for the GA/RTM release of Windows Server 2022 Build 20348 (Standard and Datacenter). Enjoy! 😎
➡ (9/11/2021): Version 10.0.14393.4169 (Revision 6) → • Fixed issue where a “Computer monitoring error” health alert was being repeatedly triggered due to a failure in the “MicrosoftSecurity!OnlineServicesPackageUpdate” component. NOTE: The root cause of the failure is a hard coded go.microsoft.com fwlink that is downloading a corrupted (language-specific) online services configuration file for the Microsoft Cloud Services Integration feature of Essentials. To workaround the issue, we’ve simply disabled the health definition that checks for updates to the Microsoft Cloud Services Integration feature. We will continue to monitor the issue, and will re-enable the health definition should Microsoft correct the ongoing problem with their fwlink. • Fixed issue where the Microsoft Cloud Services Integration section of the HOME → Get Started → Services tab of the server Dashboard fails to load. NOTE: The fix only works on English (EN-US) based servers at this time. NOTE: The root cause of the failure is a hard coded go.microsoft.com fwlink that is downloading a corrupted (language-specific) online services configuration language resources file for the Microsoft Cloud Services Integration feature of Essentials. To workaround the issue we’ve simply replaced the affected configuration files with non-corrupted copies, and marked them as read-only so that they can’t be overwritten by the corrupted ones again (sorry but we only have access to EN-US copies of the files). We will continue to monitor the issue, and will remove the read-only attribute from the files should Microsoft correct the ongoing problem with their fwlink. • Improved the Health Add-In that automatically monitors the installed version of Windows Server Essentials Experience to see if it is up-to-date. • Miscellaneous source code fixes and improvements.
➡ (9/17/2021): Version 10.0.14393.4169 (Revision 7) → • Added a new “WSEE Installer Licensing” tab to the server Dashboard’s Settings dialog box, which shows licensing and version information for the WSEE Installer. • Miscellaneous source code fixes and improvements.
➡ (9/20/2021): Version 10.0.14393.4169 (Revision 8) → • The Windows Defender “Configure…” (or “Turn on…“) button located on the “General” tab of Dashboard → Settings has been reconfigured so that it now opens “Windows Security” (instead of just producing a never ending configuration status message that cannot be dismissed). • Under Windows Server 2022, something (a bug?) is causing the “Get updates for other Microsoft products” setting (located on the “SETUP” panel of the HOME → Get Started tab of the server Dashboard) to become disabled on a regular basis, which in turn, causes a “Microsoft Update is not enable” health alert to be triggered repeatedly. Therefore, a daily check is made to see if the setting is disabled, and if so, it is automatically (re)enabled and the health alert is cleared. • Added support for non-English based servers to the fix for the broken Microsoft Cloud Services Integration go.microsoft.com fwlink that was made in the prior Revision 6 release. • Re-enabled the health definition that checks for updates to the Microsoft Cloud Services Integration feature that was disabled in the prior Revision 6 release.
➡ (9/28/2021): Version 10.0.14393.4169 (Revision 9) → • All Windows Defender tasks located on the HOME → Get Started → SETUP and QUICK STATUS panels of the server Dashboard have been redirected so that they now open “Windows Security” (instead of just producing a never ending configuration status message that cannot be dismissed). • Marked the HOME → Get Started → SETUP panel’s “Set up Windows Defender” task as being completed (with a green checkmark), since it is set up by default under Windows Server 2019 / 2022 / 2025. • Disabled the (non-functional) Microsoft Pinpoint add-in (i.e., the APPLICATIONS → Microsoft Pinpoint subtab has now been removed from the server Dashboard). • Added WSEE Installer support information, home page links, and link icons, to the HOME → Get Started → HELP panel of the server Dashboard. • Redirected (fixed) all Microsoft links on the HOME → Get Started → HELP panel. • Miscellaneous source code fixes and improvements.
➡ (10/8/2021): Version 10.0.14393.4169 (Revision 11) → • Microsoft has now corrected the issue with their go.microsoft.com fwlink that was downloading corrupted (language-specific) configuration files for the Microsoft Cloud Services Integration feature of Essentials, and so we have removed the read-only lock from the configuration files that was added in the prior Revision 6 release. • Fixed high DPI scaling issues that appear within the server Dashboard whenever the Settings → Display → Advanced scaling settings → Fix scaling for apps → Let Windows try to fix apps so they’re not blurry setting has been turned on (as it now is by default under Windows Server 2022 or greater).
➡ (12/13/2021): Version 10.0.14393.4169 (Revision 12) → • Added additional (required) “Essentials” files and registry entries that were overlooked/missed in prior releases. • All files and/or registry entries added by the WSEE Updater (i.e., all files and/or registry entries added since the time when the original installation first took place) are now properly removed from the server during an uninstall of WSEE.
➡ (1/2/2022): Version 10.0.14393.4169 (Revision 14) → • Miscellaneous source code fixes and improvements.
➡ (1/7/2022): Version 10.0.14393.4169 (Revision 15) → • Miscellaneous source code fixes and improvements.
• (4/13/2022): Fixed issue where the Configure Windows Server Essentials wizard would fail to run automatically, upon completion of the installation/setup process, when an in place upgrade had been performed.
• (4/13/2022): Fixed issue where the Configure Windows Server Essentials wizard would fail to open, with an UnauthorizedAccessException exception, when an in place upgrade from Windows Server 2012/2016 to Windows Server 2019 / 2022 / 2025 had been performed.
➡ (4/27/2022): Version 10.0.14393.4169 (Revision 16) → • The WSEE Installer license will now be reassigned automatically (without you needing to formally request a license reset from us) when installing WSEE onto a new server, or when changing/upgrading the existing server’s hardware configuration, so long as 30+ days have lapsed since the last license assignment occurred. • Miscellaneous source code fixes and improvements.
➡ (6/20/2022): Version 10.0.14393.4169 (Revision 17) → • Fixed issue where licensing could inadvertently become invalid on some systems. • Miscellaneous source code fixes and improvements.
➡ (8/4/2022): Version 10.0.14393.4169 (Revision 18) → • Improved exception handling and logging procedures. • Miscellaneous source code fixes and improvements.
➡ (8/28/2022): Version 10.0.14393.4169 (Revision 19) → • Improved update available health alerts.
• (8/31/2022): Removed support for builds of Windows Server Preview (i.e., Windows Server vNext) that were hard coded to expire on September 15, 2022 (i.e., all builds prior to Build 25192).
• (9/1/2022): Fixed issue where the Default Web Site would fail to start, due to port conflicts with the Windows Sync Share service, after performing an in place upgrade while WSE WorkFolders is installed and Work Folders has been enabled. NOTE: Work Folders will need to be re-enabled (via the “Enable Work Folders” task on the “WORK FOLDERS” page of the server Dashboard) after performing an in place upgrade.
➡ (11/21/2022): Version 10.0.14393.4169 (Revision 20) → • Fixed issue where licensing could inadvertently become invalid when licensing server cannot be reached. • Improved exception handling and logging procedures. • Miscellaneous source code fixes and improvements.
➡ (7/4/2023): Version 10.0.14393.4169 (Revision 21) → • Temporary fix for issue where the server would inadvertently shutdown due to old licensing server being taken offline.
➡ (7/12/2023): Version 10.0.14393.4169 (Revision 22) → • Permanent fix for issue where the server could inadvertently shutdown when the licensing server cannot be reached for any reason. • The WSEE Installer license will now be reassigned automatically (without you needing to formally request a license reset from us) when installing WSEE onto a new server, or when changing/upgrading the existing server’s hardware configuration, so long as 3+ days have lapsed since the last license assignment occurred. • Improved exception handling and logging procedures. • Miscellaneous source code fixes and improvements.
➡ (7/14/2023): Version 10.0.14393.4169 (Revision 23) → • Improved exception handling and logging procedures. • Miscellaneous source code fixes and improvements.
• (10/30/2023): Removed support for builds of Windows Server Preview (i.e., Windows Server vNext) that were hard coded to expire on September 15, 2023 (i.e., all builds prior to Build 25951).
• (1/26/2024): Removed support for builds of Windows Server Preview (i.e., Windows Server vNext) that were still branded as Windows Server 2022 (i.e., all builds prior to Build 26040).
➡ (2/26/2024): Version 10.0.14393.4169 (Revision 24) → • Configured IIS with SSL/TLS deployment best practices. • Fixed issue where configuring Anywhere Access using a Microsoft personalized domain name (https://<YourDomainPrefix>.remotewebaccess.com) fails when connecting to the Microsoft personalized domain name service provider with the following (timeout) error:
An error occured while setting up your domain name
The domain name was not set up for your server. Wait a few minutes and run the wizard again.
An unknown error occurred. Please wait a few minutes, and then try again.
EDIT (3/15/2024): This appears to be caused by an issue over on Microsoft’s end seeing as it is occurring under Windows Server 2016 Essentials as well.
EDIT (5/10/2024): Microsoft seems to have corrected the issue now. However, I STRONGLY recommend that folks avoid these types of (frequent and lengthy) interruptions in the future by setting up a custom/vanity domain name instead.
➡ (2/29/2024): Version 10.0.14393.4169 (Revision 25) → • Fixed issue where Windows Update fails to connect to the update service, under Windows Server 2022/2025, after IIS has been configured with SSL/TLS deployment best practices via the prior Revision 24 release. • Miscellaneous source code fixes and improvements.
➡ (4/27/2024): Version 10.0.14393.4169 (Revision 26) → • Added support for automatically (properly) renewing a free Let’s Encrypt SSL certificate on Windows Server Essentials (via Certify the web) when manually setting up a custom/vanity domain name in Anywhere Access. NOTE: With the remotewebaccess.com Microsoft personalized domain names becoming less and less reliable as Windows Server Essentials draws closer to its end of life date (January 12, 2027), I now STRONGLY recommend that folks avoid the (frequent and lengthy) interruptions by setting up their own custom/vanity domain name in Anywhere Access instead. We have a step-by-step guide that walks you through doing just that over here: How To Manually Set Up A Custom / Vanity Domain Name In Windows Server Essentials • Miscellaneous source code fixes and improvements.
• (5/10/2024): Added support for Windows Server 2025 Preview Build 26212 (i.e., the next version of Windows Server with the new Windows 11 style Graphical User Interface). See: Announcing Windows Server Preview Build 26212 — Enjoy! 😎
TheDoc says:
Hi, are you saying that if I buy WSE WorkFolders basic or even starter edition, I get password to download the WSEE MSI file?
Regards Han
Mike says:
Yes, you sure do… If you purchase, or happen to already own, ANY of our products, then you can simply contact us via our email support form and request the password for downloading the WSEE Installer package (i.e. the MSI file). Just be sure to include the User Name from your existing (or newly purchased) license when making your request.
TheDoc says:
Hi, thanks for your reply, I’ll look around for something that fits my needs. Lots of people are looking for an easy way to get experience role back in server 2019. You should just sell the msi I would say.
Mike says:
The WSEE Installer package was initially built for our own internal use only. However, since it ended up working so well, we decided that making it available to our customers (at no additional charge) would be a nice way of saying thank you to them for supporting us by purchasing our products. Unfortunately, we are not able to sell the MSI file directly seeing as the Essentials ‘bits’ it installs are not ours to sell (i.e. they belong to Microsoft).
A.C.Tanner says:
Thanks for the step-by-step instructions, and thanks for making them free! I administer a church network using WSEE 2016, and software assurance gives us the Server 2019 Essentials for free, so I am interested in using it instead of the Standard or Datacenter versions to upgrade. Is there any way of adding the Remote Desktop Gateway role? It’s a really big component of our setup. If I could add it, and then follow your instructions, I would be a “very happy camper”! Thanks.
Mike says:
You’re most welcome for the step-by-step instructions. I hope that you enjoy using Windows Server Essentials Experience on Windows Server 2019. I know that I sure am. 😉
Alas, I’m afraid that I don’t know of any way to add the Remote Desktop Gateway server role to Windows Server 2019 Essentials (at least not without putting in waaay more work than I’m willing to attempt at this point in time). I understand your predicament, but for most folks, it’s just easier to use Standard or Datacenter than it would be to try and go down that road (as I’m sure that it will be chalked full of pitfalls).
While you can follow the steps above to install WSEE on Windows Server 2019 Essentials, and end up with a semi-functional Essentials setup, you won’t be able to use its Anywhere Access / Remote Web Access features (which are probably the most useful features of the entire Essentials package).
Bob Jones says:
How Much Would You Charge For The MSI File? Ive followed the instructions but had nothing but problems throughout the entire process.
Mike says:
As mentioned in my comments above, we’re not selling the WSEE Installer seeing as it was only ever intended to be for our own internal use (and seeing as we don’t want to be committed to providing long term technical support for it, etc.). However, since it ended up working so well, we decided to just go ahead and make it freely available to our existing customers as a simple way of saying thank you to them for all of their support.
So… If you really want to “buy” it (so to speak), then you can always just purchase one of our products (such as one of the lower priced editions of our WSE RemoteApp or WSE WorkFolders products), and then use your newly received registration info (i.e. User Name) in order to submit a request for the download password via our email support form.
Other than that, I’d be more than happy to try and help you through any problems that you may be having with manually installing WSEE on Server 2019 if you’d care to elaborate on the specifics (without you needing to buy anything at all from us).
Ralph says:
Hi,
Thank you for posting this item.
I’m getting stuck at 73% of the installation Start-WssConfigurationService. Where can i begin to troubleshoot the proces.
Kind Regard
Ralph
Mike says:
Are you certain that you are starting with a completely clean/fresh install of Windows Server 2019 Standard or Datacenter (that has no other server roles, features or applications installed)?
Is your Windows Server 2019 Standard or Datacenter install fully up-to-date with all of the latest Windows Updates installed on it? And what about your Windows Server 2016 (Standard, Datacenter or Essentials) source?
Are you using an English (en-us) language install of both Windows Server 2019 and Windows Server 2016? While it “should” work with any language, I’ve only ever tested it under English (en-us).
I’ve performed the WSEE installation on Windows Server 2019 (using the exact steps listed above) dozens and dozens of times now, and I’m not seeing any issues with it here. Typically when the installation stalls at a certain percentage like that, it means that you’re missing something that’s required for it to continue (such as a specific file, registry entry, etc.). Are you absolutely certain that you’ve followed the steps EXACTLY as I’ve outlined them (and that you haven’t missed or omitted any of the steps)?
Other than that, you can try looking in the Logs folder just to see if any of the log files in there happen to list something that gives you a clue as to why the installation is getting stuck. You can find the Logs folder at the following location on the server:
C:\ProgramData\Microsoft\Windows Server\Logs
I typically sort the folder by date modified and then start looking through the log files from top down. You can open the log files in Notepad, and the newest entries will be listed down at the very bottom of the file (so start there and then move upwards looking for any clues as to what might be causing the problem).
You can also try opening the Event Viewer applet (Control Panel → Administrative Tools → Event Viewer) and taking a look in the Windows Logs → Applications log file just to see if it happens to show anything in there as well.
Bob Jones says:
Hi, Ive Re run through all the steps on a new fresh install and have gotten further but i am stuck at starting the start-wssConfigurationService. Here Is What I Get. Any Suggestions?
Start-WssConfigurationService : Cannot start service WseNtfSvc on computer ‘.’.
At line:1 char:1
+ Start-WssConfigurationService
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : NotSpecified: (:) [Start-WssConfigurationService], InvalidOperationException
+ FullyQualifiedErrorId : System.InvalidOperationException,Microsoft.WindowsServerSolutions.Setup.Commands.InvokeE
ssentialsConfigureServiceCommand
Mike says:
Looks like it’s failing to start the “Windows Server Essentials Notification Service” (WseNtfSvc) on your server. The eight “SC CREATE” commands listed in my above post create all of the required services for WSEE on the server, but they don’t actually start them. The individual services are physically started by the Start-WssConfigurationService PowerShell cmdlet, and it appears that that particular service is failing to start for you.
Are you sure that you ran all eight of the “SC CREATE” commands from an elevated command prompt (i.e. “Run as Administrator”), and in the exact order shown? Did any (or all) of the “SC CREATE” commands return an error, or did they all complete successfully?
Maybe you can try opening up the Services applet on the server (Control Panel → Administrative Tools → Services) and check to see if you can manually start all eight of the services that start with “Windows Server Essentials” from there (the only one that doesn’t actually need to be running is the “Windows Server Essentials Email Service” – WseEmailSvc).
If you’re not able to start any/all of the services manually, then you’ll need to checkout the log files (as I mentioned previously) in order to see if you can find out why the service(s) won’t start (e.g. file not found, missing registry entries, etc.).
In the mean time, I’ll go ahead and install WSEE on Windows Server 2019 Standard again (following the above steps) just to see if I can reproduce your issue here.
Mike says:
Okay, I just tried it again here and it is working perfectly for me. No issues whatsoever.
I started with the English evaluation ISO of Windows Server 2019, selected the Standard with GUI installation option, updated the resulting Windows Server 2019 Standard install to the latest OS Build 17763.168 (checked via running WinVer.exe) using Windows Update, and then I walked through all eight of the manual install steps listed above. After two or three server restarts, Get-WssConfigurationStatus -ShowProgress indicates 100% progress and zero errors. After that, the server Dashboard application starts up and runs just as expected.
So… The manual install steps seem to be working just fine. There must be something that you’re missing (or omitting). Are you absolutely certain that you’ve got all of the folders/files (including the 151 GAL folders), registry entries, etc. correctly installed onto Windows Server 2019?
Are you feeding the Get-Credential and Start-WssConfigurationService PowerShell cmdlets the proper parameters? There are four bracketed ([…]) values that you need to replace with your own specific entries for your specific server (while keeping them surrounded by quotes).
Other than that, you might want to try using our WSEE Installer instead (seeing as it automates all of this and makes installing WSEE on Windows Server 2019 a total breeze).
Bob Jones says:
Hi, Thanks For The Reply. All 8 SC Create Commands were created successfully. When I try to start the service I get “The Windows Server Essentials Provider Registry Service service terminated unexpectedly. It has done this 3 time(s).” When I Start Other Services It Requires This One To Be Started First. In The Log File I Get (Listed Below). I Don’t Know if the Files I Pulled From My 2016 Server Are Bad. Everyone Else Seems To Be Having No Problems At All Or Getting Further Than I Got. Ive Done 5 Fresh Installs Of 2019 With Both Data Center And Standard Just To See But Same Results. If I Use A Fresh Version of 2016 To Grab The Files From Would That Make A Difference Over A 3 Year Old Running Updated Version? Thanks 🙂
[4752] 181206.191752.2341: PRS: Information: [0] : OnStart: service "ServiceProviderRegistry" starting up.[4752] 181206.191752.3437: PRS: Information: [0] : This is a server, so our server registry is the local one.
[4752] 181206.191752.3468: PRS: Information: [0] : Not joined to domain, or setup in progress.
[4752] 181206.191752.3483: PRS: Information: [0] : Finished Provider Registry Service Initialization
[4752] 181206.191752.3502: PRS: Information: [0] : Starting to open host...
[4752] 181206.191752.3995: WssgCertMgmt: Found 0 matching certs without verification:
[4752] 181206.191752.4016: WssgCertMgmt: Collection Empty
[4752] 181206.191752.4041: IDENTITY: Local machine cert not found, trying to import the root cert backup to fix
[4752] 181206.191752.4057: IDENTITY: Starting certutil.exe process
[4752] 181206.191752.4621: IDENTITY: Process Exit Code: 0
[4752] 181206.191752.4626: IDENTITY: root "Trusted Root Certification Authorities"
[4752] 181206.191752.4631: IDENTITY: Signature matches Public Key
Mike says:
Ah, that’s what you’re doing wrong then…
When the Essentials configuration wizard runs, it modifies some of the required files and registry entries. Therefore, you should NOT be starting with an existing Windows Server 2016 Essentials install as your source. Instead, you want to start with a completely clean/fresh Windows Server 2016 install that has the WSEE server role installed (note that the Essentials SKU has the WSEE role installed by default). The key here is that you want to cancel out of the Essentials configuration wizard before it completes (i.e. you DO NOT want to run/complete the configuration wizard). After doing that, you can then run Windows Update as many times as it takes to get the installation fully up-to-date (which, as of this writing, is OS Build 14393.2641). Once you’ve got a fully up-to-date Windows Server 2016 install, where the configuration wizard has NOT been completed yet, then you can use that as your source for copying out all of the required files and registry entries.
I hope that helps you out some (and I’m sorry if that wasn’t made clear in my list of steps above – I’ve now edited the first step to try and make this a bit more clear for everyone).
Bob Jones says:
Thanks For The Info. I Will Give It A Shot. I really Appreciate All The Help 😀
Bob Jones says:
Hi, Just A Quick Update. I Ran Through All The Steps And Used All New Files From A Fresh Server 2016 And Bam Worked Like A Charm. Just Wanted To Say Thank you For All The Help. Much Appreciated 😀
Mike says:
That’s great news! Thanks for taking the time to let me know that you got it working. I’m glad that we were able to discover what the issue was. Enjoy using WSEE on Windows Server 2019!
Bobby Mangrum says:
Wow what a great guide that took all your time and efforts to make. Thank you so much and it works great!
Mike says:
You are most welcome. I’m glad to hear that it’s working well for you. Enjoy using WSEE on Windows Server 2019!
Jürgen Breitag says:
Hello Mike
first sorry for my english it´s not perfect especially the times. Understanding is perfect 😉
i ran in problems installing the wsse role in my 2019 datacenter.
ok let me begin at the start.
i had run a 2016 datacenter at home with essentials role installed. And i realy spent work in setup my home network with all clients auto backup all pictures from all phones, connect from everywhere with the phones to the “cloud storage at my home”. it was more a project for play and to check what could be done.
Then i was stupid and had bad luck, i got a license for the 2019 datacenter from an good friend that works in a it company. because i am not totaly stupid i done a server-backup from c:\ (bare metal) and after that an inplace upgrade. after the upgrade i regonized oh there is no more the essentials stuff inside.
i thought no problem i have a backup.
and there was the bad luck. Sector read error on the backup hdd .-(
SO what to do now a destroyed system because startet restore interupted with the read error. No running server any more and every client in home is asking for the server network drives.
i have to start a new setup from ground, and then i found you tutorial here. So why not use the new 2019 with the functions i need.
i done a fresh install from the 2019 datacenter and extracted every thing i need from the 2016 install.wim
the only thing i done differnt from your tutorial is the extraction from the HKEY_CLASSES_ROOT registry stuff. i did not understand how to mount HKCR with imagex. but i found in the internet that these keys where also stored in hklm so i used that keys and copied them in hkcr from my installation.
end of the day Start-WssConfigurationService interupts at 83% and i have no clue what to do.
Could you please help me? i would pay you a beer per paypal freinds.
Because it is no working system only a home system (could only be nude pics found of my wife maybe 😉 ) i have no problem to let you log in via remotedesktop if you could then better help me.
greetings
Jürgen
Mike says:
Sorry to hear about the corruption of your backup data. That really stinks, but it’s a good lesson learned as to why we should never rely on a single backup source for our important data. Ouch!
As I mentioned in a prior comment, when Start-WssConfigurationService hangs/fails at a certain percentage like that, it generally indicates that something (such as a file, registry entry, etc.) is missing or in a state that is not what’s being expected. Since you mentioned that you are using the ADK method to extract the source files from the install.wim file of your Windows Server 2016 installation disk/ISO, perhaps you should forgo using that method and try using the alternative method that I mentioned instead (where you use a completely new/clean install of Windows Server 2016 Standard, Datacenter, or Essentials that is fully up-to-date, but hasn’t had the Windows Server Essentials Configuration wizard run/completed yet).
Other than that, you might want to try using our WSEE Installer instead (seeing as it automates all of the hard stuff and makes installing WSEE on Windows Server 2019 a total breeze).
Jürgen Breitag says:
Mike i used now your wsee.msi over top of my try. Started wsee setup again, it began at 75% and ran to 100%. Every thing works now, as it should. And it is 100% in german. So I think your installer works with International versions without a problem. Only thing I ask me is what happens when Microsoft release a new big update. Sometimes it use the same inplace routine like the upgrade from 2016 to 2019. Will the wsee role then every time be deleted? Mhhhh. We see in future.
Thanks for your work with the wsee.msi.
Greets from Germany.
Jürgen
P.s. work folder is nice.
Mike says:
That’s great news! I’m very glad to hear that the WSEE Installer worked for you.
I assume that you must of been most of the way there with your manual install attempt, and that the MSI simply got you past whatever was missing and hanging you up on the last step.
As for the German language working… That’s most likely because you had already copied over all of the required German language files during your attempt to manually install WSEE on Windows Server 2019. WSEE then recognized those files and used them to display its UI in German instead of English. As of right now, our WSEE Installer only installs the English (en-us) language files. However, if I get enough requests, I may incorporate the required files for other languages as well (starting with German since it seems to be the most popular language for our customers other than English that is).
Regarding “what happens when Microsoft release a new big update”… I assume that you’re asking what would happen if you upgraded Windows Server 2019 to a newer version of Windows Server (such as Windows Server 2022, etc.)? If so, then I don’t really know at this point. However, I can tell you that we’re not actually installing WSEE as a server role here, and so I doubt the installer would recognize and remove it (as happened to you when you upgraded from Windows Server 2016 to Windows Server 2019). Instead, it should just be treated as any other installed .NET application would be and survive the upgrade process intact. However, whether all of the required server roles, etc. would exist in the newer version of Windows Server is completely unknown at this point. That’s at least 3 years down the road, and so I’m not going to worry about it now. Also, WSEE from Windows Server 2016 would be getting pretty long in the tooth by then, and so maybe it would indeed be time to move on to some other solution at that point. Who knows though.
Anyway… I’m glad to hear that you are finding WSE WorkFolders a nice addition to your Essentials server. If you like Work Folders, you should check out WSE RemoteApp as it’s absolutely AMAZING! But then again, I’m a bit biased seeing as I’m the one who wrote it. 🙂
Enjoy using WSEE on Windows Server 2019!
Jürgen Breitag says:
No did not mean a version upgrade of Windows like 2016 to 2019, mean a partial update like the fall creators update.This also installs a new image of windows but same version of windows like befor.
Spent allready the last night Hours in front of my Server, to restore every thing (drive pools etc.) Allmost done, tomorrow i pair the client Pc´s with the new server and then it is done.
greets
Jürgen
Mike says:
As far as I’m aware, Microsoft does not provide “feature updates” like that to their server operating systems (they only do that for Windows 10). Typically a newer version of Windows Server like that would be labeled a “R2” release by Microsoft, and it would actually be considered a completely new version of Windows Server (e.g. “Windows Server 2019 R2”). Therefore, you shouldn’t need to worry about something like that happening.
As for the standard Windows Updates for Windows Server… Since all of the Essentials components are taken straight from Windows Server 2016 (and not modified or changed in any way), any updates/fixes/changes that Microsoft happens to make to 2016, can easily be brought over to 2019 as well.
For example, while it’s quite rare that Microsoft updates/fixes/changes anything at all in Essentials any more (seeing as they’ve pretty much abandoned it now), one of the recent Windows Updates for Windows Server 2016 (i.e. OS Build 14393.2641) actually did contain two updated Essentials files (i.e. AlertViewerSubTab.dll version 10.0.14393.2636 and WSSBackupRepair.exe version 10.0.14393,2608). And, all that needs to be done in order to update an older WSEE install running on Windows Server 2019 is to simply overwrite those two files with their newer versions. Easy peasy!
BTW, before that, I don’t believe there had been any changes made to any of the Essentials components since May or June of 2018. And of course, our current WSEE Installer is based off of OS Build 14393.2641, so it already has those updated Essentials files integrated (otherwise, you could just manually copy them over from a fully up-to-date Windows Server 2016 install).
Joseph Ozdemir says:
Hi Mike,
Thanks for such a useful guide! I did an in-place upgrade to Server 2019 yesterday and found out very quickly that the Essentials role was not included.
I just wanted to add something which I hope will assist someone in the same boat as me. I already had a pre-configured domain and did not want to pick that apart or do a fresh install just to get this to work (My backup plan was just to run a Server 2016 VM).
I went through all of the steps as above, however, when I reached step 8 I stopped, manually started the newly created WSEE services and everything *I required* was working. I feel that’s worth noting as my main requirement was for easy configuration of Anywhere Access.
All of those steps could be done without a restart for me.
The only outstanding issue is that I can’t get the Email service to start, but I haven’t had a need to troubleshoot that just yet as I don’t require it.
Thanks again for the time taken to put this together!
Regards,
Joseph
Mike says:
I’m very glad to hear that you’ve found my guide for installing WSEE on Windows Server 2019 useful, and that WSEE is working well for you on Windows Server 2019.
I have never tested installing WSEE on a Windows Server 2016 server that was forcefully upgraded to Windows Server 2019 seeing as I always HIGHLY recommend folks start with a completely new/clean install of Windows Server (Standard or Datacenter) instead. I assume that since your server was previously configured with the WSEE server role before you upgraded it to Windows Server 2019, that most of the configuration (of the domain controller, etc.) survived the upgrade process and that’s why things are working for you. However, I also assume that if you did attempt to run the Start-WssConfigurationService PowerShell cmdlet that it would fail at some point (due to your server already being set up as a primary domain controller, having the CA already installed on it, etc.). It is very interesting that WSEE is working for you without running the cmdlet though (kudos!). I’m not exactly sure of everything that is set up and configured by the configuration cmdlet, and so I assume that if you ever encounter any oddities with your WSEE install, that they will stem from you not actually running Start-WssConfigurationService. For most folks, I think it’s far better to put in the extra work and start with a completely new/clean Windows Server 2019 install then it is to attempt to upgrade a pre-existing Windows Server 2016 (Essentials or Standard/Datacenter with the WSEE server role) install seeing as they’re much more likely to succeed that way (and not run into any issues down the line).
That being said… I have tested (multiple times) using our WSEE Installer to install WSEE on a Windows Server 2019 server that is already domain joined (i.e. that’s running as a member server and not acting as the primary domain controller), and that works just great. Admittedly though, I have never tried doing that manually via the Start-WssConfigurationService PowerShell cmdlet (although the configuration wizard does call Start-WssConfigurationService, and so I assume that doing so would work just fine as well).
As for the Email service not starting… I think that’s completely normal seeing as it most likely will not be able to start until you have set up the Exchange Server Integration (and/or the Microsoft Office 365 Integration) functionality from within the server Dashboard (i.e. it’s probably missing the components that it needs to run until such time as the wizard has added and configured them). Admittedly though, I have never tested this functionality either seeing as we don’t actually use that feature here on any of our in-house Essentials servers.
Thanks for sharing your findings, and enjoy using WSEE on Windows Server 2019!
Andrew Macaulay says:
Two questions about your installer:
1. Will you be updating the 2016 source every so often to make sure that the Essentials Role components are up-to-date for new installations?
2. Once you have installed Essentials “Role” this way, what is your recommendation for the best way to keep the files up-to-date? Would you suggest keeping a small VM with 2016 able to keep updated and then doing some for of version checking between the VM and the 2019 installed code (maybe a PowerShell Script to do this, and then update if needed)?
Thinking about doing this on my Home Server as I would like to have access to the improved Hyper-V, the Linux subsystem and containers from 2019 on my home server to run up some home automation stuff (without having yet more hardware) but need to see how manageable it will be….
Mike says:
I will definitely be keeping a watchful eye over the future Windows Server 2016 updates to see if Microsoft makes any changes to the WSEE source files. And if they do, I will indeed incorporate the updated source files into a newer version of our WSEE Installer (in order to ensure that all new installations are fully up-to-date). As of this writing, the current WSEE Installer is based off of Windows Server 2016 OS Build 14393.2641 seeing as that is the last known build of Windows Server 2016 that had any changes made to the WSEE source files.
That being said… I would pretty much consider WSEE as “abandonware” now seeing as I seriously doubt that Microsoft will be releasing (m)any updates for it over the coming months/years ahead. Therefore, it might just be easier for me to specify exactly which files have changed, and then you guys can go ahead and manually overwrite those files with their newer versions as required.
For example, Windows Server 2016 OS Build 14393.2641 has two updated WSEE source files in it (i.e. AlertViewerSubTab.dll version 10.0.14393.2636 and WSSBackupRepair.exe version 10.0.14393,2608) and so if you happened to of used the older version of our WSEE Installer (i.e. Version 1.0.0.0), then you could simply update your WSEE install (to Version 10.0.14393.2641) by simply overwriting those two source files with their newer versions (taken from any fully up-to-date installation of Windows Server 2016 Essentials).
Again though, I don’t foresee Microsoft making (m)any changes to the WSEE source files from here on out, and so the amount of work required in order to keep WSEE up-to-date on Windows Server 2019 really should be quite minimal IMHO.
Gary says:
I’ve reached Step 8. I’ve created the new admin credential but I keep getting an error when trying to start the WssConfigurationService. What should I be using as the domain? The machine isn’t joined to any domain as I hoped to make it a DC once I’ve complete the Essentials piece. I’ve had no issues to this point. Any assistance you could provide would be greatly appreciated!
Mike says:
Windows Server Essentials Experience MUST be or see a domain controller.
Under a normal set up (where you’re not running it as a member server and joining it to an existing domain controller), the Start-WssConfigurationService cmdlet will configure the Essentials server as your primary domain controller. Therefore, the -NetBiosName parameter used in step 8 should be set to the domain name that you want to use for your Essentials server. For example, my company name is “The Office Maven”, and so the domain name that I’d most likely want to use would be “TheOfficeMaven” (i.e. just my company name without any spaces or other illegal characters).
Jonathan says:
Hi Mike,
thanks for putting so much effort into this guide. One question tho:
How does the licencing work? Do we have to buy a bunch of [expensive] CALs for Server 2019, or can we use the 25 users included in Essentials? If the latter, that’s great as we can only afford the “basic Essentials package” with 25 users included for our small business. Giving me a hint on this matter would be great.
Greetings from Germany, Jonathan
Mike says:
You are most welcome. It took a crazy amount of work to figure all of this out (and write it up, etc.), so I’m very glad to hear that folks are indeed appreciative.
As for licensing… That’s kind of a gray area seeing as you’re actually installing WSEE on Windows Server 2019 here (i.e. where Microsoft never intended it to be installed). However, I assume that you’d have to treat it exactly the same as you would when you install the WSEE server role on Windows Server 2016 Standard or Datacenter. And in such a case, Microsoft requires CALs for each Remote Web Access user. For more information see the fourth and fifth paragraphs in:
Understanding Licensing for Windows Server 2012 R2 Essentials and the Windows Server Essentials Experience role
Since you cannot install WSEE on the Windows Server 2019 Essentials SKU (seeing as Microsoft has stripped all of the Remote Desktop Services server roles out of it, and WSEE requires the Remote Desktop Gateway server role in order to be able to use its Anywhere Access/Remote Web Access functionality), you don’t get to utilize the “theoretical” 25 user CALs that typically accompany the Essentials SKU.
That being said… Unless you’re in a situation where you’ll be audited by Microsoft (which I seriously doubt that you are), then there are no “CAL police” that are ever going to come knocking on your front door checking to see if you have them. Also, since WSEE doesn’t use Remote Desktop Services, there is no licensing server available, and so there’s no place to enter in CALs even if you wanted to. However, if you still want to be “legit” with Microsoft’s licensing, then you can simply buy the (cRaZy expensive) CALs and keep them tucked away in your desk drawer should you ever need to produce them (which I seriously doubt that you ever will).
♫♪♬ The CAL police
They live inside of my head
The CAL police
They come to me in my bed
The CAL police
They’re coming to arrest me
Oh no ♫♪♬
I’m certainly not a Microsoft licensing specialist though, and so please do take all of this with a grain of salt. If you’re really worried about Microsoft’s licensing, then you’d be MUCH better off just sticking with Windows Server 2016 Essentials instead.
TheDoc says:
Working now for 3 months with this Server 2019 with essentials role installed and I absoutely love it. Thanks for all the work you did on this and would recommend for all (home) users coming from server 2016.
Mike says:
That’s great news! Thanks for taking the time to post back and let us all know. It’s been working really great for us here as well.
You are most welcome. I’m super glad that I was able to get WSEE working on Windows Server 2019 for everyone. It was a real shame that Microsoft killed it off when there’s still such a high demand for it.
Take care.
Rey Will says:
I have tried this a few times with fresh, updated installs and keep getting this error, any ideas of what I am doing wrong?
Start-WssConfigurationService : A parameter cannot be found that matches parameter name 'CompanyName'.At line:1 char:31
+ Start-WssConfigurationService -CompanyName “Rey Technologies” -NetBio ...
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Start-WssConfigurationService], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.WindowsServerSolutions.Setup.Commands.
InvokeEssentialsConfigureServiceCommand
Mike says:
Hmm… That’s a strange one as based on the limited amount of what I can see in that error, it appears that the -CompanyName parameter is indeed there and it’s correctly set. The only thing I can think of off the top of my head is that you should make certain that you’re using standard straight quotes, and not fancy curly quotes, around all of your passed in parameter values.
Also, make sure that you’re passing in all five of the expected parameters just as I’ve shown in my example (i.e. -CompanyName “[your company name here]”, -NetBiosName “[your domain name here]”, -NewAdminCredential $cred, -ComputerName “[your server’s name here]”, and -Setting “All”). While I don’t believe that it’s required, maybe try surrounding the word All in quotes in the -Setting parameter just to see if that helps any.
Other than that, take a look at the Start-WssConfigurationService cmdlet’s documentation that I linked you to in my example and ensure that you’re entering everything correctly.
Lastly, I’m assuming that your $cred variable has been properly set beforehand using the Get-Credential cmdlet just as I’ve shown in my example.
Dan says:
Mine was working perfectly thanks to this guide, although now for some reason it is broken? Has this happened to anybody else (possibly a windows update)?
I cannot get Windows Server Essentials Management Service to run, it’s set to auto but I cannot get to to force start. Also the email service is broken.
Mike says:
We’re not seeing any issues whatsoever here… All of our Windows Server 2019 with WSEE installed servers are kept fully up-to-date via Windows Updates, and they are all currently running the latest OS Build 17763.316 (and all of them have been moved up through the OS Build ranks via Windows Updates starting from the original OS Build 17763.1 RTM release). All services are starting and running normally (although we don’t use any of the features that make use of the Windows Server Essentials Email Service, and so that service is never running on any of our in-house servers).
Bruce LeRoy says:
Is there a way someone could make a video and post it on how to do this? You guys lost me at “mount and extract using ADK.”
Mike says:
Alas, I’m not much good at making videos, and so there definitely won’t be one coming from me. Perhaps someone else will step up and produce one for the community.
Other than that… You don’t need to use the ADK to get things accomplished. Rather you can completely skip using the ADK method I’ve mentioned and just grab all of the required files straight from a clean/fresh installation of Windows Server 2016 instead. Just make sure that you grab all of the required files and registry entries BEFORE the Essentials configuration wizard has been run/completed (seeing as the configuration wizard modifies/changes some of the files and registry entries, and we don’t want that to take place since it will mess things up when trying to install WSEE over on the Server 2019 side)!
For Windows Server 2016 Essentials, simply CANCEL OUT OF the configuration wizard when it appears, run Windows Update until it’s fully up-to-date, and then grab all of the required files and registry entries. For Windows Server 2016 Standard or Datacenter, open the Server Manager, add the “Windows Server Essentials Experience” (WSEE) server role, but DO NOT complete the configuration wizard. Then run windows Update until it’s fully up-to-date, and grab the required files and registry entries. That’s pretty much all there is to it.
If you’re still having trouble, then I’d highly recommend that you try using our WSEE Installer package instead seeing as it takes care of all the “techie” stuff for you. It makes installing WSEE on Windows Server 2019 a total breeze!
Mike says:
💡 FYI: I’ve just added a really nice feature to our WSE RemoteApp 2016 product (Version 1.255.1604.0 or greater when running under Windows Server 2019) that takes advantage of Microsoft’s new performance counters in Windows Server 2019 in order to show “User Input Delay” (i.e. mouse and keyboard usage delay/lag) and “CPU Usage” directly on the server Dashboard’s “WSE REMOTEAPP” –> “Users” details pane. This new feature should go a long way towards helping you diagnose poor application performance within your user’s active remote sessions (i.e. bad end-user RemoteApp experiences).
Basically, you can use this feature to quickly view the correlation between mouse/keyboard usage lag in your user’s remote sessions, and CPU usage on the server (as CPU usage increases due to an increased number of active remote sessions/load on the server, the User Input Delay will start increasing sharply as the server begins running out of available resources). For further details on Microsoft’s new “User Input Delay” performance counters in Windows Server 2019 see:
Use performance counters to diagnose app performance problems on Remote Desktop Session Hosts
theglow says:
I have tried 3 times and keep getting stuck on Step 8. These are the steps I’m doing.
Server 2016 Standard:
I start with a virtual machine and install Server 2016 Standard, I do not activate. I have a license but want to make sure I can successfully install this first. After install, I add WSEE roll but do not complete/promote the server. I then install all available updates. Once fully updated, I locate the all folders and copy them. I then export all the registry keys.
Server 2019 Standard:
I install Server 2019 Standard on a virtual machine ( again do not activate). I change server name to “SERVER.” After a restart, I run all the updates. Then I proceed with installing the rolls in Step 2. I then copy back all the folders in Step 3 and 4. Now, in Step 5, I just double click on the registry keys to install. I do not manually import them using “Regedit.” Steps 6 and 7 are installed without any issue. At this point I noticed that all the “Windows Essential” services are “disabled” and not running. I set them to start “automatically” but I am unable to start the services. I proceed with Step 8 with the following;
$cred = Get-Credential -UserName “Admin” -Message “Specify the password for your existing domain administrator account.”
then
Start-WssConfigurationService -CompanyName “Starbucks” -NetBiosName “Bucks” -NewAdminCredential $cred -ComputerName “SERVER” -Setting All
I get the following error: “A parameter cannot be found that matches parameter name ‘Setting’.”
I keep getting stuck here and I’m not certain what I’m doing wrong. Your help is very much appreciated.
Also, is there a way that you can show us in detail how to make the WSEE Installer Package (MSI file) to avoid all the steps? The Microsoft links are extremely confusion.
Thank you!!
Mike says:
First off, you do not need to activate your Windows Server 2016 (source) install, nor your Windows Server 2019 (destination) install for any of this to work. Using the (un-activated) evaluation editions (downloaded straight from Microsoft’s website) will work just fine (and you can always convert the evaluation edition of Windows Server 2019 into a full retail edition later on using the method that I’ve described in the main article above).
Typically, when things fail at step #8, it means that you’ve missed something when sourcing the files, folders, and registry settings from your Windows Server 2016 source. While it sounds like you’ve done all of your sourcing properly, I have no way of knowing if you’ve successfully grabbed everything that’s actually required or not. I’ve never seen that particular error before, but it appears to be coming from the PowerShell script files. Thus, are you certain that you’ve properly sourced the “WssCmdlets” and “WssSetupCmdlets” module folders from your Windows Server 2016 source install as indicated in step #3?
Additionally, there is no need for you to name your server and manually start any of the Essentials services before performing step #8, seeing as all of that is handled for you by the “Start-WssConfigurationService” cmdlet that’s being run in step #8 (and in fact, doing so, may actually end up causing problems to arise when the cmdlet is run; therefore, it is best just to let the cmdlet handle doing all of that for you). You should be starting with a 100% clean/fresh install of Windows Server 2019 exactly as it comes after doing a straight-out-of-the-box install. Don’t mess with it one little bit before performing the manual WSEE install steps.
Lastly, our WSEE Installer package is built using Visual Studio 2019 and the Windows Installer XML (WiX) toolset. It is quite involved (seeing as a lot of work was put in in order to get it to successfully use the Essentials configuration wizard), and so it is not something that I plan on attempting to walk folks through building here (as doing so would take pages and pages of explanation, etc.). Therefore, if you’re interested in using our WSEE Installer package, then you can simply license one of our products and put in a request for it. The WSEE Installer is by far and away the easiest way to install WSEE on Windows Server 2019 seeing as it takes care of everything for you.
theglow says:
Thank you for your quick reply. I tried one more time and I’m still getting stuck on Step 8. I decided to try something different. Instead of running the full script, I just ran “Start-WssConfigurationService” only. It quickly asked me for the “NetBiosName” followed by a prompt to select “Y” to preceed with the installation. After a restart, the WSEE was installed successfully!! Although, it didn’t change the server name or the company name but that’s not a big deal, I’ll try again and change the server name manually before running the script.
One last question, since all the WSEE install files are copied to the “System32\Essentials” folder, can the WSEE wizard be installed using the GUI as show on your screen shots instead of running a PowerShell script? If so, which wizard do I run since there are several wizards in that folder. Again, thank you for all your help!!
Mike says:
Typically, running the “Start-WssConfigurationService” PowerShell cmdlet without any parameters (other than the -Credentials parameter) is reserved for configuring Essentials as a “member server” where it has already been manually joined to an existing domain (via the native Windows tools). I’ve personally never attempted to use it in any other way. I am glad to hear that you’ve managed to get it (somewhat) working though. I still have absolutely no idea why the cmdlet is giving you that error about the -Setting parameter no being found when you attempt to use it as stated in my list of steps. I’m not able to reproduce that issue here, and as far as I’m aware, no one else is having a similar issue.
As for your other question… Our WSEE Installer uses the Configure Windows Server Essentials wizard when installing WSEE on Windows Server 2019 (as is shown by the screenshots posted in the main article above). While the wizard is really just a graphical user interface (GUI) for running the “Start-WssConfigurationService” PowerShell cmdlet, it performs some other system checks in order to verify that everything was properly installed/configured by the WSEE server role. Obviously, since the WSEE server role doesn’t exist under Windows Server 2019, the wizard will fail if you attempt to manually run it from the “%System32%\Essentials” folder. I had to jump through all kinds of hoops in order to get it to work properly via our WSEE Installer package. And, it’s way too involved for me to try and attempt to explain it all here. Thus, it’s just easier for those who are wanting to manually install WSEE on Windows Server 2019 to use the PowerShell cmdlet directly instead.
Believe me, if it was easy, then I would of instructed folks to use the wizard instead of the PowerShell cmdlet. I tried to make the list of manual install steps as easy to follow as possible for folks (and since it’s already quite an involved process, I didn’t want to further complicate things by sending everyone down unnecessary rabbit holes).
Bobby says:
It is great and still working but I have an alert that says my firewall is not configured correctly and I think it was after installing remote acess. Do you have any thoughts on what may be the problem? Thanks in advance.
Mike says:
This one is addressed in the fourth paragraph/bullet point of the “Suggestions, Limitations, and Known Issues” section of the main article (above). Basically, it’s just a benign “false positive” error that you can safely ignore.
Bobby says:
Thank You
Antoon says:
Thanks for this nice tutorial! I’m still undecided whether to install the Server Essentials Experience on my Server 2019 Datacenter, as it is not officially supported. As I have a licence for Server 2016 Essentials lying around, I guess I could also install it as a virtual machine on my Server 2019, right?
Mike says:
Yes, you certainly could install the Hyper-V server role on your Windows Server 2019 Datacenter installation (making it your Hyper-V host), and then set up Windows Server 2016 Essentials as a Virtual Machine within Hyper-V.
Heck, you could even go a step further and set up a second copy of Windows Server 2019 Datacenter as a Virtual Machine as well, and then install WSEE on it by following the list of manual install steps given above. You could then easily switch between Windows Server 2016 Essentials and Windows Server 2019 with WSEE installed as desired (by simply spinning up the appropriate VM in Hyper-V).
Antoon says:
Hi Mike,
That’s a great idea! Indeed, installing it on a Windows Server 2019 Datacenter VM allows me to try out the WSEE on Server 2019 with zero risk. Thank you! Just bought WSE Workfolders 🙂
Craig Humphrey says:
FYI Managed to get this working on a server that I had completed an in-place upgrade from Server 2016 Standard (+ Essentials) to Server 2918 Standard. (Teach me for not spotting that Essentials had been removed)
It might not be quite 100% (Health service says it’s not configured, but it is. Remote Access complains, but works….) but so far it’s working for everything that I’ve used. Will have to wait and see what happens with the client backups…
Thanks so much for providing this resource!
Mike says:
Glad to hear that you’ve managed to get it working. Thanks for letting us know.
I’ve never personally attempted installing WSEE on a server that was in-place upgraded from Windows Server 2016 to Windows Server 2019 (and I doubt that I ever will seeing as I feel you should always start with a completely clean/fresh installation of Windows Server 2019), but it’s good to hear that folks are getting it to work.
johnnyblazing says:
Is there anyway you could do a step by step video and host it on Youtube. Also I realize you said that you can’t host the free file on your server, you you be willing to host the free file on one of the free cloud servers like https://mega.nz, or Dropbox, etc.
Mike says:
As I mentioned in another comment above, I’m no good at making videos, and so there definitely won’t be one coming from me. Maybe someone else will step up and make one for you guys who are requesting it. Personally, I don’t think that there’s any real need seeing as the installation is fairly straight forward as long as you follow the manual install steps I’ve provided (and EXACTLY as given).
As for your other question… I have no plans on ever hosting our WSSE Installer package on any file sharing site, etc. As I mentioned above, the installer was written strictly for our own internal use (and was never intended to be distributed to the general public). However, we’ve decided to offer limited (and temporary) access to it for our paying customers as a simple thank you for all of their support over the years.
Besides that, there are quite literally thousands of files involved in the installation, and so there’s a HUGE number of places for some unruly sole to hide their nasties in. Thus, I would NEVER trust installing ANYTHING on any of my servers that was downloaded from a public file sharing site without 100% being able to verify where it came form, what’s in it, and who created it. Yikes!
That being said… There’s no real need for anyone to have/use an installer. While it does make things a bit easier seeing as you don’t have to source the files for yourself, if you follow the list of manual install steps I’ve provided above (EXACTLY as given), installing WSEE on Windows Server 2019 is pretty easy.
johnnyblazing says:
Well I’m sorry to hear that. I’ve tried to do this 5 times with no luck. The instructions were not completely clear to me. I guess this isn’t for everyone to do.
johnnyblazing says:
At step 3 you say copy the 7 folder from:to my question is copy them from the server 2016 installation but to where? Same for step 4, copy them to where? and when did you switch over to server 2019, considering you starting at step 1 talking about server 2016
Mike says:
Other than sourcing the specified folders/files and registry entries from a clean/fresh Windows Server 2016 install (where the Essentials configuration wizard has NOT been run/completed yet), all eight of the steps I’ve listed take place over on your (clean/fresh) Windows Server 2019 (Standard or Datacenter) installation.
When I say “from/to”… I mean “from 2016” / “to 2019”. For example, in step #3, you would copy the “C:\Program Files\Windows Server” folder (and all of its files and subfolders) “from” your Windows Server 2016 source over “to” the exact same location on your Windows Server 2019 installation (using copy/paste or drag n drop).
Same goes for the registry entries (for which you should use the Registry Editor in 2016 to export the specified registry entries “from” your Windows Server 2016 source, and then use the Registry Editor again in 2019 to import all of the exported .reg files “to” your Windows Server 2019 installation).
If you are having difficulties, then I suggest that you double/tripple-check your sourcing of the folders/files and registry entries from your Windows Server 2016 source, seeing as that’s where most folks seem to be going astray. The biggest tip I can offer here is to MAKE SURE THAT YOUR WINDOWS SERVER 2016 SOURCE HAS NOT HAD THE ESSENTIALS CONFIGURATION WIZARD RUN YET, AND THAT YOU HAVE RUN WINDOWS UPDATE ON IT TO ENSURE THAT IT HAS ALL OF THE LATEST UPDATES.
johnnyblazing says:
Last question, am I using a windows server 2016 standard or windows server 2016 essential as my source
Mike says:
As the source… You can use either Windows Server 2016 Essentials, or Windows Server 2016 Standard/Datacenter with the Windows Server Essentials Experience (WSEE) server role installed.
NOTE: Under the 2016 “Essentials” SKU, the WSEE server role is installed by default (and is mandatory). Under 2016 Standard/Datacenter, the WSEE server role is not installed by default, and needs to be manually installed via the Server Manager.
IMPORTANT: Under the 2016 “Essentials” SKU, you need to be sure that you cancel out of the Windows Server Essentials Configuration wizard when it first appears seeing as you DO NOT want the wizard to complete since it modifies some of the files and registry entries (and we don’t want that to happen yet!). After you cancel out of the wizard, go ahead and run Windows Update (over and over) until the server is fully up-to-date. Under Standard/Datacenter, use the Server Manager to install the WSEE server role, but DO NOT complete the Windows Server Essentials Configuration wizard (for the same reasons I’ve listed above). Go ahead and run Windows Update (over and over) until the server is fully up-to-date.
As the destination… You should use Windows Server 2019 Standard/Datacenter. The 2019 “Essentials” SKU should NOT be used seeing as it does not contain the Remote Desktop Gateway server role that is required in order to make the Anywhere Access/Remote Web Access feature of “Essentials” work (unless you simply don’t care about that feature, and only intend to use WSEE for its offline client PC backup features, etc.).
EDIT: BTW, I don’t mind helping out with questions if you have them. If you’re stuck, ask away, and I’ll do my best to try and help you get unstuck.
johnnyblazing says:
Steps 6, 7, 8 all are giving me errors, I’ve copied the cmd screen errors (step 6 &7) and the powershell errors (step 8) and save them to a notepad. Maybe you can solve this for me. Let me know if I can send them to you.
Mike says:
Please don’t take offense, but quite honestly, if you’re receiving that many errors and are having that much trouble getting the manual install steps to work, then I highly suggest that you find someone locally who knows a bit more about working with servers to help you out. It’s truly not that difficult. IMHO the hardest part of the entire process is properly sourcing all of the folders/files and registry entries from a clean/fresh (and fully up-to-date) Windows Server 2016 source. Once you’ve got that part right, then the rest should all just fall into place. Sometimes it’s good to have a second pair of eyes that can spot something that you’re simply overlooking (i.e. one of those “if it were a snake, it would of bit me” kind of moments).
Other than that… If you’d like to copy the text of the error messages here, then I’ll see what I can make of them for you. Alternatively, please feel free to start a new topic over on our Community Support forum seeing as you can post screenshots/images over there.
johnnyblazing says:
No offense taken, All of the steps taken were easy and error free for me up to step 6, when I typed this code in that you had posted it gave me errors. All of them for from step 6. I figured maybe I typed something wrong, so I saved the webpage as a pdf, which then allowed me to simply copy the code and paste them one by one and still the outcome was the same. I’m familiar with working with servers and I’ve currently been running my own home server for well over 5 years. This happens to be the first time for me installing a service from this approach, so it took me a moment to follow you instructions. But again I thank you for your patience and for providing the instructions for all of us that haven’t purchased software from you. Thank you. So, what might I be doing wrong with your code?
SC CREATE “WseStorageSvc” start= disabled binpath=
“%SystemRoot%\System32\Essentials\storageservice.exe” depend= rpcss/samss/vds/winmgmt
DisplayName= “Windows Server Essentials Storage Service”
Mike says:
The command line that you’ve indicated looks just fine to me (i.e. I don’t see anything wrong with it). The only suggestions that I can offer you there is:
1. Make sure that all of the quotes surrounding the values are standard straight quotes (and not those fancy curly quotes).
2. Make sure that the command prompt window that you’re entering the command line into has been started with elevated privileges (i.e. make sure that you’ve started it using the “Run as administrator” option). Otherwise, the command line will most certainly fail (seeing as it requires elevated privileges in order to be successfully run).
And yes… I do realize that this website is locked down from standard select/copy operations making it difficult for folks to grab the manual list of steps. My apologies for that. However, you do have a nice suggestion to print (i.e. save) the page as a PDF file so that you can then easily grab the web page’s text from the PDF. Thanks for sharing that tip.
johnnyblazing says:
I’ve done all of the things you suggested in your reply to me. I copied exactly what you had listed and pasted it in an elevated command prompt. Can you show me exactly what response I should see after running anyone of these commands.
Mike says:
The documentation for Microsoft’s SC tool (Sc.exe) can be found here:
How to create a Windows service by using Sc.exe
As far as I remember, the tool just silently returns back to the command prompt on success. Otherwise, it will list an error on failure.
Since you’re using the SC tool to create a service, you can also verify that the service has been successfully created, after you’ve run the command, by simply opening up the “Services” applet (i.e. Control Panel → Administrative Tools → Services) and then searching through the list of available services for the service that you’ve just created (e.g. “Windows Server Essentials Storage Service“, etc.). Or, you can open an elevated PowerShell prompt and type:
Get-Service -DisplayName "Windows Server Essentials*"That cmdlet will simply display the current status of all the Windows Server Essentials services that have been created on the server (note that the services should all initially have a status of “Disabled” since they get created in the Disabled state, and they don’t get moved to the Running state until the Start-WssConfigurationService cmdlet actually enables and starts them during the Essentials configuration process).
johnnyblazing says:
This is the command I copied, paste and ran:
SC CREATE “WseStorageSvc” start= disabled binpath= “%SystemRoot%\System32\Essentials\storageservice.exe” depend= rpcss/samss/vds/winmgmt DisplayName= “Windows Server Essentials Storage Service”
This is the error message it returned:
At line:2 char:55+ “%SystemRoot%\System32\Essentials\storageservice.exe” depend= rpcss/s ...
+ ~~~~~~~
Unexpected token 'depend=' in expression or statement.
+ CategoryInfo : ParserError: (:) [], ParentContainsErrorRecordException
+ FullyQualifiedErrorId : UnexpectedToken
Mike says:
Strange…
If you type the following command into the command prompt:
SC CREATE /?You’ll see:
depend= [Dependencies(separated by / (forward slash))]Which indicates that the list of dependencies should be separated by a forward slash (just as I have them in in step #6). However, the documentation I linked you to states that the dependencies should be surrounded by quotes and separated by spaces. I assume that’s old behavior, but you might want to give that a try just to see what happens. For example:
depend= "rpcss samss vds winmgmt"I’ve never come across a case where using the forward slashes (and not surrounding them in quotes) didn’t work though. I have no idea why you’re seeing that issue???
EDIT: BTW, make sure that the SC CREATE text that you’re pasting into the command line window doesn’t have any line separators within it (i.e. make sure that it’s just one continuous line of text and not broken up into multiple lines). To verify this, try pasting the text into Notepad first and making sure that there’s just one single line of text. If it’s not, then you’ll need to remove the line breaks. That’s probably where your issue lies.
johnnyblazing says:
Success Success, I can’t believe it was that simple. Mike you were 100% right, I wasn’t making the code all one line, I pasted it in notepad, made the correction, now it’s good. Thank you so very much.
EDIT (M.C.): That’s great news! I’m glad to hear that resolved the issue for you. I’ve now added an edit to the very bottom of the list of manual install steps that cautions folks to check for line breaks within their copied/pasted commands so that they hopefully don’t run into the same issue. Oh, and BTW, it appears that comment nesting can only go up 10 levels deep, and so I had to edit your comment since I couldn’t reply to it.
Sidney says:
For those having trouble with step 8, I found that you’ll need to make sure that you’re copying the required files with something like robocopy. It allows you to preserve file permissions etc. What I ended up doing was mounting the C drive of the server 2016 with WSEE installed and then copying the files over one by one. For example:
robocopy “z:\Program Files\Windows Server” “c:\Program Files\Windows Server” /E /COPYALL
After numerous attempts at trying to fix file permissions, I eventually gave up and started with a fresh 2019 install. After copying the files as suggested above, it worked perfectly.
Thanks to Mike for this excellent article!
Mike says:
You are most welcome.
Thanks for sharing the heads up on this one.
Sidney says:
Oh and also I forgot to mention. I just left out the -Setting parameter. That just sets how Windows update should work. It runs fine without that parameter and you could always manually configure Windows updates afterward.
See the Start-WssConfigurationService article linked above for more info.
Frank says:
Hi Mike,
We ran into an issue where we are setting up 2019 without realizing it lacked WSEE and our client doesn’t have access to 2016 media. Any chance you can provide a password so I can download the MSI file that you guys built? I really appreciate any assistance you can give. Thanks!
Mike says:
Contact us via our Support page (making sure that you include the User Name from your purchased product), and we’ll be more than happy to provide you with access to the WSEE Installer package.
Jon Langford says:
Hi, is it possible to purchase the installer for WSEE on Server 2019 without purchasing one of your products please?
Although I’ve worked in IT for many years the guide isn’t straight forward for me to follow 🙁
Thanks!
Jon
Mike says:
As mentioned above, we’re not selling the WSEE Installer package. The installer was only built for our own internal use, and it was never designed/set up to be a commercial product (i.e. it’s contents are not ours to sell, we can’t provide long-term technical support for it, etc., etc., etc.). If you don’t already own (or don’t want to own) any of our products, then you can simply follow the list of manual install steps I’ve provided above in order to get WSEE installed on Windows Server 2019. The WSEE Installer just automates those exact steps anyway. The steps shouldn’t be too difficult to follow (especially for someone with an IT background).
Jon Langford says:
Thanks Mike, I think $50 for the Student RemoteApp 2016 is a decent price to pay just to get Anywhere Access on my Windows 2019 Server and I may use that feature too 🙂
A quick question, do you recommend that after the initial installation of Server 2019 that I should install WSEE before I join to the domain and install other roles or features? Or can I do it at any point?
Many thanks
Jon
Mike says:
If you want to join your 2019 server to an existing domain (i.e. run it as a member server), then you MUST do that (using the native tools in Windows) BEFORE you install WSEE. Otherwise, WSEE will automatically configure the server as your primary domain controller (seeing as that’s the way Essentials sets itself up by default).
Jon Langford says:
Thanks Mike. So I have an existing domain now based on Server 2012 R2 with an additional Hyper-V VM (Server 2016) which is also a DC.
My aim is to build a new Server 2019 server, install HyperV, reattach the Server 2016 DC (I’ll make sure it has all the roles), then join my Server 2019 to the domain and promote to a DC. Then install WSEE.
Does that sound like a plan? 🙂
Mike says:
Not 100% sure that I’m following you there (seeing as there’s a whole lot of DCs happening within that paragraph), but yes, overall it does sound like a decent plan. That being said… I highly suggest folks always start with a clean/fresh install of Windows Server 2019 without any other roles, features, applications, etc. adding to the complexity of the situation (as that way it’s much easier to figure out and resolve any problems that may occur along the way). However, I do understand that some folks prefer to run Essentials as a member server, rather than having it be the primary DC. Good luck, and enjoy using WSEE on Windows Server 2019!
Jon Langford says:
Hi Mike,
I realise it’s Good Friday but I placed an order for WSE2016 Student Edition in the hope I could get an installer for WSEE 2109…. I don’t suppose you could organise that today could you? 🙂
Thanks!
Jon
Mike says:
Done…
Thanks for your order, and enjoy using WSEE and WSE RemoteApp 2016 on Windows Server 2019.
Nick says:
so if i purchase a copy of wse workfolders 2016 i can access the wsee installer package
Mike says:
See this comment and this comment posted above.
Nick says:
sorry did read post 2 and 3.
meant to write does it also count if one buy’s a Student version
Mike says:
In this comment I’ve mentioned “ANY of our products”, and so yes, that does indeed encompass the less expensive “Student Edition”. Which is also mentioned in the this comment as well.
johnnyblazing says:
Mike why was my last post deleted?
Mike says:
None of your posts have been deleted. I just nested them all underneath your original post (since you have so many, it’s much easier for others to follow them all that way). Simply scroll up a bit and you’ll see your last post, and my reply to it.
BTW, if you click the “Reply” link that’s located under your original post, or under any of my replies to it, then it will keep all of your posts neatly contained within the same topic thread (instead of adding a new separate post to the very bottom of the list each time you post something new).
Frank says:
How long should the MSI installer take? It’s been sitting here for 20 minutes or so on “Adding roles and features” Clearly it says it may take awhile but on the first server I tested this on in our lab it only took 5 minutes. Just want to make sure everything turns out the way it should. Thanks!
Mike says:
In most cases (unless you have a really slow server), I assume that it should indeed take less that 10 minutes to complete adding the required roles and features. I’ve personally never seen a case where it has taken longer than around 5 minutes to complete, and I’ve never seen a case where it has failed (or gotten stuck).
I’d say let it go for at least an hour before terminating the installer (via Task Manager). Since I’ve never encountered this particular issue before, I’m not exactly sure what will happen if you terminate the installer, and then attempt to run it again (i.e. I don’t know if it will fail on the second go around because it thinks WSEE has already been installed, or if it will simply start the install anew again).
Are you certain that you’re starting with a completely clean/fresh installation of Windows Server 2019 (Standard or Datacenter) where no other roles, features, applications, etc. have been installed on he server (yet)? If not, then I highly suggest that you do that (seeing as that’s the ONLY way I’ve ever tested the installer). Other than that, you could try manually installing the five prerequisite server roles and features (as shown in step #2 of the manual installation steps) if you continue running into issues here. That way, the required roles and features will already be installed when you run the WSEE Installer, and so it “should” just quickly move thorough that part of the installation process (instead of getting stuck). Manually installing the prerequisite server roles and features one-by-one (via an elevated PowerShell prompt) would also let you see if an error is popping up when they are getting installed.
Jon Langford says:
Hi Mike,
Many thanks for the WSSE 2019 Installer over the weekend, it eventually worked like a dream (took 2 rebuilds though!)… everything works as I expect except for one thing, the Remote Web Access Wesbite.
On my Server 2012 R2 I was able to see the Remote Web Access to provide my friends with Userhomes and access to files that I wanted to shre with them, however on Server 2019 I just get IIS.
I’ve checked the bindings, my Cert is in place, but even from IIS when I browse to 80 or 443 I just get the IIS default page.
There is a script that someone created to check Essentials installation (which admitedly does only support up to 2012) but that returned no errors either.
I ran a repair from WSSE – Anywhere Access and this showed no errors either… oddly I can still use Remote Web Access to get RDP accees to my server – which is actually what I really wanted it for.
Any ideas?
Many thanks
Jon
Jon Langford says:
Hi Mike,
An update to my message…. If I use https://xxxxxxxxxxxxxx.co.uk/remote it works…. Do you know how I could access the website without the /remote?
Thanks
Jon
Mike says:
That is the expected (default) behavior for the Remote Web Access website under Windows Server 2016 (and hence under Windows Server 2019 as well when you install WSEE from 2016 on it). It has nothing whatsoever to do with the WSEE Installer (i.e. it’s by design on Microsoft’s part).
I recommend that you use the feature exactly as Microsoft intends it to be used (by simply instructing your users to go to https://YourDomainPrefix.remotewebaccess.com/remote instead). Otherwise, you can look at the following web pages for information on how to use a redirect in order to go back to the old behavior:
Remote Web Access login page Redirect
Remote Web Access does not redirect as expected
Keith MacKenzie says:
Hi, this is intriguing. I am moving from a Essentials 2012 and would ike to use 2019. I have a clean server up nd running. One question how well does this hold up to regular windows updates? Any concerns there?
Mike says:
I don’t foresee any issues with Windows Updates down-the-line, but ya never know. If you’re overly concerned/cautious about it, then you’d probably be much better off just going with Windows Server 2016 Essentials instead (seeing as it will be fully supported by Microsoft for many years to come).
Geoff says:
Can this be added to Windows Server Essentials 2019 when you don’t have an existing setup to migrate or access to any of the files from a previous version.
Mike says:
Not sure I’m following exactly what it is that you’re asking here…
If you’re talking about using our WSEE Installer package to install WSEE on a clean/fresh install of Windows Server 2019 (Standard or Datacenter), then the answer is: Yes, that’s the preferred way to do it. You DO NOT want to start with a 2016 → 2019 migration (or in-place upgrade), and all of the source files and registry entries are handled for you by the WSEE Installer. It’s 100% plug-n-play!
If you’re talking about using the steps I’ve listed above in order to manually install WSEE on a clean/fresh install of Windows Server 2019 (Standard or Datacenter), then the answer is: Yes, but you will obviously need to have access to a Windows Server 2016 (Essentials, Standard, or Datacenter) source in order to be able to extract all of the required files and registry entries from.
G says:
Thanks for your reply, although to clarify you only mention (standard or datacenter) for your installer, does this work on the essentials version (new install).
As an alternative option to achieve this wouldn’t it be possible to just install the evaluation version of Windows Server 2016 Essentials, ensure that the WSEE role/feature is installed and running and then just do an upgrade to 2019 essentials and activate the new license code.
Mike says:
The Windows Server 2019 Essentials SKU is an ABOMINATION!
Not only does it have absolutely nothing at all to do with “Essentials” as we currently know it (due to Microsoft removing the WSEE server role from it), but Microsoft has also removed all of the Remote Desktop Services server roles from it as well.
As a result, you cannot (i.e. should not) install WSEE on it seeing as there is no Remote Desktop Gateway server role available, and so the Anywhere Access / Remote Web Access feature of Essentials will not work (which, is probably the most used feature of Essentials, along with client PC backup). Therefore, you’re MUCH better off just using Standard or Datacenter instead.
As an alternative option to achieve this wouldn't it be possible to just install the evaluation version of Windows Server 2016 Essentials, ensure that the WSEE role/feature is installed and running and then just do an upgrade to 2019 essentials and activate the new license code.Alas, I’m afraid it doesn’t work like that. When you do an in-place upgrade of Windows Server 2016 Essentials to Windows Server 2019 Essentials, Microsoft forcefully removes all of the “Essentials” bits (i.e. the WSEE server role), as well as all of the Remote Desktop Services server roles (including the Remote Desktop Gateway server role). All you’re left with is the abomination that is Windows Server 2019 Essentials (i.e. a non-essential version of Essentials!).
corsario says:
Will this fix the issue with SodaPlayer casting to Chromecast?
Mike says:
I have absolutely no idea what those things are. However, since they are not part of the WSEE server role, I’d say that the answer to your question is most likely no.
Basically, if something doesn’t work in Windows Server 2016 Essentials, then the odds are good that it also won’t work in Windows Server 2019 with WSEE installed seeing as it is just a direct copy of the files from the WSEE server role of Windows Server 2016 being installed over on Windows Server 2019 (i.e. nothing is “hacked” or changed in any way – it’s just a one-to-one copy of the files taken from 2016 being installed on 2019 is all).
jriker1 says:
When you setup a standard Windows 2019 server, and add essentials to it, do you still need to make this the primary DC? I know with the other versions and the pure essentials versions, Essentials needs to be your primary DC and can’t be demoted. Curious if I eliminate my current 2016 Essentials server then implement this 2019 version, if I can make my secondary DC the primary and leave it that way.
Thanks.
JR
Mike says:
When you install WSEE on Windows Server 2019 Standard or Datacenter, you can indeed configure it as a member server where it is not the primary domain controller, but rather joined to another (existing) domain controller on your network. The key to doing so is that you must use the native Windows tools in order to domain join Windows Server 2019 Standard/Datacenter to your existing domain BEFORE you install WSEE on it. See:
How To Join Windows Server 2012 to a Domain
If you’re using our WSEE Installer, it will run the Windows Server Essentials Configuration wizard, and the wizard will recognize that the server is already joined to an existing domain, and then continue to set up Essentials as a member server. Otherwise, if you’re manually installing WSEE (via the steps I’ve listed above), then you just run the Start-WssConfigurationService PowerShell cmtlet without any additional parameters (as is mentioned in the last NOTE that’s shown in the manual install steps above).
For more info see:
Add Windows Server Essentials as a Member Server
jriker1 says:
Thanks Mike. Do you have any thoughts on how to migrate from Essentials 2016 to 2019 and retain the same IP and name? I am even thinking of using the same server. All my stuff is on an array on an E: and F: drive so was thinking of replacing the primary drives with new ones of the same kind and rebuilding 2019 following your guidance. I would just like to be able to tie it back to my existing backups and not have to have all our workstations have to rejoin the domain. Not sure if that’s possible or what I’d have to backup to restore all the workstation info and backups.
Thanks.
JR
Mike says:
Alas, I’m afraid not. I’ve never done a migration from any prior version of Essentials to Windows Server 2019 (nor even an in-place upgrade for that matter) seeing as I always highly suggest that folks start out with a completely clean/fresh install of Windows Server 2019 if they’re planning on installing WSEE on it.
Personally, I feel that unless you have some really pressing need to utilize features that are specific to Windows Server 2019, that you should simply stick with using Windows Server 2016 Essentials instead. Windows Server 2016 (Essentials/Standard/Datacenter) will be fully supported by Microsoft for a long time to come, and as far as the “Essentials” bits are concerned, there’s absolutely no difference whatsoever when running them under 2016 vs 2019 (especially seeing as you’re essentially just taking all of the “Essentials” bits from 2016 and simply installing them on 2019 here).
Other than that, if you’re bound and determined to do a migration from 2016 to 2019, then I suggest that you have a look at Mariëtte Knap’s Server Essentials Community website seeing as she is an expert on doing migrations and has lots of those types of guides and tutorials available over on her site.
Craig says:
FYI Don’t attempt to create tiered storage in Srv2019 + Essentials.
Windows Server 2016 RTM -Storage Pool Virtual Disk Tiers Mirrored using Powershell results in Layout: Empty and Provisioning: Unknown
So there was a long-standing bug in Srv2016, that was eventually fixed, but I can confirm that it’s back in Srv2019. And given that Srv2019 + Essentials is basically unsupported, I’m not expecting it to ever get fixed.
FYI I did an in-place upgrade of Srv2016 Standard + Essentials, to Srv2019 and then used the above instructions to re-install Essentials – most of the regkeys were already there, but the binaries weren’t. It kept the name and IP, etc.
Mike says:
Thanks for the heads up on the tiered storage issue. Since it was a pre-existing problem under Windows Server 2016 + Essentials, it doesn’t at all surprise me that it remains a problem under Windows Server 2019 + WSEE. And, as you’ve somewhat mentioned, Essentials 2016 is pretty much abandonware now, so I wouldn’t expect Microsoft to fix any bugs it has going forward unless they’re absolutely mission critical, or present serious security issues. 😮
Glad to hear that the in-place Windows Server 2016 + Essentials to Windows Server 2019 upgrade + WSEE install worked out for you. I typically don’t recommend anyone do that seeing as there are some files and registry entries that get modified when the WSEE server role gets configured on Windows Server 2016 + Essentials, and we want to start completely fresh without those files/registry modifications being there (so that they get modified appropriately when WSEE gets configured on Windows Server 2019).
That being said… If everything appears to be working fine for you, then kudos, and enjoy using WSEE on Windows Server 2019.
Mike says:
💡 FYI: Our WSEE Installer package is now available in Czech, Chinese (Simplified), Chinese (Traditional), Dutch, English, French, German, Italian, Japanese, Russian, Spanish, and Swedish.
EDIT (7/7/2019): Other languages that are available upon request:
Hungarian
Korean
Polish
Portuguese
Portuguese (Brazil)
Turkish
NOTE (6/26/2019): The language of the WSEE Installer that you use should match the base language of Windows Server 2019 that you have installed on your server (i.e. don’t mismatch the two languages).
TheDoc says:
Hi Mike, any chance of posting Dutch version?
Mike says:
Okay, a Dutch version has now been posted. 😉
TheDoc says:
Great, thanks again for your support and for making my Server 2019 Essentials running as a proper Essentials version for 8 months now without any issues. Most appreciated.
bobby says:
Mike has anyone posted a video on how to do this yet? If not I have one
Mike says:
Not as far as I know.
Please do feel free to post a link to yours if you’d like. I’m sure that folks would benefit from it.
Thanks!
bobby says:
ADD ESSENTIALS ROLE TO SERVER 2019 STEP BY STEP PART 1 AND PART 2
EDIT (M.C.): Apparently there is a charge to view this video. While I personally would of liked for it to have been a free benefit for the Essentials community (especially since it is most likely based off of the work done here), I do understand that it takes time and effort to produce such content (as well as the costs involved to host it, etc.). Because of this, I am unable to vouch for the accuracy of its contents, but I will go ahead and leave the link to it here for those who still wish to view it.
jriker1 says:
So if I did decide to trash my Essentials server and create a fresh install, how would I do that without loosing my domain? So in other words, I have a secondary domain controller, DNS, DHCP, etc. I’m assuming I would have to transfer the master role to the secondary one, however as long as it’s up doesn’t the essentials have to be the master? If I then build a 2019 server and add the essentials role would I need to switch it back to be the master or would that automatically happen? Guessing not since it’s not technically an Essentials server more a standard server with the role? Would all the computers still be on the domain or have to be added again?
Thanks.
JR
Mike says:
Personally, I always recommend starting with a clean/fresh install of Windows Server 2019 instead of trying to do a domain migration. I’d simply shut down the old Essentials server, and then set up the new Windows Server 2019 with WSEE server using the exact same computer name, domain name, IP address, etc.
That being said, there are others who have successfully done domain migrations from earlier versions of Essentials over to Windows Server 2019 with WSEE installed. In fact, see the comment right below this one for a link to a nice Microsoft article that walks you step-by-step through the entire domain migration process (including transferring all of the FSMO roles over to the new 2019-based domain controller, etc.). The process is identical to migrating any earlier version of Windows Server Essentials to Windows Server 2016 Essentials (seeing as the WSEE role from 2016 is simply being brought over “untouched” to 2019 here).
And yes, according to that document, you will indeed need to uninstall the Windows Server Essentials Connector software from all of your existing client PCs, and then install the newer version of it (from 2016). See the Microsoft-provided documentation for further details.
3434rrc says:
The WSEE installer worked great for me! However, I had a glitch to overcome as a result of my specific transition scenario, so wanted to do a quick post here to point out the problem (and workaround) for others.
My installation involved doing a migration from an existing Win 2012R2 Essentials Server DC to a new Win 2019 Server DC (with WSEE). While Microsoft provides a process for doing similar migrations (see Step 2: Install Windows Server Essentials as a new replica domain controller), an additional step is needed if the source server (in my case, the Win 2012R2 Server) was itself the destination of an earlier migration from an older server (in my case, SBS 2008).
After bringing up the new Win 2019 Server as a replica domain controller and installing the WSEE msi, I next invoked the WSEE Configurator. The configuration wizard successfully ran through the pre-requisites verification step and correctly identified the server as a domain controller. However, after it started the actual configuration process it stopped with the message:
“Configuration encountered some issues Please restart the server and then run the configuration wizard again. If this issue still exists please refer to the help link for more troubleshooting steps.”
Neither a server restart nor the help link were of any use in clearing the problem. 🙁
After looking through the logs under Event Viewer → Applications and Services Logs → Microsoft → Windows → Server Essentials Deployment → Deploy, I found errors indicating that the WseMgmtSvc service could not successfully start. Examining the service (the Windows Server Essentials Management Service) showed that it was configured with login account “ServerAdmin1”.
There is an older posting for WSEE at: The Post-Deployment Configuration task may fail after you install the Windows Server Essentials Experience role on Windows Server 2012 R2 which mentions the same error message and identifies accounts (in particular, “ServerAdmin”) that need to be present in the appropriate “Log in as a Service” group policy setting in order for the Essentials Configuration to successfully complete.
I added the “ServerAdmin1” account to the ‘Logon as a Service’ Group Policy (configured under Default Domain Controller Policy → Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → User Rights Assignment), forced the policy update (gpupdate /force), and then re-ran the Windows Essentials Configuration Wizard. This time, the Configuration Wizard ran to successful completion. 🙂
Not sure why this particular login account was chosen by the 2019’s WSEE installer, but I suspect it may have been due to the original server having had the Essentials Experience added to it when it was first configured (and the “ServerAdmin” account leftover in the AD).
Thanks once more to Mike for putting the new WSEE installer together. I’ll bet there would have been many other error paths I might have gone down without it!
Mike says:
Wow, that’s some terrific sleuthing going on there!
Thank you for taking the time to share with others how you managed to get the Windows Server 2012 R2 Essentials to Windows Server 2019 with WSEE domain migration working.
Without that Microsoft Support document link you found, I seriously doubt that I would of managed to figure out the error that you were getting from the “Configure Windows Server Essentials” wizard. That’s a really nice find!
Anyway, as I’ve mentioned in other comments here, I’ve never attempted a domain migration from any previous version of Essentials to Windows Server 2019 with WSEE installed. However, I’m very glad to hear that it can indeed be done.
Thanks again for sharing your experience with everyone, and you are most welcome for the WSEE Installer. I’m super glad to hear that it helped you get Essentials running under Windows Server 2019.
JIngol says:
Hello,
again. After i downloaded now the german version from your wsee.msi and tryed it i have some Problems.
I installed a fresh/clean W2019 Datacentre only installed you wsee.msi. To marry a client with the wsee is no Problem, but after i set up wich drives to backup i tryed to run the first backup. But no suckses, every time the Clientbackup service is crashing. But always at a different Time in the Backup. Sometimes early at 4% und once at 91% but no succes Backup. But it´s only crashing during a backup attemp.
I have no Idea what i could do that the one service is not crashing anymore. i really would like to get these w2019 with wsee to run properly.
King regards
JIngol says:
(Your edith time from comments is to short 😉 ok then again.)
On the same machine at a second harddisk is my primary w2019 with manual installed wsee (in english) and work without any problem. So i think it can´t be a problem hardware related.
I tryed it now with a german, well because it is nicer to read for a german. 😉
Mike says:
I’m not seeing any issues with client backups (i.e. they’re working just fine for us here). It’s certainly possible that there could be a localization issue going on there (since I’ve only ever tested the feature with an English WSEE install and English Windows 7/8/10 client PCs).
Please try looking in the following location on BOTH the client computer AND on the server itself to see if there are any log files that give you an idea as to why your client backups are failing:
C:\ProgramData\Microsoft\Windows Server\Logs
Just sort the log files within the folder by their modification date, and then look at the newly modified log files to see if you can find any information within them related to the client computer backup service crashing (i.e. open the log file in Notepad, scroll all the way to the bottom, and then work your way upwards).
EDIT (6/26/2019): Also, make sure that the language of the WSEE Installer that you’re using matches the base language of Windows Server 2019 that you currently have installed. For example, if you’ve installed a German language edition of Windows Server 2019 on your server, then make sure that you’re also using the German language edition of the WSEE Installer (i.e. don’t mismatch the two with different languages).
JIngol says:
Some news, client backup now is working. The Problem was some corruptet file in the clientbackup folder on the server and every time it was trying to acces that file the service on the server was crashing. Delted the folder and recreate it in the wsee dashboard than it was working.
But i now have a other Problem, after the backup was working i want to chance my second client to the new server. Every thing is fine expect, the second client shows allways offline. cmd Ping is working without problem from server and from client to each other. but on client the tray icon shows gray and server offline and server dashboard wsee shows client offline.
Have now add in lights out for the server the lights out bulp in tray on client shows server online.
Why cannt every thing work like it should out of box?
Tryed to uninstall kaspersky on client but that changed nothing. But befor uninstall every essentials app have all pewrmissions. And that client was working with the english server essentials without problems too with kaspersky installed.
Could you please give me again some hind where to search. The last hind with logs was good that was showing me the read error. But now i have no logs because after the marriage from client with server the client is allways offline so i cant set up even the backup.
Have static ip4s:
Server 192.168.1.2
Client 2: 192.168.1.8
Mike says:
Glad to hear that client backup is working for you now. As for your client connect issue… Since one of your clients is properly connecting to the server, that indicates to me that it has noting to do with installing WSEE on Windows Server 2019, but rather, that it’s probably just an issue that’s specific to that one particular client. Thus, about the best I can tell you here is to check out the log files (on both the client and server; and in the same location that I mentioned to you in my prior comment) to see if you can find any indication as to why the connection is failing.
Other than that, have you tried completely uninstalling the connector software from your client computer, and then reinstalling it again? Is the client computer properly joined to your Essentials domain? You may also want to take a look over in Microsoft’s Windows Server Essentials TechNet forum, or over on Robert Pearman’s Title (Required) website, to see if you can find any additional info about resolving client connection issues over there.
Good luck!
Mike says:
💡 FYI: You could also try running Robert Pearman’s Windows Server Essentials – Configuration Troubleshooter script to see if everything checks out okay with your server and clients. However, in order to successfully use the script on Windows Server 2019 (with WSEE), you will need to edit it by opening the script in a text reader (such as Notepad, etc.), and changing the following line (in two separate places) from:
$checkOS = $os.Contains("2016")to:
$checkOS = $os.Contains("2016") -or $os.Contains("2019")Lastly, note that the “Test Role Install” test will not be fully accurate under Windows Server 2019, and so you should disregard the results from that particular test.
Mike says:
💡 FYI: For those of you who are contemplating an in place upgrade from a previous version of Windows Server Essentials see:
In-place upgrade of Windows Server Essentials 2012 R2 to Windows Server Essentials 2016 on the same hardware
While I don’t typically recommend that folks go the in place upgrade route (i.e. IMHO you’re much better off just starting out with a brand new/clean installation instead), if you are going to attempt one, then I highly suggest that you only do the in place upgrade starting from Windows Server 2016 (where all of the files, registry entries, etc. are identical to the ones we’re using when installing WSEE on Windows Server 2019).
If you’re running an older version of Windows Server Essentials (such as Windows Server 2012 Essentials or Windows Server 2012 R2 Essentials) then you really should in place upgrade it to Windows Server 2016 Essentials first, and make sure everything is working properly, BEFORE you proceed on with the in place upgrade to Windows Server 2019 with WSEE.
That being said… I still can’t guarantee that the in place upgrades will work properly for you, even after going from 2012/2012 R2 → 2016 → 2019 with WSEE installed (via the WSEE Installer), but the odds are probably MUCH greater that you’ll be able to succeed when going the stepped/graduated route instead.
Good luck!
ADDITIONAL INFO (12/9/2020): When doing an in place upgrade of Windows Server 2016 Essentials to Windows Server 2019 Essentials, Microsoft forcefully removes all of the “Essentials” bits (i.e. the WSEE server role), as well as all of the Remote Desktop Services server roles (including the Remote Desktop Gateway server role). All you’re left with is the abomination that is the Windows Server 2019 Essentials SKU (i.e. a non-essential version of Essentials!). However, once you’ve completed the in place upgrade, you can then convert the SKU → Standard by running the following from an elevated command prompt:
DISM /online /Set-edition:ServerStandard /ProductKey:N69G4-B89J2-4G8F4-WWYCC-J464C /AcceptEulaAfter doing that, you can then run the WSEE Installer in order to install the Windows Server Essentials Experience on it (and you can activate it 4 free using abbodi’s KMS_VL_ALL script 😉 ).
EDIT (12/10/2020): For Windows Server 2016 Essentials → Windows Server 2019 Essentials in place upgrades, you can use the Windows Server 2019 Essentials installation media (ISO) that’s available on Microsoft’s evaluation center here (and then convert the SKU → Standard afterwards as per above). However, for Windows Server 2016 Standard/Datacenter (with or without the WSEE server role added) → Windows Server 2019 Standard/Datacenter in place upgrades, you will need to source and use retail (MSDN) installation media instead seeing as the evaluation editions that are available on Microsoft’s evaluation center do not support in place upgrades (i.e. the “Keep personal files and apps” installation option is disabled in the the eval editions).
SEE ALSO: How to In-Place Upgrade Windows Server 2008 R2 to Windows Server 2019
SEE ALSO: Mike’s reply to comment #4660 by kgoroway
CartierMas says:
Hi Mike,
Thanks very much for this. I have been trying to complete your detailed steps but get stuck at 70% with a failed status. When I load server manager it tells me that configuration is required for the Active Directory Certificate Services. I have tried a few times and get stuck at that place all the time. Any ideas?
Mas.
Mike says:
Are you starting with a completely clean/fresh out-of-the-box install of Windows Server 2019 Standard/Datacenter that has all of the latest Windows Updates installed on it (and no other server roles, features, or applications installed)?
Other than that, have you checked the log files (in C:\ProgramData\Microsoft\Windows Server\Logs) to see if they give any indication as to why the configuration process is failing?
You might also want to check:
Event Viewer → Windows Logs → Applications
and
Event Viewer → Applications and Services Logs → Microsoft → Windows → Server Essentials Deployment → Deploy
[Although, I can’t remember off the top of my head if the later one is only enabled when using our WSEE Installer or not.]
I’ve found that when you get a failure in the last step like that, it typically indicates that you’ve missed something when copying over the source files and/or registry entries from Windows Server 2016 Essentials (or from Windows Server 2016 Standard/Datacenter with the WSEE role added) to Windows Server 2019. Did you happen to run into any issues with any of the earlier steps?
Are you certain that you’ve used a copy of Windows Server 2016 Essentials, Standard, or Datacenter (as your source) that had all of the latest Windows Updates installed on it (i.e. OS Build 14393.2641 or greater), and where the Essentials configuration wizard had NOT been run/completed yet?
Lastly, if you’re running into repeated failures, that you just can’t seem to resolve, then I highly suggest that you try using our WSEE Installer instead. It takes care of everything for you (effortlessly in the background) so that these types of niggling annoyances don’t consume all of your time and energy.
CartierMas says:
Finally figured it out, spaces were needed where none were and some were where none were needed lol. I have yet to test remote connection using the connector but other then that it now works fine. I have to admit that what you did requires a lot of work (Believe me, I know having been a network analyst for more than 30 years) so congrats are in order, this is awesome!!!!!!! as for the installer, I will be bying it for my customers when needed but I wanted to test this on my own.
Thanks very much Mike, this is great.
CartierMas
txbd75 says:
I downloaded the WSEE Installer on a clean Windows Server 2019 Standard. I had to delete the virtual storage pool on my server since windows said it belonged to a different domain. On my first client, I had to delete the user associated with my old domain, since I’m trying to use the same domain name. It seemed to be working great – thanks!
The server is auto backing up, so that’s great! However, my first client (I haven’t tried any other machines) shows:
Status – Online
Backup Status – Not set up
Update Status – Upto to date
Security Status – In compliance
On the right panel, it says:
XXX-Desktop Tasks:
View the computer properties
Remove the computer
There is no task option for setting up the back or running the backup.
In Computer Tasks, there is a task for “Client computer backup tasks” which lets me set the client backup schedule and to “auto-enable backup when client computer connected” (which is turned on). PS – I turned it off and then on again, but no difference.
Any ideas on how I can setup the client computer backup?
txbd75 says:
Okay, realized that my storage space was just 10.9GB on a 10.9TB pool! My inability to create a client PC may be related to the tiny pool it initially created, which was only 10GB.
After a lot of exploration, I deleted the storage space, got the drives UNALLOCATED and I was able to create a storage pool in the 2019 Server Manager.
However, the Essentials Dashboard would not recognize it.
So I deleted the pool in Server Manager, got the 4 drives I have in the Primordial pool of available disks and went to the Essentials Dashboard. When I try to create the storage space in the Dashboard, it says to select drives to create the storage space, but none are shown. I clicked ‘formatted drives’ and nothing changes (The drives are unallocated in Computer Management).
Thoughts?
Mike says:
A “clean” (out-of-the-box) install of Windows Server 2019 would never have an existing storage space setup, and so you couldn’t really of been using a truly clean/fresh install of 2019 as you’ve stated. However, that being said… In all of our testing, we’ve found that the storage space feature/hooks in Windows Server Essentials, while running WSEE under 2019, work exactly the same as they do when running under 2016 (bugs and all). Therefore, I doubt that any issue you’re seeing with your drive pools, etc. has anything to do with specifically installing WSEE on 2019.
My guess is that you’d be seeing exactly the same behavior under 2016 as well. I’m no expert on storage spaces, and I’ve not tested it all that much under 2019 nor 2016 (seeing as I simply do not use that feature), and so I can’t really say for sure though. Maybe others with experience in this area will jump in and provide you with some further assistance. Other than that, I suggest that you try looking over on the Essentials boards of Microsoft’s TechNet user forums to see if you can find any related issues posted over there. A word of advice though, if you happen to make a post on those boards, I’d probably leave out the fact that you’re running WSEE on 2019 seeing as the “EULA police” will just point out that you’re not supposed to be doing that, and you simply won’t get any real help from them.
As for the client computer backup issue you’re having… Was that particular client computer domain joined to a previous Windows Server Essentials installation (2016, 2012 R2, etc.)? If so, then that’s most likely what’s causing the problem. Even if it wasn’t, I’d try completely uninstalling the “Client Connector for Windows Server Essentials” app from the client computer (via the “Programs and Features” applet that’s located in the Control Panel), deleting the “C:\Program Files\Windows Server” and “C:\ProgramData\Microsoft\Windows Server” folders, deleting the “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Server” and “HKEY_CURRENT_USER\SOFTWARE\Microsoft\Windows Server” registry key branches, and then reinstall the client connector again (by going to “http://YourServerNameOrIPAddress/connect” to download the connector setup program). After the (successful) reinstall of the connector software, make sure that its tray icon is green and shows that the client is properly connected up to the Essentials server (and not grey or red, which indicates a connection problem).
Lastly, please be aware that if your client computer is running Windows 10 1903, then there are LOTS of reports of issues with getting the client computer (successfully) connected up to the Essentials server appearing over on the Essentials boards. I’ve been advising folks to simply stay away from 1903 since it’s still supper buggy. It’s better to give Microsoft some time to fix all the known issues that it seems to have (i.e. it’s a total mess right now, and so I’d avoid it at all costs).
EDIT: Did you happen to see this related storage space (set up with combined HDD and SDD) comment, and read the linked forum post?
txbd75 says:
Working backward:
Storage Space comment: Yep, read that comment. If I create a storage space in WinServer 2019, outside of WSEE, you get those options. When I created a storage space outside of WSEE, I used this recommendation and the space gets created fine. However WSEE doesn’t see this space and I don’t know how to get WSEE to use it…. argh….
When I try creating the storage space files when using the WSEE Dashboard, it doesn’t give you any of those options to get into trouble. In the Dashboard, it fails during setup of the storage space (at about 20% mark, after “Preparing”, I think it goes to creating/formatting and then it says one of the drives is now offline or read only and it fails. Yeah, I checked and the selected drives are online, and I can put files over to the two test drives with no problems. Sigh…
Clean Install: I did a ‘clean install’ which wiped out the system drive all cleanly. However it does NOT wipe out the other drives, which contain my old 2016 storage space. When I saw it wouldn’t recognize the old space, I deleted the storage space and got the individual drives broken out (Storage space merges physical drives into a one virtual drive).
Good suggestion about looking in the essentials board – thanks for the link and the suggestion to stay out of trouble!
Mike says:
I’ve just tried setting up a very simple storage space (consisting of only two small HDDs) using the “Create a storage space” task that’s located on the “Hard Drives” subtab of the “STORAGE” page in the server Dashboard, when WSEE is installed on 2019, and it worked just fine for me here. There were no errors, and the storage space was recognized just fine by the server Dashboard.
Thus, I’m not exactly sure what’s going on with yours. Have you checked the “C:\ProgramData\Microsoft\Windows Server\Logs” folder over on the server just to see if anything is getting logged in there about the issue?
EDIT: Or perhaps in the Event Viewer applet under:
Windows Logs\Microsoft\Windows\Storage-Tiering
Windows Logs\Microsoft\Windows\StorageManagement
Windows Logs\Microsoft\Windows\StorageSpaces-XXXX
Other than that, maybe you can try completely wiping out your 2019 server setup, and this time around, try setting up the storage space (via the Server Manager) BEFORE you install WSEE on the server (I assume that you’ll need to add the “Storage Services” server role if it isn’t already added by default). That way you’re taking WSEE completely out of the picture.
If you manage to get the storage space successfully set up in 2019 (without WSEE installed), then you’ll know that you’ve got a valid starting point to work from. Once everything is working properly (i.e. when the storage space appears in the File Explorer, etc.), then go ahead and try installing WSEE on the server again and see what happens. Hopefully, the server Dashboard will recognize, and use, the storage space when you’ve set it up previously like that. Otherwise, we’ll have to assume that there’s a storage space bug/issue in 2019 that’s related to WSEE being installed on it.
Also, I assume that the drive pool you’re setting up isn’t comprised of a mix of HDDs and SSDs since that combo appears to present a known problem under 2019 and WSEE.
Mike says:
💡 FYI: If your users are running into issues when attempting to connect to the Essentials server (and/or to WSE RemoteApp 2016) from a Windows 10 client computer, then you should probably check to see if the client computer has recently been updated to version 1903 (by running winver.exe), seeing as that’s most likely what will be causing the problem.
Windows 10 version 1903 is a complete and utter mess IMHO. It has so many bugs/flaws in it that Microsoft should be ashamed of themselves for forcing it upon their users! 😡
Apparently when Windows 10 gets updated to version 1903, it wreaks havoc on the installed Windows Server Essentials Connector software (i.e. the Launchpad, etc.), and no longer allows it to properly connect the client computer to the Essentials server. And, since WSE RemoteApp 2016‘s client-side connector software relies upon the successful connection of the client computer and the server (seeing as it’s an Essentials client-side add-in), it also fails to make local (LAN) connections to the Essentials server after the Windows 10 version 1903 feature update has been installed.
Here’s what you can try in order to resolve the issue…
From the Windows 10 version 1903 client computer:
1. Open the Control Panel’s “Programs and Features” applet.
2. Locate the “Client Connector for Windows Server Essentials” program within the list of installed programs, and uninstall it.
3. (Optional) After the above program has been successfully uninstalled from the client computer, manually delete the following folders from the client computer if they happen to still exist:
C:\Program Files\Windows Server
C:\ProgramData\Microsoft\Windows Server
NOTE: The “C:\ProgramData” folder is a hidden system folder, and so you will need to ensure that you have set the “Show hidden files, folders, or drives” option that’s located on the “View” tab of the Control Panel’s “File Explorer Options” applet in order to be able to see the hidden system folder.
4. (Optional) Delete the following registry key branches (using Regedit.exe) from the client computer if they happen to still exist:
HKEY_CURRENT_USER\Software\Microsoft\Windows Server
HKEY_LOCAL_MACHINE\Software\Microsoft\Windows Server
5. (Optional) Open the Control Panel’s “Adminitrative Tools → Task Scheduler” applet and delete ALL of the tasks that exist within the following folder (if they still exist):
Task Scheduler Library\Microsoft\Windows\Windows Server Essentials
6. If you are using Microsoft’s “SkipDomainJoin” client connection method in order to skip the joining of the client computer to your domain, then add it back again as per:
Connect computers to a Windows Server Essentials server without joining the domain
7. Set the adapter settings/options for the network connection on the client computer so that its preferred IPv4 DNS server address is set to the static IP address of your Essentials server, and its alternate IPv4 DNS server address is set to the IP address of your network router or other DNS server as follows:
a) Open the Control Panel’s “Network and Sharing Center” applet.
b) Click on the “Change adapter settings” link.
c) Right-click on your network connection and select “Properties” from the context menu that appears.
d) Double-click the “Internet Protocol Version 4 (TCP/IPv4)” item.
e) Choose the “Use the following DNS server addresses” option and set the “Preferred DNS server” to the static IP address of your Essentials server (e.g. 192.168.1.100, etc.), and set the “Alternate DNS server” to the IP address of your network router (e.g. 192.168.1.1) or other DNS server (e.g. 8.8.8.8).
f) Click the “OK” button in order to save your changes.
Doing so will allow the client-side Windows Server Essentials Connector software’s installer to be able to successfully locate and connect the client computer to your Essentials server.
8. Reinstall the Windows Server Essentials Connector software on the client computer by browsing to http://<ServerName>/connect (where <ServerName> is the name of your Essentials server), as per:
Get Connected in Windows Server Essentials
That should do it!
NOTE: If the WSE RemoteApp client-side connector add-in isn’t installed on the client computer (when it should be), then do the following:
A) Open the server Dashboard and go to the “APPLICATIONS” page.
B) Select (highlight) the “WSE RemoteApp” application in the list of installed add-ins.
C) Click on the “Install the add-in on network computers” task and follow the prompts.
Hopefully that will get your users back up and running again (at least until Microsoft releases their next total disaster of a feature update for Windows 10 anyway 🙄 ).
EDIT (9/10/2019): For more info see the following thread over on Microsoft’s Windows Server Essentials TechNet forums: Windows 10 Feature Update 1903 disables Essentials Connector
MR.G says:
I actually run into this issue quite a bit with W10 bi-yearly updates screwing up the WSE connector on W10 computers joined to a domain. My solution is to uninstall the connector from the W10 computer, then run this command on a admin cmd prompt, then reinstall the connector from http://servername/connect web page.
reg add “HKLM\SOFTWARE\Microsoft\Windows Server\ClientDeployment” /v SkipDomainJoin /t REG_DWORD /d 1
It creates a registry entry that makes it so that when you reinstall WSE connector on domain joined computer, it will skip the domain join step and just install the connector software. This process takes a minute or two, but works every time 🙂
I found this information here Connect computers to a Windows Server Essentials server without joining the domain
Mike says:
Thanks for your reply.
Yes (as mentioned above), the SkipDomainJoin connection method is well documented by Microsoft over on their website:
Connect computers to a Windows Server Essentials server without joining the domain
The real question here is does your suggestion work if the client computer has previously been joined to the Essentials server’s domain (i.e. what happens when you reinstall the connector software using the SkipDomainJoin connection method when it is already domain joined)? I’ve never tested that particular scenario before.
That being said… I (personally) always use the SkipDomainJoin connection method when joining my client computers to the Essentials server’s domain seeing as I find it a pain to have the client computers domain joined. Don’t get me wrong here as I definitely see the advantages to having client computers joined to the domain for business use, but for personal/home office use, I prefer them not to be joined and skip all of the extra hassle that doing so brings along with it.
abacus says:
Hi,
Thanks for this. We upgraded from server 2016 Essentials to server 2019 standard before realising essentials was no longer included.
question: how can we revert to a state where we can comfortably run the WSEE installer file?
Mike says:
I’m afraid that I don’t really know the proper answer to that one seeing as I always start with a clean/fresh installation of Windows Server 2019 Standard or Datacenter and then install WSEE on it. That being said… There are folks here who have done in-place upgrades from Windows Server 2016 to Windows Server 2019, and then installed WSEE (which I certainly don’t recommend).
If it were me, I’d make sure that all of your data is backed up, and then I’d nuke the server and start over with a clean/fresh install of Windows Server 2019 before attempting to install WSEE on it. Or, even better, I’d simply restore the server back to Windows Server 2016 Essentials using your last good server backup and just be done with it.
Other than that, if you’re not going to heed my advice, then you can just cross your fingers and jump straight into the WSEE install and see what happens.
Good luck!
zman says:
Hi,
I was wondering if the WSEE Installer is supported on Windows Server 2019 Essentials or not? I was planning on upgrading to a newer Windows server OS soon. I wasn’t sure if I should go with Windows 2019 Essentials or Standard for a small business. I would like to still use the Essentials server roll option that Microsoft removed after server 2016.
Mike says:
The Windows Server 2019 Essentials SKU is an ABOMINATION!
While you can indeed install WSEE on the Windows Server 2019 Essentials SKU, doing so makes no sense IMHO seeing as Microsoft has removed all of the Remote Desktop Services (RDS) server roles from it, and as a result, the Remote Desktop Gateway server role (and hence Remote Web Access) is not available for use under the SKU.
Remote Web Access (RWA) is (arguably) one of the best features of WSEE, and so without it, WSEE is severely limited. That’s why I always recommend that folks simply skip using the Windows Server 2019 Essentials SKU, and just use Windows Server 2019 Standard or Datacenter instead (the silly “theoretical” CALs of the SKU don’t matter in the least, but the higher cost of Standard/Datacenter can indeed be a bit painful to swallow).
That being said… The early releases of our WSEE Installer package actually blocked themselves from being installed on the Windows Server 2019 Essentials SKU (mostly due to the fact that all of our add-ins require RWA, and so without it, there’s just no reason to install it on the SKU from our point of view). However, we’ve had a few users request that we still allow it to work seeing as they don’t want/need the RWA functionality in Essentials. Thus, the latest version of our WSEE Installer package now simply warns you if you are attempting to install it on the SKU (where you won’t be able to use RWA), but still allows you to proceed with the installation if you so desire.
zman says:
Will client backup work on WSEE within Windows Server 2019 like it does on Windows Home Server 2011?
Mike says:
Yes, the client backup feature in all versions of Windows Server Essentials (i.e. 2012, 2012 R2, 2016, and 2016 while running on 2019 with WSEE installed) is identical to the one that’s in Windows Home Server 2011.
zman says:
Mike,
You wouldn’t happen to know if the client backup would work on Windows Server 2019 Essentials with the WSEE installed?
The server I plan on upgrading doesn’t use the remote access feature on WSEE for a small business that doesn’t want any security risks involved.
They just want client backup feature available for use. Should I recommend Windows Server 2016 Essentials instead of Windows Server 2019 Essentials?
Mike says:
Yes the client backup feature does indeed work under the Essentials SKU. The only thing that doesn’t work is the Anywhere Access / Remote Web Access feature (since there’s no RD Gateway available for it to use).
IMHO, if you’re setting this up for a client, then you should give them Windows Server 2016 Essentials seeing as it is fully supported by Microsoft for many years to come. If they’re only after client backup, then they would receive no benefit whatsoever using 2019 over 2016. Thus, you might as well give them a platform that is fully supported by Microsoft.
withwolf1987 says:
Thank you for this post, this is a very cool “hack”. I hate that Microsoft abandon Server Essentinal with this great feature.
I tried a test installation in a VM.
Everything is working except third party plug-ins.
On my bare metal system, I`m using Lights-out3 and StableBit DrivePool.
In the VM, they won’t show up. There is no error during installation.
Do I have to copy some other Files or modify anything else?
withwolf1987 says:
Sorry, don’t know why, but in another VM it is working.
Mike says:
Very strange. I’m afraid that I have absolutely no idea what’s going on there. Glad to hear that you got the add-ins working in a different VM though.
Mike says:
I certainly wouldn’t call it a “hack”. Not a single file is modified nor altered in any way. You are simply copying the files from 2016 over to 2019 and then configuring Windows Server Essentials in EXACTLY the same way as the Windows Server Essentials Experience (WSEE) server role does it under 2016. There’s no difference whatsoever other than the fact that Server Manager does the install for you on 2016, and you’re doing it manually on 2019.
Third party add-ins are indeed fully supported (i.e. everything is in place for them to function). As you can see, our own Windows Server Solutions add-ins (WSE RemoteApp 2016 and WSE WorkFolders 2016) install and work wonderfully under Windows Server 2019 with WSEE installed. If the add-ins you are attempting to install are not working, then they either aren’t written to properly conform to the Windows Server Solutions SDK specs, or the manufacturer of the add-in has done something to prevent their use under any server OS other than Windows Server 2016. Your best bet there would be to contact the manufacturer of the add-in directly and ask them about it.
Sam T. Arving says:
Great stuff!
I got it running following your instructions above, but am continuing to see a problem (which also existed in Essentials 2016) where the storage service gets confused and declares a folder offline even though the underlying disk still exists.
The generally accepted workaround (according to Missing server folder alert, but folder is still present!) is to create a scheduled task which restarts the Essentials storage service whenever triggered by Event 1280 from event source “Microsoft-Windows-ServerEssentials/Admin” located in provider “Microsoft-Windows-Windows Server”.
However, I can’t find that event source anywhere. Is it possible that registration of the event sources got missed in your instructions above?
Otherwise, I’m greatly enjoying the Essentials experience on Server 2019. Thanks for figuring it out!
Mike says:
As you’ve mentioned, that particular issue is a long-standing problem in Essentials 2016 (which Microsoft doesn’t seem to have any intentions on fixing). Therefore, it doesn’t really have anything to do with installing WSEE on Windows Server 2019 per se. Pretty much any issue/bug that exists in Essentials 2016 will most assuredly carry over to Windows Server 2019 with WSEE (from 2016) installed on it I’m afraid.
As for the event source that you’ve mentioned… In an attempt to keep things simple, I have not included its registration in the list of manual install steps. However, our WSEE Installer does indeed register all of the WSEE event sources (i.e. Microsoft-Windows-ServerEssentials/Admin, Microsoft-Windows-ServerEssentials/Deploy, etc.).
As is mentioned at the top of the manual install steps shown above, the steps only represent the bare minimum that is required in order to get Windows Server Essentials Experience installed, and working, on Windows Server 2019. Whereas, our WSEE Installer takes things quite a bit further by “dotting all the i’s and crossing all the t’s” so to speak. If someone is looking for a straight forward (easy, complete, and proper) install, then we suggest using the WSEE Installer package instead.
I’ve been honing and refining the WSEE Installer package over the last year (i.e. since I first figured all of this stuff out and posted the manual install steps back in September / October of 2018), and so it does include quite a bit of additional detail that just can’t be easily explained within the manual install steps (at least not without further complicating the already complicated installation process and confusing folks even further).
That being said… For “most” users, the manual install steps listed above will net them a well functioning Windows Server 2019 with WSEE based server.
KurtH says:
Hi Mike,
I just purchased Work Folders for WSEE and am awaiting the MSI download password. Thanks for everything you’ve done to make this solution possible!
I have a couple of quick questions. I attempted the manual process in a scenario where I’m trying to preserve my old WSEE domain, and go the “member server” route, but my step 8 failed at 75% and I wasn’t able to recover. I did follow the “member server” path instructions to the letter. My original WSEE 2016 server was demoted and removed from the domain, blanked, reinstalled fresh as 2019, re-joined to the domain, and started at your steps 1-8 from there.
I’m going to try again with the MSI but I just have a couple of questions I’m hoping you can answer… the “domain migration” documentation you linked to above was frustratingly opaque on the questions below:
#1. Does the WSEE config process in fact promote the member server to a domain controller?
#2. If not, can the member server be promoted to a domain controller AFTER the config process has completed successfully?
#3. Also if not, should the server actually be a Domain Controller for the existing domain BEFORE starting the WSEE config process?
I know you always mention “member server” in your documentation above, but I’m trying to figure out how the timing of this is actually supposed to work. What I’m trying to do is I’m trying to end up with a server that is 2019, running WSEE, AND is also a Domain Controller for an existing domain.
In my case, I am also trying to recycle the same server name (SERVER1) which was previously used for my original 2016 WSEE server which has been demoted and removed from the domain (DOM). I have another domain controller (SERVER2) which owns all the FSMO roles and is keeping the domain alive at the moment.
Any help appreciated and thanks!
(Oh also… yes I know you would recommend blowing away the WHOLE domain and starting over, but I’m not trying to do that!)
Mike says:
You are most welcome. Thanks for your support (and your WSEE Installer download information has now been sent).
Alas, I’m afraid that I can’t really help you out any with the domain migration stuff seeing as I just don’t do them. I’m a software developer by trade, and not a server/network IT guy. For help with domain migrations, you’re probably much better off seeking help elsewhere; such as from Mariëtte Knap’s Server Essentials Community website seeing as she is an expert on doing domain migrations and has lots of those types of guides and tutorials available over on her site (although I get the sense that she doesn’t like me too much, and so I wouldn’t mention me on her site, or else your post will probably get removed 😕 ).
As I’ve mentioned here several times (and as you’ve noted), I always suggest that folks start with a completely new/clean/fresh Windows Server 2019 (Standard or Datacenter) installation, and then install WSEE on it from there. If you want to keep the domain name and server name from your old Essentials 2016 server, just be sure that the old server is offline, and then use the exact same domain name and server name when configuring your new Windows Server 2019 with WSEE installation (i.e. when entering that info into the Start-WssConfigurationService PowerShell command when you’re doing a manual install, or when you’re prompted for that info by the Windows Server Essentials Configuration wizard when you’re using our WSEE Installer).
Unless you have lots of users, and have heavily modified your Active Directory, Group Policy, etc. settings on the old Essentials 2016 server, then I see no real benefit to doing a domain migration. When WSEE gets installed on Windows Server 2019, it will automatically create the Active Directory, Group Policy, etc. settings that are required by WSEE, and you can just use the server Dashboard to add all of your users to the AD (i.e. to the newly created/configured domain controller).
If for some reason you want to go the “member server” route instead (where the Windows Server 2019 server with WSEE installed on it won’t be acting as your domain controller), then you can just set up a new/separate (bare metal or virtual) server as the primary domain controller, and then use the native tools in Windows Server to natively join your Windows Server 2019 server to it BEFORE you install WSEE (either manually via the steps provided above, or via our WSEE Installer).
As for your questions…
#1 – No. When you are going the “member server” route, the domain controller MUST already be set up, and natively joined to Windows Server 2019 BEFORE you attempt to install WSEE on it. Whereas, on a normal installation of WSEE, the server will automatically get configured as a primary domain controller for you as part of the Essentials configuration process. I myself have never tried installing WSEE on a server that was already configured as a domain controller. I assume that it would work (and others have reported here that it does indeed work), but doing so may just end up being a source of failure and frustration for you I’m afraid.
#2 – No. You need to natively join Windows Server 2019 to your domain controller BEFORE you install WSEE on it (in order for the Windows Server 2019 server to be properly configured as a “member server” in the existing domain). See: How To Join Windows Server 2012 to a Domain
#3 – Yes. See: Add Windows Server Essentials as a Member Server
From the sounds of it, you’re not actually looking to run your server as a member server. You’re just looking for a normal/regular Essentials set up where the Essentials sever is acting as the primary domain controller. So… My advice to you (if you don’t want to heed my suggested start with a new/clean/fresh install advice) would be to migrate your existing Essentials 2016 install over to Windows Server 2019 Standard (where you’ll be left with Windows Server 2019, without WSEE, but configured as your primary domain controller), and then simply install WSEE on it from there (as usual).
Of course, that may be easier said than done seeing as I have no idea if it will actually work for you or not since I’ve never tried/tested doing it that way. Your two areas of concern/difficulty will be… One, migrating Windows Server 2016 Essentials to Windows Server 2019 Standard (i.e. I don’t know if you can do a successful 2016 Essentials to 2019 Standard migration or not). And two, installing WSEE on Windows Server 2019 that is already configured as a domain controller. In theory, you “should” be able to do it, but I’ve never tried, and so I can’t offer you any real help there I’m afraid.
Good luck!
KurtH says:
Got it… I’ll give it a try and let you know how it goes!
Believe it or not, your answers have actually been most helpful!
The key for me was understanding whether or not WSEE configuration was attempting to promote the member server to a domain controller during the process. Now that I know it’s not going to do that, I think I have the right steps in mind.
Thanks again!
KurtH says:
Hey, so it looks like it worked!
I’ll post the full steps and results of what I did in case it helps anybody else in a similar situation.
So I had an environment that was a single WSEE server based on Windows 2016. Let’s call it SERVER1 and my domain DOM. This server was installed the “normal” way, meaning it wasn’t the result of a domain migration or in-place upgrade or anything. It was the first server in the environment, created the new domain etc.
So I wanted to upgrade this server to Windows 2019 but continue to use WSEE, and of course I found this website. (Thank you Mike!!)
But like many people (I suspect), I wanted to save my domain for several good reasons:
1. I have a lot of custom Group Policy that I’ve put in, and I can’t necessarily even remember what all of it is
2. I have a lot of data, and data has permissions, and permissions are based on SSIDs… to migrate all that data to a new domain structure would leave me with a bunch of scrambled permissions that I would have to sort out… and that’s no fun
3. I’ve got a lot of DNS entries that I would have to manually recreate
So here’s what I did that worked:
1. Built a new server called SERVER2 as a Windows 2019 Standard server (Windows updates etc.)
2. Promoted that server to a secondary domain controller for the DOM domain
3. Transferred all FSMO roles to SERVER2
4. Backed up SERVER1 and all the data on it, including the ServerFolders directory
5. Demoted SERVER1 to a member server for the DOM domain
6. Removed SERVER1 from the DOM and put it in a Workgroup
7. Destroyed SERVER1
8. Rebuilt SERVER1 as a new fresh clean Windows 2019 Standard server (Windows updates etc.)
9. Joined SERVER1 back to the DOM domain as a member server
10. Promoted SERVER1 to a Domain Controller for the DOM domain
11. Transferred all the FSMO roles back to SERVER1
12. Ran Mike’s Windows Server Essentials MSI file
At this point, the MSI installer asked me if I wanted to check a box to run the WSEE configuration right now. I checked the box and clicked OK, but then the installer disappeared and nothing seemingly happened. I looked around for any running processes (none) and checked the new Server Essentials deployment Event Log that the MSI created in my Event Viewer but nothing (no events). I checked Get-WssConfigurationStatus -ShowProgress and it said “Not Started”.
13. Rebooted the SERVER1 server
On first logon after reboot, the Windows Server Essentials configuration wizard launched. I cancelled the wizard without completing it.
14. From an Administrative PowerShell command prompt I ran Start-WssConfigurationService (with no arguments)
15. I watched the configuration progress via Get-WssConfigurationStatus -ShowProgress
16. Restored data from backup to ServerFolders
Voila! The process went to 100% and I now have my hoped-for outcome. My SERVER1 server is upgraded to 2019 (including WSEE), but my domain DOM (including all my user accounts, Group Policy, security permissions, etc. etc.) has been kept intact through the process. As a side benefit I now have a secondary domain controller SERVER2 as well.
Thanks again, Mike, and I hope these steps are useful for somebody… all the various comments above have GREATLY helped me navigate my way through this.
Mike says:
I’m glad to hear that my ramblings were able to help you out some. 😉
Kudos on making the migration work, and a big thanks for sharing how you accomplished it with others here.
As I mentioned previously, I personally feel that most “typical” Windows Server Essentials users wouldn’t have a lot of Group Policy edits, etc., but you certainly do fall outside of that norm with all of your GP changes, user permissions, and DNS entries. Therefore, I can indeed see why you wanted to perform the migration instead of starting with a new/clean/fresh install. Again though, I’d venture to say that 90% (or more) of our customers fall into the “typical” group and probably don’t require a domain migration.
I’m not exactly sure why the Windows Server Essentials Configuration wizard didn’t start properly for you after the main installation completed. I’m not able to replicate that behavior over here, but I have had one or two other users mention that the same had happened to them when using the WSEE Installer. It might have something to do with the state of the migrated server. I’ll need to look into that one a bit more. That being said… If it happens to anyone else, then they can simply restart the server (as you did), or they can just manually run the wizard by executing the following program (anytime after the main installation has successfully completed, or after any subsequent restart of the server that takes place during the Essentials configuration process):
C:\Windows\System32\EssentialsRoleConfigWizard.exe
EDIT (11/16/2019): I’ve now added a desktop shortcut that allows you to manually run the configuration wizard (just in case).
Lastly, if you start noticing that your Essentials server keeps shutting itself down (after a 21-day grace period), then you’ll most likely need to take that secondary DC offline in order to stop that from happening (as I believe that using a secondary DC will trigger an ‘out of compliance with the licensing policy’ condition).
Great job! And enjoy using WSEE on Windows Server 2019.
KurtH says:
Oh, interesting… you’re thinking that the 21-day timer could be applicable even with WSEE not installed as a true “role” on Windows Server 2019? Have you seen this behavior? I was making an assumption that functionality would have been deprecated in Windows 2019 and not likely to come over with the WSEE installation.
Also, wouldn’t I be getting warning messages if that were the case?
I’ll definitely let you know if it happens in my environment, so the community can be aware.
KurtH says:
Yeah, no… I looked into it and it’s fine. First off, I don’t have any warnings in my event logs about FSMO check violations. And secondly, having another domain controller in the domain doesn’t violate the licensing terms for Windows Server Essentials anyway. Here are the rules:
* The Essentials server MUST be a domain controller.
* The Essentials server must hold all the FSMO (Flexible Single Master Operation) roles.
* Only one domain is permitted in the forest where the Windows Essentials edition server resides.
* No forest/domain trusts are permitted.
* The Remote Desktop Session Host role feature is not supported and typically will not function.
So, as long as the Essentials server is the master for ALL FIVE of the FSMO roles, then you are good, even with (one or more?) replica domain controller(s) in the domain. What the article you linked above is saying (though it’s very poorly written and very confusing) is that if you haven’t COMPLETED your migration (a.k.a. transferred the FSMO roles) from the SOURCE server in 21 days, then the SOURCE server will shut itself down.
(Fun fact… it turns out the the timer is not 21 days actually like the warning message says, but it’s 27 days and 16 hours… somebody’s math was apparently off in the code)
But what I personally think is that this functionality doesn’t exist in Windows 2019 at all, even after the WSEE package is installed. I think this because the service which is responsible for monitoring the FSMO roles and initiating the shutdown is not even present in my WSEE server.
Mike says:
Thanks for sharing the info.
The Server Infrastructure Licensing service (silsvc.exe) isn’t included with the WSEE Installer (because it’s based upon the WSEE server role and not the Essentials SKU). However, since I didn’t know for sure if you had migrated from the 2016 Essentials SKU or the 2016 WSEE server role over to 2019 Standard, I didn’t know if the licensing service would (still) be running on your 2019 server or not.
AFAIK, the licensing service is only included with all of the Essentials SKUs that are limited to 25 users (which most likely also includes the abomination that is the Windows Server 2019 Essentials SKU even though it doesn’t have anything at all to do with Essentials as we typically know it).
And yes, I do recall reading that the grace period is more accurately represented as 28 days (vs 21). Typical Microsoft. 🙄
I wasn’t 100% sure on all of the licensing details when it comes to replica DCs (thanks for the clarification), but I assume that as long as the Server Infrastructure Licensing service isn’t running on your server, then it won’t ever be shutdown (whether you’re in compliance with the Essentials licensing policy or not).
Anyway… It sounds like you’re all set. 😉
Mike says:
BTW, quick question for you… May I ask why you opted to cancel the configuration wizard and then manually run the Start-WssConfigurationService PowerShell command (without any arguments) instead?
The config wizard is pretty much a GUI wrapper for that PowerShell command (with some additional environment checks built in), and so it “should” have noticed that your server was already set up as a domain controller and adapted itself accordingly. Was that not the case?
As I mentioned before, I have never tried/tested using the WSEE Installer on a 2019 server that has already been set up as a DC, but in theory it should still work in such a case. See:
Deploy Windows Server Essentials in an existing Active Directory environment
Just curious.
KurtH says:
Well, I did that because you said in the original instructions that if going the so-called “member server” route, you would want to run Start-WssConfigurationService with no arguments except “Credential”… but when I tried that with my first attempt, I got an error that the parameter “Credential” was not valid. (I know… WTF?) But I found that running the command without any arguments seemed to pass the current user’s credential which in my case was the credential that I needed to pass.
Also, I read somewhere on this page that you advised somebody else not to run the Configuration Wizard, but instead to run the PowerShell command, because you assumed the Wizard would fail during role check, since the actual role did not exist and was not installed.
You advise several times in several different contexts to “cancel the Wizard”… so like a cave man, I got that stuck in my head – Wizard Bad! PowerShell Good!
Finally, in thinking it through for myself, I didn’t want to run the Wizard because the Wizard was assuming that I needed to do a lot of things I didn’t need to do in my own situation… such as create a domain name, and a company name, and a new admin account, etc. I had a bad feeling that the Wizard would either fail and hose my WSEE installation, or possibly even worse it might succeed and hose my working domain.
Mike says:
Ah okay, thanks for the clarification.
I actually think the wizard would have worked just fine for you. I believe that it would have checked your server’s current configuration, realized that it was already set up as a domain controller (while not being natively joined to another server/domain controller as a member server), and then just started the configuration process without ever prompting for a domain name, server name, company name, etc. (just like is shown in my thumbnails above when you are going the member server route).
At least that’s what I would expect it to do based upon the Microsoft dosumentation that I linked you to above. Again though, I haven’t tried/tested it yet (but I believe that others here have). I suppose that in those other comments you reference that I made, I was indeed probably just assuming that it would fail. However, I now don’t believe that, and I would indeed recommend using the wizard over the PowerShell command for others following in your footsteps.
No harm, no foul, on your config though seeing as the wizard simply executes the PowerShell command in exactly the same way as you did manually.
Lastly, I’m not sure what went wrong with the -Credential parameter for you seeing as it should work just as mentioned in step 3b here:
To install Windows Server Essentials by using Windows PowerShell
Good to know that it will work without it and that it will just use the credentials of the signed in admin when omitted.
Thanks!
KurtH says:
UPDATE: PROTIP
For anybody planning to go this route of attempting to get to Windows 2019 + WSEE while preserving their existing domain… I have a slight caveat to the steps above.
When restoring data to ServerFolders, DO NOT restore the Client Computer Backups directory. Doing this will cause client computers to go into a strange state when reconnected to the server. (They will be online and functioning, but will show as “Archived” and “Removed” in the WSEE dashboard).
My recommendation is follow all the steps above up to 15 (use the Wizard or the PowerShell per your preference / comfort level)… restore ServerFolders *excluding* Client Computer Backups and File History Backups, then reconnect all client computers (by uninstalling and reinstalling the Client Connector for WSEE)… verify all the computers are connected in the Dashboard.
I think it might be possible to restore the Client Computer Backups AFTER reconnecting the client computers and then running the Client Backup Repair tool… but honestly I’m not feeling that ambitious and I’m not that concerned about trying to save my Client backup data.
Hope it helps somebody avoid a couple of hours frustration…
Mike says:
Excellent tip! Thanks again for sharing your findings with everyone. It looks like you’ve got the migration process pretty well dialed in now. I’ll have to do some domain migration testing myself (along with in-place upgrades) as soon as I get some spare time.
Interesting that restoring the Client Computer Backup server folder would cause the clients to appear as Archived or Removed, but I guess that’s not unreasonable to expect seeing as all of the prior Windows Server Essentials configuration data wouldn’t come over with the domain migration (i.e. you’ve installed WSEE completely from scratch here and so it wouldn’t have any way of knowing about the prior client connections and their backups).
mia2wa says:
HEALTH MONITORING ALERTS
Has anyone else run across and [most importantly] figured out how to fix the “Computer monitoring error” warning that appears in the WSE Dashboard’s Health Monitoring tab?
The error shows up every night, and the details simply say “Can only partially assess the health of this computer. The failing components are: WSE RemoteApp\Definition.xml.”
For what it’s worth, it does seem like the Health Monitoring is, in fact, working, because I can Delete and Ignore alerts, and alerts will auto-disappear when the warnings are remediated (e.g. I install missing updates). However, I’m unable to Refresh the Health Monitoring tab; when I try, I get the following Health Alert Error: “Unable to collect alert information.” Additionally, the Health Reports do actually run. I guess, given this information, the issue is more of a nuisance than an actual problem.
The Health Monitoring system worked perfectly well, until [I believe] I implemented some suggestions I received involving enabling/updating the RADC Web Feed. I undid and re-implemented the suggestions with several reboots in between, but it seems whatever damage was done, was done permanently.
VPN/ANYWHERE ACCESS
I have another issue – this one really is an issue, and not just a nuisance…
I’ve never been able to get my VPN working. Has anyone been able to get it working? Mine was a fresh build, not an in-place upgrade. Whenever I try connecting to the Anywhere Access VPN, I get the following message:
“Can’t connect to The connection was prevented because of a policy configured on your RAS/VPN server. Specifically, the authentication method used by the server to verify your username and password may not match the authentication method configured in your connection profile. Please contact the Administrator of the RAS server and notify them of this error.”
I feel silly saying this, but I don’t know how to check the authentication method configured in the connection profile. When I run the EssentialsTester PowerShell Mike referenced above, it does complain about IIS authentication for Default Web Site\RDWeb\FeedLogin (which BTW is enabled with windowsAuthentication) and Default Web Site\RDWeb\Pages (which is configured for digestAuthentication, but is disabled). All other Essentials Tests (except the Role Install) pass.
Thankfully, WSE RemoteApp works beautifully, so I do still have remote access to my network resources, but it would be really nice to get Anywhere Access working.
Any and all assistance for either issue would be GREATLY appreciated!
Mike says:
We don’t typically enable the VPN feature on our Essentials servers (mainly because we use Microsoft’s SkipDomainJoin connection method when connecting our clients to the Essentials server since we don’t want them to be joined to the domain, and the VPN feature is not available when the client is not domain joined), and so I wasn’t aware of any VPN issues until just recently. Apparently, VPN connections to Windows Server 2019 (via RRAS) are still somewhat buggy at the moment (which has nothing whatsoever to do with installing WSEE on Windows Server 2019).
However, after doing some research and testing, I believe that the VPN connection issues can be resolved by performing the following steps:
1. Connect to your Essentials server (via a standard Remote Desktop Connection, etc.) and sign in as an administrator.
2. From the administrator’s server desktop, open an elevated Command Prompt.
INFO: Click on Start, type “Command Prompt” (without the quotes), and then right-click on the located command prompt item and select “Run as administrator“.
3. Run the following command:
sc sidtype IAS unrestricted
MORE INFO:
Always On VPN and Windows Server 2019 NPS Bug
4. Run the following command (from the same elevated command prompt):
sc privs Dhcp SeChangeNotifyPrivilege/SeCreateGlobalPrivilege/SeImpersonatePrivilege
MORE INFO:
Upgrade From 2016 to 2019 Breaks DHCP Relay Agent when Using RRAS
5. Restart the server.
Does that resolve the VPN connection issue for you?
NOTE: You will need to repeat the steps above any time the configure/repair Anywhere Access wizard has been manually run from the Essential server’s Dashboard (seeing as it will overwrite the changes I believe).
EDIT (12/7/2019): Our WSE RemoteApp 2016 (Version 1.255.1771.0 or greater) and WSE WorkFolders 2016 (Version 1.0.259.0 or greater) add-ins will automatically apply these fixes for you (in the background) when they are installed.
mia2wa says:
Thank you, Mike. Sooo easy! Two service changes and, voila! VPN is working!
Mike says:
As for the WSE RemoteApp related computer monitoring error that you’re seeing…
I’m not able to replicate that issue over here on any of our in-house test servers (with or without the RADC web feed feature enabled), and so I’m not exactly sure what’s going on there.
Try taking a look in the server’s Logs folder (C:\ProgramData\Microsoft\Windows Server\Logs) to see if you can find a log file that pertains to the health monitoring error that you’re seeing. Sort the Logs folder by date modified (which will place the most recently modified log files up at the top), open the log files in Notepad, and the newest entries will be located down at the bottom of the log file.
Additionally, you can open the Event Viewer applet on the server (Control Panel → Administrative Tools → Event viewer), and take a look in the Windows Logs → Application log to see if there are any related errors/warnings being logged there.
Sonicfreak says:
Hi Mike,
Is it possible to install WSEE on Windows Storage Server 2016 Standard because I used to have a WHS2011 server and I bought a server with Windows Storage Server 2016 Standard.
I would like to use WHS2011 features like server/client backup and remote web access on my new server.
Mike says:
Alas, I’m afraid not. As you can see in the “Features Not in Windows Storage Server 2016” section of the following Microsoft Windows Storage Server 2016 announcement article, it is missing many of the server roles that are required to use the Windows Server Essentials Experience. Therefore, WSEE won’t work on it I’m afraid. You’ll need to upgrade your server’s operating system to Windows Server 2016 Essentials if you want to use the Essentials features you’ve mentioned.
Announcing Windows Storage Server 2016
Sonicfreak says:
Thanks for your answer. Do you know if it’s possible to upgrade Windows Storage Server 2016 Standard to Windows Server 2016 Essentials? Or do I need to do a fresh install?
And with Windows Server 2016 Essentials I don’t need to install the WSEE, right?
Mike says:
DISM can be used to convert between Standard and Datacenter editions, but I don’t believe that there is any way to in-place upgrade Windows Storage Server to Windows Server Standard, Datacenter, or Essentials I’m afraid. Thus, you will indeed need to do a clean/fresh install with either Windows Server 2016 Essentials (i.e. the SKU) or with Windows Server 2016 Standard/Datacenter (and then add the WSEE server role afterwards using Server Manager).
With Windows Server 2016 (Essentials, Standard, or Datacenter) you don’t need to manually install WSEE (or use our WSEE Installer) seeing as WSEE is already included with the operating system (either directly in the case of the Essentials SKU, or indirectly by adding the WSEE server role via Server Manager in the case of Standard/Datacenter).
Sonicfreak says:
Thanks for your comprehensive answer. I bought a Windows Server 2016 Essentials license yesterday and you’re right, it’s not possible to do an in-place upgrade Windows Storage Server 2016 to Windows Server 2016 Essentials. The installer tells you it’s not possible to keep your apps and data since it’s another Windows Server version.
The installation first failed and reverted back to Windows Storage Server. Only when I selected not to install updates during installation, the installation succeeded.
So it’s a fresh install, but what’s curious is that there’s a Windows.old folder with the previous Windows Storage Server so that I could copy my old apps and drivers from that folder.
JamesFish says:
Good Evening Mike, I have been intrigued by your guide to install Essentials onto server 2019, I followed your instructions to the “T” but im failing at 75% on one attempt and on last attemt im getting this error, Im pulling my hair out trying to accomplsh this install. Please any advice where i messed up?
Start-WssConfigurationService : The term'Start-WssConfigurationService' is not recognized as the name of a
cmdlet, function, script file, or operable program. Check the
spelling of the name, or if a path was included, verify that the
path is correct and try again.
At line:1 char:1
+ Start-WssConfigurationService -CompanyName “---------
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Start-WssConfiguratio
nService:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
Mike says:
My best guess is that you have some unexpected line breaks within the command that you’re entering. Try pasting your command into Notepad first and making sure that it’s one continuous line of text and not broken up into multiple lines.
EDIT (1/4/2020): Other than that, are you sure that you’ve copied over the following folder properly:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\WssSetupCmdlets
As the “Start-WssConfigurationService” cmdlet is a component of the “WssSetupCmdlets.psd1” file that’s located within that folder.
abacus says:
my configuretion is stuck at 17% for days now
Mike says:
Alas, I’ve never seen this issue before, but I have had one other user report the problem thus far (I believe it’s actually a long-standing issue with installing WSEE, and has nothing really to do with installing WSEE on Windows Server 2019 per se).
From what I can gather it appears that the problem stems from the Windows Server Essentials services not starting properly (even though they have been properly configured to start Automatically during the configuration of Essentials). I do not know why that’s happening on some systems though (since I’m not able to replicate the issue over here).
So… Try opening up the “Services” control panel applet (services.msc), and making sure that all of the “Windows Server Essentials …” services are started. There are a total of 8 Windows Server Essentials services, and all but the email services should be started. Hopefully, manually starting the services will get you past being stuck at 17% in the configuration process.
jmone says:
I have WS2016 Essentials using Domain Skip and use it to backup my PC’s on a Home Network. Works great for both file and bare metal restores. If I upgrade to 2019+WSEE is there anyway to keep / restore the existing Client Backup Database?
Thanks
Nathan
Mike says:
If Windows Server 2016 Essentials is working just fine for you, then there should be no real reason for you to make the upgrade to Windows Server 2019 with WSEE installed. There’s nothing really for you to gain by doing that, and so if I were you, I’d just stick with what’s currently working well for you (i.e. if it an’t broke, then don’t fix it).
That being said… I do not know if you can transfer the client PC backups from one Essentials server to another seeing as I’ve never tried doing that before. I imagine that, if it is possible, it will be a fairly involved process.
Your best bet of getting an answer to such a question would be for you to post it over on Microsoft’s Windows Server Essentials 2016 TechNet forum. Although, if you do, then you probably shouldn’t mention Windows Server 2019. I’d simply phrase the question as you’re wanting to move the client backups from one Windows Server 2016 Essentials server over to another (which is essentially what you’d be doing anyway).
Good luck, and please do post back here if you ever get a definitive answer on that one.
w3bguru says:
Mike,
Thank you for the comprehensive instructions. I’m running WSEE on 2019 and all desired features are working except the remote dashboard. It hangs up on configuring remote session, and when you show details it’s stuck at unlocking the remote PC. Have you run across this, or have any suggestion on where to troubleshoot this?
Thanks!
Mike says:
Alas, I’m not seeing any issues with connecting to the server Dashboard over a Remote Desktop Connection here (and I don’t recall anyone else reporting such an issue that I am aware of). Have you checked your network router, firewall, etc. to see if something is blocking the connections?
jlig says:
Mike, I know you have said this a thousand times “I recommend doing a clean install..rather than in-place upgrade” but I have a question:
– I’m not looking to do an “in-place upgrade or migration from Essentials 2016 to Windows 2019”
– I only have a fully installed (w/Domain/AD/DHCP) active “clean-install” of Windows Server 2019 Standard (was never migrated or upgraded previously)
– So my question is: Will the “manual install” or “your auto install app” of WSEE work for my customer?
– If all you are doing is copying in the folders/directories/registry keys, and not replacing any of the existing files..
– then it would seem that if I have a good server backup (just in case), It should just install then Windows 2019 would “see” the new WSEE features?
Mike says:
Since you’re just starting with a (clean) 2019 server that has already been setup as a domain controller, then it should work just fine. When you run the Start-WssConfigurationService cmdlet (when manually installing WSEE), or when the Configure Windows Server Essentials wizard runs (when using our WSEE Installer), it will recognize the existing domain controller, and configure WSEE on the server accordingly. For a bit more info see:
Deploy Windows Server Essentials in an existing Active Directory environment
jlig says:
Mike, thanks for the tips & the link to the download!
A couple of questions before I fully install the WSEE Installer after I unzipped the installer, entered the key & see the msi file
1) When I run it I get the following message: “An unsupported feature of Windows Server has been detected. You will need to remove all Remote Desktop Services roles from this server, using the Server Manager’s Add Roles and Features Wizard, before installing Windows Server Essentials Experience”
– I assume I can turn off/remove those roles & continue?
– Any advice?
3) On the link you provided to “Deploy Windows Server Essentials in an existing AD environment” it says I need to “Join your server running Windows Server Essentials to an existing domain as follows:
If you want this server to be a domain controller, set up the server as a replica domain controller.
If you do not want this server to be a domain controller, join this server to your domain by using the Windows native tools.”
– I do not want to make any changes to the existing Domain or AD, I just want to add the WSEE to the server.
– Do you have any advice on this step?
3) Does WSEE require a real SSL Cert or can I use a “Self Signed Cert?”
– back in the days of SBS, they used the Self Signed cert
Mike says:
1) You are not really starting off with a “clean” install if your existing 2019 server has any/all of the Remote Desktop Services (RDS) server roles added to it. The Windows Server Essentials Experience (WSEE) is NOT compatible with RDS. Therefore, you will need to remove ALL of the RDS server roles from your existing 2019 server (via the Server Manager) before running the WSEE Installer on it. Once they’ve been completely removed, then the installation will proceed just fine. If you want/need RDS features on your Essentials server (i.e. RemoteApp programs, etc.), then use our WSE RemoteApp 2016 add-in instead (as that’s exactly the reason it was created).
2) A server that has WSEE installed on it must either be or see a domain controller. Under a “typical” WSEE installation, the server is automatically configured as the primary domain controller when the WSEE server role is configured. However, you can also opt to join a server that has WSEE installed on it to an existing (i.e. separate) domain controller as a “member server” that’s running as part of the existing domain. That’s what the documentation is referring to there. However, in your case (from what I understand), your existing 2019 server is already configured as a primary domain controller, and you just want to add the WSEE server role to it. In that case, when you configure WSEE on your server, it will discover that the server is already a domain controller, and it will allow you to complete the WSEE configuration on the existing domain controller (instead of having to join it to a separate domain controller or create a brand new domain controller from scratch). Thus, you should just proceed with the WSEE configuration once it (i.e. the wizard) recognizes that your existing server is already set up as a (primary) domain controller.
3) WSEE configures your server as a Certification Authority (CA) and will set up all of the required self-signed certificates for you automatically (with nothing being required on your part – although if you’ve already set up your existing 2019 server as a CA, then you’ll have a bit of a mess to deal with, and that’s one of the reasons I always recommend starting with a “clean” install). Additionally, if you are going to be taking advantage of the Essentials server’s Anywhere Access features (i.e. Remote Web Access and/or VPN), then the Anywhere Access configuration wizard will guide you through setting up a proper SSL certificate on the server (for free if you use a Microsoft personalized domain name – e.g. YourDomainPrefix.remotewebaccess.com). All of that stuff is included as part of the “Essentials” feature set.
jlig says:
Mike, reporting back my results after following your excellent advice, tips & tool! I’m excited to have the Essentials Dashboard management tools back in Server 2016 Std! I only wish I had found your site earlier, when I was installing/setting up Server 2016 Std last year! You’re right that a clean install would have saved me these lingering issues I have below! anyway..
– I uninstalled my Remote Desktop Services from the Server 2019 and rebooted
– I ran your WSEE install & it installed successfully
– I then started the WSEE Configure wizard & it completed successfully
All the Essentials stuff looks & works correctly except the following:
1) In the Essentials Dashboard, under the “Devices” tab, only the server is displayed, no users computers?
2) After I set up “Anywhere Access”, I can connect remotely to the user, I can see shared folders & files,but no devices? It says “There are no devices available for remote access.”
Is there a way to get the computers to display under Devices, other than rerun the “Connect Computer” wizard?
– I’ve heard that re-running the client connect may help but others say it won’t run again?
Mike says:
You are most welcome. I’m glad to hear that you got WSEE installed and working on Windows Server 2019.
As for the client computers/devices…
In order for Essentials to be able to “see” your client computers, they MUST have the Windows Server Essentials Connector software installed on them (i.e. they must be connected to the server). This is done by going to http://<ServerName>/connect from the client computer and downloading/installing the connector software from there. For more info see:
Get Connected in Windows Server Essentials
NOTE: The connector software will automatically join the client computer to your domain by default. If you don’t want your client computers to be domain joined, then you can use Microsoft’s SkipDomainJoin connection method in order to prevent that from happening. For more info see:
Connect computers to a Windows Server Essentials server without joining the domain
I’m a bit confused about your last paragraph. Are you saying that you already have the Windows Server Essentials Connector software installed on your client computers? If so, then I assume that you had them connected up to an older version of Essentials (e.g. 2016, 2012 R2, etc.) at some point. In that case, then you’ll need to completely uninstall the connector software from the clients, and then reconnect them back up to your new 2019 Essentials server (seeing as they just won’t magically reconnect themselves to the new server). Or, you could just try reinstalling the connector software straight over the top of the existing installation, but I’ve not tried doing that myself, and so I can’t say if going that route will work or not (especially if they were domain joined to the prior server). For more info see here and here.
jlig says:
Mike, thanks again for all the details & links!
– I originally installed/setup this server back in 2019 including AD/DHCP/Shared Folders/etc.
– I then created the 15 users in AD, and joined their Win10 machines to the domain manually in Control Panel/System/etc…
– If I now run the “connect computer” command at each computer, will it mess with the existing users desktop/profile locally? Hoping it doesn’t create a new profile for the user.
– I wasn’t sure what effect the connect computer wizard would have there, but I will go ahead and run it to make the devices show up in WSEE. Thanks again for a great “hidden” add-in gem.
ps: My last paragraph was what I did back in 2012 when the customer had Windows Server 2012.
Mike says:
I’m afraid that I haven’t done much testing in this area with domain joined clients seeing as I typically connect all of our clients using the SkipDomainJoin connection method. Thus, I’m not 100% sure what will happen to the user’s existing profiles if you install the connector software on the (already joined) client computers. However, I would think that the connector software would recognize that the client is already joined to the Essentials server’s domain, and if you give it the proper domain credentials, then it should be smart enough to keep the existing users profile in tact during the installation process. Again though, I cannot say for certain as I’ve never tried doing that before.
That being said… Since you want the client computers to appear in the server Dashboard, then you don’t really have a choice but to install the connector software on them in order for that to happen. If it messes up the user profile, then you’ll probably need to use a profile mover tool in order to get the profile back.
Alternatively, you could try the “trick” that MR.G mentions in the last link that I linked you to in my prior reply, where he sets the SkipDomainJoin registry value on the (already joined) clients, and then installs the connector software in order to force the connector software to skip the domain join part of the installation process (since the client is already joined to the domain). Then go ahead and delete the SkipDomainJoin registry value after the installation completes.
jlig says:
Mike, this is the final post! All computers are now showing up under devices! Client backups work, Anywhere Access works, Shares work, etc!
For anyone that has Server 2019 Standard and you previously joined the clients to the domain manually.. it’s rather simple to add the Essentials Experience to the server & network as follows:
1) Install the WSEE from this site (buy a product & use the free installer)
2) Run the WSEE Configuration Wizard (leave all prompts at default)
3) Install the WSEE Connector w/o joining domain on each client computer (see the links below)
Note: Step 3 is very important so you don’t end up with a new user profile & desktop for your users! Follow the links below & you won’t have to copy the profile/programs/apps.
These two links were invaluable:
– Connect computers to a Windows Server Essentials server without joining the domain
– Comment #4487 by MR.G
Mike deserves a big thank-you for making Windows 2019 an even better product for small business!
Mike says:
Thank you for the follow up post to let everyone know what worked for you when installing WSEE on a 2019 server that has already been configured as a domain controller (prior to installing WSEE on it), and when installing the Windows Server Essentials Connector software on client computers that have already been joined to the domain (prior to installing the connector software on them). I’m very glad to hear that everything worked for you and that you now have a fully functioning 2019 server with WSEE installed on it. Great job!
Take care and stay safe.
RobC says:
Hi Mike,
I’ve been tracking this website for about a year before finally deciding to move from Server 2012 Essentials to Server 2019. Great work, BTW!
I’ve now decided to go ahead, but am stumbling at the very first hurdle (file extraction from Server 2016).
I have an ISO of Server 2016 Evaluation from MS.
I don’t really know how to use the ADK, TBH, but I have copied the ISO to my local PC (folder Server-Image2016) and run a DISM command to extract the files from the install.wim:-
dism /Mount-Image2016 /ImageFile:”C:\Server-Image2016\sources\install.wim” /Index:1 /MountDir:”C:\ServerMount2016″
The dism works and I end up with a folder (Server-Mount2016) which contains all the Server folders in it.
However, when I browse the folders I can’t find any of the files or folders that I need to extract into Server 2019. No Program Files\Windows Server folder, no folders at all that relate to Windows Server. No files, such as Policy.6.1, etc, etc.
I’ve also tried browsing the install.wim using things like 7z as well, but I get the same results. Can’t seem to see the files and folders I need.
Do you know what I am doing wrong?
Regards
Robert
Mike says:
Sorry, it looks like I forgot to mention that if you’re going the ADK file extraction route, then you’ll need to use the Windows Server 2016 Essentials ISO (and not the Windows Server 2016 Standard/Datacenter ISO) in order to be able to pull the files directly out of the ISO. The reason for this is that the “Essentials” SKU has the Windows Server Essentials Experience (WSEE) server role installed on it by default (i.e. straight out-of-the-box). Whereas, on the Standard/Datacenter versions, the WSEE server role needs to be manually installed via the Server Manager AFTER the operating system itself has been installed. That’s why you aren’t seeing the Essentials files. Just switch over to using the Windows Server 2016 Essentials ISO (which can also be downloaded from Microsoft’s evaluation site) as your source, and you’ll be golden.
That being said… The ADK file extraction route is how I first wen’t about figuring all of this stuff out. Later on (i.e. once I figured out exactly which files were required, etc.), I determined that it’s probably MUCH better for you to use a separate install of Windows Server 2016 Standard where you’ve installed the WSEE server role on it (but have NOT yet run the Configure Windows Server Essentials wizard!) as the source for your files. There are two main reasons for this… First, after installing the WSEE server role, you can run Windows Update and it will bring down all of the latest versions of the Essentials files for you (so that you’ll have the latest and greatest set of files as your starting point). The 2016 ISOs are no longer updated by Microsoft, and so they’ll only have the older/out-of-date Essentials files on them out-of-the-box (until such time as Windows Update gets run). Second, the Essentials SKU has some licensing limitations imposed upon it that Standard/Datacenter with WSEE server role does not have. Therefore, it’s probably best to start with Standard/Datacenter with the WSEE server role as your file source just to avoid those limitations being imposed on your install (although I haven’t spent much time exploring this seeing as I always use Windows Server 2016 Standard with the WSEE server role installed as my file source). I hope that makes sense.
Lastly, the WSEE Installer has come such a long way now (and does so much more than you’ll get when doing the install manually for yourself), that I highly recommend everyone use it instead. Take my word for it when I say that purchasing one of our products, just to get the WSEE Installer, will be the best money that you’ve ever spent (bar none!). The WSEE Installer makes the whole process 100% plug-n-play and gives you a MUCH more proper/complete install (not to mention that it’ll save you many hours of time and frustration). That’s just my $0.02 though. If you enjoy tinkering with servers, then by all means, please do have at it. 😉
RobC says:
Thanks Mike.
Appreciate the quick response. I should have read the instructions properly!
I am now using an installed Server 2016 Standard install with WSEE installed as the base for initial testing.
I may well ultimately purchase one of your products for my main production build. Question – Is the WSE Workfolders product similar to using Folder Redirection/Offline Files, but without all the hassle? Also, will your product work if the Server is a DC?
Robert
Mike says:
WSE WorkFolders simply allows you to use Microsoft’s Work Folders server role on an Essentials server (integrating it nicely with the Essentials server Dashboard, and working around the conflicts that exist between the Work Folders server role and the Essentials server’s Anywhere Access/Remote Web Access features). It is not a direct replacement for Microsoft’s Folder Redirection/Offline Files technologies, but it can indeed be integrated with them if desired. For more info see:
Redirecting Windows Special Folders to Work Folders
Q: How does Work Folders compare to other Microsoft sync technologies?
Q: How does Work Folders work with Offline Files? Why would someone use both?
Q&A With Fabian Uhse, Program Manager for Work Folders
And yes, WSE WorkFolders works just fine when your Essentials server is running as a primary domain controller (and even when it’s running as a member server where it’s domain joined to another server that’s acting as your primary domain controller).
RobC says:
Thanks Mike…..I’ll Have a look; could well be of use to me.
DavidK says:
HI Mike – I see from one of your Edits on 2-6-20 that you got the “Manage Storage Spaces” control panel applet working. Do you think this could be added on it’s own without the rest of Essentials? I am running 2012R2 Essentials now and looking to move to 2019 Standard and while I don’t really need any of the other Essentials features, I would love to get the Control Panel GUI back to manage my Storage Spaces. Thanks!
Mike says:
Alas, I’m afraid not seeing as it requires the “Essentials” bits to be installed on the server in order for it to function properly. EDIT: I’ve updated my 2-6-20 comment so as not to confuse folks on that one.
DavidK says:
Thanks for the input, I’ll try out the essentials install then as well.
Mike says:
While it seems a real shame for you to use the WSEE Installer just to get the “Storage Spaces” applet to appear in the Control Panel on Windows Server 2019, I suppose that if you’re going to go that route, then you don’t actually have to fully configure Essentials on the server… Basically, you could just run the WSEE Installer on your 2019 server, and then close/cancel out the “Configure Windows Server Essentials” wizard that opens after the installation completes. That way, the “Essentials” bits (along with the “Storage Spaces” Control Panel applet) will get installed on the server, but Essentials itself will never be fully configured on your server. The config wizard will automatically reappear on every restart of the server (since Essentials hasn’t been configured yet), but you can stop that form happening by opening the Task Manager, clicking on “More Details”, going to the “Startup” tab, and disabling the config wizard startup from there.
RobC says:
Hi Mike,
So I’ve now completed my first run through using the manual processes, and thing look great. Hats off to you for publishing this on the Web.
I do have a few observations, however, and just wondering if other people are seeing the same things:-
Just to give you some background I ran two VMs on my PC. One for Server 2016 Standard (fully set-up with WSEE role installed (but not configured), and the other running Server 2019 Standard. I moved the various settings and files from one VM to the other using a shared virtual disk.
The PC with the two VMs is attached to my Server 2012 Essential domain/DC, the server having the name “Orion” and with Company ID as “Cook Ltd” and Domain name as “CookLTD”. Using a PC attached to a domain may be why I had some issues as documented below (though I can’t undertand why).
1. My commands to do the final configuration were as follows:-
$cred = Get-Credential -UserName “Robert Cook” -Message “Specify a password to be used for your new administrator account.”
Start-WssConfigurationService -CompanyName “Cook Ltd” -NetBiosName “CookLTD” -NewAdminCredential $cred -ComputerName “Orion” -Setting All
1. When I ran the second command, after about 20 seconds, I got a message saying that the Company Name was in use, so I changed the Company Name in the command to:-
Start-WssConfigurationService -CompanyName “Cook Limited” -NetBiosName “CookLTD” -NewAdminCredential $cred -ComputerName “Orion” -Setting All
I re-ran the command and received a message saying the “-Setting All” attribute was invalid. I see that others have had this issue so I left it off (and checked the Windows Update settings later):-
Start-WssConfigurationService -CompanyName “Cook Limited” -NetBiosName “CookLTD” -NewAdminCredential $cred -ComputerName “Orion”
This command ran successfully, and after a reboot, continued and finished after a few minutes.
Everything looked good, with a working Dashboard and full functionality. However, there are a few puzzles:-
1. According to the Microsoft document, the Start-WssConfigurationService command should change the Computer Name from the default Computer Names provided by Windows during the install to “Orion”. This did not happen (maybe because my VMs could “see” my existing domain???; no idea). If this is normal it means when I do the real build I will need to change the Computer Name manually in Control Panel/Server Manager early on.
2. My understanding of WSEE (and Essentials 2012) is that the Start-WssConfigurationService command hides the standard Administrator Account and replaces it with the new one (in my case “Robert Cook”. However, this did not happen. I now have two Admin Accounts; “Administrator” and “Robert Cook”. I only expected to have “Robert Cook” with “Administrator” hidden.
3. When running the Dashboard I get an UAC message saying “Publisher: Unknown”, and I need to press “yes” to run the Dashboard. Unsure why it isn’t saying Publisher: Microsoft (preferably with no UAC message).
The first issue may be because my VMs could unexpectedly see my existing domain (not sure how, though), but I’d be interested to see if these three issues have been encountered by others, though (especially the last two).
Mike says:
First off, you need to take that Windows Server 2012 Essentials server (that’s running as a primary DC holding all of the FSMO roles) completely out of the equation (i.e. take it offline) seeing as you cannot run more than one Essentials server on the same network. If I had to guess, that’s most likely what was causing many of your issues when running the Start-WssConfigurationService cmdlet (including your #1 and #2 puzzles). To tell you the truth, I’m actually quite surprised that you even got it to work at all under that environment. 😮
I’m not exactly sure why the -Setting All parameter was causing you (and others) issues seeing as I’ve never seen that happen before in the hundreds, upon hundreds, of installs I’ve done to date (and it’s well documented by Microsoft as a supported parameter for the cmdlet). Maybe it’s a line break issue??? Anyway, as you’ve mentioned, you can indeed just omit it if needed.
As for your #3 puzzle… That’s normal behavior seeing as the Dashboard.exe file isn’t digitally signed. In a normal install of the WSEE server role (under Windows Server 2016 or earlier), everything is installed in a trusted manner by the operating system itself, but since that isn’t happening when you manually go and install the WSEE server role bits on 2019, the install is not implicitly trusted by the operating system, and so you get that unknown publisher prompt (again, since Microsoft hasn’t digitally signed the Dashboard.exe file).
eugp says:
Hi,
I am trying to join a 2019 Standard server to an existing WSE 2016. I had it all working but got spooked because it looked like the 2019 server was holding or taking FSMO roles away from the wse 2016. I demoted the 2019 and wiped it, this time joining it to wse 2016 using //server/connect to get it show up on the wse 2016 console, which worked. But of course that breaks the WSS config service install because of the things that the connect wizard installs and even after uninstalling CA it gets stuck at 89%. i doubt it would work even if I got past that.
So, I should start again, join the 2019 member with the basic join, then do the wse config.
What AD roles does the WSS Config Service add to the member server? Part of the reason to do this is to eventually demote the 2016 wse server because we are at 36 users and even though I have 40 licenses for 2019, I do not think they are valid for the WSE 2016 and it must go away.
I want to use DFS to sync the data folders to the new 2019 server, then move folder redirection, then demote and pull the 2016.
Thanks for working this up, and thank you for any insight or assistance.
Mike says:
Wow! I’m not sure that I’m following you at all on this one… You say “join” here, but I think that you actually mean “connect”…
First off, you cannot have multiple Essentials servers running within the same network when they are acting as a primary domain controller holding all of the FSMO roles (which is the default configuration for an Essentials server). The only way that you can run multiple Essentials servers on the same network is if they are each running as member servers (where they are domain-joined to a completely separate domain controller). For more info see:
Enabling multiple instances of Windows Server Essentials Experience in your environment
Secondly, while you can “connect” a second server to an Essentials server (by installing the Windows Server Essentials Connector software on it via http://<YourServerName>/connect), you cannot (or at least should not) do that for another Essentials server. For more info see:
Join a second server to the network
So… I’m afraid that I’m not going to be much help for you on this one seeing as I’d never attempt to do what you’re doing there (or at least what I think you’re doing anyway). Personally, if you want a successful installation of the Windows Server Essentials Experience on Windows Server 2019, then I STRONGLY recommend that you start off with a new/clean/fresh (straight out-of-the-box) install of Windows Server 2019 Standard and not attempt any type of domain join to, or connection of, a prior version of Essentials, etc.
As for what AD roles, etc. Essentials adds to your server, take a look at:
Changes implemented by Essentials Role on Windows Server 2012 R2
All that being said… If you’re just looking to migrate your 2016 server over to 2019, then that’s not at all how you should be going about doing that. While I personally don’t recommend doing domain migrations, if you’re adamant about doing one, then Microsoft has the steps that you need to take in order to do that listed over here:
Step 2: Install Windows Server Essentials as a new replica domain controller
And, another user has very kindly posted the steps that he took for doing a successful domain migration here.
I hope that helps, and good luck with your endeavor.
eugp says:
Thanks for your comments, I am reworking my process. I went virtual so at least I can roll back if things aren’t right.
I did successfully join the existing WSE2016 domain and get the essentials role installed on 2019 standard, I did the join just before the Start-WssConfigurationService. I’d like to suggest that you add the command Test-WssPrecheckResult to your tutorial. Mine showed “domainmember” as the install. So then ” the configuration wizard simply configures other roles and features without changing your domain environment.”
Now I’ll do a lot of reading and research so I don’t goof it up again. Thanks for the links. I will probably go with Mariattes server-essentials tools. I believe I added the AD roles to the member server incorrectly before.
I had hoped to start a new domain and move the old over, but its a hot production machine and everyone’s remote so that makes things trickier.
Mike says:
Yes, both the Test-WssPrecheckResult and Test-WssConfigurationOption cmdlets probably should be run before Windows Server Essentials is configured via Start-WssConfigurationService (just to ensure that everything is copacetic before proceeding). In fact, the “Configure Windows Server Essentials” wizard (which is automatically run whenever the install is performed via our WSEE Installer) automatically does all of that for you behind the scenes. However, I intentionally left the cmdlets out of the manual install steps because I just didn’t want to further complicate (the already complex) installation process and confuse folks even further. I do agree that “advanced” users (or users who are running into issues when attempting to manually install WSEE on Windows Server 2019) should run them though. Thanks for pointing that out for everyone.
eugp says:
Are you aware of a way to disable TLS 1.0 and 1.1 within the WSE Role? We are all being told to disable these but it appears that WSE is deeply dependent on them. I know that if I disable TLS 1.0 I cannot use //server/connect to join new computers. It seems like Microsoft is not going to update this role to newer requirements. Also that Office 365 integration
will require TLS 1.2
Mike says:
Alas, I’m afraid that you should not disable TLS 1.0 on an Essentials server, seeing as doing so breaks all kinds of things in it (such as client computer backups, client-to-server communications, Essentials add-ins with client-side components, etc.). You can still harden the security on an Essentials server by disabling many of the other insecure protocols, ciphers, etc. (such as SSL 3.0, TLS 1.1, etc.), enabling SSL perfect forward secrecy in IIS, etc. but ultimately, you’ll still need to leave TLS 1.0 enabled I’m afraid. In fact, in my WSE RemoteApp 2016 add-in, I implement a script (and other security settings) that automates all of this hardening stuff for my customers (while still leaving TLS 1.0 enabled), and in doing so, it’s about the best (compromise) that one can achieve on an Essentials server.
Basically, Microsoft needs to recompile the assemblies being used by Essentials so that they support a higher version of the .NET Framework, which can then be used to enable support for TLS 1.2. Unfortunately, Essentials is pretty much considered to be abandonware by Microsoft now, and so unless something really forces their hand on this issue (such as a major security breach in this area, etc.), I very seriously doubt that we’ll ever see them add native TLS 1.2 support to Windows Server 2016 Essentials.
Unless it involves emoji, colorful app icons, dark modes/themes, ninja cats, or other completely worthless crap, then Microsoft just doesn’t seem to care about it anymore in Windows (Server). 😡
eugp says:
Not even these?
WSE16 client backup errors after disabling TLS 1.0/1.1?
How to resolve Azure backup agent issues when disabling TLS 1.0 for PCI Compliance
“Yes, I ran it on Windows Server 2016 Essentials up until lat week when I upgraded to Windows Server 2019 Standard with the added (unsupported but working) Essentials role. 🙂 Works in both.”
I can hope, can’t I?
Mike says:
LOL You can always wish in one hand, want in the other, and see which one fills up faster. 😉
Seriously though, that SchUseStrongCrypto setting probably won’t do anything for you in this area. While it will enable an older .NET v4.0 or v4.5 compiled assembly to default to using TLS 1.2, it most likely won’t do anything for the existing Essentials WCF assemblies that are specifically written to use TLS (1.0) as the communication protocol within their bindings. Without Microsoft directly implementing the fix within their own assemblies (or possibly by some other forceful means within the .NET Framework that I’m currently not aware of), there’s no “quick fix” for getting TLS 1.0/1.1 support fully disabled (and TLS 1.2 fully enabled) in Essentials that I know of.
One can only hope that Microsoft will eventually step up and natively implement TLS 1.2 support in Essentials for us all, but I’m certainly not going to hold my breath on that one.
EDIT (5/11/2020): Mea culpa! Looks like I may have been (somewhat) wrong on this one… It appears that you can indeed enable TLS 1.2 support (and fully disable TLS 1.0/1.1 support) on an Essentials server with a bit of determination. See this comment below for a bit more info.
EDIT (5/13/2020): BTW, this is the Microsoft documentation that I was thinking of when I made my statement above about the WCF assemblies not working:
For WCF using .NET Framework 3.5 – 4.5.2 using TCP transport security with Certificate Credentials
Based on that Microsoft documentation, the WCF framework in .NET v4.0 and v4.5 (which is used by some of the Essentials assemblies) is hardcoded to use TLS 1.0, and so disabling it on an Essentials server technically should not be done. Unless Microsoft has changed something in this regard, disabling TLS 1.0 on an Essentials server will, as I stated above, break all of the client-to-server (WCF-based) communications. Therefore, I’m somewhat surprised to find that it’s actually working. Perhaps WCF isn’t involved after all, and if that is indeed the case, then we would simply need to consider this one instead (which would then explain why the SchUseStrongCrypto and SystemDefaultTlsVersions settings work):
For .NET Framework 3.5 – 4.5.2 and not WCF
Additional testing is most definitely warranted here before folks proceed with implementing it on a production server IMHO.
eugp says:
Ok, Thank you.
I’ll keep those checkpoints going.
Mike says:
BTW, looking a bit closer at the posts in your first link… For the bloke who claims that he has TLS 1.0 fully disabled on Essentials with everything working, I’d really love to know if all of the client-to-server communications stuff is truly working for him (especially client computer backups and client computer connections to the server). If so, then I have to admit that I’ve never actually tried enabling the SchUseStrongCrypto settings on both the server AND on ALL of the client computers before. Maybe that’s something you might want to try. Although my gut tells me that it probably won’t work, but I guess ya never know.
EDIT (5/11/2020): Well I’ll be… I just completely disabled TLS 1.0 and TLS 1.1 on one of our Essentials servers, implemented the SchUseStrongCrypto and SystemDefaultTlsVersions settings on BOTH the server AND on ALL of the client computers, and it does indeed appear that all client-to-server communications are still working. I’m now seeing an A+ grade on the SSL Labs site for the Essentials server (due to TLS 1.0/1.1 being fully disabled, TLS 1.2 being fully enabled, etc.), and client computer backups, etc. appear to be working just fine. I’ll need to do some more testing just to make sure that everything is working as it should, but it looks like the trick was indeed enabling the SchUseStrongCrypto settings on BOTH the server AND on the client computer(s). Mea culpa! Someone needs to buy that Joe Mills bloke a beer for figuring this one out! Guess it’s never too late to teach an old dog (i.e. me) new tricks. 😉
EDIT (5/21/2020): After some more thorough testing, I’m still finding that everything is indeed working just fine with TLS 1.0 disabled… Client computer backups are still humming along, Essentials add-ins are installing/updating (when executed from a connected client computer), the client-side components of Essentials add-ins are installing/updating on the connected client computers, and (domain-join or SkipDomainJoin) connecting client computers to the server (via http://<YourServerName>/connect) is still working (with the one caveat mentioned below).
The only real issue I’ve found thus far is that when I connect a client computer to the server, the connector software’s wizard can no longer discover the server by its IP address (IPv4 or IPv6). Rather, I have to manually type in the server’s NetBIOS (i.e. computer) name into the wizard’s “Type the server address” field in order for it to be able to discover the server (which is only a minor inconvenience I suppose).
Of course you’ll need to watch out for the infamous chicken or the egg dilemma here seeing as you’ll need to make sure that you have the .NET Framework security settings added to your client computers BEFORE you attempt to connect them to the server, but I suppose that’s a trade off many will be willing to make in order to get TLS 1.2 enabled (and TLS 1.0/1.1 fully disabled) on their Essentials server.
EDIT (5/21/2020): I’ve just released updates for all of my WSE RemoteApp add-ins (i.e. Version 1.255.1836.0 or greater) that now allow you to easily “Setup IIS for SSL perfect forward secrecy and TLS 1.2“, and optionally “Disable TLS 1.0“, on your Essentials server (see: Enabling TLS 1.2 On Windows Server Essentials). When you choose to disable TLS 1.0, you will be prompted to download a simple .REG file that can be run on all of your client computers in order to add the required .NET Framework security settings. With TLS 1.2 enabled, and TLS 1.0/1.1 disabled, you’ll be able to obtain an A+ grade (as of this writing) from the SSL Labs SSL Server Test site for your Essentials server’s built-in Remote Web Access website. Enjoy! 😎
eugp says:
interesting. Now I need to figure out the right sequence of joining as a replication AD, installing WSE role, locking down Crypto, etc.
eugp says:
Are you using the script found here-
Setup Microsoft Windows or IIS for SSL Perfect Forward Secrecy and TLS 1.2
or your own? Sounds like you put together your own reg kit. I only get an “A” from SSL labs not an “A+” after running the script.
Mike says:
Yes, it’s a slightly modified version of the Hass Alexander script (v3.0.1) as I’ve mentioned here:
Enabling TLS 1.2 On Windows Server Essentials
In my tests, it gives an A+ grade (as of this writing anyway)… Are you sure that you’ve also enabled HTTP Strict Transport Security (HSTS) on your server (seeing as that’s probably required in order to hit the maximum A+ grade)? WSE RemoteApp automatically handles enabling HSTS for you as mentioned in my post above.
eugp says:
From your RemoteApp screenshots it looks like you are enabling TLS 1.2 on clients through your RemoteApp, is that the case? I don’t really need RemoteApp at this point (though it would have been nice for Quickbooks before it went to the cloud), but I do need a way to push TLS 1.2 out to 38 clients. I’m not sure that RemoteApp is cost-effective for this, but I am curious if it would work on standard domain users working remotely over WSE VPN or Remote Desktops.
eugp says:
WooHoo- A+ !
Mike says:
😉
eugp says:
Last night I had to re-enable TLS 1.0 in order to get the Configure Anywhere Access Wizard to complete successfully. I was having a problem with some users not being able to map drives after connecting with VPN so I thought I would re-run the CAA wizard. It would not run successfully until I re-enabled TLS 1.0 in IIScrypto for both client and server settings. Then it ran successfully, then I re-ran the PFS script. to get back to the starting point. Still having trouble with some clients mapping drives but not others. Is there a way to post to the TLS 1.2 page?
Mike says:
I can’t say as it at all surprises me that you’re having some difficulties after disabling TLS 1.0 (seeing as it’s deeply ingrained in Essentials). It’s quite possible that some of the Essentials features are using WCF (as I mentioned in my comment above), and so they’ll just never work properly with TLS 1.0 disabled. Temporarily enabling TLS 1.0 (when doing one-off type of things on the server such as connecting clients, configuring Anywhere Access, etc.), and then disabling it again afterwards, is probably the only solution there I’m afraid. It’d certainly be nice if Microsoft would step up and officially provide TLS 1.2 support in Windows Server 2016 Essentials, but I very seriously doubt that will ever happen at this point in time.
dhallam says:
Any info as im running server 2016 with the above working, but i only use the automatic DNS name registration and updating for remote connection to router etc, ie the remotewebaccess.com
i dont use it to connect to the server, just some services that are port specific.
when i do an in place to 2019 i loose this after a few days, any way of keeping the domain after upgrade. im asuming as it stops updating the new ip with microsofts remotewebaccess end.
As this is all i use dont use the backup or anything else, just the domain name for access to emby server and my router.
Dont realy want to loose the DNS name
Mike says:
Actually, you don’t ever lose your Microsoft personalized domain name (e.g. https://YourDomainPrefix.remotewebaccess.com) seeing as it remains linked to the Microsoft (Live) account that you used when you very first created it. You can have up to five different Microsoft personalized domain names associated with a single Microsoft account. Therefore, all you need to do is simply configure Anywhere Access/Remote Web Access again on the new server (be it 2012, 2012 R2, 2016, or 2019 with WSEE installed), and then sign in with your same Microsoft account, and the wizard will allow you to choose any of the Microsoft personalized domain names that you’ve already associated with your account (or you can create a new one). Just don’t ever “release” the domain name via the wizard (otherwise it will be removed from your Microsoft account and returned back to the pool of domain names available to everyone).
EDIT: BTW, you’ve stated that you’re doing an “in-place” upgrade from 2016 to 2019… I assume that you mean from the Windows Server 2016 Essentials SKU to the (absolutely horrible) Windows Server 2019 Essentials SKU. If so, then you shouldn’t be doing that… When you in-place upgrade Windows Server 2016 Essentials to Windows Server 2019 Essentials, Microsoft removes ALL of the Essentials bits from the server (which is why the Microsoft personalized domain name stops working for you). While you can manually install WSEE on the Windows Server 2019 Essentials SKU, you still won’t be able to make the Microsoft personalized domain name stuff work since Microsoft has removed all of the Remote Desktop Services (RDS) server roles from the (abomination that is the) Windows Server 2019 Essentials SKU, and so you can’t use the Anywhere Access/Remote Web Access feature (since it requires the RD Gateway server role that is part of RDS). The ONLY way to make it work is for you to use Windows Server 2019 Standard/Datacenter instead. Personally, you should just stick to using Windows Server 2016 Essentials since you’ll gain absolutely nothing from moving up to Windows Server 2019 for your stated use case.
dhallam says:
Yep sorry it was to in place to 2019 standard not that “it shoud not be named” version.
but i may have found an extreme work around by as i have a dreytek router they provice a free ddns service
its a shame as i will have visit a few remote sites but might prove better in the long run
as personall y i dont need any of the other WSEE services anymore. i used to love the remote access and backup , but i now use veeam and other remote services so moved away now, was just the ddns needed
Foden says:
Outstanding!!!
Followed your details steps to the letter, eventually ;o). Did a test install, about 80% successful, before I did what I should have done in the first place. I did seriously consider buying something so I could get the msi but decided to go the manual route. Some copy and pasting later I had a rudimentary robocopy script to copy the required files and folders to USB and another to copy it to the 2019 standard install. Then copied and pasted the other requirements, sanitizing the text in notepad. (also repeatable) As ever a little bit of planning work paid off in the end, plus it allowed me to mess around on the physical as well as virtual sandboxes.
Everything is up and running, I’m not using (yet) domains on my clients (home network) so used the skipdomain registry key but am messing around with that on my virtual setup. I’d say it’s 99.99% of the way there. Only issue I have encountered, that wasn’t caused by me is clearing, deleting or ignoring alerts in the Health Monitor. When I choose any of those options I get a progress window that says ‘Your request is being processed’ which stays there until you click the close gadget ‘X’ in the window. Have you seen anything like this before?
Thanks for all the hard work putting this together
Mike says:
Sounds like you didn’t run Windows Update on your 2016 Essentials source before you grabbed the files from it, and so you don’t have the latest set of Essentials files. The issue you’ve mentioned is a known problem with Windows Server 2016 Essentials that Microsoft addressed in one of their Windows Updates (i.e. KB4478877). See here and here for more info.
Foden says:
Hi Mike
I did run Windows update until there where no more updates to install.
So am I best starting my build again from scratch or is it recoverable, I will look through the links you sent now
Foden says:
Just powered on my setup VM and of course it’s applying updates :o( Which means the lateset updates had not been applied exactly as yo pointed out :O( Would your msi help at this point or is it best to bite he bullet and redo from scratch?
Mike says:
The WSEE Installer has come super far over the last couple of years, and does so many more things for you than you’ll get with a manual install, that I HIGHLY recommend that everyone uses it now instead of attempting to do the install manually. That being said, you CANNOT use the WSEE Installer over the top of an existing manual install of WSEE on 2019 (so it won’t work for you here unless you’re willing to completely start over from scratch again).
However, if you download the zip file that I’ve offered up in my second link, it contains the updated set of files that you’ll need to get you past this particular issue. Just read both of the links that I’ve pointed you to, and you should be all set.
Foden says:
Cheers Mike, clean is always the best foundation, so I think I’ll bite the bullet and start from scratch. I’ll use your msi too. So will take a look your product list for my ‘best’ purchase option
Thanks again for all the hard work on this
Mike says:
😉
Foden says:
Hi Mike
Everything has been going well since in installed your WSE installer on a fresh 2019 Std install. However, the last couple of days the client backup service kept stopping, then the server backup started to hang around 51-55%. This is all i see in the Backup log
“The backup operation that started at ‘2020-06-15T08:26:16.427589000Z’ has failed because another backup or recovery operation is in progress. Please stop the conflicting operation, and then rerun the backup operation.”
Disk management then becomes unresponsive. After a reboot everything looks OK and all my drives are good as far as S.M.A.R.T. is concerned
Contemplating started again from scratch if I have too but would rather not. So looked at the wse installer on your site and the one I used.
Mine is dated 2020-06-03 10:05am revision {AEFF9F57-46E2-4874-9C04-D85366BD89BD}
Site is dated 2020-06-10 5:06pm revision {F473A03D-E8C3-40D3-8300-84062B504DF7}
When I re-run mine it says in need to run a cleanup exe first and the site one says the older version must be removed first. Presumably then I’m not able to simply re-run the msi – I will need to remove and re-install. Will that have any ipmpatc on my data saved on the server?
Thanks
Mike says:
I’ve never come across that particular issue with the client/server backups before I’m afraid (under 2019, 2016, etc.). However, there’s nothing different in that area between 2016 and 2019 with WSEE installed, and so you might want to try searching Microsoft’s Windows Server Essentials TechNet forums just to see if anyone else has come across the issue before (in 2016 or earlier).
Other than that, have you tried running the backup repair wizard on your client computer backups just to see if that helps any? Open the server Dashboard, go to the “DEVICES” tab, click on the “Client computer backup tasks” task, click on the “Tools” tab in the dialog box that opens, and then click on the “Repair now” button. Ultimately, if the problem persists, you may just need to wipe out your existing server and/or client backups and start over from scratch again. I don’t know for sure though.
As for reinstalling WSEE on 2019 by re-running the WSEE Installer again (which probably wouldn’t help anyway)… I’m afraid you can’t do that seeing as the WSEE Installer was never designed to work like that (due to the complexities that are involved with installing Essentials). Rather, you’d need to completely uninstall all traces of Essentials from your server (by running the cleaner app, as instructed, before uninstalling it from the “Add or Remove Programs” applet in the Control Panel), and then install it again using the latest version of the WSEE Installer. Personally, you’d be better of just starting over with a completely new/clean/fresh install of Windows Server 2019 instead of attempting to go that route IMHO.
EDIT: BTW, one of the greatest features in Essentials is server backup. EVERYONE should take the time to enable it on their server. That way, if you ever encounter issues such as this one, you can just restore the server back to a time prior to when the problem first started occurring. For more info see:
Set up or customize server backup
Manage Server Backup in Windows Server Essentials
Restore or repair your server running Windows Server Essentials
Foden says:
Thanks Mike
The client backups run fine as long as the service is running, so a service restart is an easy fix, The server one thought isn’t and the current backup gave up the ghost at 55% again.
I prefer a clean start to these things anyways so will go that route, plus I have an image of the server pre wse install which will speed things up
Thanks again
Foden says:
So, touch wood, server backup is now running like it should
I use the server backup process but also have a secondary image backup using Acronis TrueImage. It was Acronis that helped me out this time
Mike says:
Glad to hear it. 🙂
cge says:
Hi there,
I’m trying the manual way and I’m facing an issue with the Start-WssConfigurationService, it says that arguments -CompanyName, -NetBiosName, etc doesn’t exist ?
Regards
Christophe
PS C:\WINDOWS\system32> Start-WssConfigurationService -CompanyName "" -NetBiosName "Home" -NewAdminCredential $cred -ComputerName "VMServeur" -Setting AllStart-WssConfigurationService : Impossible de trouver un paramètre correspondant au nom « CompanyName ».
Au caractère Ligne:1 : 31
+ Start-WssConfigurationService -CompanyName “” -NetBiosName “Home” -Ne ...
+ ~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument : (:) [Start-WssConfigurationService], ParameterBindingException
+ FullyQualifiedErrorId : NamedParameterNotFound,Microsoft.WindowsServerSolutions.Setup.Commands.
InvokeEssentialsConfigureServiceCommand
Mike says:
I don’t think the -CompanyName parameter can be an empty value (i.e. “”). Try including an actual value for it (or just omit it altogether since it doesn’t appear to be a required parameter). For more info see:
Start-WssConfigurationService
hfournier says:
Hi Mike,
First, thanks for providing this fantastic resource. I had given up on WS2019E.
After installing WS2019 Std and getting Essentials all setup and running, is it possible to change the Product Key to the WS2019E SKU, or will that rip out needed components?
BTW, when I tried posting a comment as a guest, I received the following error:
Error: You entered an incorrect CAPTCHA answer. Please go back and try again.
But, there’s no CAPTCHA question. Tried Firefox and new Edge.
Mike says:
You are most welcome. I’m glad that was able to help folks continue to use Essentials on Windows Server 2019. 😉
Great question, and I’m afraid it’s one that I don’t really know the answer to. If I had to guess, I’d say that the DISM /online /Set-Edition:ServerSolutions /ProductKey:XXXXX-XXXXX-XXXXX-XXXXX-XXXXX /AcceptEula (or slmgr /ipk <ProductKey>) command would simply fail (since going from ServerStandard to ServerSolutions most likely isn’t a supported downgrade). And, if it did by some chance succeed, I don’t know if all of the RDS server roles (including the RD Gateway role) would get stripped out or not (but I suspect that they would). I don’t have a Product Key for the Windows Server 2019 Essentials SKU, so I can’t test this out for you here, but when I run the DISM /online /Get-TargetEditions command in an activated Windows Server 2019 Standard install, it simply tells me that the only edition that can be upgraded to is ServerDatacenter. For more info see:
Converting a current evaluation version to a current retail version
DISM Windows Edition-Servicing Command-Line Options
Also, note that the Microsoft document linked above includes a “Limitations” section that states:
"You cannot set a Windows image to a lower edition. The lowest edition will not appear when you run the /Get-TargetEditions option."And:
"You should not use the /Set-Edition option on an image that has already been changed to a higher edition."Which just confirms what I’ve said above (i.e. the answer to your question is: Nope, it won’t work.).
As for the CAPTCHA issue on my site when attempting to post a comment as a guest… Thank you for bringing that one to my attention. I hadn’t noticed that this was broken (and no one else ever bothered to take the time to report the issue). I believe that it has been fixed now.
hfournier says:
So if you want a server running longer than the 3-year extended trial, you have to buy a WS2019 Standard license, right?
Mike says:
Yes, that’s typically how things work. Three years is quite a long time though. By that time, a completely new version of Windows Server will be available (Windows Server 2022, etc.), and you can just move to that newer version and start the extended trial all over again (or you can just go the local KMS server emulator route instead 😉 ).
Michael Weaver says:
I am only doing this upgrade because after 7 installs of WSE2016 (to fix an unrelated issue), I CANNOT get Anywhere Access to install/complete. There is no resolution that I can find on the web. FRUSTRATING!
—————————————–
I have read through the documentation provided. (Very thorough! Nice work) However, I cannot determine if, like WSE2016, that the WS2019STD server has to be a domain.
To test, I have installed WS2019STD into a VM (courtesy of Oracle VirtualBox).
It’s all patched. However, in the Server Manager > Local Server output, I see ‘Workgroup WORKGROUP’. During the installation, I did not have it skip creating/joining a domain. (There wasnt an option)
Will this do all of the basic things without hosting the domain? (remoteapp, backups, file share, etc AND work with WSE added?)
**At the time of this post, I was still waiting on the password for the WSEE download.
Mike says:
Nothing changes in Essentials when you install it on Windows Server 2019 (as compared to installing it on Windows Server 2016) seeing as you’re merely extracting out all of the Essentials bits from 2016 and then adding them to 2019 here (100% unchanged). So… Just as with 2016 (and 2012 R2, 2012, and 2011 that preceded it), Essentials must either be or see a domain controller (and cannot be configured in a Workgroup).
By default (in an out-of-the-box install), Essentials is configured as the primary domain controller on your network. If you don’t want Essentials to be a domain controller, then you must manually join your (to be Essentials) server to another server that is acting as the primary domain controller (using the native tools in Windows) BEFORE you configure Essentials on the server. That way, the configuration wizard for Essentials will see that the server is already joined to another domain, and it will then configure the Essentials server as a member server within that domain (instead of configuring it as the primary domain controller). This is just how Microsoft designed Essentials to work, and it has nothing whatsoever to do with installing Essentials on Windows Server 2019.
As for your Anywhere Access/Remote Web Access issues… If you can’t get those features to work under 2016, then you most likely won’t get them to work under 2019 either. There’s nothing magic going on here… We’re simply extracting the Essentials bits from 2016 and then adding them to 2019 is all. As a general rule of thumb, if something in 2016 isn’t working for you, then it more than likely won’t work in 2019 either.
Therefore, if I were you, I’d just try and resolve your issues in 2016 so that you can stick with that platform instead (seeing as it’s still fully supported by Microsoft for many years to come). AFAIK, there are no outstanding issues with Anywhere Access/Remote Web Access in 2016, and so whatever problems you’re encountering are most likely specific to your particular server, network, router, ISP, etc. (as we’re not seeing any issues whatsoever setting up Anywhere Access/Remote Web Access over here under 2016/2019; outside of the “normal” quirks that it has always had that is).
Zack says:
Hello,
I followed your instructions above, I think, correctly and in the order that you specified. However I am experiencing an issue at the Start-WssConfigurationService command. It fails at 75%. In event viewer I’m seeing 2 different errors.
The first being Event 1026, .NET Runtime
Application: SharedServiceHost.exeFramework Version: v4.0.30319
Description: The process was terminated due to an unhandled exception.
Exception Info: System.IO.FileNotFoundException
at System.IO.__Error.WinIOError(Int32, System.String)
at System.IO.FileStream.Init(System.String, System.IO.FileMode, System.IO.FileAccess, Int32, Boolean, System.IO.FileShare, Int32, System.IO.FileOptions, SECURITY_ATTRIBUTES, System.String, Boolean, Boolean, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode, System.IO.FileAccess, System.IO.FileShare, Int32, System.IO.FileOptions, System.String, Boolean)
at System.IO.FileStream..ctor(System.String, System.IO.FileMode)
at Microsoft.WindowsServerSolutions.Common.XmlSerializationHelper.
XmlDeserializeFromFile[[System.__Canon, mscorlib, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089]](System.String)
at Microsoft.WindowsServerSolutions.Configuration.Tasks.AddTrustedSiteTask.
Run(Microsoft.WindowsServerSolutions.TaskManagement.ITaskDataLink)
at Microsoft.WindowsServerSolutions.TaskManagement.Data.Task.
Run(Microsoft.WindowsServerSolutions.TaskManagement.ITaskDataLink)
at Microsoft.WindowsServerSolutions.TaskManagement.TaskScheduler.
RunTasks(System.String, System.String)
at Microsoft.WindowsServerSolutions.ConfigService.
ServerSetupActivity+c__DisplayClass58_0.b__0(Boolean)
at Microsoft.WindowsServerSolutions.ConfigService.ServerSetupActivity.
HandleWindowsUpdate(System.Action`1)
at Microsoft.WindowsServerSolutions.ConfigService.ServerSetupActivity.
RunInitialConfiguration()
at System.Threading.ExecutionContext.RunInternal(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.ExecutionContext.Run(System.Threading.ExecutionContext, System.Threading.ContextCallback, System.Object, Boolean)
at System.Threading.TimerQueueTimer.CallCallback()
at System.Threading.TimerQueueTimer.Fire()
at System.Threading.TimerQueue.FireNextTimers()
The 2nd is Event 1000, Application Error
Faulting application name: SharedServiceHost.exe, version: 10.0.14393.0, time stamp: 0x57898f9eFaulting module name: KERNELBASE.dll, version: 10.0.17763.1339, time stamp: 0xff7ee565
Exception code: 0xe0434352
Fault offset: 0x0000000000039709
Faulting process id: 0x2aa8
Faulting application start time: 0x01d65eaf600913bd
Faulting application path: C:\Windows\System32\Essentials\SharedServiceHost.exe
Faulting module path: C:\Windows\System32\KERNELBASE.dll
Report Id: bd49fac6-2942-48c1-bd86-ba3384426038
Faulting package full name:
Faulting package-relative application ID:
Any help would be greatly appreciated.
Thanks,
Mike says:
Alas, I’m afraid that I’ve never come across that one before. Looks like one of the dependency files are missing on your system. Best I can tell you here is to try it all again while making sure that you have properly copied over all of the required files (along with their required permissions). Other than that, you can try looking in the “Logs” folder over on your server to see if any of the log files in there give you a bit more information to go on. You can find the Logs folder here:
C:\ProgramData\Microsoft\Windows Server\Logs
Ultimately, if you just can’t get it to work, then I suggest you try using the WSEE Installer instead (seeing as it will just work for you without all the hassle).
Good luck!
dylan says:
Hi Mike,
I’ve followed through the steps and all has gone well but i seem to have fallen at the last hurdle. when i try to run start-WssConfigurationService i get the following
Start-wssConfigurationService : The term ‘Start-wssConfigurationService’ is not recognized as the name of a cmdlet, function, script file, or operable program. Check the spelling
of the name, or if a path was included, verify that the path is correct and try again.
At line:1 char:1
any suggestions on solving this would be muchly appreciated.
Regards
dylan
Mike says:
That particular error indicates that PowerShell is not able to find the Start-wssConfigurationService cmdlet on your server, and so you must not have installed all the required folders/files properly (as per step #3). Specifically, the Start-wssConfigurationService PowerShell cmdlet is located within the WssSetupCmdlets.psd1 file of the following folder:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\WssSetupCmdlets
BTW, if you’re getting stuck on stuff like this, then I highly suggest that you use the WSEE Installer instead (seeing as it takes care of everything for you and makes installing WSEE on Windows Server 2019 super easy – no muss, no fuss!).
dylan says:
Hi Mike,
ive gone ahead and got the MSI installer. is there any way at all that it can be run on 2019 essentials before we shell out for standard?
sorry to be a pain in the place.
dylan
Mike says:
Alas, I’m afraid not…
The Windows Server 2019 Essentials SKU is an ABOMINATION!
Microsoft not only removed all of the “Essentials” bits from it, but they also removed all of the Remote Desktop Services server roles from it as well. As a result, the Remote Desktop Gateway server role is not available in the SKU, and so you can’t use any of the Anywhere Access/Remote Web Access features when you install WSEE on it. For this reason (and many others), I’ve physically blocked the WSEE Installer from being able to be used on the SKU. You must use Windows Server 2019 Standard or Datacenter instead.
cge says:
Hi Mike,
I’ve installed WSEE manually few month ago and I’ve seen your message “EDIT (8/21/2020): Version 10.0.14393.3866 of the WSEE Installer has now been released”
I understand that I need to pick up the 3 mentioned new files in my Server 2016 updated but what does the registryUpdate.reg file exactly ?
Christophe
Mike says:
The registry updates in that file are only for installations that have already been performed via prior releases of our WSEE Installer, and not when you’ve performed the installation manually.
The manual installation steps I’ve provided try to keep things simple (by design), and so they only net you the bare minimum that is required in order to get the Windows Server Essentials Experience installed, and working, on Windows Server 2019. Whereas, the WSEE installer performs a much more complete, and proper, installation (i.e. it gives you the whole nine yards so to speak).
In the beginning, the two installation procedures were nearly identical, but over the years, the WSEE Installer has evolved to produce a much more detailed and through install (that’s just too complex for me to describe with a succinct list of steps). That’s why I now (highly) recommend that folks use the WSEE Installer instead of attempting to perform the installation manually. Basically, the WSEE Installer does a much better job of applying all of the esoteric details that I’ve learned about the WSEE server role installation over the last couple of years (it’s still not perfect, but it’s getting pretty close now).
That being said… If the manual install is working well for you, then there’s absolutely no need to worry. You should simply continue to enjoy it as it stands.
Troels Bjerre says:
Thx, Mike. Your manual process is still working, only two things: Setting -All gives an error – but can omitted as somebody mentioned, and the server name is not changed and cannot be changed later. So change server name before starting the process.
Mike says:
I’m glad to hear that.
I’m still not seeing any issues here with the -Setting All parameter, but I’ll go ahead and remove it from the Start-WssConfigurationService command in step #8 since many folks appear to be having an issue with it (and since it’s an optional parameter that isn’t really needed anyway).
I’m definitely not able to replicate the issue with the server name though (and I don’t believe that anyone else has reported a similar problem with it that I am aware of). In every test I run, the server always gets (re)named properly for me here. You are correct in that you can always just manually (re)name your server (and reboot it), and then omit the -ComputerName “<TypeYourServerNameHere>” parameter from the Start-WssConfigurationService command in step #8 since it too is an optional parameter.
Troels Bjerre says:
I tried again, still no change of name. The EE part works well, the WS part not so much. I end up with a very limited administrator role, cannot access the network adapter or change the name of the server. When I expand the administrator role, I get locked out of the server on the well known trust issue. Now getting your product.
Mike says:
I’m afraid that I have absolutely no idea what’s going on there as I’ve never encountered anything like that before. However, it doesn’t really sound like those issues have anything to do with installing WSEE on Windows Server 2019 per se. Are you starting out with a 100% new/clean/fresh out-of-the-box Windows Server 2019 (Standard or Datacenter) install with NO OTHER server roles, features, and applications installed? If not, then I STRONGLY suggest that you try that instead. Based on the issues that you’re currently seeing, I seriously doubt that the WSEE Installer is going to work for you either (unless you start over from scratch with a new/clean/fresh out-of-the-box install that is).
Troels Bjerre says:
Your installer works as intended, it seems. I must have made an error somewhere in the manual process.
This was the starting point:
Windows Server 2019 Standard fresh installed
After updates i have this:
Version 1809
OS Build 17763.1432
Mike says:
That’s great news. I’m glad to hear that the WSEE Installer got you up and going.
The WSEE Installer just makes everything so much easier (and far less prone to errors/failure), and so that’s why I now highly recommend that folks use it to install WSEE on Windows Server 2019 (Standard or Datacenter).
kgoroway says:
Here’s my experience:
Long running 2012 R2 Essentials server, in-place upgrade to Server 2019 Essentials. (Didn’t know any better)
Change 2019 Essentials to Standard. Install via WSEE Installer. It didn’t go well.
Bare metal restore to 2012 R2 Essentials. In-place upgrade to Server 2016 Essentials. Download/install all updates. Create a server backup just in case I need to roll back to 2016. In-place upgrade to Server 2019 Standard. Download/install all updates. Install via WSEE Installer.
This also didn’t seem to go well (looked very similar to the 2012 → 2019 path).
So, I started digging.
First problem: All of the server essentials services were set to disabled. Turned on what I needed to automatic and rebooted. Hey, would you look at that? Dashboard looked much happier.
Second problem: Went to install a connector from a client, and found that the web page didn’t work.
Found this:
Connect Page Error Essentials 2016 Upgrade
which points out that this is a permissions issue on the log files. Fix applied, connector downloaded/installed and everything seems to be working fine. My Users/Folders/Client Backups are all intact. Only thing I seem to have lost are the server backups (from 2012 and 2016)
(So, there’s a chance that the direct 2012 → 2019 would have worked also, I guess?)
Mike says:
Thanks for sharing your experience with what worked (and what didn’t work) for you.
That being said… This is exactly the reason why I always suggest that folks start with a brand new/clean install of Windows Server 2019 when installing WSEE onto it. In place upgrades from prior versions of Windows Server Essentials (and even domain migrations) will often just end up causing you a lot of extra work (and grief) in the long run. IMHO It’s always best to start off with a completely clean install. Of course I’ll leave that up to folks to decide for themselves though.
As for the permissions issues on the Logs folder… I just double checked, and the Configure Windows Server Essentials wizard properly sets all of those permissions for you on a clean/fresh install. Thus, and as Robert Pearman mentions in his article, it only seems to present itself as an issue when doing an in place upgrade from prior versions of Windows Server Essentials (to Windows Server 2016 Essentials). Nice find on locating and linking us to his fix for the problem though.
EDIT (9/13/2020): And as I’ve mentioned here, it’s always best practice to in place upgrade your earlier version of Essentials to 2016 in graduated steps (e.g. 2011 → 2012 → 2012 R2 → 2016) BEFORE attempting to in place upgrade it to Windows Server 2019 Standard (i.e. don’t jump 2012 straight to 2019).
EDIT (9/20/2020): I’ve now added support for in place upgrades to the WSEE Installer for folks who choose to go that route. The WSEE Installer will now recognize that Windows Server 2019 has been in place upgraded from a previous instance of Windows Server Essentials (e.g. Windows Server 2016 Essentials, etc.), and it will configure the server accordingly (by fixing the starting of all the services, setting the required permissions on the Logs folder, etc.). The only real caveat is that the Configure Windows Server Essentials wizard may refuse to start at the end of the WSEE Installer’s installation process, and if so, you will simply need to double-click on the “Configure Windows Server Essentials” shortcut on the server’s desktop in order to force the wizard to run (or you can just restart the server). The wizard will then recognize the in place upgrade, and configure it accordingly.
EDIT (12/9/2020): I’ve now added support for in place upgrades from 2019 → 2022 (or from older → newer vNext builds) to the WSEE Installer (via the WSEE Zapper). See my 12/7/2020 edit here for further details.
kgoroway says:
Yep, understood that I wasn’t obeying best practices. In my mind, I was willing to spend up to two days troubleshooting/getting it working, since I think it would have taken me about 3 days if I started with a clean install and had to reconfigure/install everything that is there already.
In the end, it was probably 45 minutes of work/poking around (which was largely time spent waiting for reboots), which is why I wanted to post this so people know that it *can* work.
Mike says:
😉
Tom says:
I have been using this on a 2019 server of almost a year now with everything working great. I have upgraded my Windows 10 PCs to version 2004 and now they show offline and not available in the console. Any ideas?
Mike says:
Alas, this has nothing whatsoever to do with installing WSEE on Windows Server 2019, but is rather just a (unfortunate) side-effect of installing feature updates on your connected Windows 10 client computers I’m afraid. That being said, the fix is quite easy as all you need to do is run the Windows Server Essentials Connector software on each of your upgraded Windows 10 clients again by (re)visiting http://<YourServerName>/connect from each of them. Once you’ve done that, they will then be reconnected to the server once again.
The only thing that you’ll want to make note of here is if your (previously) connected client computers are joined to your domain, then you’ll want to temporarily add the SkipDomainJoin registry entry to them BEFORE you run the connector software on them, and then remove it again right afterwards. Doing that will force the connector software to skip joining the client computer to your domain a second time (and messing up your user profile on the client computer). Thereby saving you a lot of grief in the long run.
Tom says:
Thank you for the quick response.
Scott Baker says:
Why would I not be able to run the Start-WssConfigurationService -Credential $cred command? I get the following error:
Start-WssConfigurationService : The 'Start-WssConfigurationService' command was found in the module 'WssSetupCmdlets',but the module could not be loaded. For more information, run 'Import-Module WssSetupCmdlets'.
At line:1 char:1
+ Start-WssConfigurationService -Credential $cred
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Start-WssConfigurationService:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule
Mike says:
I’ve never come across that one before. Are you certain that you have manually copied over all of the required folders/files (including those in the GAC) correctly?
Han Arts says:
Hi Mike, tried to install WSEE on vNext in a VM however gave me message that WSEE needed server 2019 or 2022 to continue. Can that be language related or build related (page redirects me to 20241)
Mike says:
What version of Windows Server vNext are you using? The latest is Build 20251 (which just came out yesterday), and I’ve just updated the WSEE Installer to work with it. Therefore, you can simply re-download the WSEE Installer again and it will now work with Windows Server vNext Build 20251.
TheDoc says:
Perfect, tried with your latest version and all ok now. Cheers
Bill says:
It all installed fine, but I’m having issues promoting the new machine to a domain controller. It’s complaining about the AD certificate role, and that’s needed for some of the IIS stuff. It’s joined to the domain fine and all permissions seem to be working right, but I can’t really demote the WSE 2012 R2 machine without bringing this one up.
Mike says:
I’m not sure exactly what’s going on there as I don’t do domain migrations very often (but they have been known to work). I STRONGLY suggest that folks always start off with a new/clean install of Windows Server 2019 before attempting to install WSEE onto it. Other than that, you probably should of done an in place upgrade from WSE 2012 R2 to WSE 2016, and then on to WS 2019 after that as I’ve described here.
TheDoc says:
Received my first update for the experience role and all updated perfect. Thanks for your continious support Mike. Cheers.
Mike says:
I’m very glad to hear that. The latest 14393.4046 update took a huge amount of work for me to implement in the updater due to the large number of updated assemblies (and with one of them very strangely being switched over to targeting .NET Framework 4.6 as opposed to all of the others targeting .NET Framework 4.5). Anyhow, it’s good to hear that the update went smoothly for you. Thanks for taking the time to drop a note letting me know as that’s a really big help for me. And you’re most welcome for the support. I love Essentials and I’m happy that I can make it continue to work for folks under Windows Server 2019/2022. 😉
JesAmos says:
Great Guide. First time running through it. Everything went fairly smoothly (minus some missing spaces in my copy paste in step 6 preventing service creation) until step 8. I’m guessing I must have missed something farther back but I get an error trying to Start-WssConfigurationService.
PS C:\Windows\system32> Start-WssConfigurationServiceStart-WssConfigurationService : Cannot retrieve the dynamic parameters for the cmdlet. Could not load file or assembly
'SetupCommon, Version=10.0.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35' or one of its dependencies. The
system cannot find the file specified.
At line:1 char:1
+ Start-WssConfigurationService
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : InvalidArgument: (:) [Start-WssConfigurationService], ParameterBindingException
+ FullyQualifiedErrorId : GetDynamicParametersException,Microsoft.WindowsServerSolutions.Setup.Commands.InvokeEsse
ntialsConfigureServiceCommand
Any idea where I need to look?
Mike says:
SetupCommon.dll is one of the required Windows Server Solutions (WSS) assemblies that are stored within the GAC. You must of missed it while performing step #4 in the manual install instructions.
Troels Bjerre says:
Now there is a new build available: Windows Server Preview Build 20270. I could download that and upgrade, but that would be wise, I suppose?
Mike says:
I wouldn’t recommend using Windows Server vNext (i.e. Windows Server 2022) right now unless you’re just doing so for testing purposes. Microsoft is currently releasing new builds of it at a feverous pace (about once every week or two). That’s probably not a good thing if you’re trying to actually use it for a stable/working server.
Also… I haven’t released a version of the WSEE Installer that will work with Build 20270 yet seeing as I’m running a bit behind at the moment (due to Thanksgiving and some unforeseen blues screens on my main development machine due to ill-behaved Windows Updates – thanks Microsoft!). Hopefully I’ll have it out soon though.
Lastly… While the WSEE Installer supports in place upgrades from 2016 → 2019/2022, it doesn’t currently support in place upgrades from 2019 → 2022. There’s an extra (manual) step that needs to be done before it will work, and I haven’t finished all of the testing surrounding that quite yet. I’ll do that as we get closer to RTM/GA for 2022.
EDIT (12/3/2020): I’ve now released new builds of WSEE Installer, WSEE Updater, WSE RemoteApp 2016, and WSE WorkFolders 2016 with support for Build 20270. Enjoy! 😉
EDIT (12/7/2020): I’ve now added support for in place upgrades from 2019 → 2022 (or from older → newer vNext builds) to the WSEE Installer (via the WSEE Zapper). See my 12/7/2020 edit here for further details.
Jimmy says:
Has anyone completed this recently, in say 2020/2021? I had a working setup a year or so ago when the article was published, but my recent attempts at this all fail. I went as far as installing server 2016, updating it as of Jan 1 2021, installing the role, but not configuring it, then sharing the whole c drive. Went back to my 2019 box and wrote a script in cmd to run all the powershells in order, then robocopy the files. Since you can’t copy all reg keys from a remote host, I exported them all to .reg on 2016, and just called them from my batch script as import reg1.reg through 10. Did the services, the firewall rule, and vpn fix. But I cannot start wssconfiguration from powershell. Even manually, it just keeps saying that it doesn’t exist like in previous comments. The solutions there were to ensure the config wizard was not run on the 2016 install. Does the installer available free with purchase of another product still work on the most recent server 2019 install? I’m about ready to give up and buy your least expensive product for the sake of getting this installer…
Mike says:
While I haven’t personally tried the manual installation steps in quite a few months now, I see no reason as to why they wouldn’t still work (and I can tell you with 100% certainty that the WSEE Installer works wonderfully seeing as I’ve just completed two installations with it yesterday; one under Windows Server 2019 and one under Windows Server 2022/vNext). From the sounds of it, you’ve missed/overlooked something that’s required by the Start-WssConfigurationService PowerShell cmdlet. Are you sure that you’ve properly copied over all of the required folders and files from the three “C:\Windows\System32\WindowsPowerShell\v1.0\Modules\…” folders, as well as all of the (151) required GAC folders and files? Are you running the PowerShell cmdlet from an elevated (i.e. Run as administrator) PowerShell prompt?
Personally, if it were me, I’d just use the WSEE Installer here and stop wasting any more of my time on the manual installation. The WSEE Installer handles all of this messy stuff for you. And, as I’ve mentioned in many of my other comments, the WSEE Installer has evolved so much now, and does so much more for you than you’ll get with a manual installation (including health alerts when updates become available, and a simple/easy process for installing those updates via the WSEE Updater, etc., etc.), that I no longer recommend that folks do the installation manually. That’s just my two cents though. If you’re dead set on doing the installation manually, then by all means please do. AFAIK, it should still work just fine for a minimal/bare bones installation of WSEE as long as you’re following my manual installation steps exactly as I’ve outlined them. Good luck!
Jimmy says:
Thanks for your reply, Im sure its much more straight forward with the installer, I need to look over your products and either choose the least expensive or see what seems interesting. This is for a homelab, so I’d need to see what I could actually use. If you want to look at it, here is my script that I am running as admin as a notepad file saved as wsee.cmd.
<<SNIP>>
(pastebin may show line breaks, but trust me the original document is all solid lines with the correct spacing)
I’m sure theres a better way to write it, but that works for me, well it actually doesnt, but Im not sure if its the script or the process. I have tried it manually too, The error I get running it on a bare stock version of winserver2019 with all the switches is.
PS C:\Users\Administrator> $cred = Get-Credential -Username "Administrator" -Message "Enter Password Here"PS C:\Users\Administrator> Start-WssConfigurationService -NetBiosName "redacted" -NewAdminCredential $cred -ComputerName "alphaserver" -Setting "All"
Start-WssConfigurationService : The term 'Start-WssConfigurationService' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the
path is correct and try again.
At line:1 char:1
+ Start-WssConfigurationService -NetBiosName "redacted" -NewAdminCredent ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Start-WssConfigurationService:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
and the error I get if i just run wssconfig
PS C:\Users\Administrator> Start-WssConfigurationServiceStart-WssConfigurationService : The term 'Start-WssConfigurationService' is not recognized as the name of a cmdlet,
function, script file, or operable program. Check the spelling of the name, or if a path was included, verify that the
path is correct and try again.
At line:1 char:1
+ Start-WssConfigurationService
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Start-WssConfigurationService:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CommandNotFoundException
So its something in the files not allowing wssconfigurationservice to start. I was wondering if it had to do with the latest build versions of winserver2016 or winserver2019, since this write up and the original source files are just over 2 years old. I considered trying to hunt down older iso’s to mount as vms and try again, but Im going to look at your products too, to evaluate getting a license for your installer.
A final question on the installer, If I license your least expensive product and use the installer on my dc, but then reimage it say a year down the line, or upgrade to 2022, will your installer still work since its the same physical pc? this question is relating to your clause that the installer is bound to the pc that you run it on.
Mike says:
I took a quick look at your script, and it seems fine to me except for you’re missing the /COPYALL option parameter on all of your robocopy calls. Other than that, from your stated PowerShell errors, it appears that the “Start-WssConfigurationService” cmdlet is simply not being found on your server. This could possibly be due to a permissions issue on the following file:
C:\Windows\System32\WindowsPowerShell\v1.0\Modules\WssSetupCmdlets\WssSetupCmdlets.psd1
As that’s the file (module) that defines the “Start-WssConfigurationService” cmdlet. Take a look at the file and make sure that both the SYSTEM and the Administrators accounts have read & execute permissions to it. Also, the module requires the following assembly, so make sure that it’s available and that it also has the proper permissions:
C:\System32\Essentials\Wssg.Setup.Commands.dll
Other than that, I can’t see any reason as to why it wouldn’t be working for you (as the manual install process has always worked just fine for us here).
As for your question about the WSEE Installer… The “Registration Key” you receive from us will be linked to the copy of Windows Server 2019/2022 that you initially install it on (as well as to the underlying hardware of the physical machine or virtual machine). If you simply re-install on the exact same Windows Server product edition (e.g. Standard or Datacenter), and underlying hardware (or VM configuration), then you will be just fine (even after in place upgrading to 2022, etc.). However, if you happen to run into any issues in that area, all you need to do is contact us and we’ll just reset the license for you.
Jimmy says:
Perfect, thanks Mike, Im still looking into your products on what may be valuable in a homelab environment, but just to update. I did get the manual method working, my script actually had two typos in it, one line i robocopyed from z: to z: instead of c: (thus not actually copying anything, that was the start menu) and if you look closely at the wsssetupcmdlets copy, you will notice that i am copying it to the wrong directory, thus not allowing the setup to run. I have corrected these errors, and all ran well. Thanks again for your pointers. Sorry to make a software dev read through my terrible batch programming. But hey, it was quick and dirty, and in the end after fixing typos, it did work. Im sure theres a more efficient way of writing it, but I like automation, which is why im still probably going to buy a product to look into the installer.
Mike says:
Glad to hear that you found those typos, and correcting then resolved your issue. Nice sleuthing!
Enjoy using WSEE on Windows Server 2019. 😉
Jimmy says:
Well I got everything running, but can’t seem to get the vpn to install, and have done quite a few searches, and fixes. Anyhow, I have just purchased a license to one of your products and put a ticket in for the WSEE Installer. So hopefully that will just fix me up.
Thanks again for everything !
Mike says:
Thanks for your support. I’ve now emailed you over your access information for the WSEE Installer. 😉
EDIT: (1/9/2021): BTW, I’m not 100% sure what will happen if you attempt to run the WSEE Installer on a server where WSEE has already been manually installed and configured. I assume that it will just install/overwrite all the required files, etc. and then run the Configure Windows Server Essentials wizard (which would then just inform you that WSEE has already been successfully configured), but I do not know for certain as that’s an unsupported (i.e. untested) installation path.
Jimmy says:
Thanks again Mike, I plan to format and reinstall server2019standard prior to using your installer just to ensure nothing goes wrong. Its a Homelab and not production, so I can do that basically whenever I choose lol, but as for the VPN fix, I have already applied both of those. The error I am getting is more similiar to what is described here: Set up Anywhere Access wizard completed with errors, VPN was not configured successfully
but I have already tried that fix, and I still cannot set it up. I am going to wait to see what happens when using your installer.
Mike says:
That sounds like a plan.
Strange as I’ve never come across that problem before, but then again I don’t use the SSTP VPN feature of Windows Server Essentials much (as I explained in the VPN fix comment that I linked you to previously). Well, let me know what happens after the fresh 2019 install, and if you still can’t get VPN working, then let me know and I’ll look into it for you.
twizt3dkitty says:
Just to update, it seems like everything went well when using your installer, Anywhere Access and VPN have installed and configured successfully. Not sure what was causing the issue with manual install, but to me it doesn’t matter anymore. I can absolutely say that to anyone else still setting this up, using Mike’s installer just simplifies things so much, its absolutely worth investing in one of his products just for the sake of getting the installer license.
A side note, not really an issue, but just an FYI to all and Mike, if you plan to setup the client restore service, you need to download the Windows PE add-on for the ADK, version 2004, from: Download and install the Windows ADK However it does inform you of that during setup. Perhaps Mike, you may want to look into silently installing this package with the WSEE Installer, just to save users that step. The PE ADK does not require a reboot and the actual ADK supports /quiet switch, so I assume the PE addon does as well, but you would need to look into that.
Mike says:
😉
EDIT (3/23/2021): I looked into your suggestion of installing the Windows ADK along with the WSEE Installer, but unfortunately, the end result is absolutely HUGE (at around 3.46 GB), and so I’m just not going to be able to accommodate doing that. Folks will simply need to follow the download link that Microsoft provides and manually install the appropriate version of the Windows ADK on their servers for themselves if they want to enable the client restore feature.
MATT GRANT says:
I am reinstalling a Server 2019 Essentials server that I used your WSEE Installer on about a year ago and now with the latest WSEE Installer it says it will not install on 2019 Essential because of the Anywhere access/Remote Desktop Gateway role. I remember seeing this message when I used it last time, but I thought I could proceed at my own risk. Now it just ends the install. The only option I need for 2019 Essentials that WSE16 had is Workstation backups. I do not care about any other pre-WSE19 features. Is there a way to only install the WS backups feature? I am going to be really bummed if this won’t work 🙁
Mike says:
Alas, I’m afraid not. See my 6/3/202 edit here for the details on that one.
Why not just convert (i.e. transition) your Windows Server 2019 Essentials SKU to Windows Server 2019 Standard so that you can use the WSEE Installer? The Windows Server 2019 Essentials SKU is an abomination, and so you’re MUCH better off just using Windows Server 2019 Standard instead (IMHO). I talk about doing this in the second paragraph/bullet point of the “Suggestions, Limitations, and Known Issues” section of the main article above.
EDIT (1/22/2021): I’ve now removed the block that prevents the WSEE Installer from being used on the Windows Server 2019 Essentials SKU. NOTE: While I continue to insist that WSEE should NOT be installed on the Windows Server 2019 Essentials SKU (since it does not contain the Remote Desktop Gateway server role that is required by certain parts of the Anywhere Access / Remote Web Access feature), you can now proceed with the installation if you do not need to use the Anywhere Access / Remote Web Access feature. 🙄
MATT GRANT says:
Do I lose the built in 25 user licenses that WSE19 comes with if I switch it to WS2019 Standard?
Can I use a previous installer version to do the install anyways? All WSEE functionality has been working except for Anywhere Access/Remote/VPN (which I do not need). It has worked perfectly for me on the server I have reloaded a few times.
Mike says:
See don’t fret about silly CALs.
Troels Bjerre says:
Hi Mike!
When you wrote about the WSEE Zapper, did you mean first use the Zapper, then uninstall WSEE via Apps and features? First Zapper then reinstall WSEE did not work well for me.
Mike says:
The WSEE Zapper is only meant to be run AFTER you’ve done an in place upgrade from Windows Server 2019 with WSEE installed to 2022 (or from an older preview/vNext build of 2022 with WSEE installed to a newer one). Therefore, you should NOT uninstall WSEE via the Programs and Features applet, or via Settings → Apps, before doing the in place upgrade.
Additionally, the WSEE Zapper is NOT needed when doing an in place upgrade from Windows Server 2016 to 2019/2022.
Pat says:
I installed the Install WSE Experience on Server 2019 successfully and was able to configure everything per your excellent write up. However, using SkipDomainJoin connection, I cannot connect client PCs to the server.
I used a connector I used on Server2016 Essentials but I get the error “No server detected in the network.” I also tried to input the Server2019 ip address of 192.168.1.10 and got “Cannot get information from 192.168.1.10. Please contact your administrator.”
When I tried on the client PC to download the connection using http://server2019/connect I get a “403 Forbidden: Access is denied”.
Mike says:
I’m not seeing any issues over here connecting client computers to WSEE under Windows Server 2019/2022 (with or without using Microsoft’s SkipDomainJoin connection method).
Have you followed the guidance I’ve given for connecting client computers that’s shown in the “• (8/25/2019)” bullet point under the “Suggestions, Limitations, and Known Issues” section of this article? Basically, if you point your client computer’s preferred IPv4 DNS server address to the static IP address of your Essentials server, and point its alternate IPv4 DNS server address to the IP address of your network router (e.g. 192.168.1.1) or other DNS server (e.g. 8.8.8.8), then the client-side Windows Server Essentials Connector software should be able to find the server just fine.
Other than that, have you by chance disabled TLS 1.0 on your Essentials server (using this method provided by our WSE RemoteApp add-in, or otherwise)? If so, then you might want to try temporarily re-enabling TLS 1.0 until after you’ve joined all of your client computers to the server.
I’ve joined hundreds of client computers to Essentials servers over the years (under Windows Server 2019/2022 with WSEE installed via the WSEE Installer), and it always works just fine for me here.
Andrew Macaulay says:
Just tried this all out on Server 2022 and the manual install went really well (really great instructions) – testing before deciding whether to move to this setup in the coming months or so — although I will probably wait for Server 2022 to go “gold” so I don’t have to do it all again after that! Some comments/feedback:
One thing I did not work out is whether you have to setup e.g. keyboards, language settings and DATE/TIME and Timezone settings before running the Start-WssConfigurationService. The configuration GUI in Server 2016 explicitly has a step for time/timezone settings, but the command line does not seem to.
Is there a way to run the configuration wizard for the Essentials Experience rather than doing it through the command line?
If not, then it is probably worth calling out the need for these steps to be done as part of the preparation steps as, once setup it seems impossible to change some of these settings, at least if the server is the Primary Domain Controller.
Also noted that the Start-WssConfigurationService now has a mandatory “-Setup” value that is used to determine what automatic updates are to be included (not noted in your instructions) and also has an optional -DNSName for the domain name (as per the optional step also in the Essentials Wizard on 2016) which may be worth noting in your instructions.
Mike says:
Glad to hear that the manual installation went well for you. I’d definitely wait for Windows Server 2022 to RTM (sometime in the second half of 2021) before attempting to use it on a production server. WSEE sure does work really nice on it though. 😉
You can configure keyboard, language, date/time, etc. settings at any time on the server (before or after configuring WSEE on it). Some of that can be done from the “Settings” dialog box that’s available within the server Dashboard, and the remainder can be changed by simply signing directly into the server’s desktop as an administrator.
Unfortunately, there is no way to run the “Configure Windows Server Essentials” wizard when doing a manual install. For more info on why see here. This is just one of the (many) things that the WSEE Installer nets you over attempting to do the installation manually. As I’ve mentioned elsewhere in these comments, the WSEE Installer has evolved so far over the last few years, and does soooo much more for you than you’ll get by doing the installation manually (including notifications whenever Microsoft updates WSEE, and a super easy means to install the updates via the WSEE Updater), that I no longer recommend folks perform a manual installation. The WSEE Installer will result in a MUCH more proper, complete, secure, and maintainable installation seeing as it does way more than I could ever possibly explain in a succinct list of manual install steps.
As for the “-Setting” parameter (you said “-Setup“, but I believe you meant “-Setting“)… It’s actually an optional (and not mandatory) parameter. I used to have it included in the manual install instructions, but I removed it a while back because it was causing the “Start-WssConfigurationService” cmdlet to fail for LOTS of folks. I have no idea why (since it always works just fine for me here in my tests), but since everything it does can be configured via the “Settings” dialog box within the server Dashboard, it isn’t really necessary anyway.
Lastly, the optional “-DNSName” parameter can indeed be used by (advanced) folks who want to change the Top Level Domain (TLD) suffix of the server, but it’s probably best for 99.9% of the people doing this to just stick with the default .local TLD (i.e. me suggesting that would just further add to complicating the already complicated manual installation process).
Enjoy using WSEE on Windows Server 2022! 🙂
Steve says:
Got the health warning that an update was available, so I downloaded and ran the updater. It seemed to work okay, but I still have the health warning. If I delete it the warning, it just comes back, and if I try to run the installer again, it tells me it’s already installed. How do I “re-arm” the alert for the next update?
Mike says:
The WSEE Updater “should” automatically clear the health alert at the end of the update process. If for some reason it didn’t, or if it keeps coming back on its own, then try giving it 24 hours just to see if it goes away after that (seeing as the health alert is set up to re-evaluate every 24 hours). Also, what happens if you manually delete the health alert (by right-clicking on it and selecting “Delete this alert“) and then click on the “Refresh” task. Does it still come back again even after doing that?
EDIT (2/25/2021): Mea culpa! It looks like I had the “available” version number set as 10.0.4196.2 instead of as 10.0.4169.2 like it should be. I’ve corrected the problem and so the issue should be resolved now. Thanks for bringing it to my attention. 😉
Steve says:
Mike, that did the trick – The alert cleared on it’s own. Thanks for looking into it!
Steve
Daniel Cesário dos Santos says:
Hi,
i’m installing on Windows Server 2019 and i got this error
Start-WssConfigurationService -CompanyName "Dacnetwork" -NetBiosName "dacnetwork" -NewAdminCredential $cred -ComputerName "srv-wse2019"Start-WssConfigurationService : The 'Start-WssConfigurationService' command was found in the module 'WssSetupCmdlets',
but the module could not be loaded. For more information, run 'Import-Module WssSetupCmdlets'.
At line:1 char:1
+ Start-WssConfigurationService -CompanyName “Dacnetwork” -NetBiosName ...
+ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+ CategoryInfo : ObjectNotFound: (Start-WssConfigurationService:String) [], CommandNotFoundException
+ FullyQualifiedErrorId : CouldNotAutoloadMatchingModule
Any idea to fix it?
Mike says:
Looks like you’re missing something in your manual install. I’d go back over all of the steps and ensure that you’ve manually installed everything properly. Alternatively, save yourself the hassle and just use the WSEE Installer instead.
Daniel Cesário dos Santos says:
I was able to install on Windows Server 2019 but integration services with the cloud such as Azure Active Directory, Office 365 integration, Intune, Azure Virtual Network, Azure Backup Azure Recovery do not work. Have you done the tests?
Mike says:
The Microsoft Online Integration Services seem to be a real mess. I’ve had a few folks tell me that they can’t get them working under Windows Server 2019/2022, stating that (at least for the Office 365 and Azure Active Directory integration stuff) they return this generic error:
There was an issue configuring the integrationMake sure that the computer is connected to the Internet, and then try again.
Since the error is always generic (and there most likely is a working Internet connection on your server), you’ll need to look in the server’s “Logs” folder (C:\ProgramData\Microsoft\Windows Server\Logs) and inspect the resulting “ConfigWizard.log“, “SharedServiceHost-EmailProviderServiceConfig.log“, “OIMGettingStartedWizard.log“, etc. files in order to identify the real reason as to why the integrations are failing.
We don’t use any of the Microsoft Online Integration Services here, and so I have no way of being able to test them out. However, if you’ve used the WSEE Installer to install WSEE on 2019/2022, then AFAIK, everything “should” be present and installed properly for those services to function properly.
That being said… I broke down yesterday and set up a 30 day trial for Microsoft 365 Premium, and tried testing out the integration stuff. Sure enough, it always fails with the the above mentioned generic error (under both 2019 and 2022). I then set up two brand new/clean Windows Server 2016 Essentials installs, and it fails exactly the same under both of them as well. Thus, it looks like the problem is over on Microsoft’s end (since I can’t get integration services to work properly even on a fully updated Windows Server 2016 install). Until such time as Microsoft resolves the issue in 2016, there’s probably not much I can do to get them working in 2019/2022 I’m afraid. Hopefully they’ll get around to fixing this stuff soon, but I certainly wouldn’t hold my breath (seeing as getting Microsoft to fix anything in Windows Server Essentials is like pulling teeth and generally takes them many months or even years sometimes).
If anyone else is having a different experience with the online services, please do let me know.
EDIT (3/8/2021): I’ve now managed to get the Microsoft Online Integration Services (such as Office 365 and Azure Active Directory) working under Windows Server 2019/2022 when WSEE has been installed via our WSEE Installer. The fix is available in the latest release of the WSEE Installer and WSEE Updater (i.e. Version 10.0.14393.4169 (Revision 3) or greater).
One thing to note here is that the online integration services in Windows Server Essentials are NOT compatible with multi-factor authentication (MFA) being enabled on your Office 365 / Azure Active Directory user accounts. Therefore, you should make sure that MFA is disabled by signing in to the Microsoft 365 admin center, clicking on Users → Active users, clicking on your admin user, and then clicking on the Manage multifactor authentication link located on the Account tab.
Microsoft has also implemented something called security defaults in Azure Active Directory, and since enforcing the enabling MFA on all of your user accounts (within 14 days) is part of this security feature, you will need to disable it as follows:
• Sign in to the Azure portal as an administrator.
• Browse to Manage Azure Active Directory → Properties.
• Select Manage security defaults.
• Set the Enable security defaults toggle to No.
• Select Save.
EDIT (3/23/2021): For a bit more information, see the “• (3/8/2021)” bullet point within the “Suggestions, Limitations, and Known Issues” section of the main article, and this comment.
Nathan says:
I followed the step you provided and I was able to get WSEE working, thank you for the great guide. My question is how do I fix the issues with Microsoft Cloud Integration Services failing when configuring them?
Mike says:
The latest release of our WSEE Installer (Version 10.0.14393.4169 (Revision 3) or greater) now fully supports the use of all of the Microsoft Online Integration Services features (such as Office 365 and Azure Active Directory).
That’s just ONE OF THE MANY advantages that folks will gain, when using the WSEE Installer (over doing the installation manually). The WSEE Installer has evolved so much over the last couple of years, and does so much more for you than can be achieved with a manual installation of WSEE, that we no longer recommend folks attempt to install WSEE manually. Using the WSEE Installer will net you a MUCH MORE complete / proper / secure (and hassle free) installation of WSEE (including health alerts whenever updates become available, and a simple/easy means of installing the updates via the WSEE Updater), and so we now STRONGLY recommend that everyone use it instead.
Unfortunately, there are just way too many steps involved in making the online services integration features work properly for me to be able to provide them within the succinct list of manual install steps (which are already fairly lengthy and complicated). Therefore, if folks want to use the online services integration features in Windows Server Essentials, then they’ll need to use the WSEE Installer to install WSEE on their servers instead.
EDIT (3/23/2021): For a bit more information, see the “• (3/8/2021)” bullet point within the “Suggestions, Limitations, and Known Issues” section of the main article, and this comment.
Nate says:
I purchased WSE WorkFolders 2016. May I please have the password to download the WSEE installer? If I already followed the guide and have WSEE working on Windows 2019, but need to get Office Integration working can I just run the installer, or do I need to remove it and start over?
Mike says:
I have just sent you over an email message with the download details for the WSEE Installer. I’ve never attempted to run the WSEE Installer over the top of a manual WSEE installation before, and so quite honestly, I have no idea what would happen there. It’s possible that it will work, but I don’t know for certain (seeing as I’ve never tried doing that before). Personally, I think it would be best if you just started over from scratch again with a brand new/clean (straight out-of-the-box) install of Windows Server 2019/2022.
Nathan says:
I have the password for the download. Thank you.
Mike says:
😉
Nathan says:
I would agree but it would be a lot of work to rebuild this server. I ran the install and it appears to have worked. Remote access through SSTP is still broken but I can live with that. Office integration is now working. Thank you for the help.
Mike says:
I’m glad to hear that running the WSEE Installer over the top of a manual installation of WSEE worked for you. Thanks for letting everyone know.
As for “remote access through SSTP”… I assume that you’re talking about the Essentials SSTP VPN feature there. If so, then Microsoft buggered up the VPN connections to Windows Server 2019 (via RRAS), but they can be easily fixed by following the information I’ve provided over in this comment (and just as an FYI, the fix isn’t required under Windows Server 2022 seeing as Microsoft un-buggered it there 😆 ).
EDIT (3/23/2021): For a bit more information, see the “• (12/7/2019)” bullet point within the “Suggestions, Limitations, and Known Issues” section of the main article.
Tom says:
Thanks alot for manual 🙂 – I feel in the beginning extremly lost, but after all I pass it very quickly.
Only I had prob with setup, but after I created domain manually, everything went smooth.
Mike says:
You are most welcome. I’m glad to hear that you managed to figure it out. 😉
I’m not exactly sure why you had to manually create your domain as doing that definitely shouldn’t be needed since the Windows Server Essentials configuration process (PowerShell cmdlet or wizard) automatically sets the server up as a primary domain controller for you. Just ONE OF THE MANY reasons why we STRONGLY recommend that everyone uses the WSEE Installer now instead of attempting to do the installation manually.
kgoroway says:
I’m trying to download/install the latest Windows Server Essential Experience Updater, and I’m running into an issue validating my license. Is the license somehow connected to a hardware fingerprint? Because the only thing that comes to mind is that I have upgraded my motherboard and cpu in my server since originally installing wse. Any way to get that fixed up?
Thanks!
Mike says:
Yes it is. You are allowed to install WSEE (via the WSEE Installer) on a single server only. If you’ve changed the underlying hardware footprint of your server (or VM configuration), then the WSEE Installer and WSEE Updater will think that you are using a completely different server (and changing out the motherboard and/or CPU would most certainly cause that to happen). You’ll need to contact us (with the User Name from the license of your purchased product) and request that your WSEE Installer license (i.e. Registration Key) be reset in order to resolve that issue.
kgoroway says:
Done, and fixed. Thanks for the amazing support as usual!
Mike says:
😉
vijaypartap says:
Hi
Can someone assist with WSSE installer PW. We purchased the Remote App, but stuck because WSSE required to move forward.
thanks
Mike says:
I took a few days off to celebrate the resurrection of our Lord and Savior with friends and family. However, all requests that came in for the WSEE Installer have now been filled. If you still haven’t received yours, then please contact us (with the User Name from the license of your purchased product) and I’ll certainly look into it for you.
Federico Mapelli says:
Hi Mike! I’ve purchased some times ago your wonderful WSE work folder and WSE remote app.. then “migrate” to WS 2019 standard and I’ve installed Experience Role using your wonderful installer and all works great!
Now I’m planning to add n. 3 server in 3 new branch offices. WSE 2016 had “Branchcache” functionality that would be helpful for my case. Now.. Can I deploy N. 3 WS 2019 in n. 3 branch offices and install your WSEE role? Can I use “BranchCache” like in 2016? For this scenario the branch office server have to be a dc?
Thank you
Mike says:
Thanks for your kind words. I’m glad to hear that everything is working great for you. 😉
As for BranchCache… I’ve personally never used that feature before, and so I can’t say too much about it other than Windows Server 2019 includes the BranchCache server roles/features, and the WSEE Installer installs everything required for the feature to work properly, and so I imagine that it will indeed work under 2019 (with WSEE installed) exactly as it does under 2016 (with the WSEE server role added).
As for how BranchCache functions… About the best I can do there is point you over to the Microsoft documentation for managing BranchCache in Windows Server Essentials here and here.
Good luck with your setup, and please do let us know how it all works out for you.
DPCLEV says:
Hi, I wanted to see if I could get the download password for the WSEE installer. I’m mostly looking at using this in a home lab for educational purposes. Please let me know. Thank you.
Mike says:
As mentioned in the main article above, the WSEE Installer is only made available to existing license holders of our software products (e.g. WSE RemoteApp 2016, WSE WorkFolders 2016, etc.). If you purchase a license for one of our software products, you can then request access to the WSEE Installer using the “User Name” that accompanies the license of your purchased product. If you are unable (or don’t want) to purchase one of our software products, then you can manually install WSEE by following the manual installation steps that are provided here.
CB says:
Thanks Mike,
Just wanted to confirm for other interested persons, the installation of WSEE on server 2019 standard which had been updated in place from a configured Server 2016 Essentials server.
Only problem was that the WSE configuration wizard would not run after the installation via WSEE tool.
The event logs indicated the error, which was the permissions on a registry key. (485 Plugin)
Once this was fixed, the wizard started and completed without interaction (having been configured already on 2016 instance).
All domain settings, Azure backup and other applications working without any changes.
Mike says:
Yes, I’m still trying to figure out exactly why the Configure Windows Server Essentials wizard is refusing to run (automatically) after performing the installation on an in place upgraded version of Windows Server (e.g. 2016 in place upgraded to 2019/2022 or 2019 in place upgraded to 2022). I’ve added a “Configure Windows Server Essentials” shortcut to the desktop that you can use in order to manually start the wizard just in case.
Thanks for the pointer to the permissions error on the registry key. I’ll certainly take a look at that.
Glad to hear that you’re up and running with WSEE on Windows Server 2019. Thanks for taking the time to let everyone know how the install went for you. 😉
CB says:
Alas, after severe messing around to get VPN access working, the Devices tab no longer shows the Server itself. Is there any way to add the Essentials server back to the Server Device tab?
Mike says:
Hmm… I’m afraid I’ve never come across that particular issue before. I’ve seen the client computers go missing from the DEVICES page of the server Dashboard (which can usually be fixed by simply reconnecting the clients to the server again), but I’ve never seen a case where the primary Essentials server has gone missing from the Devices tab. Thus, I’m not exactly sure what can be done to correct that issue other than a restore from backup or a completely new WSEE install.
More than likely, something has become corrupted in the “DevicesInfo.xml” file that Essentials uses to store the list of Devices (which is located in: C:\ProgramData\Microsoft\Windows Server\Data). Perhaps you can try restoring that file from one of your recent server backup sets (assuming that you have server backup enabled on your Essentials server that is, which I STRONGLY suggest that EVERYONE does!), or from the existing “DevicesInfo.xlm.bak” file.
Han Arts says:
Hi Mike, now that server 2022 went into preview (Announcing Windows Server 2022—now in preview) do you suggest to switch (I always like to be as updated as possible) or do I have to reinstall when final version is out.
Mike says:
We’ve been testing WSEE on the Windows Server 2022 preview for quite some time now and it works just great on it. That being said… Since Microsoft is still labeling it as a “preview” I’d probably hold off in place upgrading your production server to it until the final release is available (which shouldn’t be long now).
FYI, Microsoft just posted the evaluation version of Windows Server 2022 in the Microsoft Evaluation Center here (if you’d like to test it out before upgrading). For a bit more info see:
Windows Server 2022 Preview Available on Microsoft Evaluation Center
EDIT (5/26/2022): BTW, in place upgrading Windows Server 2019 to Windows Server 2022 will forcefully remove WSEE from the server (just like when in place upgrading from 2016 to 2019/2022). Therefore, after performing the in place upgrade, you’ll need to run the WSEE Zapper in order to remove the orphaned WSEE instance, and then run the WSEE Installer again in order to reinstall WSEE. All of your settings, etc. will remain intact during that process.
Christopher says:
What is your policy on refunds if by chance the installer does not work after purchasing a product for the purpose of downloading the installer? Apologies if that’s been covered. The thread is a bit long. 🙂
Mike says:
Yes, this thread is indeed getting to be a bit long now as it’s SUPER popular (who whould’a thought). It’s probably about time for me to close down the comments. 😕
Anyway…
As stated on our Policy page, we have a no-questions-asked 30-day refund policy on all of our software packages. While we technically do not sell the WSEE Installer, you are always free to request a refund for the product you’ve purchased if your intent was to use it on Windows Server 2019/2022 and the WSEE Installer won’t work for you (for whatever reason). Although, I don’t believe that I’ve ever come across a case where the WSEE Installer wouldn’t work on a new/clean installation of Windows Server 2019/2022.
That being said… Please do be aware that if you request a refund, then the license for your purchased product (as well as for the WSEE Installer) will be deactivated, and so any installation of the product (or of WSEE that has been installed via the WSEE Installer) will cease to function once the license has been deactivated.
Christopher says:
Thanks Mike! After a bit of troubleshooting and help from everyone here I was able to get it working like a charm. Thanks a million! I do plan on still purchasing remoteapp. After reading up on it I can utilize it 100% in my setup. Thanks again!
James says:
As mentioned last month (May 2021), thread is getting older however Mike is readily available to support his fine product line (WSEE). Installed like a dream over Server 2019 Std, no hiccups or anything ‘unusual’
Previous experience with WHS, 2012\2012R2\2016 Essentials just made home administration so easy without the whole slew of unnecessary (to the home admin) server headaches (file serving, client attached backups, storage spaces). With WSEE being so easy to work with, can continue working in my comfort level again within a home based domain.
Thanks again to Mike for your promptness and easy to work with software, much appreciated.
Mike says:
Thanks for your wonderful comments as they’re very much appreciated. I’m glad to hear that installing WSEE on Windows Server 2019 worked out well for you. 😉
Zach says:
I’ve installed the WSEE onto Windows Server 2019. Is it normal for users to lose connection and access to files after an update is installed (with a reboot)? I manually had to login them back into the connector at each computer.
Mike says:
I’m not sure that I’m quite following you on this one… Are you saying that happens whenever you install Windows Updates on the 2019 server (that has WSEE installed on it either manually, or via our WSEE Installer), or whenever you update WSEE on the 2019 server via our WSEE Updater? Either way, I’m afraid that I’m not seeing any such issue happening over here on any of our in-house test server, and no one else has reported such an issue that I am currently aware of.
Troels says:
It is quite normal to lose connection installing e.g. an insider build on the client computers . . . .
Mike says:
Ah yes, if what he’s referring to there is indeed installing “feature updates” (or as you’ve mentioned “insider builds”) of Windows, then it is quite “normal” for the client computers to become disconnected from the server at that time.
This is easily remedied by simply setting the SkipDomainJoin registry key on the clients (in order to stop them from attempting to join the domain again and messing up the existing user profiles on the already domain joined clients), and then quickly reconnecting the clients back to the server again by re-running the Windows Server Essentials Connector software on them (by going to https://YourServerName/connect from the clients).
Nice catch! 😉
Rick says:
A few comments back you mentioned:
“The license for your purchased product (as well as for the WSEE Installer) will be deactivated, and so any installation of the product (or of WSEE that has been installed via the WSEE Installer) will cease to function once the license has been deactivated.”
Does that mean that the “WSEE Installer” periodically phones home to check for a valid license?
Mike says:
Yes, it periodically checks the validity of the license, and to see if any updates are available for the WSEE bits that were installed. No personal information is sent as per our privacy statement.
Rick says:
Thank you for the response. We have strict firewall policies which will probably result in the connection being blocked. Does that mean we will not be able to use the WSEE installer? If so, do you recommend a manual install?
Mike says:
Yes, in that case, you will indeed need to perform a manual installation of WSEE. 🙁
Troels says:
Hi Mike I bought a new server, and as I see my license is assigned to another server. Which is quite right. Can I uninstall or delete the old server to free my license, or what?
Mike says:
Yes, you will need to uninstall WSEE from your old server, and then contact us to reset your WSEE Installer license so that your Registration Key can then be (re)used on the new server.
John A says:
The guide looks like a great way of continuing use for the Essentials dashboard (365 sync/Anywhere Access etc).
I’ll be honest I’ve run into a few issues after following the guide, and setting up on a freshly installed and fully updated Windows Server 2019 Standard (with GUI).
I’ve copied and confirmed the registry entries and folders from a freshly installed and fully updated 2016 Essentials server (cancelled the first run as advised).
Setup all the Services and the firewall rule.
Run the PowerShell Command to install OK, and two reboots later…It runs through to 95% and doesn’t get any further.
I’ve blanked the server and re-run the process twice always the same result. (tried “all” and “none” for the WSS status) Myself and another have gone through the service setup syntax and confirmed the list of .NET folders to copy (your list shows 150, but you mention 151 in a previous post ?)
Checking the event log and it shows that it has two main errors on .NET Runtime (1025) and Application error (1000) both related to “SharedServiceHost.exe” which is stopping any of the services dependent on it running, Primarily the “Windows Server Essentials Management Service”, I’d guess.
Any clues ?
Mike says:
I’m afraid that I haven’t done a manual install in quite a long time now since we’re no longer recommending (nor supporting) that folks go down that road due to the exact experience that you’re currently running into. That being said… AFAIK it should still work just fine since nothing has occurred (over on Microsoft’s end, etc.) that should have changed the process any.
I’ve never personally run into the particular manual installation issue that you’re describing (with SharedServiceHost.exe), but it sounds to me like you’re either missing something that’s required in order for the Essentials services to successfully start (files, registry entries, etc.), or it’s simply a permission issue that’s causing it (i.e. are you certain that you’ve maintained the existing permissions on all of the files and folders when copying them over to the 2019 server?).
Lastly, have you tried going through all of the logs in the server’s Logs folder (C:\ProgramData\Microsoft\Windows Server\Logs) just to see if they reveal anything of interest to you?
Thomas A says:
Hi there,
I’ve tested the manual stuff with a few VMs and had the same 95% stuck at my first try too.
Then I mentioned that I forgot to install the five features via powershell on the target server first.
(Don’t hurry, it will take a while.)
After doing that, the second run was successsful. 🙂
Hope that helps.
Thomas A says:
Since I’m very happy this interesting stuff is shared, I want to share my upgrade experience too.
I have two tiny customers using Windows Server Essentials 2016 and the integrated Client Backup.
And they might ask me at the EOL of WSE 2016 (2026/27): What about an Upgrade to Server 2022/25?
So, I prepared two VMs for Testing:
– A fully installed, configured and updated WSE 2016 with some additional Software like SQL Server as “Production”
– A fully installed and updated WS STD 2016 with the WSEE role added as Source for the required Files and Registry-Entries
After grabbing all necessary stuff, I upgraded the “Production” with WS STD 2022.
To do this, adprep /forestprep and /domainprep was necessary and the Domain Admin of WSE 2016 required some additional group membership.
(Take a look at the adprep output and the group membership of the local Administrator)
Upgrade went fine and Essentials Dashboard went away. Somehow expected….
Then I’ve done the complete manual stuff with my extracted Files and Registry-Entries:
– The five features were already in place
– Copied all Files with success
– Two of the eight registry entries were blocked (Permission?), but the content was already in place
– SC create went fine and netsh also
Finally the last two PowerShell CMDs:
– $cred …(set a new password for the existing Domain Administrator) went fine
– Start-WssConfigurationService with all options failed…
– Start-WssConfigurationService without any options run a few seconds and -> 100% success 🙂
After that I have had the Dashboard back again and I have done some basic tests (server backup)
Currently everything looks good, but for sure I will do some additional testing with clients and so on…
Hope that helps.
Mike says:
Glad to hear that your in-place upgrade to 2022 with WSEE manually installed worked out well. Thanks for sharing your experience with everyone. 😀
Joe says:
I have 2 servers (2019 with WSEE) that are now experiencing “Computer Monitoring Errors” after Microsoft Update KB5005102. Before I attempt a rollback and test I wanted to check with this community to see if others are having the same problem or not. Thanks, Joe
Mike says:
Is your WSEE manually installed, or installed via the WSEE Installer (Version 10.0.14393.4169 – Revision 5) ?
We’re not currently seeing any health alert issues showing up over here on any of our 2019 servers with KB5005102 installed on them.
Have you tried looking through the log files within the Essentials server’s Logs folder to see if you can locate the reason for the “Computer Monitoring Error” that you’re seeing? You can find the server’s Logs folder located here:
C:\ProgramData\Microsoft\Windows Server\Logs
If you sort the folder by date modified, then all of the most recent log files will appear at the top, making it easier for you to locate the more relevant ones to look through.
joe says:
Hi Mike! Thanks for the reply. The error has been intermittent since the update. The Health Assessment appears to run every 30 minutes. The error will sometimes clear itself but then may return with the next assessment.
My WSEE was installed many many months ago using the installer. I don’t recall the version at that time.
I have examined the logs and can’t find a difference between a “clear” and a “computer monitoring error” assessment or any difference from logs prior to the MS Update. 🙁
Mike says:
Scratch my previous reply as it looks like I am now able to reproduce the issue you’re seeing as well. However, I don’t believe that it has anything to do with that “preview” Windows Update you’ve installed. The “Computer monitoring error” health alert that I’m seeing (and you’re correct in that the error isn’t getting logged as expected) states that the failing components are “MicrosoftSecurity!OnlineServicesPackageUpdate“.
I’ll need some more time to look into it further, but I suspect that Microsoft has now abandoned the link that the health alert engine is using to check for available updates to the online services integration stuff in Essentials (I’ll need to dig into the code to be sure though). It doesn’t at all surprise me if that turns out to be true seeing as Microsoft has pretty much completely given up on Essentials now (even though it’s supposed to be supported until January 12, 2027).
Also, I expect that the issue will start appearing under 2016 as well seeing as it most likely isn’t specific to having WSEE installed on 2019/2022. Most likely, I’ll just need to disable the health alert so that it stops checking for updates to the online services integration package (and hence will not trigger the health alert). Hopefully, Microsoft will fix the issue, but I’m certainly not holding my breath on that one. 🙁
I’ll report back once I’ve had a chance to look into it a bit more.
Joe says:
Thanks again Mike! Unless it is purely coincidence that I never observed the active “Computer Monitoring Error” whenever I was monitoring the 2 servers prior to the “preview” update; something had to have changed because of the update that made it much more frequent. While you investigate I think I will try reversing the update on the non-critical server and let you know. Thanks!!
Mike says:
On further investigation, I’ve now figured out what’s happening here…
Whenever the health of the server is evaluated, a configuration file for the online services is automatically downloaded to the following location on the server:
C:\ProgramData\Microsoft\Windows Server\Data\Cloud\OnlineServicesConfigFile-US.xml
(where the “-US” portion of the file name is named after the specific culture region that your server is currently set up to use)
Apparently, the online services configuration file that’s being downloaded from Microsoft’s backend webserver is completely corrupted (i.e. it’s now 70-80 KB of HTML gibberish instead of the properly formatted 4 KB XML config file that’s being expected). When the corrupted config file is then interrogated for the online services version information, Essentials falls over due to the config file not being in the proper format (and tosses up that “Computer monitoring error” health alert as a direct result of that failure).
Apparently, Microsoft has done something over on their backend that’s causing the corruption of the config file. There’s not much I can do about that I’m afraid. Hopefully someone reports it to Microsoft and they correct the issue (bug) soon. If not, then I’ll go ahead and disable the health alert in a future release of the WSEE Installer/Updater so that it doesn’t get triggered.
BTW, I’ve just double checked, and it is indeed happening on a stock Windows Server 2016 Essentials set up as well (and so it has nothing whatsoever to do with installing the latest Windows Updates nor with installing WSEE on Windows Server 2019/2022 just as I suspected).
Joe says:
Ok…..but….. then why is the error clearing and intermittently returning? I would expect the error to remain constant if the config file is corrupt. And again and at least in my case across both of my servers, the error did not ever present itself on the dashboard prior to the update.
Mike says:
LOL because it’s Microsoft! 😀
Actually, I think that’s because the individual health definitions are all set up to only evaluate at specific time intervals (such as once every 24 hours, etc.) even though the health of the server is evaluated every 30 minutes (via a scheduled task). Basically, every 30 minutes the server’s health is evaluated, but only those alerts who’s specified time interval has expired are truly evaluated (that way the server doesn’t expend unnecessary resources re-evaluating every single health definition every thirty minutes when that’s not really necessary). If that makes sense.
EDIT: But you are indeed correct as I’m also seeing the alert appear and then disappear in odd ways (even though the config file is clearly corrupted). I dunno what’s causing that without investigating it further. I think we’re on the right track here though.
Mike says:
BTW, if someone wants to report this issue (bug) to Microsoft you can simply tell them to fix this fwlink that’s hardcoded within the Essentials source code:
https://go.microsoft.com/fwlink/?LinkID=785361
For whatever reason, it’s wrongly being redirected to:
https://www.bing.com/?ref=go&linkid=785361
And so the Bing.com web page HTML is being downloaded instead of the expected OnlineServicesConfigFile.xml file.
Oy! Ya gotta love Microsoft. 😛
joe mills says:
Glad to do it…. any idea where/how? I couldn’t find the correct place to report a “Windows Server bug” so I opened a discussion on the subject with the Windows Server Insiders Community Forum. I will let you know when/if I receive any response.
Mike says:
I don’t believe Microsoft Support will even talk to you unless you give them a $500 credit card deposit. If they then determine the issue to be a bug on their end, they’ll refund your money. Unfortunately, I don’t know any other way of reaching out to someone on the Windows Server Essentials team (which I seriously doubt even exists any longer). 😕
joe says:
Mike, I have now posted this problem on several forums including the Microsoft.com Windows Server forum and have received only 1 reply from another user seeing the same problem on WS2016E. I am stunned that there aren’t many other users in the US (assuming only the US link is broken) complaining of this issue. If there are I haven’t found any others from searching the web. While WS2016E end of life is coming soon on January 11, 2022 (extended support until 2027) without anymore outcry from a larger number I doubt we will get Microsoft’s attention to fix or at least explain the change. 🙁
Doran says:
I’m having the same issue, intermittent at best, but annoying, nonetheless. I’ve been searching on the “MicrosoftSecurity!OnlineServicesPackageUpdate” error for a week or two with little success at finding anything related, except this page. Do you have a link to where you posted it on the Microsoft.com Windows Server forum, as a search doesn’t bring it up, again based on “MicrosoftSecurity!OnlineServicesPackageUpdate”.
Thanks.
db
joe mills says:
WS2016E Computer Monitoring Errors
Unfortunately, if Microsoft is monitoring or participating in that forum they are staying silent on the matter.
Mike says:
FYI, I have now corrected this particular issue in the latest Version 10.0.14393.4169 (Revision 6) release of the WSEE Installer and WSEE Updater. Therefore, if you’ve used the WSEE Installer to install WSEE on Windows Server 2019/2022, then installing the latest update will get rid of the “Computer monitoring error” issue for you (by simply disabling the health definition that’s causing the error to be generated).
Kevin says:
Trying to install the server connector on a clean install of windows 10 21H1. It doesn’t work. Honestly, Microsoft seems to break the connector on every single update, it seems, so I wont be surprised if they’ve done it again. Can anyone report success using the connector from windows 10 21H1?
To be more specific, after launching the connector, it finds the server, asks for admin credentials, and then gives an error like “can’t connect computer to the server, try again”, or something to that effect. And you are done.
I’m going to start looking at the connector logs, but I’ve been down this path before, and they are rarely helpful.
Mike says:
Yes, it’s a real pain. Every time you install a feature update for Windows 10, the connection between the server and the clients gets broken. While Microsoft certainly could handle this one a bit better, that’s probably never going to happen now that they’ve completely given up on Essentials. IMHO, it’s not too big of an issue seeing as all you need to do is simply reinstall the the Windows Server Essentials Connector software on the client(s) and the reconnection is established again. That being said… I’m not sure why you’re having difficulty getting the client connector software to see your server. Are you sure that you’ve set the proper DNS info on the clients as I’ve mentioned here?
kgoroway says:
Thanks Mike. As it turns out, I think I’m dealing with an entirely different problem. I had blamed this on being a new version of windows, but after looking at logs I can see that it really boils down to a certificate on the server for https that is no longer valid, somehow… Going through the WSE RemoteAccess repair wizard seems to not work at all, despite many attempts. The foo.remotewebaccess.com domain and certificate the I’m trying to make work never really do. Trying to access my https:\\serverfoo\connector url from any of the clients brings up a warning about the certificate being self signed. And the connector logs are complaining that the domain part of the certificate doesn’t match the certificate (likely because the ipv6 or the server name itself isn’t part of the certificate?) Anyway, I’ve scoured the web to try to find a fix for this, and have so far come up short.
Ingo says:
Have a look here:
https://sbsland.me/2020/11/04/fix-windows-10-update-and-small-business-essentials-connector/
Ingo says:
Mike, I need to reinstall my WSE Role … what do I need to do? Installer tells me, that my license is used on another server …
Best regards
Mike says:
Contact us with the Registration Key from your WSEE Installer license and request a license reset.
Ingo Thiem says:
Done!
Thanks for your help!
Gary says:
I am very interested in moving to Server 2019/2022 from Server 2016 Essentials. I read in the article that Server 2019 performs much better than 2016 which is great news because it has always been sluggish. But I am torn between 2019 or 2022. 2022 is still newly released for GA. I mainly use this for backing up clients. Any thoughts from anyone on what you would do? Moving to a just GA’s OS using an unsupported product may not be the wisest choice but I also rather go with the latest and have a longer run. Thanks!!!
Mike says:
If it were me, I’d most definitely go with Windows Server 2022 (over Windows Server 2019). Windows Server 2022 is more secure (offering both TLS 1.3 support and “Disable Legacy TLS” support in IIS; SEE: Enabling TLS 1.2 On Windows Server Essentials) and it resolves some bugs that still exist in Windows Server 2019.
Gary says:
Thanks for the quick reply and advice. I will go with Server 2022. I am installing 2016 Standard on VMWare Player to get the files. I am thinking of keeping it and let it update once a month and see if any of the Essentials files were updated. Thanks for figuring all this out. I love having a Home Server and hate that MS gutted Essentials 2019.
Han says:
Am on 2022 with Mikes experience role installed now for couple of weeks. All very smoothly without ANY issues (came form 2019), highly recommended
Gary says:
Thanks for the reply. I went with 2022 and all is working great. I do have one odd issue. I am not sure if you are using it for client backups but when I set mine up I have an item called Local Disk in my Select which items to back up. After looking at the folders under it, it seems they are folders under C:\Program Files\ModifiableWindowsApps\HaloMCC. I do have Halo series I bought from the Microsoft Store but have no idea why it sees some of these folders under an item called Local Disk. If I drill down into that Local Disk item under the Select which items to backup, it still does not include all the folders under C:\Program Files\ModifiableWindowsApps\HaloMCC. But if I drill down into C:\Program Files\ModifiableWindowsApps\HaloMCC under the Select which items, that does not include all the actual folders. But the combination of Local Disk and C:\Program Files\ModifiableWindowsApps\HaloMCC under the Select which items seems to equal what is really under C:\Program Files\ModifiableWindowsApps\HaloMCC. It is odd.
Alex says:
Hi Mike, do you know of any issues or bugs with Windows 11 and WSEE? It looks like Windows 11 isn’t officially supported as a WSEE client on Microsoft’s site.
Mike says:
I’m not currently aware of any issues with installing the Windows Server Essentials Connector (i.e. client connector) software on Windows 11 clients. Admittedly, I haven’t spent any real time testing under Windows 11 as of yet though, and so I can’t say for sure. However, since WSEE is being supported by Microsoft until 2027, I would assume that they would fix any issues that may happen to exist (but we all know how that goes right 😯 ). Personally, I don’t see enough differences between Windows 10 and Windows 11 to think that any issues would arise (i.e. it “should” run exactly the same under either OS).
Martin says:
Hi Mike, I had an Essentials 2019 and downgraded it to a 2019 standard server. Then I upgraded the 2019 server standard to a 2022 inplace. Now the wizard runs after I have adjusted the values in the registry, but the installation hangs on the certification body (I should remove it. After I have removed it (without restarting) the wizard runs through but does not recognize the existing domain. The server is DC with me.
Mike says:
As I’ve mentioned to you in our private email conversations, I’m out of ideas for you to try on this one. You’ll either need to restore your server from backup to Windows Server 2019 Essentials, or just wipe it out and start over from scratch again. I’m sorry that I don’t have a better answer for you on this one.
J Cain says:
Hi Mike! Thank you for this page and all the information!
I’m a small business owner and by default I’m my company’s “IT Guy”. I’m self taught on computers and know alot more about client machines and software, than server software.
I’ve been using WSE 2012 R2 on my server for many years. I’m planning to build a newer much more powerful and faster server and wanted to use Windows Server (WS) 2022. I installed WS 2022 on a VM to check it out — and spent half an hour looking for the WSE Dashboard! I know that thing like the back of my hand but it was missing!! I’m lost without it for doing all sorts of functions. I need my WSE Dashboard back, I’ll stick with 2016 if I have to, but I hear good things about WS 2019 and 2022.
I’ll look over your manual installation steps for WSE, but I’m intrigued by your WSE installer.
If I buy one of your products and get my hands on your WSE installer and then install WSE on WS 2022 it is a one and done installation, or do I have to keep installing/updating it and/or keep updating some license for my WSE installer, through some type of subscription???
My preference is obviously a one and done installation of WSE.
Many, many thanks again!
— Cain
Mike says:
Welcome to our world! Microsoft must really hate their SOHO customers eh. 😕
Yes, the WSEE Installer is indeed, as you say, “one and done installation of WSE”. I do release updates for it from time-to-time (via the WSEE Updater), in order to apply updates Microsoft makes to the underlying 2016 Essentials “bits”, to add additional functionality, to fix bugs, etc., but there isn’t a charge for any of that (just as there isn’t a charge for the WSEE Installer itself).
J cain says:
Thank you so much for the prompt reply Mike! I agree MS must hate Small Businesses like mine, and/or they are in cahoots with people like Dell, to remove a helpful features for part time IT folks like me, who cannot configure a server from scratch themselves. (Maybe they should offer it as a paid add-on, folks like me would pony-up!).
I’ve built my own computers since the early 90’s and have built myself three servers, each one better/faster than the last. 2012 WSE is slow as Christmas, and I can’t see where 2016 is much quicker. I’m encouraged that you said WS 2019 and 2022 are quicker, that is encouraging.
I’m gonna take a crack at doing the WSE install on WS 2022 Standard myself on a test VM, but if it’s too complex, taking too much time or simply does not work, I’ll be becoming a customer of yours soon! (What is my least expensive option?? I feel badly for asking, but I thought I’d ask.)
Take care, I’m enjoying looking around your site, and you’ve given me hope for using WS 2022 instead of being forced to use the old WS 2016 on my brand new server.
— Cain
PS As a suggestion, I know you hate to take money directly for the WSE installer. Perhaps allow people to donate to a charity of your choosing, then receive the password?
Cain says:
OK, I read a bunch of comments all the way back to to the start. 🙂
I see now you recommend against doing this WSEE installation manually. That’s cool, it looked like a pain!
I also see you suggested buying some sort of “student package” that was your lowest cost option, but I’m not seeing that option, my guess is it’s gone now??
Thanks!
— Cain
Mike says:
The “Student Edition” of WSE RemoteApp, and the “Starter Edition” of WSE WorkFolders are no longer available. The lowest priced editions are currently the 3-user “Starter Edition” of WSE RemoteApp, and the 10-user “Basic Edition” of WSE WorkFolders. For details see our Pricing page.
Cain says:
Thx Mike! Last question. I’m installing various versions of WS on Virtual Machines practicing the setup and trying to decide if a server installation from scratch will work for me, vs buying a pre-built server.
I’m still undecided if I’m going to build my own server and do everything myself including hardware RAID data drives. Like I said I’m self-taught by trial and error.
Will there be any problems with me installing your WSEE installer on several virtual machines??
Thanks again.
— Cain
Mike says:
The WSEE Installer may be used to install WSEE on a single server only (i.e. it’s one WSEE install per purchased product).
You may use the WSEE Installer to (re)install WSEE as many times as needed/required onto the exact same underlying server hardware footprint (RAM and hard disks do NOT count towards the footprint).
For Virtual Machines (VMs)… As long as you keep the exact same VM configuration (which represents the underlying server hardware footprint), you may interchange virtual hard disk image files (VHD, VHDX, etc.) within the existing virtual machine configuration (for backup purposes) as many times as needed/required.
In the rare event of a hardware failure/upgrade (or when moving from a test to production server), you may make a (one-off) request for your WSEE Installer license to be reset in order for you to be able to perform another run of the WSEE Installer on the new/replacement server hardware.
Cain says:
Thx Mike! Take care.
Cain says:
I’m fiddling with this, I’m not clear what “server roles and features” I need to add.
I’m looking around in Server Manager in 2022, not able to figure out what I need to add.
TheAndyMac says:
I’m planning to move to 2022 with your installer (which looks great) but I’ve got two questions:
1. with your installer, is it now safe to upgrade from 2016 Essentials to 2022 and then run your installer, or are you still recommending a completely fresh install?
2. and, maybe connected to Q1, is there any way to migrate existing client backups across to the upgraded/rebuilt server with WSE Experience?
Specifically I have some saved PC backups of pre-rebuild and pre-Win11 upgrades that I would ideally like to keep a while longer.
Mike says:
I always STRONGLY recommend that folks start off with a brand new/clean (out-of-the-box) instance of Windows Server 2019/2022/2025 (with the Desktop Experience GUI in the language of your choice), with no other server roles, features, or applications installed, for the best results.
That being said… The WSEE Installer fully supports in-place upgrades from prior Windows Server Essentials installations. Just MAKE SURE THAT YOU HAVE A WORKING BACKUP OF YOUR SERVER, AND ALL OF YOUR DATA, BEFORE PROCEEDING just in case things don’t work out for you!
If you’re using the Windows Server 2016 Essentials SKU (as opposed to Windows Server 2016 Standard/Datacenter with the WSEE server role), then you will first need to in-place upgrade it to the Windows Server 2019 Essentials SKU, and then convert the SKU into Windows Server 2019 Standard as I’ve mentioned here.
From there, you can either stick with Windows Server 2019 Standard, or you can go ahead and further in-place upgrade it to Windows Server 2022 Standard (assuming that you have access to the retail (MSDN) installation media for Windows Server 2022 Standard that supports doing in-place upgrades, rather than the evaluation installation media that doesn’t – again, as I’ve mentioned here).
During the in-place upgrade process, Microsoft will automatically (forcefully) remove all of the “Essentials” bits from the server. However, the WSEE Installer can be used to (easily) add everything back to the server, and it will re-configure WSEE with all of your previous settings, etc.
As for the existing backups from your prior 2016 install… The only way I know of to keep them is by performing an in-place upgrade as I’ve mentioned above (i.e. by going from 2016 Essentials SKU → 2019 Essentials SKU → 2019 Standard [→ 2022 Standard]), and then using the WSEE Installer to (re)install the “Essentials” bits, and thus, restoring access to all of your existing backups.
EDIT: Alternatively, it might be even better to Transition from Windows Server 2016 Essentials to Windows Server 2016 Standard (using this Product Key: WC2BQ-8NRM3-FDDYY-2BFGV-KHKQY) and then in-place upgrade it directly to Windows Server 2022 Standard instead (again, assuming that you have access to retail (MSDN) Windows Server 2022 Standard installation media that is).
Jeff Bowman says:
Does the installer add the IIS bits as well?
Mike says:
The WSEE Installer provides all of the bits required for the Essentials IIS infrastructure, but it’s Microsoft’s “Windows Server Essentials Configuration” wizard (via Start-WssConfigurationService) that actually sets everything up in IIS for you. So, the short answer to your questions is yes, the WSEE Installer takes care of EVERYTHING for you.
Jeff Bowman says:
> the WSEE Installer takes care of EVERYTHING for you.
Cool. I’m about to make my purchase. It’ll be under NPG.
John Barnes says:
Can you use Server 2019 Essentials in place of Server 2016 Essentials to extract the required files, reg keys, etc from?
Mike says:
I’m afraid not… Windows Server 2019 Essentials is an abomination. It doesn’t include any of the original “Essentials” bits (despite being its namesake).
John Barnes says:
Mike,
Thank you, I have download the 2016 version and will extract the files from it.
John
Jeff Bowman says:
Hi Mike
It looks like your installer creates the WSE Media Streaming Service:
SC CREATE “WseMediaSvc” start= disabled binpath= “%SystemRoot%\System32\Essentials\MediaStreamingProvider.exe” depend= ServiceProviderRegistry DisplayName= “Windows Server Essentials Media Streaming Service”…but I’ve run into a problem with my setup.
The service fails to start, creating these three entries in SysLog:
7038: The Windows Server Essentials Media Streaming Service service failed to start due to the following error: The service did not start due to a logon failure.
7031: The Windows Server Essentials Media Streaming Service service terminated unexpectedly.
7000: The Windows Server Essentials Media Streaming Service service failed to start due to the following error: The service did not start due to a logon failure.
I tried adding the DOMAIN\MediaAdmin$ account to the Log On as a Service GPO, as advised here:
The Post-Deployment Configuration task may fail after you install the Windows Server Essentials Experience role
…but that didn’t help, even after rebooting. I also notice that the article references SysLog EventID 7041, not 7038.
Any ideas?
Mike says:
Alas, I’m afraid that I’ve never encountered that particular issue before.
Mariëtte seems to have a resolution article for that one posted over on her website here (did you try everything she mentions?).
Other than that… Did you start off with a brand new/clean (i.e. straight out-of-the-box) instance of Windows Server 2019/2022 with no other server roles, features, or applications installed? If not, then I strongly suggest that you go that route in order to ensure success.
Lastly, did you run the WSEE Installer and/or the Configure Windows Server Essentials wizard while signed in as a local administrator (instead of as a domain administrator)?
Jeff Bowman says:
I figured out what happened.
I did start out with a clean 2022 Standard standalone installation, as advised. As expected, running WSEE and the WSE Configuration Wizard created a new AD forest with a single domain. In my situation, however, I needed to replicate my AD from a different DC (it had user SIDs in it that I needed for my Azure DevOps on-prem instance).
So I demoted the new 2022 server from a DC to a member server—which of course wiped the AD—joined the domain of the other DC and then promoted it back to a DC. In doing so, I got the password for the MediaAdmin service from the old AD, while the service is configured to use the password from the new AD (which is now gone). That’s why I’m getting EventID 7038 instead of 7041.
So I’m stuck in a no-man’s land. Can’t go forward, can’t go back. I tried the Reset-ADServiceAccountPassword cmdlet, but I’m getting an error with that one. I’m still digging around trying to figure out how to reset that password, but so far all I’m finding are sales pitches for expensive tools.
I could run the service under LocalSystem, but I don’t know what the ramifications are of that.
Mike says:
Yikes! Unfortunately, I’m not exactly sure how you’d go about unraveling that birds nest. I wonder if you could simply delete the existing MediaAdmin and ServerAdmin managed service accounts and then just recreate them???
Although, if you did, I’m not exactly sure where/if Essentials is storing the passwords for the accounts (so that it can use them internally, etc.). I’d probably need to dig through the source code in order to figure that kind of stuff out, but I don’t have much free time ATM I’m afraid.
FYI, I found this text in some of the Microsoft documentation explaining what Essentials does on the server in regard to those accounts…
The following Managed Service Accounts are created:
MediaAdmin: Service account used by Windows Server Essentials Media Streaming Service during configuration
ServerAdmin: Service account used by Windows Server Essentials Management Service during configuration
The ServerAdmin account is added as a member of the Administrators, Domain Admins and the Enterprise Admins groups. The MediaAdmin account is added as a member of the Administrators group.
Jeff Bowman says:
I posted a question over on ServerFault, in case you’d like to follow along:
Error trying to reset service account password
We’ll see if anything comes of it.
Jeff Bowman says:
OK, got it.
I’m now 101% certain that the MSA problem occurred because I did the DC/FSMO bits AFTER installing WSEE and running the WSE Config Wizard. I should’ve done them BEFORE, like so:
KurtH comment
Mariette Knap over at www.server-essentials.com confirms as much.
So I’m going to redo everything, and this time I’ll do it all in the exact order that our friend KurtH advises. Also, once I get everything moved back over to SERVER3 and dump SERVER2, I’ll delete the MediaAdmin MSA so that the wizard can create/configure it properly when I get to that part on the new SERVER2.
Mike says:
Sounds reasonable. Let us know how it goes.
Hugo Lyppens says:
Given your deep knowledge of Essentials you might know this: I have Windows Server 2016 with essentials experience installed but not the Remote Desktop Services role. I did add the RD Gateway UI via dism. This allows me to change the RD gateway https port number from 443 to something else (4343 in my case, necessary because 443 is already going to another LAN destination from my router). But now when I want to connect to a host on the LAN via Essentials Remote Web Access, it does not write the port number :4343 as a suffix to the gatewayhostname within the .rdp file. I wonder if there is some registry setting to update the gatewayhostname in the generated .rdp file.
As it stands it is necessary to manually change .rdp files from Remote Web Access to add :4343 to gatewayhostname field.
Closest thing I could find is HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Terminal Server\TSAppAllowList\DeploymentRDPSettings but it does not appear to be applicable to the Essentials Experience Remote Web Access to LAN desktops via the RD Gateway. Thanks for any info you might have.
Mike says:
In my experience, it is not recommended (and probably not possible) to change the HTTPS port number that’s being used by Essentials (i.e. port 443) seeing as Microsoft has hard-coded it in multiple places within the Essentials assemblies (i.e. within the Essentials source code).
If you’re running into a port conflict due to another application, service, etc. requiring the use of port 443, then you’re far better off getting that application, service, etc. to use an alternative port than you are attempting to configure Essentials to do so. This is exactly what we’ve done with our WSE WorkFolders add-in seeing as both Essentials and Work Folders are web servers that conflict over the use of TCP port 443.
As a last resort, it is possible to write an add-in for Essentials that overrides that (hard-coded) behavior of the built-in Remote Web Access website (as we’ve done in our WSE RemoteApp add-in), but that would probably require quite a bit of time and skill in order to accomplish. And you’d still have to contend with all of the default bindings to port 443 in IIS, etc. It’d be quite a tangled web to unweave for sure.
Mike says:
Hi Everyone,
After being open to comments for more than three years, and with over 400 comments on this post, I think that it’s finally time to go ahead and close it down now.
If you have any further questions/comments about the WSEE Installer, etc., please feel free to ask them over on our Questions & Answers (Q&A) forum instead.
Thanks, and I hope everyone is enjoying using Windows Server Essentials Experience on Windows Server 2019 and beyond! 😉