What voodoo sorcery coming from Teamviewer (disabling other remote access applications)?
I've searched plenty but have not found much discussion about this voodoo...
Teamviewer [TV] (probably starting from version 14) blocks usage of other remote desktop (Anydesk=[AD]) or screen sharing (Mikogo=[Mo], Quick Assist=[QA]) applications. (recent test reveals affecting version 13 too)
I hate all the nags from Teamviewer, even while connecting no more than 1 minute. So, I would use a screen sharing application such as [Mo]. What I would do is as follows:
-----on local PC [windows 10]:
1.Launch [Mo] and generate a remote control session ID to give to remote PC later
2.Connect using [TV] to remote PC [over the internet]
-----on remote PC [windows 10/8.1]:
3. via [TV] session, open [Mo] and join established session with ID, allowing to screen sharing with local PC
4. close [TV] connection
As a result, can remote control via [Mo] session alone. This has been working for the past year, until recently. Now, after closing [TV] connection, step 4, the [Mo] session becomes blank/black with a banner message "you are unable to view the remote computer's screen. The remote computer may require local input in order to continue" or shows the remote screen but unresponsive to keyboard or mouse. Only after reconnecting [TV] would the [Mo] session return to the locked sign and becomes responsive normally again.
Similar situation with AnyDesk, where the session screen is displayed but the mouse cursor and keyboard are unresponsive. As for Quick Assist on a remote Windows 10 PC, it worked the first time using it. Subsequent times, similar unresponsive [black?] screen appears with no banner text message.
What is Teamviewer doing that disables use of another remote control or screen sharing program?
remote-desktop teamviewer
asked Feb 12 at 20:20
DSubDSub
11
add a comment |
I've searched plenty but have not found much discussion about this voodoo...
Teamviewer [TV] (probably starting from version 14) blocks usage of other remote desktop (Anydesk=[AD]) or screen sharing (Mikogo=[Mo], Quick Assist=[QA]) applications. (recent test reveals affecting version 13 too)
I hate all the nags from Teamviewer, even while connecting no more than 1 minute. So, I would use a screen sharing application such as [Mo]. What I would do is as follows:
-----on local PC [windows 10]:
1.Launch [Mo] and generate a remote control session ID to give to remote PC later
2.Connect using [TV] to remote PC [over the internet]
-----on remote PC [windows 10/8.1]:
3. via [TV] session, open [Mo] and join established session with ID, allowing to screen sharing with local PC
4. close [TV] connection
As a result, can remote control via [Mo] session alone. This has been working for the past year, until recently. Now, after closing [TV] connection, step 4, the [Mo] session becomes blank/black with a banner message "you are unable to view the remote computer's screen. The remote computer may require local input in order to continue" or shows the remote screen but unresponsive to keyboard or mouse. Only after reconnecting [TV] would the [Mo] session return to the locked sign and becomes responsive normally again.
Similar situation with AnyDesk, where the session screen is displayed but the mouse cursor and keyboard are unresponsive. As for Quick Assist on a remote Windows 10 PC, it worked the first time using it. Subsequent times, similar unresponsive [black?] screen appears with no banner text message.
What is Teamviewer doing that disables use of another remote control or screen sharing program?
remote-desktop teamviewer
asked Feb 12 at 20:20
DSubDSub
11
I don't think it's teamviewer to blame here. More sounds like the weakness of your other tools: they seems to work only when remote computer is attended by a person and a TV confection gives them this feeling.
– Máté Juhász
Feb 12 at 20:26
Could it be a Windows issue? Do you have the same problem when using AD+Mo instead of TV+Mo?
– masgo
Feb 12 at 20:26
@ Máté Juhász : The other tools mentioned have always been working through these steps for over a year, until recently. All the remote computers are unattended.
– DSub
Feb 13 at 2:03
1 of 3 remote PCs tested does not seem to have this issue. I think I need to put a hold on this question post while i can find additional opportunities to test. I don't always have access to these PCs. I'll be back when I get more results (perhaps next week). Thanks
– DSub
Feb 13 at 2:10
add a comment |
I've searched plenty but have not found much discussion about this voodoo...
Teamviewer [TV] (probably starting from version 14) blocks usage of other remote desktop (Anydesk=[AD]) or screen sharing (Mikogo=[Mo], Quick Assist=[QA]) applications. (recent test reveals affecting version 13 too)
I hate all the nags from Teamviewer, even while connecting no more than 1 minute. So, I would use a screen sharing application such as [Mo]. What I would do is as follows:
-----on local PC [windows 10]:
1.Launch [Mo] and generate a remote control session ID to give to remote PC later
2.Connect using [TV] to remote PC [over the internet]
-----on remote PC [windows 10/8.1]:
3. via [TV] session, open [Mo] and join established session with ID, allowing to screen sharing with local PC
4. close [TV] connection
As a result, can remote control via [Mo] session alone. This has been working for the past year, until recently. Now, after closing [TV] connection, step 4, the [Mo] session becomes blank/black with a banner message "you are unable to view the remote computer's screen. The remote computer may require local input in order to continue" or shows the remote screen but unresponsive to keyboard or mouse. Only after reconnecting [TV] would the [Mo] session return to the locked sign and becomes responsive normally again.
Similar situation with AnyDesk, where the session screen is displayed but the mouse cursor and keyboard are unresponsive. As for Quick Assist on a remote Windows 10 PC, it worked the first time using it. Subsequent times, similar unresponsive [black?] screen appears with no banner text message.
What is Teamviewer doing that disables use of another remote control or screen sharing program?
remote-desktop teamviewer
asked Feb 12 at 20:20
DSubDSub
11
I've searched plenty but have not found much discussion about this voodoo...
Teamviewer [TV] (probably starting from version 14) blocks usage of other remote desktop (Anydesk=[AD]) or screen sharing (Mikogo=[Mo], Quick Assist=[QA]) applications. (recent test reveals affecting version 13 too)
I hate all the nags from Teamviewer, even while connecting no more than 1 minute. So, I would use a screen sharing application such as [Mo]. What I would do is as follows:
-----on local PC [windows 10]:
1.Launch [Mo] and generate a remote control session ID to give to remote PC later
2.Connect using [TV] to remote PC [over the internet]
-----on remote PC [windows 10/8.1]:
3. via [TV] session, open [Mo] and join established session with ID, allowing to screen sharing with local PC
4. close [TV] connection
As a result, can remote control via [Mo] session alone. This has been working for the past year, until recently. Now, after closing [TV] connection, step 4, the [Mo] session becomes blank/black with a banner message "you are unable to view the remote computer's screen. The remote computer may require local input in order to continue" or shows the remote screen but unresponsive to keyboard or mouse. Only after reconnecting [TV] would the [Mo] session return to the locked sign and becomes responsive normally again.
Similar situation with AnyDesk, where the session screen is displayed but the mouse cursor and keyboard are unresponsive. As for Quick Assist on a remote Windows 10 PC, it worked the first time using it. Subsequent times, similar unresponsive [black?] screen appears with no banner text message.
What is Teamviewer doing that disables use of another remote control or screen sharing program?
remote-desktop teamviewer
remote-desktop teamviewer
asked Feb 12 at 20:20
DSubDSub
11
asked Feb 12 at 20:20
DSubDSub
11
asked Feb 12 at 20:20
DSubDSub
11
asked Feb 12 at 20:20
DSubDSub
11
asked Feb 12 at 20:20
DSubDSub
11
11
I don't think it's teamviewer to blame here. More sounds like the weakness of your other tools: they seems to work only when remote computer is attended by a person and a TV confection gives them this feeling.
– Máté Juhász
Feb 12 at 20:26
Could it be a Windows issue? Do you have the same problem when using AD+Mo instead of TV+Mo?
– masgo
Feb 12 at 20:26
@ Máté Juhász : The other tools mentioned have always been working through these steps for over a year, until recently. All the remote computers are unattended.
– DSub
Feb 13 at 2:03
1 of 3 remote PCs tested does not seem to have this issue. I think I need to put a hold on this question post while i can find additional opportunities to test. I don't always have access to these PCs. I'll be back when I get more results (perhaps next week). Thanks
– DSub
Feb 13 at 2:10
add a comment |
I don't think it's teamviewer to blame here. More sounds like the weakness of your other tools: they seems to work only when remote computer is attended by a person and a TV confection gives them this feeling.
– Máté Juhász
Feb 12 at 20:26
Could it be a Windows issue? Do you have the same problem when using AD+Mo instead of TV+Mo?
– masgo
Feb 12 at 20:26
@ Máté Juhász : The other tools mentioned have always been working through these steps for over a year, until recently. All the remote computers are unattended.
– DSub
Feb 13 at 2:03
1 of 3 remote PCs tested does not seem to have this issue. I think I need to put a hold on this question post while i can find additional opportunities to test. I don't always have access to these PCs. I'll be back when I get more results (perhaps next week). Thanks
– DSub
Feb 13 at 2:10
I don't think it's teamviewer to blame here. More sounds like the weakness of your other tools: they seems to work only when remote computer is attended by a person and a TV confection gives them this feeling.
– Máté Juhász
Feb 12 at 20:26
I don't think it's teamviewer to blame here. More sounds like the weakness of your other tools: they seems to work only when remote computer is attended by a person and a TV confection gives them this feeling.
– Máté Juhász
Feb 12 at 20:26
Could it be a Windows issue? Do you have the same problem when using AD+Mo instead of TV+Mo?
– masgo
Feb 12 at 20:26
Could it be a Windows issue? Do you have the same problem when using AD+Mo instead of TV+Mo?
– masgo
Feb 12 at 20:26
@ Máté Juhász : The other tools mentioned have always been working through these steps for over a year, until recently. All the remote computers are unattended.
– DSub
Feb 13 at 2:03
@ Máté Juhász : The other tools mentioned have always been working through these steps for over a year, until recently. All the remote computers are unattended.
– DSub
Feb 13 at 2:03
1 of 3 remote PCs tested does not seem to have this issue. I think I need to put a hold on this question post while i can find additional opportunities to test. I don't always have access to these PCs. I'll be back when I get more results (perhaps next week). Thanks
– DSub
Feb 13 at 2:10
1 of 3 remote PCs tested does not seem to have this issue. I think I need to put a hold on this question post while i can find additional opportunities to test. I don't always have access to these PCs. I'll be back when I get more results (perhaps next week). Thanks
– DSub
Feb 13 at 2:10
add a comment |
0
active
oldest
votes
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "3"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1404992%2fwhat-voodoo-sorcery-coming-from-teamviewer-disabling-other-remote-access-applic%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
0
active
oldest
votes
0
active
oldest
votes
active
oldest
votes
active
oldest
votes
Thanks for contributing an answer to Super User!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fsuperuser.com%2fquestions%2f1404992%2fwhat-voodoo-sorcery-coming-from-teamviewer-disabling-other-remote-access-applic%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
I don't think it's teamviewer to blame here. More sounds like the weakness of your other tools: they seems to work only when remote computer is attended by a person and a TV confection gives them this feeling.
– Máté Juhász
Feb 12 at 20:26
Could it be a Windows issue? Do you have the same problem when using AD+Mo instead of TV+Mo?
– masgo
Feb 12 at 20:26
@ Máté Juhász : The other tools mentioned have always been working through these steps for over a year, until recently. All the remote computers are unattended.
– DSub
Feb 13 at 2:03
1 of 3 remote PCs tested does not seem to have this issue. I think I need to put a hold on this question post while i can find additional opportunities to test. I don't always have access to these PCs. I'll be back when I get more results (perhaps next week). Thanks
– DSub
Feb 13 at 2:10