Configuré un laboratorio para probar un dominio que une varias computadoras con un script de Microsoft.
Después de ejecutar el script, volvió a aparecer: no se pudo establecer una conexión WMI con la computadora con el siguiente mensaje de error: acceso denegado.
Hay dos computadoras del grupo de trabajo, ingreso su nombre, sus credenciales. El comando que se ejecuta en un dispositivo es:
Add-Computer -ComputerName SWC2-PC -LocalCredential SWC2-PC\[email protected] -DomainName swc.local -Credential swc.local\Administrator -Restart -Force
Cuando el script se ejecuta DESDE el DC que ejecuta el dominio, estoy intentando encender las computadoras del grupo de trabajo y aparece ese error continuamente.
Respuesta1
Tu -localcredentialno se ve bien. Debe ser una credencial de administrador para la computadora del grupo de trabajo, por ejemplo, SWC2-PC\Administrator.
Parece [email protected]un dominio UPN y eso no funcionará en su computadora que no está unida al dominio. Para ver si puede conectarse con la credencial, pruébela con Enter-PSSession:
Enter-PSSession -ComputerName SWC2-PC -Credential SWC2-PC\Administrator
Solo como principio general, utilice nombres de dominio NETBIOS al solucionar problemas. por ejemplo, SWC\Administrador (suponiendo que el nombre NETBIOS de su dominio sea "SWC"). A veces "simplemente funciona" cuando el formato FQDN no funciona.
Finalmente, el uso .localestá obsoleto para los nombres de dominio AD. Incluso en un laboratorio, simplemente no lo hagas: usa un subdominio de un dominio que hayas registrado o como se llamará en la actualidad. Es mejor evitar adquirir malos hábitos, incluso en el laboratorio.
Por ejemplo, de forma predeterminada, Windows Server 2016 Essentials agrega .local al nombre de la computadora de una instalación nueva (mal diseño de MS). Debería acostumbrarse a verificar y corregir el FQDN de su dominio durante la instalación en lugar de hacer clic en los valores predeterminados. (El método Powershell para instalar un dominio es más fácil y consistente).