Mes: octubre 2008

La secuencia de apagado:

1. El proceso WinLogon avisa al proceso del subsistema Win32, Csrss.exe (Client Server Runtime Subsystem) para que inicie la rutina de apagado.
2. Csrss.exe mediante un bucle con los procesos activos, va notificándoles de que el sistema se está apagando. Para cada uno de ellos, a excepción de Services.exe, Csrss.exe esperará un tiempo -especificado en la clave HKEY_USERS.DEFAULTControl PanelDesktopToKillAppTimeout que de forma predeterminada es de 20 segundos- antes de pasar al siguiente proceso.
3. Cuando Csrss.exe llega al proceso Services.exe le notifica que el sistema se está apagando, pero el tiempo de espera es específico de SCM.
4. Csrss.exe reconoce a SCM mediante el identificador de proceso (PID) que guardó cuando SCM se registró con Csrss.exe durante el inicio del sistema.
   Este tiempo de espera difiere del de los demás procesos ya que Csrss.exe espera mientras SCM se comunica con los servicios que necesitan llevar a cabo una limpieza cuando se están apagando; por lo tanto, un administrador puede necesitar ajustar sólo el tiempo de espera de SCM. Este valor se encuentra en la clave HKLMSYSTEMCurrentControlSetControlToKillServiceTimeout, que de forma predeterminada es de 20 segundos.
5. El manejador de apagado de SCM es responsable, solamente, del envío de las notificaciones asíncronas a aquéllos servicios que solicitan una notificación de apagado cuando han sido iniciados con el SCM. El código de control de apagado es SERVICE_CONTROL_SHUTDOWN.
6. SCM entra en un bucle de su base de datos, buscando servicios que necesitan la notificación de apagado y les envía a cada uno un comando de apagado.
7. Para cada servicio que ha de ser apagado, SCM envía un comando de apagado y guarda el valor de indicador de espera -un valor que el mismo servició le comunicó cuando se registró con SCM.
   El valor del indicador de espera de un servicio es la cantidad de tiempo que SCM permanecerá en un bucle esperando a que el servicio se inicie o se apague. Este indicador debe señalar cuantos milisegundos esperará el programa que está enviando el código de control antes de interrogar sobre su estado al servicio otra vez. SCM mantiene el seguimiento durante todo el tiempo del indicador recibido.
8. Después del envío de los mensajes de apagado, SCM espera hasta que todos los servicios notificados del apagado han terminado, hasta que el tiempo del indicador ha finalizado, o hasta que el valor de WaiToKillServiceTimeout se ha excedido. Services.exe en sí es detenido por Csrss.exe.
   

   SCM no espera por inteligente, sino simplemente porque entra en un bucle examinando el estado de todos los servicios que han solicitado una notificación de apagado. Asimismo, para disminuir el tiempo de apagado, SCM no sigue un orden de dependencias durante el apagado de los servicios.

   • Si el tiempo del indicador finaliza sin un servicio terminando, SCM determina si uno o más de los servicios que están esperando para terminar ha enviado un mensaje diciéndole que está progresando en su apagado.
   • Si al menos un servicio ha hecho progresos, SCM esperará otra vez el tiempo del indicador. SCM continua ejecutando su bucle de espera hasta que todos los servicios hayan finalizado o que ninguno de ellos sobre el cual está esperando ha notificado progreso dentro del tiempo del periodo de espera del indicador.

   Mientras SCM está ocupado comunicando a los servicios que se apaguen y espera que lo hagan, Csrss.exe espera a que SCM finalice.

   • Si todos los servicios acaban con el estado SERVICE_STOPPED, SCM finaliza su propio proceso.
   • Si todos los servicios no han acabado con el estado SERVICE_STOPPED, SCM realiza un bucle de 30 segundos. Los servicios que no han finalizado con dicho estado son finalmente detenidos, un poco más adelante Services.exe con Csrss.exe y el sistema se apaga.

     SCM, en realidad, nunca detiene los servicios en el apagado. Esto solamente ocurriría cuando el apagado de los servicios del equipo no lo hacen por sí mismos.

   • Si la espera mediante Csrss.exe acaba sin que SCM haya finalizado (es decir, el tiempo de espera de WaitToKillServiceTimeout ha expirado), Csrss.exe sigue el proceso de apagado resultando finalmente con la detención de Services.exe.

Siguiendo con SCM.

Inicio de controlador de dispositivo

SCM agrega registros en su BD para controladores de dispositivos además de los servicios. SCM inicia los controladores configurados como auto-start y detecta los errores en el inicio de los configurados como boot-start y system-start. El administrador de E/S carga los configurados como boot-start y system-start antes de que cualquier proceso se inicie en modo usuario, y por lo tanto cualquier controlador con estos tipos de inicio se cargará antes de que el propio SCM inicie.

Si un servicio que inicia SCM tiene un valor de 1 (SERVICE_KERNEL_DRIVER) o 2 (SERVICE_FILE_SYSTEM_DRIVER) en su entrada del registro, éste es un controlador de dispositivo y SCM lo cargará.

SCM habilita el privilegio de carga de controlador segura para el proceso de SCM y entonces llama a la API del Kernel NtLoadDriver, pasándole el valor de la entrada ImagePath de la subclave del registro del controlador.

Nota: A diferencia de los servicios, los controladores no necesariamente han de especificar un ImagePath, si este no existe, SCM genera uno agregando el nombre del controlador a la cadena ruta_del_sistemaSystem32Drivers.

Inicio de controladores y servicios en modo seguro

Cuando el sistema operativo se inicia en modo seguro SCM se asegura que cada servicio y controlador o está identificado por nombre o por grupo en la subclave correspondiente de la subclave SafeBoot del registro. Hay dos claves de modo seguro, Minimal y Network, en la rama HKLMSYSTEMCurrentControlSetControlSafeBoot. Cual de las dos comprobará SCM depende del modo elegido durante un reinicio del equipo.

• Si seleccionamos Modo Seguro o Modo Seguro desde la línea de comandos en el menú de inicio (se accede mediante la pulsación de la tecla de función F8 durante el arranque), SCM lee el valor de Minimal de la clave.
• Si seleccionamos Modo Seguro con Red, entonces SCM lee la entrada Network de la clave. La presencia de una entrada Option de tipo string en la subclave SafeBoot indica no sólo que el sistema se ha iniciado en modo seguro sino que además está seleccionado el modo usuario.

Los servicios y controladores iniciados en cada uno de los modos son:

Modo Seguro

• Servicios de cifrado (Cryptographic services)
• Registro de sucesos (Event log)
• Ayuda y soporte técnico (Help and support)
• Servicio del administrador de discos lógicos (Logical Disk Manager Administrative Service)
• Inicio de sesión en red (Net logon)
• Plug and play
• Llamada a Procedimiento Remoto (Remote Procedure Call (RPC))
• Instrumental de administración de Windows (Windows Management Instrumentation (WMI))

Modo Seguro con Red

• AFD Networking Support Environtment
• Examinador de equipos (Computer Browser)
• Cliente DHCP (DHCP client)
• Cliente DNS (DNS client)
• Registro de sucesos (Event log)
• Ayuda y soporte técnico (Help and support)
• Administrador de discos lógicos (Logical Disk Manager)
• NetBIOS Interface
• NetBios over Tcpip
• Inicio de sesión en red (Net logon)
• Conexiones de red (Network Connections)
• Plug and Play
• Llamada a Procedimiento Remoto (Remote Procedure Call (RPC))
• Servidor (Server)
• Ayuda de NetBIOS sobre TCP/IP (TCP/IP NetBIOS Helper)
• TCP/IP Protocol Driver
• Servicios de Terminal Server (Terminal Services)
• Instrumental de administración de Windows (Windows Management Instrumentation (WMI))
• Estación de trabajo (Workstation)

Además del inicio de servicios, el sistema carga SCM con el propósito de cuando la configuración del registro del sistema, HKLMSYSTEMCurrentControlSet, lo indique, guardar un punto de control de Última configuración buena conocida. CurrentControlSet contiene la subclave Services, por lo tanto, incluye la representación en el registro de la BD de SCM. También contiene la subclave Control, que almacena muchos de los valores de configuración de los subsistemas modo-kernel y modo-usuario.

Predeterminadamente, un inicio con éxito consiste en un inicio correcto de los servicios auto-start y del inicio de sesión. Un proceso de inicio falla si el sistema se detiene porque un controlador de dispositivo falla y para al sistema en su arranque, o si un servicio auto-start con una entrada ErrorControl con valor 2 (SERVICE_ERROR_SEVERE) o con valor 3 (SERVICE_ERROR_CRITICAL) devuelve un error de inicio.

SCM sabe cuando se ha completado un inicio correctamente de los servicios auto-start; sin embargo, la aplicación Winlogon (ruta_del_sistemaSystem32) es la que ha de decirle que el inicio de sesión es correcto, indicando que el sistema ha procedido con éxito hasta el punto de que el conjunto de CurrentControl puede guardarse y seleccionarse como Última Configuración Buena Conocida. Cuando iniciamos sesión, Winlogon envia un mensaje al SCM, siguiendo un inicio correcto de los servicios auto-start y SCM guarda la configuración de inicio actual del registro.

La definición de inicio correcto puede ser sustituido por aplicaciones de terceros con una definición propia de dicha aplicación. Por ejemplo SQL puede no considerar un inicio como correcto hasta que SQL Server sea capaz de aceptar y procesar transacciones.

 

Iniciando servicios automáticamente

Durante la inicialización de servicios, SCM arranca todos los que tiene en las entradas del registro con un valor 2 (SERVICE_AUTO_START) y los servicios de los que dependen. E.g. Si uno de los servicios marcados como inicio automático depende de uno marcado como manual, el servicio de inicio por demanda iniciará ese servicio manual también. El orden de carga se determina teniendo en cuenta:

1. El orden de los grupos de servicios según la lista de orden de carga de grupos de la subclave HKLMSYSTEMCurrentControlSetControlServiceGroupOrder.
2. El orden de controladores dentro de un grupo especificado en la subclave HKLMSYSTEMCurrentControlSetControlGroupOrderList.
3. La lista de dependencias de cada servicio.

Cuando el proceso de inicio se completa, el sistema ejecuta el programa de comprobación de arranque especificado en la subclave HKLMSYSTEMCurrentControlSetControlBootVerificationProgram.

Predeterminadamente, este valor no está establecido. El sistema informa que el proceso de arranque se realizó con éxito después de completar la secuencia de inicios automáticos.

Después de que el equipo se ha iniciado correctamente, el sistema operativo guarda un clon de la base de datos en la Última configuración buena conocida. El sistema podrá utilizar esta copia de la base de datos si cualquier cambio hace que la base activa falle en el reinicio del equipo.

Si la entrada del registro ErrorControl de un servicio de inicio automático tiene un valor 2 (SERVICE_ERROR_SEVERE) o 3 (SERVICE_ERROR_CRITICAL) y el servicio falla en su inicio, SCM reiniciará el equipo usando la configuración de Última configuración buena conocida. Si ésta ya se ha usado, el reinicio del equipo fracasará.

Un inicio automático de un servicio sigue la secuencia:

1. SCM inicia todos los servicios marcados con inicio automático y un valor 2 en la entrada Start. También inicia los controladores de inicio automático.
   El algoritmo para iniciar los servicios en orden correcto procede en varias fases, un sistema por el que una fase corresponde a un grupo, y las fases proceden según la secuencia definida por el orden de grupo definida y almacenada en la lista de la entrada del registro HKLMSYSTEMCurrentControlSetControlServiceGroupOrder. El valor de la entrada incluye los nombres de grupos en el orden en que SCM los iniciará.
2. SCM marca todas las entradas de servicios que pertenecen al grupo de la fase de inicio.
3. SCM entra en un bucle con los servicios marcados, comprobando si puede iniciar cada uno de ellos. Esa comprobación consiste en determinar si el servicio tiene una dependencia en otro grupo, especificada en la entrada DependOnGroup de la subclave del servicio.
   • Si existe alguna dependencia, el grupo del que el servicio es dependiente debe estar ya iniciado, y al menos un servicio de dicho grupo se ha iniciado correctamente.
   • Si el servicio depende de un grupo que inicia posteriormente, según la secuencia de orden de inicio, que el grupo al que pertenece él mismo, SCM registrará un error de dependencia circular del servicio.
4. SCM comprueba si el servicio depende de uno o más servicios, y si dichos servicios ya están iniciados. Las dependencias de servicios se indican en la entrada DependOnService de la subclave del servicio.
   • Si un servicio depende de otros que pertenecen a grupos que se encuentran después en la lista de la entrada ServiceGroupOrder, SCM devuelve un error de dependencia circular y no iniciará el servicio.
   • Si el servicio depende de cualquier otro del mismo grupo que no ha sido ya iniciado, el servicio se saltará.
5. Cuando las dependencias de un servicio se han cumplido, SCM realiza una comprobación final para ver si el servicio es parte de la configuración de arranque actual antes de iniciarlo.
6. Cuando SCM inicia un servicio, primero determina el nombre del archivo que ejecuta el proceso del servicio leyendo su valor en la entrada ImagePath en la subclave del registro del servicio.
7. Entonces examina el valor de la entrada Type, y si ésta es 32 (es decir, que el servicio comparte proceso), SCM se asegura que el proceso que ejecuta el servicio -si ya está iniciado- ha iniciado sesión mediante la misma cuenta que tiene especificada para ser iniciado. Una entrada del registro ObjectName del servicio almacena la cuenta de usuario con la que se ejecuta el servicio. SCM fallará en el inicio del servicio si no hay cuenta determinada y devolverá un error ERROR_INVALID_SERVICE_ACCOUNT.
8. SCM comprueba que el proceso del servicio no ha sido ya iniciado con una cuenta distinta comprobando si el valor de la entrada ImagePath tiene una entrada en la base de datos de SCM identificada como image database.
   • Si esta imagen no tiene un registro para la entrada ImagePath, SCM crea una. Cuando se crea un nuevo registro, se almacena la cuenta de inicio de sesión utilizada para el servicio y los datos del valor de la entrada ImagePath. SCM necesita que los servicios tengan una entrada de ImagePath.
   • Si el servicio no tiene una entrada ImagePath, SCM devuelve un error de estado que no puede encontrar el path del servicio y es incapaz de iniciarlo.
   • Si SCM localiza una entrada en una image database existente un dato coincidente con el valor de la entrada ImagePath, se asegura que la información de cuenta de usuario del servicio es la misma que está almacenada en el registro de la BD. Un proceso puede iniciar sesión con una única cuenta, devolviendo un ERROR_DIFFERENT_SERVICE_ACCOUNT si el servicio especifica una cuenta distinta que otro servicio ya iniciado dentro del mismo proceso ha usado.
9. SCM inicia sesión de un servicio si la configuración del servicio especifica que el proceso del servicio debe iniciarse. SCM inicia sesión de los servicios que no se ejecutan con la cuenta del sistema (system) mediante llamada a la API LogonUserEx, implementada por Lsass.exe (Local Security Authority). Lsass.exe normalmente necesita una contraseña, pero SCM le indica que la contraseña está almacenada mediante LSA en la subclave HKLMSECURITYPolicySecrets.
   

   Los contenidos de la clave HKLMSECURITY no suelen estar visibles porque su configuración predeterminada sólo permite el acceso desde la cuenta System.

10. Cuando SCM llama a LogonUserEx, especifica un inicio de sesión de servicio como tipo de inicio de sesión. Lsass.exe busca la contraseña en la clave mencionada y SCM le redirige para almacenar la contraseña como un secreto cuando un programa de control de servicio configura información de inicio de sesión de un servicio usando las API CreateService o ChangeServiceConfig.
11. Cuando un inicio de sesión es correcto, LogonUserEx devuelve un handler para un token de acceso para el llamante. Windows Server 2003 usa tokens de acceso para representar su contexto de seguridad, y luego SCM asocia el token con el proceso que implementa el servicio.
12. Después del inicio de sesión correcta, SCM carga la información del perfil de la cuenta, si no está ya cargada, llamando a LoadUserProfile, que está implementada en Userenv.dll en ruta_sistemasystem32. La entrada del registro ProfileImagePath de la rama HKLMSOFTWAREMicrosoftWindows NTCurrentVersionProfileList<<clave_perfil_usuario>> contiene la ubicación en disco de un conjunto de registro que carga en el registro, estando la información del conjunto en la rama HKEY_CURRENT_USER, para el servicio.
13. SCM procede a iniciar el proceso del servicio, si el proceso no ha sido ya iniciado. SCM lo hace en un estado de suspensión y crea un conducto mediante el que se comunica con el proceso, y le asigna el conducto al nombre PipeNetNetControlPipeX, donde X es un número que se incrementa cada vez que SCM crea un conducto.
14. SCM reanuda el proceso del servicio y espera que el servicio conecte con su conducto SCM.
    • Si el conducto existe, el valor de la entrada del registro ServicesPipeTimeout en la rama HKLMSYSTEMCurrentControlSetControl determina la duración que SCM espera a que el servicio conecte antes de abandonar y terminar el proceso.
    • Si la entrada ServicesPipeTimeout no existe, SCM usa 30 segundos como el tiempo predeterminado. Tiempo que usará SCM en todas las comunicaciones del servicio.
      Cuando un servicio conecta con SCM mediante un conducto, SCM envia un comando de inicio al servicio. Si el servicio falla en la respuesta positiva al comando de inicio dentro del tiempo de retardo, SCM abandona y se mueve hacia el inicio del siguiente servicio.
      Cuando un servicio no responde a una solicitud de inicio, SCM detendrá el proceso si éste no contiene otros servicion en ejecución. Procederá a la detención sin un servicio OWN_PROCESS falla o si el primero de los servicios SHARED_PROCESS a iniciar falla. En este último caso, SCM devolverá un ERROR_SERVICE_REQUEST_TIMEOUT (en solicitudes de inicio por demanda) y registrará un EVENT_CONNECTION_TIMEOUT.
      Un servicio inicio por demanda colgado -por ejemplo, un servicio clavado en un SERVICE_START_PENDING siempre- no será detenido por SCM, pero generará un mensaje de evento de error (EVENT_SERVICE_START_HUNG) y posiblemente un mensaje en una ventana emergente.
15. Así, de esta manera, SCM continua un bucle mediante los servicios pertenecientes a un grupo hasta que todos ellos han sido iniciados o han devuelto errores. El bucle es la forma en que SCM ordena automáticamente los servicios dentro de un grupo de acuerdo con el valor de sus entradas DependOnService. El bucle ayuda a SCM enviar parámetros de inicio a un servicio dependiente mientras los argumentos se mantienen en la pila hasta que el servicio dependiente es iniciado. SCM iniciará los servicios de los que otros dependen en anteriores bucles, saltando los servicios dependientes hasta bucles subsiguientes.
    

    SCM ignora entradas de etiqueta para controladores de dispositivos en subclaves bajo la rama HKLMSYSTEMCurrentControlSetServices. El administrador de E/S satisface las entradas para ordenar el inicio de los controladores de dispositivo en el arranque e inicio de controladores de inicio-de-sistema.

16. Después que SCM completa las comprobaciones para todos los grupos en la lista de la entrada List en HKLMSYSTEMCurrentControlSetControlServiceGroupOrder, lleva a cabo la comprobación de los servicios que quedan (los no agrupados).
17. Cuando las dependencias de un servicio han sido cumplidas, SCM hace una comprobación final para determinar si el servicio es parte de la última configuración buena conocida antes de iniciarlo.

Funciones del SCM

SCM se ejecuta dentro de Services.exe. Se inicia automáticamente en cuanto se carga el sistema operativo y se detiene cuando se procede al apagado del sistema. Se ejecuta con privilegios de system, y proporciona un medio unificado y seguro de control de aplicaciones de servicios. Es el responsable de contactar con los varios servicios y les ordena iniciar, parar, pausar, y seguir.

Iniciando servicios

SCM mantiene una base de datos de los servicios instalados y de los controladores de dispositivo en el registro. La BD se usa por SCM y por programas que añaden, modifican, o configuran servicios. La subclave del registro de esta BD es HKLMSYSTEMCurrentControlSetServices.

Esta clave a su vez contiene otra por cada servicio y controlador instalado. El nombre de la subclave es la del nombre que tenía el servicio o controlador cuando SCM lo instaló.

Una copia inicial de la BD se crea durante la instalación de Windows Server 2003. Esta BD incluye todos los parámetros relacionados con los servicios definidos para un servicio, además de los campos que siguen el estado del servicio. Además, la BD contiene registros para los controladores de dispositivo necesarios durante el reinicio de sistema. El tipo de entradas se encuentran en el registro, en las subclaves del servicio bajo HKLMSYSTEMCurrentControlSetServices. Hay cuatro valores que se aplican a los controladores de dispositivo:

• 1 (SERVICE_KERNEL_DRIVER)
• 2 (SERVICE_FILE_SYSTEM_DRIVER)
• 3 (SERVICE_ADAPTER)
• 8 (SERVICE_RECOGNIZER_DRIVER)

El valor de la entrada start determina sí y cuando se carga el servicio o controlador durante el arranque del sistema.

Iniciando los procesos del servicio

El camino que recorre el inicio de los procesos de un servicio es el siguiente:

1. De forma inmediata invoca una función de servicio, StartServiceCrtlDispatcher, que acepta una lista de puntos de entrada en Services, con un punto de entrada por cada servicio en el proceso. Cada punto de entrada se identifica por el nombre del servicio al que el punto de entrada corresponde.
2. StartServiceCtrlDispatcher crea una conexión de comunicación por conducto con nombre(calcado del inglés named pipe) para el SCM, y entonces entra en un bucle esperando la llegada de comandos por el conducto (pipe).
3. SCM envía un comando de inicio-de-servicio cada vez que inicia un servicio. Por cada comando de inicio que recibe, la función crea un hilo, denominado hilo de servicio, para invocar el inicio del punto de entrada del servicio.
4. StartServiceCtrlDispatcher espera indefinidamente comandos desde SCM y devuelve el control al proceso principal sólo cuando todos los hilos del proceso del servicio han terminado, permitiendo al proceso del servicio liberar los recursos antes de salir.
5. La primera acción de un punto de entrada del servicio (rutina ServiceMain) es llamar a la API RegisterServiceCtrlHandler(Ex), con un puntero hacia la función Handler(Ex) del servicio. Esta función está diseñada para recibir y manejar mensajes de control enviados al servicio, que se pasan más adelante desde SCM.
6. La función StartServiceCtrlDispatcher almacena la tabla en un proceso local de memoria, y el RegisterServiceCtrlHandler finaliza anunciándolo con el puntero HandlerEx del servicio y SERVICE_STATUS_HANDLE. El punto de entrada del servicio continua iniciando el servicio, que puede incluir alojamiento de memoria, puntos de finalización de creación de comunicaciones, y lecturas de datos de configuración privados en el registro. Una convención que la mayoría de servicios siguen es almacenar sus parámetros específicos-de-servicio en la subclave Parameters de su subclave del registro del servicio.
7. Mientras el punto de entrada inicia el servicio, puede con periodicidad enviar mensajes de estado al SCM para indicar como va el progreso de inicio del servicio. Después de que el punto de entrada finalice el inicio, un hilo de servicio, normalmente, entra en un bucle esperando solicitudes de las aplicaciones cliente.

Un hilo principal de proceso del servicio, que se llama y se ejecuta dentro de StartServiceCtrlDispatcher, recibe comandos SCM dirigidos a servicios en el proceso y usa la tabla de funciones de handler de servicios para ubicar y llamar a la función del servicio responsable de responder al comando. Los comandos SCM incluyen comandos de parada, pausa, retoma, consulta, apaga y los definidos por las aplicaciones.

Procesos

Ejecutar todos los servicios en su propio proceso, en lugar de tener varios servicios compartiendo proceso siempre que sea posible, es desperdiciar los recursos del sistema. Sin embargo, compartir el proceso significa que cualquiera de ellos que falle causará que el proceso se detenga, o sea, se pararán todos los servicios que lo comparten.

Algunos de los servicios integrados en Windows Server 2003 corren bajo su propio proceso; sin embargo la mayoría usan un proceso compartido con otros servicios.

Los servicios relacionados con la seguridad, como el servicio SAM (Security Accounts Manager), Netlogon y IPSec comparten el proceso Lsass.exe.

También existe un proceso genérico denominado Svchost, o la aplicación Svchost.exe(ruta_de_sistemaWindowsSystem32), que contiene múltiples servicios.

Proceso genérico

El proceso Svchost contiene múltiples servicios y varias instancias del proceso pueden estar ejecutándose al mismo tiempo bajo contextos de seguridad diferentes. Algunos de los servicios que se ejecutan dentro de este proceso son: Teléfono, RPC, Administrador de conexiones de escritorio remoto.

Windows Server 2003 implementa servicios que se ejecutan en Svchost como una DLL y especifica la ubicación de la DLL de un servicio en el valor del registro ImagePath (que tiene la forma ruta_de_sistemaSystem32svchost.exe -k nombre de la instancia) en la subclave correspondiente al servicio. Cada subclave del registro del servicio debe tener una entrada llamada ServiceDll en los parámetros de la subclave que apunte a la DLL del servicio. Todos los servicios que comparten un proceso Svchost común especifican el mismo parámetro (-k nombre de la instancia).

Normalmente, cada instancia de svchost que se ejecuta en Windows Server 2003 corresponde a una cuenta distinta. Hay un par de excepciones, como RPC por ejemplo, que se ejecuta con su propia instancia de LocalSystem por seguridad.

Cuando SCM encuentra el primer servicio que tiene un ImagePath de svchost.exe -k nombre de la instancia durante el inicio de servicio, crea una nueva entrada en la base de datos para la instancia de svchost e inicia el proceso como está configurado.

El nuevo svchost toma el parámetro y busca la subclave del registro que tiene el mismo nombre que el parámetro en HKLMSOFTWAREMicrosoftWindowsNTCurrentVersionSvcHost. Svchost lee el contenido de la subclave, interpretándolo como una lista de nombres de servicio y notifica al SCM que los aloje en cuanto Svchost los registre en SCM.

Cuando SCM encuentra un proceso Svchost durante el inicio de un servicio cuyo valor de imagePath coincide con una de las entradas que SCM ya tiene en su base de datos, no inicia un segundo proceso y en su lugar envía un comando de inicio para el servicio que el proceso svchost ya tiene iniciado para ese imagepath. El proceso existente lee el valor de ServiceDll en la subclave del servicio y carga la Dll dentro de su proceso para arrancar el servicio.

En general, la razón de compartir proceso los servicios es la disminución del uso de  memoria y hilo, que se incrementan dramáticamente cuando vamos añadiendo procesos al sistema. Las distintas instancias de svchost en nuestro equipo, en su mayor parte, se ejecutan con diferentes cuentas, y cada una de ellas alberga los servicios que se ejecutan en una cuenta particular. Mediante la herramienta Tasklist.exe y el parámetro /svc, podemos ver la lista de cuentas por nombre para cada instancia de Svchost.

Grupos

Muchos servicios no trabajarán correctamente a menos que otros componentes del sistema no estén ya en ejecución. Cuando se inicia un equipo, éste sigue un algoritmo que dicta el orden en que los servicios se inician. En Windows, los servicios del sistema se dividen en un conjunto de grupos predefinidos. Asignar un servicio a un grupo no tiene otro efecto que afinar su inicio con respecto a otros servicios que pertenecen a grupos diferentes.

SCM construye su base de datos interna de servicios y lee y almacena el contenido de la lista de entradas en la subclave HKLMSYSTEMCurrentControlSetControlServiceGroupOrder, un valor de cadena que lista los nombres y su orden de los grupos de servicio especificados. Una subclave del registro del servicio contiene una entrada de grupo opcional para ser usado si el servicio o controlador de dispositivo necesita controlar su orden de inicio con respecto a los servicios dentro de otros grupos.

SCM lee el valor de la entrada Grupo del servicio para determinar si es un miembro de un grupo y lo asocia con la entrada del grupo en la subclave ServiceGroupOrden mencionada antes. SCM también lee y graba en la base de datos el grupo y las dependencias del servicio consultando las entradas DependOnGroup y DependOnService.

Desde la introducción del Plug&Play en Windows 2000, el mecanismo de orden de grupo de servicio se ha convertido en menos significante. En Windows Server 2003, Plug&Play es el responsable de la carga de los servicios y los controladores del kernel. Plug&Play administra la carga de controladores en modo-kernel según la presencia de sus dispositivos asociados.

SCM casi nunca está complicado con la carga de un controlador. Lo más interesante del uso que nos queda del mecanismo de orden de grupo de servicios en modo kernel es para file system filter drivers.

La opción auto-start para controladores en modo-kernel está desfasada. Aún cuando un controlador se marca como AUTO_START, en cuanto inicia la primera vez, recibirá un root-enumerated devnode registrado en su nombre, y en todos los siguientes inicios éste devnode hará al controlador ser cargado por Plug&Play durante la fase de arranque del sistema, antes de iniciarse SCM.

La opción demand-start está recomendada para casi todos los controladores Plug&Play. Demand-start ya no significa  «cuando SCM es requerido para iniciar el controlador» (en respuesta a un comando NET por ejemplo) como en versiones de Windows anteriores. Ahora significa cuando Plug&Play lo «solicita» debido al descubrimiento de dispositivos asociados con el controlador.

Dependencias

Además de notificar al SCM que un servicio es parte de un orden de carga de grupo particular, se le puede decir que este servicio requiere otros servicios en ejecución antes de poder ejecutarse él mismo.

Hay dos tipos de dependencias:

• El servicio actual depende de otro para iniciar. Si el servicio X es antecedente al Y, el X debe estar en ejecución antes de ejecutar el servicio Y.
• Otros servicios dependen del servicio actual para iniciar. Si el servicio X es dependiente del Y, el Y debe estar en ejecución antes de iniciar el servicio X.

Ya he mencionado en repetidas ocasiones que los Servicios son aplicaciones Win32 que se ejecutan sin necesidad de un inicio de sesión interactivo. Son aplicaciones con código añadido para recibir comandos desde el SCM(Service Control Manager) y devolver el estado de las aplicaciones al propio SCM.

Si la clave de inicio del SCM contiene un tipo de valor de registro de: SERVICE_WIN32_OWN_PROCESS, SERVICE_WIN32_SHARE_PROCESS, o SERVICE_INTERACTIVE_PROCESS, la clave es un servicio y SCM lo arrancará. Si la subclave de una aplicación contiene el valor 16 (SERVICE_WIN32_OWN_PROCESS), 32(SERVICE_WIN32_SHARE_PROCESS), o 256 (SERVICE_INTERACTIVE_PROCESS) en la entrada, la aplicación es un servicio y lo arrancará el SCM.

La entrada tipo del registro para un servicio se ubica en la siguiente subclave:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesnombre_del_servicio  (Donde nombre_del_servicio es un servicio).

Nota: Un servicio tipo SERVICE_INTERACTIVE_PROCESS no puede iniciar por sí mismo. Necesita incluirse en una de las constantes de SERVICE_WIN32_*_PROCESS. Un servicio representado por una subclave con el valor 256 (SERVICE_INTERACTIVE_PROCESS) tampoco puede iniciarse por sí mismo.

Entradas del registro de un servicio

Varios parámetros de un servicio están descritos mediante entradas del registro del servicio. El SCM almacena cada característica como una entrada del servicio en la correspondiente subclave. Las subclaves de servicios individuales se ubican en la sublclave: HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServices.

Tabla de todas las subclaves de las entradas del registro para un servicio y controlador(No todos los servicios tienen todos los tipos de entrada). Si un servició necesita entradas de información de configuración que le son únicas, se crea una subclave denominada ‘parameters’ en su propia subclave, y en ella se almacenan las entradas referentes a esa información de configuración. Los valores son recuperados por el SCM desde las entradas listadas en cada subclave del servicio.

Windows Server 2003 en todas sus ediciones, inician algunas aplicaciones durante el arranque del sistema no vinculados a ningún usuario. Estas aplicaciones se denominan Servicios, o servicios Win32 por su relación con las API Win32 para interactuar con el sistema operativo. Similar a los demonios de Unix, los servicios implementan frecuentemente la parte del servidor del modelo de aplicación cliente/servidor. Adquirir conocimiento sobre la funcionalidad, seguimiento, administración y resolución de problemas de los servicios, mejora nuestra habilitad de llevar a cabo procedimientos de diagnóstico para resolver problemas relacionados con los servicios.

 

Un servicio no es más ni menos que una aplicación basada en sofware que lleva a cabo una función específica del sistema y que frecuentemente proporciona una API para ser llamada por otros procesos. Los servicios son aplicación que se ejecutan en segundo plano en el equipo local. Muchos también proporcionan funcionalidad para otros equipos en la red.

En Windows Server 2003 y anteriores los servicios son llamadas a procedimiento remoto (RPC) hasta el punto de que pueden ser llamados desde equipos remotos de la red. La mayoría de servicios pueden añadirse/quitarse desde la opción Añadir/quitar Componentes de Windows en Añadir o quitar programas del panel de control, y pueden administrarse y configurarse mediante el complemento Services, que se encuentra en Herramientas administrativas o usando el comando Sc.exe.

Modelo aplicación cliente/servidor

Frente al paradigma informático cliente/servidor, uno o más clientes y uno o más servidores, junto al sistema operativo subyacente y la comunicacón interproceso (IPC), forma un modelo que permite la informática distribuida, análisis y presentación.

En este modelo, el cliente es el proceso que interactúa con el usuario y que tiene ciertas características:

• Presenta el interfaz de usuario, que normalmente es un interfaz de usuario gráfico (GUI).
• Solicitudes al servidor y formularios de consulta o comandos en una estructura predefinida hacia el servidor, basados en entradas del usuario.
• Se comunica con el servidor mediante un método IPC como es RPC, y lo usa para la transmisión de solicitudes o comandos hacia el servidor.
• Lleva a cabo análisis de datos sobre los resultados envíados por el servidor y muestra los resultados al usuario en un formato de aplicación definido.

El servidor por su parte es un proceso, o un conjunto de procesos, todos los que pueden existir en un equipo único que proporciona un servicio a uno o más clientes. El servidor tiene las siguientes características:

• Generalmente trabaja para el cliente. La naturaleza y extensión de sus servicios están determinados por los objetivos empresariales del sistema cliente/servidor.
• Responder a consultas o comandos desde los clientes. No inicia ninguna conversación con ningún cliente, aunque puede existir diálogo entre ambos después de un contacto iniciado por el cliente. Un servidor actúa principalmente como repositorio de datos o conocimientos, o como un proveedor de servicios.
• Oculta la composición del sistema cliente/servidor para el cliente y el usuario (es transparente). La comunicación entre un cliente y un servidor  puede ser totalmene ajeno a la plataforma de hardware/software del servidor y de la tecnología de comunicación empleada. Esencialmente los clientes necesitan conocer sólo el interfaz, no los detalles de implementación del servidor. Esto permite al servidor cambiar o escalar según crece la demanda, sin afectar al cliente.

En el modelo cliente/servidor , un servidor -o demonio- se activa y espera las solicitudes del cliente. Un demonio es un programa que se ejecuta indefinidamente y que tiene el propósito de manejar periódicamente solicitudes al servicio que un equipo espera recibir. El demonio reenvía la solicitud a otros programas (o procesos) correspondientes. Los servicios de W2k3 realizan una labor similar.

Arquitectura

Los principales componentes del núcleo de la arquitectura de servicios son Service Control Manager (SMC), service control programs y service applications.

Service control programs no comunica con los servicios directamente; todas las comunicaciones van a través de SCM. Esta arquitectura es precisamente lo que hace la administración remota transparente al servicio de control de programa y al servicio de aplicaciones.

SCM Es un proceso del sistema especial que ejecuta ruta_del_sistemaSystem32Services.exe, que es el responsable del inicio, parada e interactuación con los servicios. Los servicios son aplicaciones Win32 que llaman a funciones Win32 especiales para interactuar con SCM para llevar a cabo acciones como registrar el inicio del sistema correcto, responder a solicitudes del estado, pausar o detener el servicio.

Service control programs Son aplicaciones Win32 estándar que usan las APIs SCM CreateSercice, OpenService, StartService, ControlService, QueryServiceStatus, y DeleteService para comunicarse con, o controlar servicios. Para el uso de estas funciones, un service control program debe primeramente abrir un canal de comunicación hacia SCM. Al mismo tiempo que llama, el servicio de control de programa debe especificar los tipos de acciones que quiere llevar a cabo.Durante su inicio, SCM crea un objeto interno que representa la base de datos SCM y usa funciones de seguridad de Windows para proteger el objeto con un descriptor de seguridad. El descriptor de seguridad especifica las cuentas que pueden abrir el objeto y los permisos de acceso a aquéllas cuentas que pueden usarlo.

SCM almacena el descriptor de seguridad en la subclave del registro del servicio como el valor de seguridad, y lo lee durante el inicio tanto de la configuración de seguridad como en el reinicio del equipo. (En caso de no existencia de una subclave especifica para un servicio SCM usara un descriptor de seguridad predeterminado seguro.)

De la misma forma que un service control program debe especificar los tipos de acceso que quiere a la base de SCM, debe también decir que acceso quiere para un servicio.

El Service control program que nos debe ser más familiar es el comando Sc.exe.

Service applications Un service application contiene la infraestructura necesaria para la comunicación con SCM, que envia comandos al servicio diciéndole que pare, se pause, continue o se apague. Un servicio llama también a funciones especiales que comunican su estado al SCM.

Los Service applications, como Servidores Web, consisten en al menos una aplicación que se ejecuta como un servicio. Un usuario que quiere iniciar, detener o configurar un servicio usa un Service control program. Aunque Windows Server 2003 proporciona programas de control de servicios integrados que proporcionan funcionalidades de inicio, parada, pausa y continuación , algunas service applications incluyen su propio programa de control de servicio que permite a los administradores especificar una configuración particular del servicio que administran.

Ya que la mayoría de servicios no tienen (y no deberían) un interfaz de usuario, se integran como programas de consola. En la figura anterior, los servicios 1, 2 y 3 representan service applications.

Cuando instalamos una aplicación que incluye un servicio, el instalador de la aplicación debe registrar el servicio con el SCM. Normalmente para hacerlo, el instalador llama a la función Win32 CreateService, una función relacionada con los servicios cuya parte de cliente está implementada en Advapi32.dll (que se encuentra dentro de la carpeta System32 de la ruta_del_sistema). Esta librería dinámina implementa la parte cliente de todas las APIs de SCM.

Clientes y servidores RPC Para service applications que usan las APIs como QueryServiceStatus y OpenService, el cliente RPC comunica directamente con SCM ya que éste es el servidor para éstas APIs.

Para las que usan APIs donde el servicio mismo es el servidor RPC, el cliente RPC se comunica con el servidor RPC directamente. De este modo, SCM no interfiere en las llamadas RPC a menos que las implemente.

 

'Este script sirve para apagar una lista de equipos remotos
'listados en un archivo de texto en grupos de dos lineas
'primera linea el nombre del equipo
'segunda linea la ip del equipo

'(c) Juansa 9-10-2008


Function fl_responde_al_ping (StrEquipo)

'aquí intentaremos comprobar que el equipo está conectado
'mediante un ping a su IP.

strComputer = "."
Set objWMIService = GetObject("winmgmts:" _
    & "{impersonationLevel=impersonate}!\" & strComputer & "rootcimv2")
Set colPingedComputers = objWMIService.ExecQuery _
    ("Select * from Win32_PingStatus Where Address = '" & StrEquipo & "'")

For Each objComputer in colPingedComputers
    If objComputer.StatusCode = 0 Then
        
    fl_responde_al_ping = True
    Else
        
    fl_responde_al_ping = false
   End If
Next

End Function

'cuerpo del script

Const ForReading = 1, ForWriting = 2
Dim TabStop, NewLine
TabStop = Chr(9)
NewLine = Chr(10)


Set objFSO = CreateObject("Scripting.FileSystemObject")
Set objFSO2 = CreateObject("Scripting.FileSystemObject")
Set objFile = objFSO.OpenTextFile("C:scriptsjuansa.txt", ForReading)
Set objFile2 = objFSO2.OpenTextFile("C:scriptsLogApagados.txt", ForWriting, True)
Do Until objFile.AtEndOfStream
StrEquipo = objFile.ReadLine
StrIP = objFile.ReadLine

If fl_responde_al_ping(StrIP) then
    Wscript.Echo StrEquipo & " responde. Se intentará realizar el apagado."
    objFile2.WriteLine Date & TabStop & StrIP & TabStop & StrEquipo & TabStop & "APAGADO"

    'establecemos control de errores
    On Error Resume Next

     Set objWMIService = GetObject("winmgmts:" _
& "{impersonationLevel=impersonate,(Shutdown)}!\" & StrEquipo & "rootcimv2")
    Set colOperatingSystems = objWMIService.ExecQuery _
("Select * from Win32_OperatingSystem")
    For Each objOperatingSystem in colOperatingSystems
        ObjOperatingSystem.Win32Shutdown(1)
    Next
    if Err.Number <> 0 Then

    'mostramos el error o lo guardamos en el log
    WScript.Echo vbCrLf & vbCrLf & _
                     Err.Number & ": " & Err.Description
    objFile2.WriteLine Date & TabStop & StrIP & StrEquipo & TabStop & "Hay un Error!" & Err.Number & ": " & Err.Description

    'vacíamos el objeto Err
    Err.Clear

    end if 

else
    Wscript.Echo StrEquipo & " NO responde. Se saltará éste equipo del apagado."
    objFile2.WriteLine Date & TabStop & StrIP & TabStop & StrEquipo & TabStop & " NO APAGADO"
end if
Loop
objFile2.Close
objFile.Close
Wscript.Echo "Puedes comprobar el Log en C:scriptsLogApagados.txt"

----------------

Lo que tienen los archivos:

C:scriptsjuansa.txt

juansa
192.168.0.10
ONO
192.168.0.1
Noexiste
192.168.0.11

 

C:scriptsLogApagados

09/10/2008    192.168.0.10    juansa        APAGADO
09/10/2008    192.168.0.1      ONO          APAGADO
09/10/2008    192.168.0.11    Noexiste     NO APAGADO

Este script funciona si el que lo lanza es administrador, de hecho está pensado para lanzarlo un administrador, pero mi amigo Fernando dice que puede usarse http://urpiano.wordpress.com/2007/04/26/vbscript-como-conectar-a-wmi-con-credenciales-alternativas/ para redondearlo.

Por supuesto es mejorable, pero lo publico por sí sirve de ejemplo y ayuda.

Puertas de enlace

Si estamos recibiendo el mensaje «La puerta de enlace no pertenece a ninguno de los interfaces configurados…» durante la instalación y configuración del SO, hemos de ver si la puerta de enlace predeterminada está en la misma red lógica que el adaptador de red del equipo. La forma más fácil de hacerlo es comparando el ID de red de la IP de la puerta de enlace con el ID de red de los adaptadores del equipo. En otras palabras, comprobar las operaciones lógicas AND de ambas IP y máscaras y sean correctas.

Proxy ARP

Proxy ARP es el que responde a solicitudes ARP de parte de otro nodo. Como se describe en la RFC 925, se usa en situaciones en que una subred es dividida sin usar un enrutador. Un dispositivo proxy ARP se coloca entre nodos que no están en la misma subred lógica. El proxy ARP responde a solicitudes ARP y facilita el reenvío de paquetes IP unicast para la comunicación entre nodos en segmentos separados.

Ejemplos:

• RRAs en equipos con W2k3, que usa proxy ARP para facilitar la comunicación entre clientes remotos y nodos en el segmento de red que está asignado al servidor de acceso remoto.
• La característica de puente en XP y W2k3 estándar y la edición de 32 bits de W2k3 Enterprise, que actúan como un dispositivo proxy ARP cuando llevan a cabo la tarea de puente (capa 3) entre segmentos de red.

El tráfico de red falla en algunas ocasiones porque la solicitud de un enrutador a un proxy ARP devuelve una dirección errónea. Un enrutador hace la solicitud ARP de parte de una dirección IP dentro de sus subredes internas. El problema es que la respuesta devuelve una MAC incorrecta para enviar al equipo. Como resultado, el equipo envía su tráfico a una MAC incorrecta. En resumen, tenemos un problema de respuestas desde un proxy ARP.

Para esto necesitamos del Monitor de Red y capturar la traza. Si la misma revela que cuando el equipo envía una solicitud ARP para la MAC del destino y un dispositivo (normalmente un enrutador) la devuelve con una MAC incorrecta, es que la resolución IP-a-MAC no funciona.

Nota: Podemos ejecutar hh NETMNconcepts.chm desde Inicio->ejecutar para obtener información sobre Network Monitor.

Para determinar si este es el problema podemos comprobar la caché ARP del equipo origen para asegurarnos de que esté adquiriendo la dirección resuelta de IP-a-MAC correcta. También podemos capturar todo el tráfico con Network Monitor y luego filtrar el tráfico capturado para mostrar sólo los protocolos ARP y RARP (este convierte MAC-a-IP).

Puede que resolvamos el problema desactivando el prosy ARP en el dispositivo, dependiendo de la marca, modelo y configuración del mismo.

Enrutadores agujeros negros

Algunos enrutadores no envían el mensaje «ICMP Destination Unreacheable-Fragmentación Needed and DF set» cuando no pueden reenviar un datagrama IP. En su lugar, descartan el datagrama en silencio. Normalmente un datagrama IP no puede ser reenvíado si su tamaño máximo de segmento es demasiado grande para el servidor receptor, y está establecida la no fragmentación de bit en la cabecera del propio datagrama. Los enrutadores que ignoran estos datagramas y no envían el mensaje se denominan PMTU Black-Hole Routers.

Para responder eficazmente a estos enrutadores, debemos habilitar la característica de detección de PMTU black-hole de TCP/IP. Esta característica reconoce transmisiones desconocidas y repetidas y responde desactivando la no fragmentación de bit. Después de la transmisión de un datagrama con éxito, se reduce el tamaño máximo de segmento y se activa de nuevo la no fragmentación de bit.

La característica de detección comentada está deshabilitada de forma predeterminada, pero podemos habilitarla añadiendo la entrada EnablePMTUBHDetect con un valor a 1 en el registro. Esta entrada es opcional y no aparece en el registro a menos que la añadamos en la sub-clave pertienente, que es:

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

Podemos deshabilitarla borrando la entrada o estableciendo su valor a 0.

Una segunda entrada, EnablePMTUDiscovery, ayuda también a descubrir problemas de enrutador agujero negro. Esta clave está habilitada predeterminadamente. Habilita o deshabilita completamente el mecanismo de descubrimiento de PMTU. Si está deshabilitada, se utiliza un tamaño máximo de segmento de TCP (MSS) de 536 bytes en direcciones de destino no locales.

Descubrir PMTU con Ping

La PMTU entre dos equipos puede descubrirse manualmente mediante el comando ping -f:

ping -f -n numerodepings [-l tamaño] IP_destino

Un ejemplo de como el tamaño de los ping puede variarse hasta encontrar la MTU. El parámetro de tamaño del ping especifica exactamente el tamaño de un dato Echo ICMP a enviar, sin incluir las cabeceras IP y ICMP. La cabecera ICMP es 8 bits y la de IP es normalmente de 20 bits. En el caso de ethernet que vemos, la link layer MTU contiene el tamaño máximo de buffer plus 28 de ping, para un total de 1500 bytes del primer ping y 1501 en el segundo.

En el segundo ping, la capa IP devuelve un mensaje de error ICMP que ping interpreta. Si el enrutador es un agujero negro, ping no recibirá respuesta des que su tamaño ha excedido la mayor MTU que el enrutador puede manejar. Ping puede usarse así, para detectar el enrutador.

Servicios

Además de su función de proveedor de comunicaciones básicas de red, TCP/IP es la piedra angular de una serie de servicios de red como: RRAs, Impresión, IPSec y Examinador.

• Si deseas más información sobre los protocolos TCP/IP, procesos y detalles de implementación en Windows:

Microsoft Windows Server 2003 Servicios y Protocolos TCP/IP Referencia Técnica ISBN: 0-7356-1291-9 (Inglés) ISBN: 84-481-3809-7 (Español)

Enrutamiento IP

Winodws Server 2003 es compatible con enrutamiento IP tanto en equipos con una tarjeta-adaptador de red como con varias y con o sin el servicio de Enrutamiento y Acceso Remoto(RRAs). RRAs incluye el protocolo RIP (Protocolo de información de enrutamiento) y los protocolos de enrutamiento OSPF (Open Shortest Path First). Los enrutadores pueden usar RIP o OSPF para intercambiar información de enrutamiento dinámicamente.

No podemos conectar a un servidor específico

Si no logramos conectar a un servidor específico mediante conexiones NetBIOS, usaremos nbstat -n para determnar el nombre NetBIOS que ha usado el servidor para registrarse en la red.

La salida el comando lista varios nombres que el equipo ha registrado. Uno de ellos debe parecerse al que se muestra en el escritorio del equipo. Sino, intentaremos con uno de los nombres únicos mostrados por Nbstat.

NBstat también muestra en pantalla las entradas cacheadas desde las entradas PRE del archivo Lmhosts o nombres NetBIOS resueltos recientemente. Si el nombre NetBIOS que los equipos están usando para el servidor es el mismo, y los otros equipos están en una subred remota, hay que asegurarse que tienen en su Lmhosts o en servidores WINS el nombre mapeado.

Servidores de múltiples-usos

Servidores con otras tareas pueden proporcionar servicios de enrutamiento, especialmente en LANs. Has de poder acceder al servidor que piensas que puede estar causando el problema, especialmente si es intermitente, para poder verificar que ningún otro servicio o aplicación está interfiriendo en los recursos del servidor, o que alguno no carga archivos grandes al inicio o apagado del servidor. Esto se aplica al equipo cliente también. Un método para verificarlo sería abrir el Administrador de equipos (clic derecho en MI PC, Administrar), extendemos recursos/carpetas compartidas, y seleccionamos la carpeta Sesiones para mostrar quien tiene una sesión actual con el equipo. Desde la consola de administración de equipo, podemos también ver el Visor de sucesos, que puede mostrar quien ha accedido al servidor, como también cualesquiera otros problemas que estén ocurriendo en ciertas horas o con una frecuencia específica. Otro método sería abrir al Administrador de Tareas para comprobar que aplicaciones o procesos se están ejecutando y lo que afectan al uso de la CPU.

Conexión colgada a un equipo remoto

Para determinar porqué una conexión TCP/IP remota no trabaja adecuadamente, podemos usar netstat -a para ver el estado de toda la actividad en los puertos TCP y UDP del equipo local.

Una buena conexión normalmente muestra 0 bytes en las colas de envío y recepción. Si los datos están bloqueados en alguna cola, la conexión probablemente falla. Si no, puede que sea la red o algún retardo de la aplicación.

Examinar la tabla de rutas con Route

Para dos equipos que intercambian datagramas, ambos han de tener una ruta hacia cada uno de ellos o usar una puerta de enlace que conozca una ruta. Normalmente los enrutadores intercambian información entre ellos mediante RIP.

Habilitar Enrutamiento IP

De forma predeterminada el Enrutamiento IP está deshabilitado. Para habilitarlo, debemos permitir el reenvío de paquetes que se reciben. Si no estamos usamos RRAs para habilitarlo, entonces debemos modificar el registro.

HKEY_LOCAL_MACHINESYSTEMCurrentControlSetServicesTcpipParameters

La entrada IPEnableRouter

A la que le cambiaremos el valor a 1 para habilitar el enrutamiento en todas las conexiones de red instaladas y utilizadas por el equipo.

Si Windows Server 2003 como enrutador no tiene una interfaz en una determinada subred, necesita una ruta para llegar a ella. Esto puede manejarse mediante una ruta predeterminada o añadiendo rutas estáticas. Para añadir una ruta estática podemos usar RRAs o con el comando Route Add. Por ejemplo:

Route add 172.16.33.0 mask 255.255.255.0 172.16.0.1 metric 2

Aquí añadimos 172.16.33.0/24 alcanzable usando la puerta de enlace 172,16.0.1 en dos saltos. Si queremos que la ruta sea persistente, esté presente incluso después de reiniciar, añadimos la opción -p al final del comando. Las rutas persistentes se guardan en el registro.

Examinar rutas con Tracert

Tracert usa incrementalmente valores altos en el TTL de la cabecera para determinar la ruta desde un equipo a otro a través de una red. Lo hace enviando mensajes Echo de ICMP y analizando los mensajes ICMP de retorno. Nos permite determinar la ruta de un paquete reenviado desde un enrutador a otro hasta 30 saltos. Si un enrutador ha fallado o el paquete es enrutado en un loop, Tracert nos indicará el problema. Después de hallarlo, su administrador debe restaurarlo a su estado de completa funcionalidad, contactando si es necesario con él si está fuera de nuestra administración.