WaykNow many issues

Hi Mattz

It sounds like the end result want is possible, but we'd like to have a better understanding of the problem you're trying to solve. You say you want a run-once, but then mention building an .msi. Is the creation of the .msi a workaround for another issue? If I had to guess, I would assume you want the standalone executable, but branded and pointing to your private Den, and the .msi is just a means to achieve that?

If you can confirm that or provide some additional context it will be helpful to provide you with a more structured answer

Thanks and kind regards,

Hello Richard,

We would like to have a run once executable that has our branding and pointing to our den in Azure. Reason we need this is some clients have IT that will not allow administrative privileges to install programs. Our prior product was Team Viewer and we used it as a run once that had our branding and it worked fine.

Hi Mattz

Thanks for the explanation.

If you are using Wayk Den, normally things should work without any firewall modifications. Did you try a connection over Wayk Den (i.e. using the Wayk ID, not a hostname or IP address) without making any changes to the firewall?

"the target hostname could not be resolved" likely is because the default configuration for Wayk Now puts it on the public Wayk Den at wss://den.wayk.net. Since you already have your .msi deploying the branding archive, you could also pre-create a configuration file in %appdata%\wayk\WaykNow.cfg containing the proper setting, e.g.

{
    "DenUrl": "https://den.custom.domain"
}

Another option could be to to call WaykNow.exe to create the file for you:

wayknow.exe config denUrl https://den.custom.domain

Let me know if that helps, or if you have further questions or problems

Thanks and kind regards,

Hello Richard,

We would like to have a run once executable that has our branding and pointing to our den in Azure. Reason we need this is some clients have IT that will not allow administrative privileges to install programs. Our prior product was Team Viewer and we used it as a run once that had our branding and it worked fine.

depending on the client you might also be able to get the IT to install wayk for you (where you could also just push the branding config along) which depending on what exactly you are doing via Wayk might be essential as wayk if launched without admin as standalone cannot interact AT ALL if an elevated windows is focused (including of course the UAC itself), and even if you elevated the standalone exe but dont actually install wayk with the background service, you can interact with admin windows, but as soon as the UAC spawns you still cannot do anything (in fact you cannot even SEE anything, as Secure desktop is on a higher privilege level altogether)

so if you need to admin the PCs, there's not really a way around installing wayk as even if the user could interact with the UAC, you couldnt enter credentials and telling them those is not really the point.

do note though that if you install wayk's Background Service Secure remote Delegation is on and cannot be turned off, so by default ANYONE with an enterprise license can hop in if they know the password of ANY admin (local and domain).

So make sure the admin passwords are secure.

Hi My1,

I agree it would be nice to be able to handle UAC without admin rights, but this is an intentional platform limitation which we cannot go around. Even if we did find a way, it would likely be something that looks like malware, as it would be a form of privilege escalation. The best possible solution remains to install the software with admin rights, and have the service up and running. Now the furthest we could go in the future would be to perform a temporary service registration, but this would still require admin rights. The only difference is we would be using admin rights to register the service temporarily, and then try and make sure we correctly clean it up afterwards. However, there are a lot of potential issues with such an approach, so even if we do end up offering such a feature, we would still recommend doing a proper installation of the software.

This being said, there are many things we can consider, but we need to make sure they are worth it for the users asking them. TeamViewer can self-elevate itself as SYSTEM without installation, but this is assuming the process is launched with admin rights and the UAC prompt. This is not something we are offering right now, but if we were to offer it, would it really solve the issues you are having? It does sound like in most cases we are still talking about users with no local admin rights.

Best regards,

Our .msi copies all of the branding files & the preconfigured .cfg with our den to their %appdata%\wayk\ yet randomly we will still get unable to resolve hostname, and verified on both sides through the application: File > Options > Connectivity : <our den url>

Hi My1,

I agree it would be nice to be able to handle UAC without admin rights, but this is an intentional platform limitation which we cannot go around.

I am aware and that is fully correct behavior.
I just wanted to say that he cannot use the launch once executable for UAC and has to install no matter whether or not the IT likes it.

Even if we did find a way, it would likely be something that looks like malware, as it would be a form of privilege escalation. The best possible solution remains to install the software with admin rights, and have the service up and running. Now the furthest we could go in the future would be to perform a temporary service registration, but this would still require admin rights.

I did not mean to say that you should malware yourself system exec
I know I'm crazy but not THAT crazy, and as you say below, this can be done normally

The only difference is we would be using admin rights to register the service temporarily, and then try and make sure we correctly clean it up afterwards. However, there are a lot of potential issues with such an approach, so even if we do end up offering such a feature, we would still recommend doing a proper installation of the software.

yup for example when wayk crashes it cant go and clean

This being said, there are many things we can consider, but we need to make sure they are worth it for the users asking them. TeamViewer can self-elevate itself as SYSTEM without installation, but this is assuming the process is launched with admin rights and the UAC prompt. This is not something we are offering right now, but if we were to offer it, would it really solve the issues you are having? It does sound like in most cases we are still talking about users with no local admin rights.

in case of this topic, correct, but at least cases I have used so far, mostly the user is relatively unexperienced with computers and has admin rights, (supporting personal computers of for example elderly or otherwise technologically challenged people), and wayk could for example on launch spawn a message (if the logged in user is admin) to ask whether wayk should get admin and then relaunch itself with UAC.

Our .msi copies all of the branding files & the preconfigured .cfg with our den to their %appdata%\wayk\ yet randomly we will still get unable to resolve hostname, and verified on both sides through the application: File > Options > Connectivity : <our den url>

when the hostname does not resolve

1. maybe try nslookup on those places where it doesnt resolve and check the name servers
2. make sure it's actually the den URL and not the realm (as it usually looks like an address too)

Hi Matt,

If the issue is intermittent, maybe the logs will tell us more. The error "the target hostname could not be resolved" can happen with direct connections using the IP address or hostname, but it can also happen when using the 6-digit Wayk ID, if the ID is not recognized by Wayk Den for some reason.

You can enable the logs in the Wayk Now options, under the Advanced tab, by setting the logging level to debug. The logs for the client application should be in %ProgramData%\Wayk\logs, and the logs for the service (full .msi installation only) should be in %ProgramData%\Wayk\logs.

You mentioned earlier that you have your own Wayk Den, did you also deploy your own Devolutions Jet relay servers as well, or did you leave the default relay servers on?

Best regards,

Ran into issues after one of the updates with our own jetrelay so currently we are using your jetrelay servers until we can get the stable connectivity.

Hi Mattz

As Marc said, the best way for to diagnose that will be from looking at a log. If you can generate a debug log from both the client and server, you can upload them here, attach to a PM or send to support@devolutions.net.

Since you are using the standalone .exe in all cases, on both machines you should:

• Set the log level to "Debug" in Options > Advanced > Logging Level
• Completely close and re-open WaykNow.exe
• Reproduce the issue (try to connect)
• Provide the log files from %appdata%\wayk\logs\WaykNow.log

Thanks and kind regards,

So here are some logs, one of our engineers did some testing between laptops on different networks, verified that both were pointed towards our den url and could not get them to connect. I'll send the logs through DM

Hi Mattz

Thanks for sending the log files.

We've done some analysis on our side and consulted with the Wayk Den team as well, because things look a bit strange. In the last connection attempt, we see that the target Den ID (the "personal laptop" machine) was resolved by your Wayk Den, but in the very next step of the connection sequence (the "session" initiation), your Wayk Den returned 404 (exactly as it sounds - the Den ID was not found).

I won't rule out a Wayk Den issue, but first can we take a look at your custom .msi? You could use a service like Firefox Send to securely send that to us (sending .msi can often be tricky via email).

Thanks and kind regards,

Custom .msi information sent over through PM.

Hi Mattz

Thanks for sending it over and the explanatory notes.

The .msi is shipping a %appdata%\wayk folder which presumably you took from an existing installation. The main problem is the ".unique" file in the root of that directory - that is a unique ID, generated at runtime, used by Wayk Den for identification purposes. In your case, you have multiple clients registering against your Wayk Den with the *same* unique ID, and this is the cause of the strange behaviour.

Wayk Now generates many files at runtime and while registering with Wayk Den, including certificates and keys. It's important that these aren't shared between machines or you will see undefined behaviour.

You can reduce your shipped %appdata% directory to just contain:

• branding.7z
• Your custom .png and .ico files
• WaykNow.cfg

Anything else is superfluous and likely to cause issues.

I also wanted to point out, if it makes things easier for you, since (at least) 2020.1.5, Wayk Now supports .zip for branding resources.

Thanks and kind regards,

Updated our MSI to reflect the information that you have provided, going to have our helpdesk do some further testing and will update you with the results.

Hi Mattz

Thanks for the update. Please don't hesitate to post back with further questions or feedback.

Thanks and kind regards,