Following my suspicion of IIS, I logged in as the (Built-in) Administrator and used Server Manager to remove IIS and its dependencies completely, and then ran the installer again and now it works. Looking at the Server 2019 image I have (installed via WDS), it has IIS enabled by default, so IIS was corrupted from the start.
I am now able to log into the web ui without issue.
Thanks for your help diagnosing this, if someone finds this in the future, I hope it helps!
@theopenem_admin Using the random generated password I was able to connect as Root via CMD with a fresh Theopenem install. Very very odd, maybe an IIS issue?
@theopenem_admin I'll check to see if I can connect with a fresh install. Language is "English (United States)", and not on any domain yet. I can try and refresh the language pack, but I'm not sure if that'll make a difference.
@theopenem_admin
I have tried SFC and DISM repairs and there are no issues. On a fresh Server 2019 image with nothing else installed still gives the same error -- (10.0.17763 Build 17763). When I manually install MariaDB with my own password I can connect to it as Root without issue via the built-in CMD, but I don't know the password used with your installer -- my only idea is to install with the option "Setup Database Manually" but I don't see any documentation on how to connect a custom install of MariaDB.
Edit: I have also tried a clean-boot with only MS services running and ran the installer, still no dice.
@theopenem_admin Here you go! Thanks for the quick response.
Application.log
ClientApi.log
FrontEnd.log
After successfully installing the MSI (carefully reading the instructions), I am able to contact the server from the webui, but when logging in it says "Could Not Contact API" -- after investigating it further I found that the Keepalive task (Task Scheduler) does not have permission(s) to run.
I have tried to manually run the command "wget http://localhost:8080/Setting/KeepAlive" in PS and CMD (Admin and User) but they all resolve with an error (see below). As a test scenario I logged in as Toemskeepalive to run it via the intended user, but it resolved the same error. Giving additional privileges to Toemskeepalive has no effect.
My environment is: Microsoft Server 2019 (not joined to a domain)
Most online resources say modifying the .config file(s) for the website (IIS). Outside of that, I tried enabling "Allow unlisted file name extensions" in IIS Toems-API and Toec-API and the wget command runs, but when trying to log into the web ui an exception occurs and it crashes (also the Task Scheduler Keepalive still says it doesn't have permission).
Something tells me this is a Group Policy issue.
Command: wget http://localhost:8080/Setting/KeepAlive
wget : HTTP Error 404.7 - Not Found
The request filtering module is configured to deny the file extension.Most likely causes:
Request filtering is configured for the Web server and the file extension for this request is explicitly denied.
Things you can try:
Verify the configuration/system.webServer/security/requestFiltering/fileExtensions settings in applicationhost.config
and web.config.
Detailed Error Information:
Module RequestFilteringModule
Notification BeginRequest
Handler ExtensionlessUrlHandler-Integrated-4.0
Error Code 0x00000000
Requested URL http://localhost:8080/Setting/KeepAlive
Physical Path C:\Program Files\Theopenem\Toems-API\Setting\KeepAlive
Logon Method Not yet determined
Logon User Not yet determined
More Information:
This is a security feature. Do not change this feature unless the scope of the change is fully understood. If the file
extension for the request should be allowed, remove the denied file extension from
configuration/system.webServer/security/requestFiltering/fileExtensions.
View more information »
At line:1 char:1
+ CategoryInfo : InvalidOperation: (System.Net.HttpWebRequest:HttpWebRequest) [Invoke-WebRequest], WebExc
eption
+ FullyQualifiedErrorId : WebCmdletWebResponseException,Microsoft.PowerShell.Commands.InvokeWebRequestCommand@theopenem_admin Fantastic! Works like a charm - thanks!
I'm hoping there is a kernel argument or whatnot to set the ISO to auto-load THEOPENEM when booting from USB/ISO.
So far I have it so I can choose to automatically boot to the GRUB loader whenever I set rEFInd to do so, but right now it's just the selection menu.
TLDR: Get USB/ISO Linux GRUB to load THEOPENEM without prompting, and therefore check for tasks; E.G. with Kernal Argument when generating ISO
@theopenem_admin Ohhhh, I misread you. Thank you for the prompt reply, it's uploading now! Hopefully this is the last misconfiguration on my part... -.-
@theopenem_admin Apologies, but I just removed that myself for this post, the IP is populated correctly in the logs.
After successfully installing, I carefully following all the instructions on Server setup, I'm getting this error while attempting to upload an image from a client:
"......Could Not Start Server Image Receiver"
Application Log:
2021-01-06 09:28:45,529 [41] ERROR Toems_Service.ServiceOnlineKernel The remote server returned an error: (403) Forbidden.
2021-01-06 09:29:33,688 [42] ERROR Toems_Service.ServiceOnlineKernel The remote server returned an error: (403) Forbidden.
^unknown if related
Front End:
2021-01-06 09:29:33,688 [38] ERROR Toems_ApiCalls.ApiRequest Response Data Was Null For Resource: OnlineKernel/Get
2021-01-06 09:32:25,137 [8] ERROR Toems_ApiCalls.ApiRequest Response Data Was Null For Resource: FileSystem/GetSMBFreeSpace/
Com Server - multicast:
cmd.exe /c "C:\Program Files\Theopenem\Toec-API\private\apps\udp-receiver.exe" --portbase 9008 --interface http://[myip]:8888/ --file F:\Deployment\images\Win10\hd0\part1.ntfs.lz4
Session Win10 Started And Was Forced To Quit, Try Running The Command Manually
^Consistantly repeats every time an upload task is scheduled
I'm assuming it has to do with the udp-receiver not working properly, but I'm at a loss.
I really appreciate all your hard work.
@theopenem_admin So...I'm not sure who to be upset with, myself, or the people who made this image... As it turns out, some genius in the base image UNINSTALLED .NET frameworks...
Thanks for your help, I really appreciate it. After installing .NET Framework 4.8 it installed just fine on Server 2016.
@theopenem_admin I did a clean install of 1.2.1 on a fresh (as in, what I've been given) image of Server 2016.
@theopenem_admin Unfortunately this is the only available image I was given. 
@theopenem_admin Here's the MSI logfile: package.log
The line "Error 4106" specifies what I'm talking about. As a side note, I was able to install just fine on a absolutely clean Win10 Pro, but still can't on the Server 2016. I'm still virtually positive it's in the Group Policies somewhere. I've tried the Disabled setting for "Network access: Do not allow storage of passwords and credentials for network authentication" and it didn't seem to resolve the issue.
@theopenem_admin Unfortunately a similar result. I took a picture with my phone. Installing it gave the same error, while the picture shows the Repairing action with the same result. 9B2A975F-6A00-46D1-8F24-BBA678AF4336.jpeg
To be clear, I mean it’s not an issue of Domain authority. I’m virtually positive it’s some dumb policy that someone with a good-idea fairy turned on because it has “security” in its description somewhere.
@theopenem_admin The server is not a part of any domain as of yet, so I’d guess it’s not a GPO issue.
First of all, I want to thank the developer for making software like this, I used CloneDeploy to a minor extent and although the support dropped off, I can see he was hard at work making Theopenem. If Theopenem is as good in practice as on paper, I would love to support it.
Now onto the details; when running the initial installer on Server 2016 (via the MSI installer) I get the error "An error was encountered while creating a scheduled task: 'Toems-API Keepalive.job'. Error description: The user or password is incorrect." I suspect that upon creation of the user for the scheduled task, it gets locked out, and going to lusrmgr.msc to re-enable it, the password was never set properly.
If I choose to press "Ignore" the installation will complete, but of course it isn't correct. I am able to load up the IIS website via any browser on the network, but cannot log in, claiming "Unknown Error Obtaining Token". I assume this issue is a consequence of the issue above.
My company has set a lot of weird/pointless policies, so I have no doubt it's an issue with something in the Registry or Group Policy. I have full control over both, but I don't know where to look for this issue, and online appears to have very little info on the subject.
Thanks again for being awesome enough for developing something like this!
