Rescue mit Verbindungsabbrüchen und Blockaden
Hallo, wir haben in einer DigitalSignage-Lösung mit ca. 250 PCs (Tendenz steigend) auf einer der größten und modernsten Messegesellschaften Europas inzwischen Debian 12 mit XFCE im Einsatz. Wir haben, gemäß der Absprache mit GoTo von Central auf Rescue gewechselt, um die Linuxdevices zu unterstützen. Der Support schreibt mir, dass Debian nicht unterstützt werde, ABER dafür Ubuntu 22 unterstützt wird. Ubuntu 22 (Jellyfish) ist auf Debian 12 Bookworm OBEN DRAUF gebaut. Also ist die Aussage vom Support absolut unqualifiziert und ohne Faktengrundlage. Wie kann eine solche Aussage ("Debian wird nicht unterstützt. Wir unterstützen nur Ubuntu") zustandekommen, wenn Ubuntu GENERELL auf Debian aufgesattelt ist!? -- Das ist schlichtweg Blödsinn! Da der Support mir schrieb, ich solle mich an die Community wenden und es um einen Großauftrag geht, brauche ich noch HEUTE eine qualifizierte Antwort, welche Librarys, etc. Rescue benötigt, die nicht über den offiziellen Installer getriggert werden, damit wir diese zur Unterstützung nachinstallieren können! Ab nächste Woche Dienstag müssen wir die Systeme ins neue System bekommen. Inclusive Fernwartung!!! Wenn dies von Seitens GoTo nicht möglich erscheint und man faktisch falsche Alibiausreden nutzen möchte, sind wir gezwungen, die Lösung zu wechseln und hängen damit wieder bei TV, was aufgrund derer Sicherheitslücken auch ein Schadenersatzanspruch des Kunden aufgrund des Verkaufes der neuen Lösung bedeutet, da hier Rescue direkt mit verkauft wurde! Danke bereits jetzt für eine qualifizierte Antwort. Danke! P.S. (offizielle und öffentlich zugängliche Informationen): Ubuntu 22.04 LTS („Jammy Jellyfish“) basiert auf Debian 12, auch bekannt als „Bookworm“. Die entsprechende Debian-Version ist in der Datei /etc/debian_version als „bookworm/sid“ angegeben. Dieses Release wurde im April 2022 veröffentlicht und erhält bis April 2027 Langzeitsupport
Restrição de Campos na Console do Técnico e Controle do Status "Ausente" - Restricting Fields in the Technician Console and Controlling Away Status
Olá, equipe LogMeIn e comunidade! Gostaria de formalizar um feature request baseado em uma necessidade identificada por um de nossos clientes que utiliza o LogMeIn Rescue. Abaixo, detalho as solicitações: 1. Restrição de Campos Visíveis na Console do Técnico Atualmente, a console do técnico exibe diversos campos relacionados à sessão, como: Nome do cliente. CNPJ. ID de acompanhamento. Descrição do problema, entre outros. Embora seja possível que cada técnico ajuste manualmente quais campos deseja visualizar (clicando com o botão direito nos cabeçalhos das colunas), não há uma forma de configurar isso de maneira centralizada pela Central de Administração. Solicitação: Adicionar uma funcionalidade que permita aos administradores restringirem, de forma centralizada, quais campos serão visíveis para os técnicos na console. Isso ajudaria empresas que desejam limitar o acesso a informações sensíveis, como dados do cliente, e garantir que os técnicos vejam apenas campos básicos, como: ID da sessão. Status da sessão. Tempo total da sessão. Canal de atendimento. Essa funcionalidade seria especialmente útil para empresas que trabalham com filas de espera e desejam evitar que os técnicos escolham quais sessões atender com base em informações do cliente. 1. Restricting Visible Fields in the Technician Console Currently, the technician console displays several session-related fields, such as: Customer Name. CNPJ (Brazilian Taxpayer Registry Number). Tracking ID. Issue Description, among others. While each technician can manually adjust which fields they want to view (by right-clicking on the column headers), there is no way to configure this centrally through the Administration Center. Request: Add functionality that allows administrators to centrally restrict which fields are visible to technicians in the console. This would help companies that want to limit access to sensitive information, such as customer data, and ensure that technicians see only basic fields, such as: Session ID. Session status. Total session time. Service channel. This feature would be especially useful for companies that work with waiting queues and want to prevent technicians from choosing which sessions to handle based on customer information. 2. Controle do Status "Ausente" Manual Atualmente, os técnicos podem ativar o status "Ausente" manualmente com um simples clique sobre o próprio nome na console. Isso pode ser feito tanto de forma intencional quanto acidental, o que impacta diretamente a distribuição automática de sessões. Embora seja possível configurar o tempo de inatividade para que o status "Ausente" seja aplicado automaticamente, não há como impedir que o técnico ative esse status manualmente. Solicitação: Adicionar uma funcionalidade que permita aos administradores: Desativar a opção de status "Ausente" manualmente. Bloquear alterações manuais de status pelos técnicos. Essa funcionalidade ajudaria empresas que utilizam a distribuição automática de sessões, garantindo que os técnicos não possam evitar o recebimento de novas sessões ou alterar o status de forma inadequada. Por que essas funcionalidades são importantes? Essas solicitações visam atender empresas que precisam de maior controle sobre o fluxo de atendimento e a visibilidade de informações sensíveis na console do técnico. Além disso, ajudariam a evitar atrasos no atendimento e a garantir uma distribuição mais eficiente das sessões. 2. Manual Away Status Control Currently, technicians can manually activate the Away status by simply clicking their name in the console. This can be done intentionally or accidentally, which directly impacts automatic session distribution. While it is possible to configure the inactivity time for the Away status to be automatically applied, there is no way to prevent the technician from manually activating this status. Request: Add functionality that allows administrators to: Manually disable the Away status option. Block manual status changes by technicians. This feature would help companies that use automatic session distribution by ensuring that technicians cannot avoid receiving new sessions or change their status inappropriately. Why are these features important? These requests are intended to serve companies that need greater control over the service flow and visibility of sensitive information in the technician console. Furthermore, they would help avoid service delays and ensure more efficient session distribution. Agradeço pela atenção e espero que essas sugestões sejam consideradas para futuras atualizações do LogMeIn Rescue. Caso precisem de mais detalhes ou exemplos práticos, fico à disposição para colaborar! Atenciosamente, Gregor Maia Equipe Loupen
Rescue Calling Card in multi-user Linux environment
Hello, we have an issue with multi-user Linux setup. When the first user runs the application, the directory was created with the following owner and permission: [11:24] support@yk-lws22-01:~$ ls -la /var/tmp/rescue/ total 12 drwxrwx--- 3 support support 4096 Feb 7 09:51 . drwxrwxrwt 13 root root 4096 Mar 12 10:13 .. drwxrwxr-x 2 support support 4096 Feb 7 09:51 calling-card [11:24] support@yk-lws22-01:~$ ls -la /var/tmp/rescue/calling-card/ total 8 drwxrwxr-x 2 support support 4096 Feb 7 09:51 . drwxrwx--- 3 support support 4096 Feb 7 09:51 .. But if the second user tries to run the application, he gets the error: Mar 12 09:47:33 yk-lws22-01 rescue-callingcard.desktop[1237564]: what(): filesystem error: cannot create directories: Permission denied [/var/tmp/rescue/calling-card/] Distributor ID: Ubuntu Description: Ubuntu 22.04.5 LTS Release: 22.04 Codename: jammy rescue-callingcard: 7.52.6235 Do you have any ideas? Thanks
Unattended Access Failing – Connecting Then Drops
We have about 100 devices we've deployed the unattended MSI to via Intune. It's been working fine since last year but as of late we are unable to log into the majority of the devices. A mixture of 22H2/23h2 (Zoom Rooms) devices. Still looking into the details (Windows updates have been paused on these devices but seeing if perhaps manual updates have been performed by one of our teams). MSI is 7.5.2 1119.0. They show in the LogMeIn rescue technician console, are online, and functional, and we can authenticate (and Intune reporting indicates the software is still installed on these devices), but after authentication it says connecting for about 20 seconds and then disappears. Happening to all of us, and on most of the deployed to devices. Is there an optimal way to identify root cause here? I'm waiting on our onsite team to validate connectivity, restart the devices, verify no recent updates, validate what firewall we're using on these devices/any changes to Forcepoint or CrowdStrike, etc., but just curious if there might be something I'm missing in the meantime. For what it's worth I installed on one of my test devices, it didn't work initially, but subsequently it did (unsure if this coincided with a message I saw "This session has expired and can no longer be used, to start a new session this applet must be downloaded again" from the host device after the initial attempt. I closed this message and then attempted remoting in again and then it worked, however is consistently doesn't work on the other devices. I also see that a new version of the MSI via the admin center unattended install. I've packaged it and plan on testing the new version to determine if this remediates but only want to do that if necessary. Any requirements/logs/etc. I should be homing in on, here? Any help is appreciated!
LogMeIn Rescue keeps kicking us out every couple of minutes
Hi, we have a third party that uses LogMeIn Rescue for support that CAN connect but they are reporting that they are getting kicked out every few minutes. On our Firewall, we have set up LAN >> WAN Source is: Our Internal IP range Destination is the following FQDN's (below) which I found on support.logmeinrescue.com Ports HTTP/HTTPS *.logmein.com *.logmeinrescue.com *.logmeinrescue-enterprise.com *.logmein-gateway.com update-cdn.logmeinrescue.com *.logmein123.com *.123rescue.com *.support.me *.rescuemobile.com *.oty.com *.logmeininc.com *.remoteview.logmein.com *.turn.console.gotoassist.com *.logmein123.eu *.logmeinrescue.eu *.logmein.eu *.logmeinrescue-enterprise.eu *.rescuemobile.eu Have I missed any FQDN's that may be causing the issue? Or is there anything else I need to add, maybe IP's or extra ports. If we make it destination ANY, then all works fine so it must be the destination FQDN's to something else missing. Many thanks for your time.