Desde hace un par de días ya está disponible el Release Candidate del Service Pack 1 para Windows Server 2008 R2 y Windows 7, en lo personal e utilizado la versión Beta los últimos meses y no he tenido problema alguno http://www.microsoft.com/downloads/en/details.aspx?FamilyID=c3202ce6-4056-4059-8a1b-3a9b77cdfdda
Que se diviertan!
October 31, 2010
October 30, 2010
Autoarchivado y retención de bitácoras.
Una de las cosas que más me gusta de Windows Server 2008 es el visor de sucesos, vaya que mejora ha sido!
Vamos a explorar el siguiente escenario, necesito almacenar todas las bitácoras de seguridad por 45 días, desde luego el proceso de recolección y eliminación debe de ser automatizados para que el esfuerzo de nuestra parte sea mínimo.
Entonces manos a la obra, vamos a ajustar un poco la configuración de los eventos de seguridad “WEvtUtil SL Security /RT:true /AB:true /MS:52428800 /LFN:D:\eventViewer-depo\Security.evtx”
Con esto estoy activando la retención por medio del archivado automático y estableciendo un límite de 50MBs por archivo de bitácoras (formato EVTX). Dichos archivos serán almacenados en la ruta y archivo que indique (D:\eventViewer-Depo\Security.evtx) [La ruta por defecto es %windir%\System32\wbem\Logs]
Listo, ahora si revisamos nuestra ruta de almacenaje deberíamos de encontrar unos archivos llamados Archive-Security*.EVTX y otros más. Para manejar esto de forma automática podríamos salvar las siguientes líneas en un archivo tipo BAT e invocarla con una tarea programada diaria.
@echo off
REM ### ~ daemonRoot@sysadmin-cr.com ###
REM ### Inicia búsqueda de archivos mayores a los 45 días ###
forfiles /P D:\eventViewer-Depo /S /M * /D -45 /C "cmd /c echo @path" > D:\eventViewer-Depo\toDelete.log
REM ### Se remueven los archivos encontrados con el criterio anterior ###
for /f %%a in (D:\eventViewer-Depo\toDelete.log) do del /Q %%a
REM ### Se procede a enviar un reporte por correo electrónico sobre el purgado, el cual nos indica los archivos eliminados y la ejecución exitosa de la tarea ###
sendEmail.exe -f monitoring@sysadmin-cr.com -t server-support@sysadmin-cr.com -u REPORTE: Purgado de archivos de evento -m El archivo adjunto contiene la lista de bitácoras eliminadas como parte del proceso de retención y limpieza –a D:\eventViewer-Depo\toDelete.log -s smtp.sysadmin-cr.com
REM ### Se borra el archivo con la lista de ítems eliminados ###
del /q D:\eventViewer-Depo toDelete.log
REM ### Tarea completa ###
Que diferente era hacer esto con Windows Server 2003… que lindo como evoluciona la tecnología!
Gracias por su tiempo.
Vamos a explorar el siguiente escenario, necesito almacenar todas las bitácoras de seguridad por 45 días, desde luego el proceso de recolección y eliminación debe de ser automatizados para que el esfuerzo de nuestra parte sea mínimo.
Entonces manos a la obra, vamos a ajustar un poco la configuración de los eventos de seguridad “WEvtUtil SL Security /RT:true /AB:true /MS:52428800 /LFN:D:\eventViewer-depo\Security.evtx”
Con esto estoy activando la retención por medio del archivado automático y estableciendo un límite de 50MBs por archivo de bitácoras (formato EVTX). Dichos archivos serán almacenados en la ruta y archivo que indique (D:\eventViewer-Depo\Security.evtx) [La ruta por defecto es %windir%\System32\wbem\Logs]
Listo, ahora si revisamos nuestra ruta de almacenaje deberíamos de encontrar unos archivos llamados Archive-Security*.EVTX y otros más. Para manejar esto de forma automática podríamos salvar las siguientes líneas en un archivo tipo BAT e invocarla con una tarea programada diaria.
@echo off
REM ### ~ daemonRoot@sysadmin-cr.com ###
REM ### Inicia búsqueda de archivos mayores a los 45 días ###
forfiles /P D:\eventViewer-Depo /S /M * /D -45 /C "cmd /c echo @path" > D:\eventViewer-Depo\toDelete.log
REM ### Se remueven los archivos encontrados con el criterio anterior ###
for /f %%a in (D:\eventViewer-Depo\toDelete.log) do del /Q %%a
REM ### Se procede a enviar un reporte por correo electrónico sobre el purgado, el cual nos indica los archivos eliminados y la ejecución exitosa de la tarea ###
sendEmail.exe -f monitoring@sysadmin-cr.com -t server-support@sysadmin-cr.com -u REPORTE: Purgado de archivos de evento -m El archivo adjunto contiene la lista de bitácoras eliminadas como parte del proceso de retención y limpieza –a D:\eventViewer-Depo\toDelete.log -s smtp.sysadmin-cr.com
REM ### Se borra el archivo con la lista de ítems eliminados ###
del /q D:\eventViewer-Depo toDelete.log
REM ### Tarea completa ###
Que diferente era hacer esto con Windows Server 2003… que lindo como evoluciona la tecnología!
Gracias por su tiempo.
October 09, 2010
E14-SP1 UR1!!!
Como habrán notado desde un par de días está disponible el Update Rollup 1 para el SP1 de Exchange 2010, en este artículo veremos cómo aplicarlo a un DAG.
Básicamente moveremos las base de datos a uno de los servidores, detendremos la activación de las bases de datos (también cuando aplique debemos detener ciertos servicios que podrían causar conflictos como el de Forefront), actualizamos, y regresamos todo a la normalidad.
Con el comando “Get-MailboxDatabase” veremos el listado de bases de datos.
Ahora bien, movamos la base de datos a un solo servidor, esto ejecutando el comando “Move-ActiveMailboxDatabase nombreDaseDatos –ActivateOnServer servidorDestino” y luego lo confirmamos con el primer comando.
De la siguiente manera podemos ver la política de activación de las bases de datos en el servidor llamado HADES (recuerda que las bases de datos están en AQUERONTE, no deseo que estas se activen en el servidor que voy a parchear):
[PS] C:\>Get-MailboxServer HADES | FL Name,DatabaseCopyAutoActivationPolicy
Name : HADES
DatabaseCopyAutoActivationPolicy : Unrestricted
Para desactivarla utilizaremos el siguiente CMDLET "Set-MailboxServer HADES -DatabaseCopyAutoActivationPolicy Blocked" (el parámetro "DatabaseCopyAutoActivationPolicy -Unrestricted" revierte el cambio).
Bien, ahora podremos aplicar el RU1 simplemente ejecutando el archivo MSU en que viene empaquetado, este procedimiento también aplica para el Service Pack, solo que la instalación de este debe de invocarse mediante el SETUP (para mayor información visite este enlace).
Por el momento el UR1 solo está disponible por descarga directa, se espera que para este Patch Tuesday esté disponible vía Windows Update.
Como toda instalación/actualización de Exchange esto debe de ejecutarse en orden alfabético según las funciones del servidor (CAS-1, HUB-2, MBX-3, UC-4).
Hasta pronto.
Básicamente moveremos las base de datos a uno de los servidores, detendremos la activación de las bases de datos (también cuando aplique debemos detener ciertos servicios que podrían causar conflictos como el de Forefront), actualizamos, y regresamos todo a la normalidad.
Con el comando “Get-MailboxDatabase” veremos el listado de bases de datos.
Ahora bien, movamos la base de datos a un solo servidor, esto ejecutando el comando “Move-ActiveMailboxDatabase nombreDaseDatos –ActivateOnServer servidorDestino” y luego lo confirmamos con el primer comando.
De la siguiente manera podemos ver la política de activación de las bases de datos en el servidor llamado HADES (recuerda que las bases de datos están en AQUERONTE, no deseo que estas se activen en el servidor que voy a parchear):
[PS] C:\>Get-MailboxServer HADES | FL Name,DatabaseCopyAutoActivationPolicy
Name : HADES
DatabaseCopyAutoActivationPolicy : Unrestricted
Para desactivarla utilizaremos el siguiente CMDLET "Set-MailboxServer HADES -DatabaseCopyAutoActivationPolicy Blocked" (el parámetro "DatabaseCopyAutoActivationPolicy -Unrestricted" revierte el cambio).
Bien, ahora podremos aplicar el RU1 simplemente ejecutando el archivo MSU en que viene empaquetado, este procedimiento también aplica para el Service Pack, solo que la instalación de este debe de invocarse mediante el SETUP (para mayor información visite este enlace).
Por el momento el UR1 solo está disponible por descarga directa, se espera que para este Patch Tuesday esté disponible vía Windows Update.
Como toda instalación/actualización de Exchange esto debe de ejecutarse en orden alfabético según las funciones del servidor (CAS-1, HUB-2, MBX-3, UC-4).
Hasta pronto.
October 05, 2010
Servidores nuevos, siiii!
Estamos en la fase de diseño de nuestros nuevos controladores, necesitamos comprender como se comporta el equipo actual para asi hacer nuestros pronósticos para el siguiente.
Con perfmon puedo crear un set de contadores como memoria, tiempos de lectura de la partición donde se aloja el NTDS.DIT y procesador, estos los salvo como un archivo HMT (Server 2003) o XML para crear un machote (a partir de Server 2008) y así los puedo reutilizar en otros equipos. Además puedo especificar que el output sea en formato CSV lo cual hará más fácil el proceso de datos en Excel.
Entonces con lo anterior puedo tener ciertos números aproximados de cuanta memoria necesito, si mi arreglo de discos y velocidad de estos es adecuado, también si necesito más procesadores, o tal vez alguno más poderoso.
También algo que nos puede ser útil es llevar un archivo histórico que refleje el comportamiento de la base de datos de AD, en el EventID 1646 podemos encontrar el tamaño de este, entonces podríamos analizar el crecimiento de este y junto con información sobre el crecimiento o proyecciones de la empresa podríamos calcular el espacio adecuado de los discos para almacenarlo. También en la sana teoría es óptimo poder cargar nuestro AD en memoria, por lo cual saber su tamaño es muy importante.
Otros factores como futuras implementaciones o ampliaciones de servicios que dependen en AD nos pueden afectar, tal como Exchange que estará haciendo consultas continuas a AD, o el almacenaje de llaves de encriptación de BitLocker lo cual hará crecer el .DIT.
Recordemos que cambiar el hardware no es algo que se hace a menudo por lo cual además de lo que con nuestro método podamos prever debemos dar un espacio de error y desde luego calcular cuántos años pretendemos utilizar el equipo nuevo.
Como siempre, esto no es una guía definitiva, son tan solo un manojo de ideas que espero les puedan ayudar, gracias por su lectura.
Con perfmon puedo crear un set de contadores como memoria, tiempos de lectura de la partición donde se aloja el NTDS.DIT y procesador, estos los salvo como un archivo HMT (Server 2003) o XML para crear un machote (a partir de Server 2008) y así los puedo reutilizar en otros equipos. Además puedo especificar que el output sea en formato CSV lo cual hará más fácil el proceso de datos en Excel.
Entonces con lo anterior puedo tener ciertos números aproximados de cuanta memoria necesito, si mi arreglo de discos y velocidad de estos es adecuado, también si necesito más procesadores, o tal vez alguno más poderoso.
También algo que nos puede ser útil es llevar un archivo histórico que refleje el comportamiento de la base de datos de AD, en el EventID 1646 podemos encontrar el tamaño de este, entonces podríamos analizar el crecimiento de este y junto con información sobre el crecimiento o proyecciones de la empresa podríamos calcular el espacio adecuado de los discos para almacenarlo. También en la sana teoría es óptimo poder cargar nuestro AD en memoria, por lo cual saber su tamaño es muy importante.
Otros factores como futuras implementaciones o ampliaciones de servicios que dependen en AD nos pueden afectar, tal como Exchange que estará haciendo consultas continuas a AD, o el almacenaje de llaves de encriptación de BitLocker lo cual hará crecer el .DIT.
Recordemos que cambiar el hardware no es algo que se hace a menudo por lo cual además de lo que con nuestro método podamos prever debemos dar un espacio de error y desde luego calcular cuántos años pretendemos utilizar el equipo nuevo.
Como siempre, esto no es una guía definitiva, son tan solo un manojo de ideas que espero les puedan ayudar, gracias por su lectura.
October 01, 2010
WSUS en un RODC
Estaba yo trabajando con unas instalaciones en oficinas remotas, en uno de los casos necesitaba instalar un WSUS en mi único servidor, un RODC.
Al tratar de instalar mi WSUS obtuve el siguiente error:
CInstallDriver::PerformSetup: Installation of wYukon failed (Error 0x80070643: Fatal error during installation.)
Después de dar muchas vueltas y rascarme la cabeza note que en el contenedor Users existían dos grupos que por su descripción y tomando en cuenta el error anterior pues estos parecían estar ligados al WSUS, o al menos a la base de datos de este.
Entonces cree los grupos de seguridad con ámbito local, simplemente cambie hostName por el nombre de su servidor y listo.
SQLServer2005MSFTEUser$hostName$Microsoft##SSEE
SQLServer2005MSSQLUser$hostName$Microsoft##SSEE
Una vez que estos replicaron (repadmin /replicate serverDestino serverFuente DC=dominio,DC=com) al RODC la instalación fue exitosa.
Al tratar de instalar mi WSUS obtuve el siguiente error:
CInstallDriver::PerformSetup: Installation of wYukon failed (Error 0x80070643: Fatal error during installation.)
Después de dar muchas vueltas y rascarme la cabeza note que en el contenedor Users existían dos grupos que por su descripción y tomando en cuenta el error anterior pues estos parecían estar ligados al WSUS, o al menos a la base de datos de este.
Entonces cree los grupos de seguridad con ámbito local, simplemente cambie hostName por el nombre de su servidor y listo.
SQLServer2005MSFTEUser$hostName$Microsoft##SSEE
SQLServer2005MSSQLUser$hostName$Microsoft##SSEE
Una vez que estos replicaron (repadmin /replicate serverDestino serverFuente DC=dominio,DC=com) al RODC la instalación fue exitosa.
Este mismo truco funciona por ejemplo para instalar la consola administrativa del antivirus Kaspersky, acá se necesitan los siguientes grupos "SQLServer2005SQLBrowserUser$hostName", "SQLServer2005MSSQLServerADHelperUser$hostName" y el "SQLServer2005MSSQLUser$hostName$KAV_CS_ADMIN_KIT".
Estos originalmente son grupos locales, pero al ser esto un DC no hay SAM por ende la necesidad de crearos en AD.
Hasta pronto.
Estos originalmente son grupos locales, pero al ser esto un DC no hay SAM por ende la necesidad de crearos en AD.
Hasta pronto.
Subscribe to:
Posts (Atom)