Servidor de Marca vs. PC Clon

Porque comprar un servidor de marca en vez de una "PC Clon"?
Esta es una pregunta, que se hacen las pymes cuando empiezan a crecer y por lo general el asesoramiento que reciben es que compren una pc de buena performance y que la usen como servidor.

Pero, es esto correcto?

Evidentemente no!! Por alguna razón existe la diferencia entre PC de escritorio y Servidor.
Una Pc de muy buena performance se convierte en una workstation poderosa, no en un servidor.

Empecemos por el comienzo, una PC de escritorio, posee un mother con sonido y video, por lo general con buenas prestaciones para el uso de multimedia, algo que no se utiliza desde un servidor.
Las PCs de escritorio no vienen testeadas de fabrica con las versiones mas populares de los sistemas operativos servidores, tampoco ofrecen soporte postventa.
Son propensas a diferentes errores a nivel memoria, y no estan preparadas para estar encendidas 7x24.
Tampoco poseen un buen sistema de refrigeración y poseen cero redundancia.

Los servidores tienen algo muy importante que es fundamental para funcionamientos de stress (como los que reciben los servidores) EL CHIPSET.
En los servidores este chipset viene testeado y probado a full, para que pueda funcionar 24x7x365 con la mejor performance.
Tambien se presta especial enfasis en la refrigeración, algo fundamental para mantener la temperatura en el punto justo evitando el deterioro por calor, de los componentes internos.
Tipicamente los servidores vienen con varias turbinas potentes (por eso son más ruidosos que las PCs) y con la capacidad de agregar más de acuerdo a la cantidad de componentes presentes en el equipo.
Cabe destacar que los servidores gestionan inteligentemente estas turbinas, bajando o subiendo la cantidad de RPMs de las mismas de acuerdo a la exigencia que este recibiendo el servidor en cada momento.
Otro punto importante es el diseño del hardware de servidores.
En todos los servidores, incluyendo las gamas más bajas, todos los componentes tienen su lugar justo, entran perfecto, sin hacer fuerza, viene todo detalladamente explicado y con lucecitas por todos lados indicando el estado de cada componente, facilitando cualquier tipo de troubleshooting sobre fallas del hardware.
Un punto más a favor de los servidores (hablando de gama media-baja para arriba) es que soportan tecnologia hot swap. Esta tecnología permite insertar, cambiar y actualizar dicos, memorias y fuentes en caliente, sin apagar el servidor, logrando cero downtime, permitiendo 100% de disponibilidad ante fallas.
Por esto se dice que los servidores estan preparados para lograr alta disponibilidad.
Vienen de fabrica pensados para lograr la redundancia de componentes, permitiendo usar doble fuente, varios discos y por sobre todos muchos slots de memoria y slots de procesadores.

Estos puntos y otros más hacen que la balanza de la elección Servidor VS. PC se incline hacia el lado del Servidor.

Y todo esto se consigue a precios más que accesibles.

Un breve ejemplo:

*Una Pc con mother intel, procesador Intel Quad Core, 2 gb ddr2 non-ECC, 2 discos sata 320gb y gabinete bien refrigerado con fuente de marca, cuesta alrededor de 700 USD + IVA

*Un servidor Proliant ML 110/115 (La gama más baja de los servidores HP) Procesador Xeon u Opteron, 2 gb ddr2 ECC, 2 discos sata 320 gb, cuesta alrededor de 650 USD + IVA

Queda a la vista que a nivel precio es conveniente el servidor y a nivel beneficios obtenidos también.


Leo Huarita
Soporte Tecnico de PC y Servidores

IPConfig /FlushDns vaciando la cache de resolucion de nombres del cliente (DNS)

Muchas veces nos encontramos ante la imposibilidad de acceder a algun host de nuestra red o de internet.
Si el problema es general de la red y no somos administradores no hay mucho para hacer más que esperar, pero si la red no tiene problemas aparentes, puede que el problema este localizado en nuestro equipo local.
Cada vez que visitamos una página web o nos conectamos a alguna pc de la red local a través de su nombre, Windows coloca información de la conexión en cache, para que la próxima vez la conexión sea más rápida.
Cuando el intento de conexión falla porque el host esta caido o por un problema de red o por lo que sea, se guarda en la cache, una entrada NEGATIVA.
Si esta entrada NEGATIVA, no es correctamente vaciada, o la página del host es de nuevo accesible y en nuestra cache se encuentra todavia la entrada NEGATIVA. Veremos un error de DNS.
Entonces, ante esta situación podemos ir a Inicio-Ejecutar y escribir CMD.
Una vez en la consola de DOS tipeamos ipconfig /flushdns y le damos enter.
Después de un segundo recibiremos un mensaje de "vaciado con éxito", y luego de esto, ya podemos probar nuevamente el acceso a la página o host.
Si queremos verificar si realmente la cache DNS local, fue vaciada, podemos tipear en la consola de DOS el siguiente comando: ipconfig /dispalydns.
Si el resultado no muestra entradas efectivamente la cache fue vaciada.

En el caso de que no querramos que se almacene una cache local de resolución de nombres, solo debemos detener el servicio DNSCache, desde una consola de DOS, podemos hacerlo tipeando Net Stop DNSCache.

Hay que tener en cuenta que deteniendo este servicio, la performance en el uso de la red disminuye y el tráfico aumento, debido a que todas las consultas son hechas a los DNS de la red.

Una forma de hacer que de forma permanente no se guarden entradas negativas es modificando una clave el registro:
Debemos ir a Inicio-Ejecutar y tipear Regedit.exe, dentro de Regedit buscamos la siguiente clave HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Dnscache\Parameters le hacemos click y en el panel derecho creamos un nuevo valor DWORD (haciendo botón derecho del mouse)
A este nuevo valor le asignamos la siguiente información:
Nombre: MaxNegativeCacheTtl
Base: Hexadecimal
Información del valor: 0 (si ponemos algún otro valor, se tomará este valor como la cantidad de segundos que durará la entrada negativa en la cache local de resolución de nombres.
Aceptamos y salimos del Registro de windows y listo.

Leo Huarita
Soporte Tecnico de PC y Servidores

Backup de la base de datos de DHCP?

Por lo general los administradores de servidores solemos conformarnos con el backup general diario o semanal que se realiza sobre los servidores.... pero si hilamos fino y queremos tener una repuesta muy rapida ante fallas eventuales podriamos tomarnos unos minutitos para hacer backup de "items" en particular como puede ser el servicio DHCP, para no tener que recurrir al tape donde se encuentra TODO el backup, ya que por lo general se demora bastante en recuperar información de este tipo de soporte.

Por eso es importante saber qué backupear para tener tolerancia a fallos y a parte reaccionar rápidamente.
Por defecto , el servicio de DHCP, automaticamente hace un backup de la base de datos DHCP y las entradas relacionadas de registro, cada 1 hora.
Este backup es almacenado en \%Systemroot%\system32\DHCP\Backup\ (esta ubicación puede ser modificada).
Entonces manualmente o a través de un script se puede copiar los archivos backupeados automaticamente por el servicio DHCP en una ubicación offline.

Veamos como son las circunstancias relacionadas a la restauración de la base DHCP:

*Siempre que el servicio DHCP inicia, se intenta cargar de la base de datos, pero si esta no es capaz de cargar, el servicio DHCP automaticamente restaura el backup automático.
*En cambio si las bases de datos fallan, se puede optar por restaurar desde un directorio de backup o desde una ubicación offline.
*Y como última opción si el hardware donde la base se encuentra falla, y por ende el backup local automatico no esta disponible, solo se puede restaurar desde una ubicación offline.

Ahora veamos como se hace:
Para cambiar la ubicación del backup debemos hacer lo siguiente:
Ir a la consola de administración de DHCP, seleccionar el servidor, ir al menu action y hacer click en properties, luego en la pestaña Advanced, en el campo Backup Path, debemos escribir la nueva ruta y aceptar.

Para hacer el backup de la base de datos DHCP manualmente debemos hacer lo siguiente:
Ir a la consola de administración de DHCP, seleccionar el servidor, ir al menu action y hacer click en Backup, luego en la ventana emergente, en el campo Browse for folder, seleccionar la ruta y aceptar.

Para restaurar la base de datos DHCP manualmente debemos hacer lo siguiente:
Ir a la consola de administración de DHCP, seleccionar el servidor, ir al menu action y hacer click en Restore, luego en la ventana emergente, en el campo Browse for folder, seleccionar la ruta donde se encuentra el backup y aceptar, en la ventana emergente aceptar la petición de STOP y RESTART del servicio DHCP y luego de que termine el proceso presionar la tecla F5 para refrescar la pantalla.

Leo Huarita
Soporte Tecnico de PC y Servidores

Porque usar DHCP (Dynamic Host Configuration Protocol)?

Esta es una pregunta que se suelen hacer algunos administradores de pequeñas redes (+-10 PCs).
Y la respuesta es sencilla, en redes basadas en TCP/IP (la gran mayoria) DHCP reduce la cantidad y complejidad de la tarea administrativa de la configuración de red.
En muchas empresas no implementan DHCP, por desconocimiento o por la creencia de que es más sencillo trabajar sin este protocolo.
Repasemos:
suponiendo que una empresa tiene 10 PCs y un servidor, y el adminsitrador no usa DHCP, entonces se entiende que tuvo que configurar la dirección ip, gateway, mascara y dns manualmente en cada pc (y si es prolijo y previsor, hacer la documentación adecuada).
Una vez hecho esto en teoría se termina, la manipulación de esta configuración.
Pero ahora la pregunta es, que pasa si el DNS cambia, entonces tendremos que ir PC por PC y manualmente hacer el cambio.
Y si ingresa un nuevo puesto de trabajo y no tenemos documentada la información de configuración de ip de cada PC, tendremos que configurar una IP, al voleo, pensando en que no se repita con alguna ya asignada, o lo que es peor, ir maquina por maquina para ver cuales estan usadas y cuales no.
Ademas el tipear a mano todos los datos necesarios puede traer aparejado un error de tipeo.
Entonces... Si configuraramos el servicio DHCP Server, y lo configuraramos una vez (no demoramos más de 5 minutos) este servicio se encargaría de otorgar la información de configuración a cada cliente DHCP, incluidos los nuevos, y este servicio verifica antes de asignar las ip que no esten en uso :D.
Ademas nos ofrece una consola de administración fácil e intituiva para administrar, y nos da algunos datos adicionales útiles.


Por ende queda claro que este servicio es muy útil en ambientes de variado tamaño, incluyendo ambientes chicos.

Leo Huarita
Soporte Tecnico de PC y Servidores

Reseteo de passwords/contraseñas y cuentas en Active Directory (AD)

Sin dudas el reseteo de passwords y el reseteo de cuentas de equipo son tareas muy habituales en la administración de un servidor Windows con Active Directory instalado.
Veamoslas:

Reseteo de Passwords de usuarios

El password de un usuario se resetea cuando es olvidado (también cuando queremos sacarle el acceso al dominio, pero para esto hay otras formas)
Una vez que reseteamos el password, el usuario ya no podrá acceder a:
* mails encriptados con clave pública.
* passwords de internet que hayan sido guardados en el equipo.
* archivos encriptados.

Debemos tener en cuenta que solo usuarios de nivel administrador o con los privilegios adecuados pueden resetear passwords.

Uno de los procedimientos a seguir para el reseteo del password del usuario es el siguiente:
Ir a administrative tools - Active Directory Users and computers.
Dentro de la consola, buscamos dentro del árbol de objetos, al objeto Users le hacemos botón derecho y elegimos la opción Reset Password en la ventana emergente, en los campos de new password y confirm new password escribimos el nuevo password y damos OK.


Reseteo de cuentas de equipo

Resteamos la cuenta del equipo en dos ocaciones:
* cuando el password necesita ser sincronizado.
* cuando el equipo no puede autentificarse en el dominio.

Entre un equipo unido a un dominio y el domain controller existe un canal de seguridad de comunicación, el cual lleva una contraseña secreta la cual cambia cada 30 días. Esta contraseña se encuentra en ambos extremos (en el equipo y en el domain controller) por ende para que el acceso al equipo dentro del dominio tenga exito estas contraseñas deben estar sincronizadas.

Ahora bien, suponiendo que tenemos una politica de backup de 7 días, y que un equipo tuvo problemas con su disco rígido y quedo no funcional, si el password del canal de seguridad cambio luego del ultimo backup y antes de que el disco rígido se haya dañado, el backup tendría almacenada una contraseña no sincronizada con la contraseña que se encuentra en el controlador de dominio, ya que habiamos dicho que esta habia cambiado luego del backup.
Una vez el equipo puesto funcional y habiendose restaurado el backup, será incapaz de logearse en el dominio. Porque los passwords no estan sincronizados.
Este es un caso típico en el cual se resetearía la cuenta de equipo.

Uno de los procedimientos para resetear la cuenta del equipo es el siguiente:
Ir a administrative tools - Active Directory Users and computers.
Dentro de la consola, buscamos dentro del árbol de objetos, al objeto Computers o el contenedor que contenga la cuenta del equipo, le hacemos botón derecho y elegimos la opción Reset Account, en la ventana emergente aceptamos y listo.
No debemos olvidar que debemos rejoinear el equipo al dominio.

Leo Huarita
Soporte Tecnico de PC y Servidores

Bienvenidos!

Les damos la bienvenida a nuestro nuevo blog y damos por iniciada nuestra vida en el mundo 2.0.
Abrimos este nuevo espacio para contarles proyectos, analizar productos, y comentar temas de interés en nuestra vida como informáticos.
Intentaremos dar una visión objetiva y completa de todos los temas, y los invitamos a participar activamente en este nuevo espacio para que juntos podamos crecer y aprender.
Se dice que la mejor forma de aprender es en la práctica, así que manos a la obra!

Leo Huarita
Soporte Tecnico de PC y Servidores