NKD

Perhaps you have the admin share disabled in your environment.

Can you connect to the admin share manually? You can just put that unc path in your run command to see if you can connect?

Theopenem 1.5.7 has been released to address this. It removes the run as code noted above. It does break running WinGet as an impersonated user which I'll try to address in the next release. I think it's a fair trade off for now as Toec was basically unusable with the latest Defender updates, you couldn't even download the agent from your browser without it being detected.

This is an "emergency" release. It does not provide any new functionality but fixes Toec being detected as a virus(false positive).

Release Notes
https://docs.theopenem.com/latest/changelog/version-history.html

Update Docs
https://docs.theopenem.com/latest/tutorials/updating.html

I have submitted another defender submission to Microsoft to try and get this exluded, although I have my doubts. The culprit seems to be the impersonation code with WinGet. I think the best way forward is to just remove the run as ability for WinGet, then WinGet packages can only install as system or the currently logged in user. I'll continue to think about this for the next release.

Hello,

If you set the policy trigger to login, it will run as the current user. You can also set a module to use an impersonation account where the system account will run the installation as that user, but that's meant more for applications that won't install with system, you would probably use just a single impersonation account.

The custom attributes cannot be used in the client scripts, currently they can only be used in imaging scripts, but I can add this to the next release.

You can use a custom inventory script to collect the information from your powershell script which can be used in reports but cannot be passed to a script.

@EddieHD Not sure about that, when you install the client I believe windows keeps a copy of the msi so it can be used for uninstalling. But as far as I know it should only be one file, or at least 1 per version.

@mzprays I'm not sure that just signing it would solve the problem, but it may help. The problem is that the client is generated for your environment, it embeds your certificates, provision key and com servers into the installer. So I can can't sign the client ahead of time. This all needs addressed but I'm not sure of the best way to handle this. Does anyone have any suggestion or experience with this? The only thing I can think of at the moment is to provide a signing fee, or for anyone with a support plan or donation. They could send me their generated client, I'll sign it and send it back. Any thoughts?

I can look into getting the client signed in a future release, I tried this once before and was never able to get anywhere with Microsoft, mostly just silence.

Since Theopenem executes code that essentially provides full control over the system via the client most anti-virus is detecting it as a virus. The only option is to add exceptions to your antivirus for c:\program files\toec

It's been awhile since an update has been released. I want to assure everyone that the project is still very much alive. The next release of Theopenem will be 1.6.0. This version will provide an updated UI, created with .NET 9 using Blazor and the MudBlazor component library. I plan on releasing a short video of the new UI soon. I have also created a product board so you can see the features I'm currently working on and their status. This board also provides you with the ability to submit ideas and vote on existing ideas. I will be shutting down the Feature requests section of the forum and replacing it with this. If you have any ideas for the 1.6.0 version get them submitted now. Here is the link for the board. I'll get this added to the main site and docs as well.

https://portal.productboard.com/theopenem/1-theopenem/tabs/2-planned

This is a massive update and I'm trying to have this done by the end of August.