VMware Workstation e Device / Credential Guard não são compatíveis

Tenho executado o VMware no ano passado sem problemas, hoje abri para iniciar uma das minhas VM e recebo uma mensagem de erro, veja a captura de tela.

Segui o link e segui as etapas, na etapa 4 preciso montar um volume usando "mountvol". quando tento montar um volume usando mountvol X: \\?\Volume{5593b5bd-0000-0000-0000-c0f373000000}\ele fica dizendo The directory is not empty.que até criei uma partição com 2GB e continua a mesma mensagem.

Minhas perguntas:

Como posso montar o volume que não está vazio apesar de estar?

Por que este Dispositivo / Credential Guard foi ativado automaticamente e como posso eliminá-lo ou desativá-lo.

CMD:

O Device / Credential Guard é uma Máquina Virtual / Modo Seguro Virtual baseado em Hyper-V que hospeda um kernel seguro para tornar o Windows 10 muito mais seguro.

... a instância VSM é segregada das funções normais do sistema operacional e é protegida por tentativas de ler informações nesse modo. As proteções são assistidas por hardware, uma vez que o hipervisor está solicitando que o hardware trate essas páginas de memória de forma diferente. Essa é a mesma maneira que duas máquinas virtuais no mesmo host não podem interagir uma com a outra; sua memória é independente e regulada por hardware para garantir que cada VM possa acessar apenas seus próprios dados.

A partir daqui, agora temos um modo protegido onde podemos executar operações sensíveis à segurança. No momento em que este artigo foi escrito, oferecemos suporte a três recursos que podem residir aqui: a autoridade de segurança local (LSA) e as funções de controle de integridade de código na forma de Kernel Mode Code Integrity (KMCI) e o próprio controle de integridade de código do hipervisor, que é chamado Integridade do código do hipervisor (HVCI).

Quando esses recursos são gerenciados por Trustlets no VSM, o SO Host simplesmente se comunica com eles por meio de canais e recursos padrão dentro do SO. Embora essa comunicação específica de Trustlet seja permitida, ter código malicioso ou usuários no sistema operacional do host tentando ler ou manipular os dados no VSM será significativamente mais difícil do que em um sistema sem isso configurado, proporcionando o benefício de segurança.

A execução do LSA no VSM faz com que o próprio processo LSA (LSASS) permaneça no sistema operacional host e uma instância adicional especial do LSA (chamada LSAIso - que significa LSA isolado) é criada. Isso permite que todas as chamadas padrão para LSA ainda tenham sucesso, oferecendo excelente compatibilidade legada e com versões anteriores, mesmo para serviços ou recursos que requerem comunicação direta com LSA. A esse respeito, você pode pensar na instância LSA restante no SO Host como uma instância 'proxy' ou 'stub' que simplesmente se comunica com a versão isolada de maneiras prescritas.

E o Hyper-V e o VMware não funcionavam ao mesmo tempo até 2020 , quando a VMware usou a plataforma Hyper-V para coexistir com o Hyper-V a partir da versão 15.5.5 .

Como o VMware Workstation funciona antes da versão 15.5.5?

O VMware Workstation tradicionalmente usa um Virtual Machine Monitor (VMM) que opera em modo privilegiado, exigindo acesso direto à CPU, bem como acesso ao suporte de virtualização integrado da CPU (Intel's VT-x e AMD-V). Quando um host Windows ativa os recursos de Virtualization Based Security (“VBS“), o Windows adiciona uma camada de hipervisor baseada em Hyper-V entre o hardware e o Windows. Qualquer tentativa de executar o VMM tradicional do VMware falha porque estando dentro do Hyper-V, o VMM não tem mais acesso ao suporte de virtualização do hardware.

Apresentando o Monitor de Nível de Usuário

Para corrigir esse problema de compatibilidade do Hyper-V / Host VBS, a equipe de plataforma da VMware re-arquitetou o Hypervisor da VMware para usar as APIs WHP da Microsoft. Isso significa alterar nosso VMM para ser executado no nível do usuário em vez de no modo privilegiado, bem como modificá-lo para usar as APIs WHP para gerenciar a execução de um convidado em vez de usar o hardware subjacente diretamente.

O que isso significa para você?

O VMware Workstation / Player agora pode ser executado quando o Hyper-V está habilitado. Você não precisa mais escolher entre executar o VMware Workstation e recursos do Windows como WSL, Device Guard e Credential Guard. Quando o Hyper-V está habilitado, o modo ULM será usado automaticamente para que você possa executar o VMware Workstation normalmente. Se você não usar o Hyper-V, o VMware Workstation é inteligente o suficiente para detectar isso e o VMM será usado.

Requisitos de sistema

Para executar a Workstation / Player usando as APIs de hipervisor do Windows, a versão mínima necessária do Windows 10 é Windows 10 20H1 build 19041.264. A versão mínima do VMware Workstation / Player é 15.5.5.

Para evitar o erro, atualize seu Windows 10 para a versão 2004 / Build 19041 (atualização maio 2020) e use pelo menos o VMware 15.5.5 .

Existe uma maneira muito melhor de lidar com esse problema. Em vez de remover o Hyper-V por completo, basta fazer uma inicialização alternativa para desativá-lo temporariamente quando precisar usar o VMWare. Conforme mostrado aqui ...

http://www.hanselman.com/blog/SwitchEasilyBetweenVirtualBoxAndHyperVWithABCDEditBootEntryInWindows81.aspx

C:\>bcdedit /copy {current} /d "No Hyper-V" 
The entry was successfully copied to {ff-23-113-824e-5c5144ea}. 

C:\>bcdedit /set {ff-23-113-824e-5c5144ea} hypervisorlaunchtype off 
The operation completed successfully.

nota: o ID gerado a partir do primeiro comando é o que você usa no segundo. Não basta executá-lo literalmente.

Ao reiniciar, você verá apenas um menu com duas opções ...

• Windows 10
• Sem Hyper-V

Portanto, usar o VMWare é apenas uma questão de reinicializar e escolher a opção No Hyper-V.

Se você deseja remover uma entrada de inicialização novamente. Você pode usar a opção / delete para bcdedit.

Primeiro, obtenha uma lista das entradas de inicialização atuais ...

C:\>bcdedit /v

Isso lista todas as entradas com seus IDs. Copie o ID relevante e remova-o assim ...

C:\>bcdedit /delete {ff-23-113-824e-5c5144ea}

Conforme mencionado nos comentários, você precisa fazer isso em um prompt de comando elevado, não em PowerShell. No PowerShell, o comando irá falhar.

update: É possível executar esses comandos no PowerShell, se as chaves forem escapadas com crase (`). Igual a...

C:\WINDOWS\system32> bcdedit /copy `{current`} /d "No Hyper-V"

Ainda não estou convencido de que o Hyper-V é a coisa certa para mim, mesmo com as tentativas e tribulações do Docker do ano passado e acho que você não vai querer mudar com muita frequência, então, em vez de criar uma nova inicialização e confirmar o padrão de inicialização ou esperando o tempo limite a cada inicialização que eu ligo sob demanda no console no modo de administrador

bcdedit /set hypervisorlaunchtype off

Outro motivo para esta postagem - para evitar um pouco de dor de cabeça: você pensou em ativar o Hyper-V com o argumento "on" novamente? Não. Muito simples para MiRKoS..t. É automático !

Diverta-se!
G.

Para tornar mais fácil:

1. Basta baixar este script diretamente da Microsoft.

2. Execute seu Powershell como administrador e execute os seguintes comandos:

   • Para verificar se DG / CG está habilitado DG_Readiness.ps1 -Ready
   • Para desativar DG / CG. DG_Readiness.ps1 -Disable

Para aqueles que podem estar enfrentando esse problema com alterações recentes em seu computador envolvendo o Hyper-V, você precisará desativá-lo ao usar o VMWare ou VirtualBox. Eles não funcionam juntos. Sandbox do Windows e WSL 2 precisam do Hyper-V Hypervisor ativado, que atualmente quebra o VMWare. Basicamente, você precisará executar os comandos a seguir para habilitar / desabilitar os serviços do Hyper-V na próxima reinicialização.

Para desativar o Hyper-V e fazer o VMWare funcionar, no PowerShell como Admin:

bcdedit /set hypervisorlaunchtype off

Para reativar o Hyper-V e interromper o VMWare por enquanto, no PowerShell como Admin:

bcdedit /set hypervisorlaunchtype auto

Você precisará reiniciar depois disso. Eu escrevi um script PowerShell que irá alternar isso para você e confirmá-lo com caixas de diálogo. Ele até se eleva a Administrador usando essa técnica para que você possa clicar com o botão direito e executar o script para alterar rapidamente o modo Hyper-V. Ele poderia ser facilmente modificado para reiniciar para você também, mas eu pessoalmente não queria que isso acontecesse. Salve como hypervisor.ps1 e certifique-se de executá- Set-ExecutionPolicy RemoteSignedlo para poder executar scripts do PowerShell.

# Get the ID and security principal of the current user account
$myWindowsID = [System.Security.Principal.WindowsIdentity]::GetCurrent();
$myWindowsPrincipal = New-Object System.Security.Principal.WindowsPrincipal($myWindowsID);

# Get the security principal for the administrator role
$adminRole = [System.Security.Principal.WindowsBuiltInRole]::Administrator;

# Check to see if we are currently running as an administrator
if ($myWindowsPrincipal.IsInRole($adminRole))
{
    # We are running as an administrator, so change the title and background colour to indicate this
    $Host.UI.RawUI.WindowTitle = $myInvocation.MyCommand.Definition + "(Elevated)";
    $Host.UI.RawUI.BackgroundColor = "DarkBlue";
    Clear-Host;
}
else {
    # We are not running as an administrator, so relaunch as administrator

    # Create a new process object that starts PowerShell
    $newProcess = New-Object System.Diagnostics.ProcessStartInfo "PowerShell";

    # Specify the current script path and name as a parameter with added scope and support for scripts with spaces in it's path
    $newProcess.Arguments = "-windowstyle hidden & '" + $script:MyInvocation.MyCommand.Path + "'"

    # Indicate that the process should be elevated
    $newProcess.Verb = "runas";

    # Start the new process
    [System.Diagnostics.Process]::Start($newProcess);

    # Exit from the current, unelevated, process
    Exit;
}

Add-Type -AssemblyName System.Windows.Forms


$state = bcdedit /enum | Select-String -Pattern 'hypervisorlaunchtype\s*(\w+)\s*'


if ($state.matches.groups[1].ToString() -eq "Off"){

    $UserResponse= [System.Windows.Forms.MessageBox]::Show("Enable Hyper-V?" , "Hypervisor" , 4)

    if ($UserResponse -eq "YES" ) 
    {

        bcdedit /set hypervisorlaunchtype auto
        [System.Windows.Forms.MessageBox]::Show("Enabled Hyper-V. Reboot to apply." , "Hypervisor")

    } 

    else 

    { 

        [System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
        exit

    }

} else {

    $UserResponse= [System.Windows.Forms.MessageBox]::Show("Disable Hyper-V?" , "Hypervisor" , 4)

    if ($UserResponse -eq "YES" ) 
    {

        bcdedit /set hypervisorlaunchtype off
        [System.Windows.Forms.MessageBox]::Show("Disabled Hyper-V. Reboot to apply." , "Hypervisor")

    } 

    else 

    { 

        [System.Windows.Forms.MessageBox]::Show("No change was made." , "Hypervisor")
        exit

    }

}

a solução mais simples para esse problema é baixar a "ferramenta de preparação de hardware Device Guard e Credential Guard" para corrigir a incompatibilidade:

• https://www.microsoft.com/en-us/download/details.aspx?id=53337
• Descompacte o zip
• você encontrará :

• execute o "DG_Readiness_Tool_v3.6.ps1" com PowerShell

• Agora você deve ser capaz de ligar sua máquina virtual normalmente.

Não sei por que, mas a versão 3.6 do DG_Readiness_Tool não funcionou para mim. Depois que reiniciei meu laptop, o problema ainda persistia. Estava procurando uma solução e finalmente encontrei a versão 3.7 da ferramenta e dessa vez o problema foi embora. Aqui você pode encontrar o script do PowerShell mais recente:

DG_Readiness_Tool_v3.7

Eu também lutei muito com esse problema. As respostas neste tópico foram úteis, mas não foram suficientes para resolver meu erro. Você precisará desabilitar o Hyper-V e a proteção de dispositivo como as outras respostas sugeriram. Mais informações sobre isso podem ser encontradas aqui .

Estou incluindo as alterações necessárias, além das respostas fornecidas acima. O link que finalmente me ajudou foi este .

Minha resposta vai resumir apenas a diferença entre o resto das respostas (ou seja, desabilitando o Hyper-V e o protetor de dispositivo) e as seguintes etapas:

1. Se você usou a Política de Grupo, desabilite a configuração da Política de Grupo usada para habilitar o Windows Defender Credential Guard (Configuração do Computador -> Modelos Administrativos -> Sistema -> Device Guard -> Ativar Segurança Baseada em Virtualização).

2. Exclua as seguintes configurações de registro:

   HKEY_LOCAL_MACHINE \ System \ CurrentControlSet \ Control \ LSA \ LsaCfgFlags HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ DeviceGuard \ EnableVirtualizationBasedSecurity HKEY_LOCAL_MACHINE \ Software \ Policies \ Microsoft \ Windows \ DeviceGuard \ RequireeatPlatformS

   Importante: Se você remover manualmente essas configurações de registro, certifique-se de excluí-las todas. Se você não remover todos eles, o dispositivo pode entrar em recuperação do BitLocker.

3. Exclua as variáveis ​​EFI do Windows Defender Credential Guard usando bcdedit. Em um prompt de comando elevado (inicie no modo admin), digite os seguintes comandos:

    mountvol X: /s
   
    copy %WINDIR%\System32\SecConfig.efi X:\EFI\Microsoft\Boot\SecConfig.efi /Y
   
    bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"
   
    bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO
   
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} device partition=X:
   
    mountvol X: /d
   

4. Reinicie o PC.

5. Aceite a solicitação para desativar o Windows Defender Credential Guard.

6. Como alternativa, você pode desabilitar os recursos de segurança baseados em virtualização para desligar o Windows Defender Credential Guard.

SOLUÇÃO RÁPIDA EM CADA ETAPA:

Corrigido o erro na estação de trabalho VMware no Windows 10 host Transport (VMDB) erro -14: a conexão do tubo foi interrompida.

Hoje estaremos corrigindo o erro VMWare em um computador com Windows 10.

1. Na caixa RUN, digite "gpedit" e vá para [ERROR VER PONTO 3]

1- Configuração do computador 2- Modelos administrativos 3- Sistema - Device Guard: SE NÃO HAVER DEVICE GUARD: (BAIXE https://www.microsoft.com/en-us/download/100591 instale esta "c:\Program Files (x86)\Microsoft Group Policy\Windows 10 November 2019 Update (1909)\PolicyDefinitions" CÓPIA para c:\windows\PolicyDefinitions) 4- Ativar baseado em virtualização Segurança. Agora clique duas vezes nisso e "Desativar"

2. Abra o Prompt de Comando como Administrador e digite o seguinte gpupdate / force [NÃO FAÇA SE VOCÊ NÃO TIVER PROTEÇÃO DE DISPOSITIVO MAIS, ELE IRÁ NOVAMENTE]

3. Abra o Editor do Registro, agora vá para HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\DeviceGuard. Adicione um novo valor DWORD denominado EnableVirtualizationBasedSecuritye defina-o como 0 para desativá-lo. Próximo Vá para HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\LSA. Adicione um novo valor DWORD denominado LsaCfgFlagse defina-o como 0 para desativá-lo.

4. Na caixa RUN, digite Ativar ou desativar recursos do Windows, agora desmarque o Hyper-V e reinicie o sistema.

5. Abra o prompt de comando como administrador e digite os seguintes comandos

    bcdedit /create {0cb3b571-2f2e-4343-a879-d86a476d7215} /d "DebugTool" /application osloader

    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} path "\EFI\Microsoft\Boot\SecConfig.efi"

    bcdedit /set {bootmgr} bootsequence {0cb3b571-2f2e-4343-a879-d86a476d7215}
    
    bcdedit /set {0cb3b571-2f2e-4343-a879-d86a476d7215} loadoptions DISABLE-LSA-ISO,DISABLE-VBS

    bcdedit /set hypervisorlaunchtype off

Agora, reinicie seu sistema

Se você mantém um prompt de comando aberto personalizado "Executar como administrador" ou janela de linha de comando do PowerShell o tempo todo, pode configurar opcionalmente os seguintes aliases / macros para simplificar a execução dos comandos mencionados por @ gue22 para simplesmente desativar o hipervisor hyper-v quando precisar usar o vmware player ou estação de trabalho e ativá-lo novamente quando terminar.

doskey hpvEnb = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype auto ^& echo.^&echo now reboot to enable hyper-v hypervisor )
doskey hpvDis = choice /c:yn /cs /d n /t 30 /m "Are you running from elevated command prompt" ^& if not errorlevel 2 ( bcdedit /set hypervisorlaunchtype off ^& echo.^&echo now reboot to disable hyper-v hypervisor )
doskey bcdL = bcdedit /enum ^& echo.^&echo now see boot configuration data store {current} boot loader settings

Com o descrito acima, basta digitar "hpvenb" [hipervisor habilitado na inicialização], "hpvdis" [hipervisor desabilitado na inicialização] e "bcdl" [lista de dispositivos de configuração de inicialização] para executar os comandos on, off, list.

Bem, meninos e meninas, depois de ler as notas de lançamento do build 17093 nas primeiras horas da noite, descobri que o ponto de mudança que afeta minha VMware Workstation VM está fazendo com que eles não funcionem, são as configurações de isolamento de núcleo em Segurança de dispositivo em segurança do Windows (novo nome para a página do Windows Defender) nas configurações .

Por padrão, ele está ligado, porém quando eu desliguei e reiniciei meu pc todas as minhas VMs VMware voltaram a funcionar corretamente. Talvez uma opção por dispositivo possa ser incorporada na próxima construção para nos permitir testar dispositivos / respostas de aplicativos individuais para permitir que o isolamento do núcleo seja ativado ou desativado por dispositivo ou aplicativo, conforme necessário.

Aqui estão as instruções adequadas para que todos possam seguir.

• Primeiro, baixe a ferramenta de preparação de hardware Device Guard e Credential Guard neste link: https://www.microsoft.com/en-us/download/details.aspx?id=53337
• extraia o conteúdo da pasta zip para algum local como: C: \ guard_tool
• você terá arquivos como este nome de arquivo de cópia do arquivo de extensão ps1 no meu caso é v3.6, então será: DG_Readiness_Tool_v3.6.ps1

• Em seguida, clique no menu Iniciar e pesquise PowerShell e clique com o botão direito nele e execute como Administrador.

• Depois disso, você verá o terminal de cor azul, digite o comando cd C: \ guard_tool , substitua o caminho após cd com a localização extraída da ferramenta
• Agora digite o comando: \ DG_Readiness_Tool_v3.6.ps1 -Disable
• Depois disso, reinicie o sistema
• Quando o sistema estiver reiniciando, o tempo de inicialização do sistema mostrará uma notificação com fundo preto para verificar se você deseja desabilitar esses recursos, então pressione F3 para confirmar.
• faça +1 se ajudou :)