Controladores
de Dominio 2003 - Error 1030 y 1058
En los controladores de dominio 2003 comienzan a aparecer errores
1030 y 1058 en el visor de eventos de aplicaciones luego de un
reinicio ya sea controlado o no.
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1058
Description: Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=com.
The file must be present at the location <\\domain\sysvol\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>.
(Access is denied. ). Group Policy processing aborted. For more
information, see Help and Support Center at http://support.microsoft.com.
or
Description: Windows cannot access the file gpt.ini for GPO CN={31B2F340-016D-11D2-945F-00C04FB984F9},CN=Policies,CN=System,DC=domain,DC=com.
The file must be present at the location <\\domain\sysvol\domain\Policies\{31B2F340-016D-11D2-945F-00C04FB984F9}\gpt.ini>.
(The network path was not found. ).
Event Type: Error
Event Source: Userenv
Event Category: None
Event ID: 1030
Description: Windows cannot query for the list of Group Policy
objects. A message that describes the reason for this was previously
logged by the policy engine. For more information, see Help and
Support Center at http://support.microsoft.com.
Porque se generan estos errores ?
El origen de este problema puede ser muy variado, pero normalmente
depende de la secuencia de inicio y de cuando en dicha secuencia
se inicia la controladora de red, ya que el origen radia en que
el proceso Winlogon trata de procesar la política de grupos antes
que otros componentes necesarios estén ejecutando.
Las indicaciones de Microsoft lo referirán y es correcto hacerlo,
a verificar lo siguiente
- El servicio Netlogon y el DFS estan iniciados y funcionando.
- Los DCs tienen los permisos y derecho suficientes sobre la
política de los DCs.
- Los permisos NTFS y Share están correctamente aplicados sobre
el SYSVOL.
- Las entradas DNS sobre domain controllers son correctas.
En nuestra experiencia, si alguna de estas situaciones se verifica
como errónea, entonces, los eventos 1030 y 1058 serán el menor de
sus problemas, ya que lo arriba indicado es básico para el funcionamiento
correcto de un dominio, normalmente Uds verificará que todo esta
correcto, sin embargo los eventos se registran.
La solución corta
Los DCs normalmente no se apagan ni tampoco se reinician, por
lo menos hasta que sea necesario en funcón de la aplicación de
algún parche, por lo tanto, si bien esta solución no es definitiva,
si puede aplicarse hasta tanto un reinicio o apagado del server
haga que los eventos vuelvan a aparecer.
Para solucionar temporalmente el problema, podemos utilizar la
herramienta DFSUTIL.exe que se encuentra dentro de las herramientas
de soporte de 2003 ("Windows Support Tools"), mismas que se incluyen
en el soporte magnético del server en Support -> Tools.
Una vez instaladas las herramientas, haga lo siguiente:
Inicio -> Run -> dfsutil /purgemupcache
Una vez ejecutado el dfsutil, la cache MUP será vaciada y los
errores dejarán de aparecer.
La solución larga (y peligrosa)
La solución larga, implica realizar cambios en la Registry y luego
reiniciar el servidor para ver que la aplicación de los cambios
ha dado el resultado esperado.
ACLARACION: Como en todas mis otras notas, si no sabe exactamente
que es el Registro de Windows o Registry, entonces no lo toque.
Si
realmente
sabe lo que esta haciendo, entonces no olvide hacer un backup antes
de realizar cualquier cambio, y siempre que pueda evite tocar el
registro de windows.
Hechas las salvedades pertinentes, aqui el procedimiento
- Inicie Regedit o Regedit32
- Localice la siguiente clave HKLM\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon
- Verifique si existe la entrada WaitForNetwork
- Si la entrada no existe, haga click con el botón derecho sobre
la subclave Winlogon
- Seleccione agregar un valor Dword, y coloque como nombre WaitForNetwork.
- Luego haga click con el botón derecho sobre WaitForNetwork y seleccione modificar
- Como valor indique 1
- Cierre el editor de registro
Este cambio en el registro hace que el proceso Winlogon espere
el inicio de la red para ejecutarse, luego de reiniciar el servidor,
los eventos 1030 - 1058 no deberían volver a producirse.
Referencias
Microsoft
- Base de Conocimiento 842804
NOTA: Si bien este documento indica que el problema fue resuelto
en el Service Pack 1 de Windows Server 2003, personalmente hemos
verificado
que la situación se sigue dando inclusive con el Service Pack 2
aplicado. |