GoToMeetin g e Webex end controlam o cliente quando o cliente alterna para o Visual Studio ou o SQL Server Management Studio

Question

Frequentemente uso software de reuniões on-line para encontrar clientes. Normalmente, organizarei uma reunião usando o Webex e o cliente compartilhe seu computador. Então assumirei o controle e trabalharei remotamente usando uma variedade de programas - o Visual Studio, o SQL Server Management Studio (SSMS), um navegador, etc. Essa técnica funcionou maravilhosamente nos últimos dois anos.

No entanto, tenho um novo cliente para o qual percebemos um comportamento estranho (e repetitivo). O problema surge ao usar o Webex lançado do meu computador ou o GoToMeeting lançado a partir dele. Em suma, quando ele compartilha sua área de trabalho e eu tomo o controle, eu sou capaz de mover o mouse e usar o teclado muito bem quando o IE tem foco, ou bloco de notas ou o Windows Explorer. Mas assim que mudo para o Visual Studio ou o SSMS, meu controle é interrompido abruptamente. Mover meu mouse ou usar o teclado não é mais registrado em sua área de trabalho. O cliente pode mudar o foco para algum outro programa (como o IE) e depois retornar o controle para mim, mas assim que eu volto para o VS ou SSMS - bam - isso acontece novamente.

Observação: Depois de mudar para o VS / SMSS, ainda consigo ver o cliente movendo o mouse ou alternando entre as janelas, por isso não é como se toda a sessão congelasse - em vez disso, apenas meu controle do computador remoto parece para ser encerrado e não retornado até que meu cliente se mude para outra janela e diga ao programa de compartilhamento de tela para me dar o controle novamente.

Se for importante, o cliente está usando o Windows Vista com todos os sinos e apitos do Aero ligados.

Alguém viu ou ouviu falar de um comportamento como esse?

UPDATE : Eu continuo tendo esse problema em 2014. Os clientes que encontro não estão usando o Vista atualmente, mas o Windows 7 e o problema também existem no Visual Studio 2013. Curiosamente, as coisas funcionam bem com o Visual Studio 2005 e o SQL Server 2005, mas versões mais modernas desses produtos ainda causam os problemas que eu encontrei pela primeira vez em 2011.

    

Answer 1

O artigo O VS 2010 Team Explorer trava com o WebEx Connect tem alguns conselhos que podem ser aplicados aqui.

Um conselho foi:

In the WebEx Connect preferences, select the Integrations category and uncheck the box labeled "Display WebEx Connect status in Microsoft Office applications".

Outra foi:

We had the same problem for a while. This is due to the TFS PowerTools add-on, where the Team Member collaboration points to "Microsoft Office Communicator" by default (which I don't have ! but use WebEx instead) .

Just remove the default value, that way: In Team Explorer, for ex within VS2010:

• Right-click on the "Team Members" tree node (below "Work Items", "Reports" and "Builds")
• Choose the last option: "Personal Settings..." (it opens a pop-up)
• In the "Gereral" tab, you will see "Collaboration" group
• Change the default "Provider" from "Microsoft Office Communicator" to ""
• You will end-up having "", then click "OK"

    

Answer 2

Eu tenho usado o join.me para esse tipo de reunião e percebi há algum tempo que o lançamento da reunião do host join.me com privilégios administrativos era necessário para controlar qualquer janela administrativa no computador host. Isso é verdade para cmd.exe assim como é verdadeiro para o Visual Studio (devenv.exe).

Recentemente eu tentei mudar para outro aplicativo de compartilhamento de tela devido a problemas com o join.me executando um serviço persistente que parecia retardar drasticamente o meu computador, especialmente durante as reinicializações.

Até agora, não consegui fazer o trabalho de banda ou webex funcionar nessas janelas administrativas, mas funciona bem no join.me se e quando a reunião do host for iniciada com acesso administrativo (iniciar como admin).