@theopenem_admin That might be the fastest fix I've ever experienced! Thanks boss, that was it I've gotten past that screen

@theopenem_admin Thanks, that would be great.

@gunnie I'm getting this from most software on windows 11 now, including other parts of windows. Yesterday I got one of these because Remote Desktop Connection tried to save the .rdp file to my documents folder.

There's an unintuitive way to interact with the UI in your screenshot that lets you authorize it, I don't remember it at the moment, something there is a button

switch your pxe bootloader to ipxe

@eruthon You want to avoid passing Výučbový softvér through Theopenem at all; either have it hardcoded in the script file, or have the script get it from somewhere else like an SMB server.

Been going through requests trying to figure what to work on next and I think this makes the most sense. This will be a focus of the next release.

@curling0221 I am being faced with this problem again. Did you ever find a resolution to it?

OK, found it in HTML source code. No idea how come this help is not a part of actual page.
To anyone looking for this:

To add from list, one per line, in format:
computername,00:11:22:33:44:55

Theopenem has a built in replication system, you should be able to add the new server to the com server list, configure it's storage, and then ensure the replication schedule is set up.

If you have a com server that is using an SMB server, and you want to change that SMB server out from under the com server, then you should be able to replicate the SMB data using whichever tools it's platform affords and then point the com server at the new SMB server.

The data in the storage location is file copy modules, images, and "Client Versions", I'm not yet familiar with the last one but the later two only change when you change them so you should be able to schedule around the replication. My client versions folder is empty, if yours is too then that is also solved.

As far as a proper "backup", I'm unclear if that's truly possible with Theopenem, since the data at the storage location is understood based on metadata in the database. I think the intent is that you will have 2 or more com servers and that will provide redundancy, just not any sort of snapshot functionality.

Noticed this a few weeks ago. It's been fixed and will be in the next update.

Creating new client deployment installers fixed the problem.
But now i have to do this for an entire organization?
Is there an easier way?

I had the thought, right now Process_File_Copy() is downloading the archives via curl, via the com server API, and I use SMB Direct so there's no reason to do it that way.

I thought maybe the 404 is happening because I don't have any of the files replicated onto the com server, I tried copying <storage>\software_uploads to C:\toems_local_storage\, this didn't work but I don't think the server config knows about this file location anymore. I would have to dive into the api code and I can't do that right now.

Since it should be using SMB for this anyway, I implemented that, and now it seems to be working

I can provide the code, but I'm not quite happy with some rough edges it has, I've made a lot of other tweaks along the way, and ultimately this solution is derived from existing code; also the codeblocks here don't know about powershell and make a visual mess of it.

One additional note, the call to Expand-Archive doesn't use -force, which means it can't overwrite. I didn't locate the overwrite value so I just hard-forced it, which won't matter for my case. It should probably be something like -force:$file.Overwrite