Category: Troubleshooting


En este muy pequeño post, veremos un comando para eliminar archivos con una extension determinada (por ejemplo .bak) o todos los archivos de una carpeta , discriminandolos por su antiguedad. En el ejemplo veremos, eliminar todos los archivos .Bak con mas de 30 dias.

FORFILES /P C:\backups-sql\ /S /M *.bak /D -30 /C "cmd /c del @file"

/S – Busca en Subdirectorios

*.bak  – Busca todos los archivos con la extension .bAK, si queremos eliminar todos, sin importa la extensión,  usaremos *.*

/D -30 = Colocamos la cantidad de días que queremos que tengan como minimo un archivo de antigüedad.

/C – El comando el cual queremos correr respecto a los archivos seleccionados

Espero que les sea de utilidad

En este post  empezaremos a tratar  de explicar las consultasy modficiiones del Active Directorya traves de linea de comandos, de esta manera obtendriamos varias ventajas como  poder simplificar la administracion del mismo ademas de poder obtenerinformacion que no podriamos obtener del entorno grafico. Con este metodo hasta podriamos crear cientos de usuarios, con sus respectivos, permisos, contrasenas importandolas de un  Excel, realizar inventarios de las pcs en segundos, crear listas segun que sistema operativo tienen….entre muchisimas otras cosas…

.

Para comenzar un poquito de teoria

DSQUERY

Es una Consulta al AD mediante el uso de criterios de búsqueda . Cada uno de los comandos dsquery encuentra objetos de un tipo de objeto específico, con la excepción de dsquery *, que puede consultar cualquier tipo de objeto

Dsquery es una herramienta de línea de comandos que está integrado en Windows Server 2008. . Para utilizar dsquery, debe ejecutar el comando dsquery desde un símbolo del sistema con privilegios elevados. Para abrir un símbolo del sistema con privilegios elevados, haga clic en Inicio, haga clic en Símbolo del sistema y, a continuación, haga clic en Ejecutar como administrador.

.

REDIRECCION CON | (PIPE)
Puede redireccionarse el resultados de las  DSQUERY a por ejemplo DSMOD con el fin de modificar un objeto.

Veamos un ejemplo simple:

“‘C:\> dsquery computer -inactive 4″” Con este comando consultamos todas las pcs que estuvieron inactivas las ultimas 4 semanas

“‘C:\>dsmod computer * -disabled yes”” COn este comando reemplazando el * por el “”nombre” de una pc, podriamos desactivarla la computadora en cuestion.

Bueno ahora utilizaremos el | (pipe)

C:\> dsquery computer -inactive 4 | dsmod computer -disabled yes

Que estamos diciendo con este comando? Traeme todas las pcs que estuvieron inactivas en las ultimas semanas, el Pipe realiza la redireccion del ID de todas estas pcs al segundo comando que es dsmod (comando que sirve para modificar un atributo de obetos) y las deshabilita.

DSGET

Muestra las propiedades de un equipo en el directorio. Hay dos variaciones de esta orden. La primera variación se muestran las propiedades de varios equipos. La segunda variación muestra la información de la pertenencia a un solo equipo.

Ejemplo, poder ver la descripcion de todas las computadoas que comienzan con marketing de la ou ventas.

dsquery computer OU=ventas,DC=Argentina,DC=Com -name marketing* | dsget computer -desc

.

Bueno despues de la teoria seguimos con mas teoria 😦

Dsquery computer

Syntaxis
      DSQuery Computer [{StartNode | forestroot | domainroot}]
         [-o {dn | rdn | samid}]  [-scope {subtree | onelevel | base}]
            [-name Name] [-desc Description] [-samid SAMName] [-inactive NumberOfWeeks]
               [-stalepwd NumberOfDays] [-disabled]
                  [{-s Server | -d Domain}] [-u UserName] [-p {Password | *}]
                     [-q] [-r] [-gc] [-limit NumberOfObjects] [{-uc | -uco | -uci}]

Key
   StartNode | forestroot | domainroot  The node in the console tree where the search starts.
                                        forestroot = search using the global catalog. 

   -o           The format used to display the search results.
                dn = distinguished name.
                rdn = relative distinguished name.
                samid = Security Accounts Manager (SAM) account name.

   -scope       The scope of the search:
                subtree = subtree that is rooted at the start node in the console tree.
                onelevel = immediate children of the start node only.
                base = single object that the start node represents.
                If forestroot is the StartNode, then subtree is the only valid scope. 

   -name        Search for computer(s) whose name attribute(CN) matches Name.
                For example, "br*"

   -desc        Search for computer(s) whose description matches. For example, "dell*"

   -samid       Search for computer(s) whose SAM account names match SAMName

   -inactive    Search for computer(s) that have been inactive for N number of weeks

   -stalepwd    Search for computer(s) whose passwords have not changed for n number of days.

   -disabled    Search for computer(s) whose accounts are disabled.

   -s       Server to connect to (Default=the domain controller in the logon domain.)
   -d       Domain to connect to.

   -u       Username with which the user logs on to a remote server.
   -p       Password     (UserName or Domain\UserName or Username@domain.com)

   -q       Quiet, suppress all output
   -r       Recursive search (follow referrals)
   -gc      Use the AD global catalog during the search.
   -limit   The maximum number of objects to return, default=100.

   -uc      Unicode format
   -uco     Unicode format for output only
   -uci     Unicode format for input only

.

Bueno vayamos a la parte divertida

Ejemplos:

En contrar todas las pcs que comienzan con ventas, suponiendo que la tenemos nombradas por sector ventas01, ventas02…

C:\> dsquery computer -name ventas*

Encontras todas las computadoras de la ou(unidad organizativa) Mendoza.

.

C:\> dsquery computer ou=Mendoza,ou=Workstations,dc=argentina,dc=com

.

Encontrar pcs con 4 semanas de inactividad:

C:\> dsquery computer -inactive 4

.

Encontrar las pcs con 4 semanas de inactividad y deshabilitarlas:

C:\> dsquery computer -inactive 4 | dsmod computer -disabled yes

.

Estos comandos pueden sernos muy utiles para poder realizar inventarios, ahorrandonos muchisimo tiempo 🙂

.

dsquery computer -name * | dsget computer -samid

Que le esstmos pidiendo? Que nos traiga todas las pcs, no importa cual sea el nombre y que nos devuelva el samid (nombre en la sam, por ejemplo servidor1)

.

COmo podemos exportar esto a un Notepad, excel?

dsquery computer -name * | dsget computer -samid > c:\pclist.txt

Agregandoles “”> c:\*.txt” nos exporta el resultado a un archivo de texto. >)

.

Obtener un listado de las computadoras segun que sistema operativo tienen

dsquery * domainroot -filter “(&(objectCategory=computer)(operatingSystem=Windows Server*))” | dsget computer -samid

Donde dice windows server *, podemos cambiarlo por ”windows seven” o “”windows xp””

.

Bueno esto es todo por hoy, espero que les haya sido de utilidad,  se puede consutar casi cualquier cosa del AD, les dejo un enlace a microsoft para que sigan investigando:

http://technet.microsoft.com/en-us/library/cc754340%28WS.10%29.aspx

Estan activados mis equipos de la red?

Existen 2 tipos de activaciones:

  •  MAK (Múltiple Activation Keys) Que se activan directamente contra el servidor de Microsft
  •  KMS (Key Management Service), para lo que deberíamos definir el servidor interno. 

Para mas info: Volume Activation en la TechNet Library

La instalación de claves y activación remota pueden hacerse con ayuda del script SLMGR.VBS, en particular:

  • slmgr.vbs <equipo remotorio> <contraseña> –ipk >clave de producto>
  • slmgr.vbs <equipo remotorio> <contraseña> –ato

Pero a medida que crece la infraestructura  va creciendo se complica: la gestión remota, el inventariado y la monitorización del estado de los sistemas y su estado de activación:

La VAMT 2.0 nos permite en minutos, hacer consultas a del estado de nuestros equipos, por conjunto de IPs, Directorio Activo, Grupo de trabajo o repositorio LDAP, y almacenar las claves de los productos para usarlas en caso de tener que instalarlas y activarlas remotamente::

image

Hacemos una consulta al dominio para obtener el estado de todos los equipos:

image

Obtenemos que algunos equipos no están correctamente activados:

image

Seleccionamos uno de ellos, le introducimos la clave correspondiente de las que tenemos almacenadas;

imageimage          image

y lo activamos de manera remota:

image

Sin título

Mas información:

Se vera en un ambiente de dominio con Windows Server 2008R2 y Windows 7, donde se desarrollará una configuración simple demostrando el uso de la tan desaprovechada Asistencia Remota, para que que el personal de soporte de usuarios pueda ver y tomar control remoto de máquinas de usuarios y solucionar problemas remotamente. Y sin utilizar aplicaciones de terceras partes.

El motivo por el cual menciono que esta potente opción es tan desaprovechada, se debe principalmente a la complejidad de la implementación inicial, según la cual el usuario que necesita ayuda debía entrar en la Ayuda del sistema y crear una Invitación que luego debía enviar por correo, Messenger o dejar en una carpeta compartida, donde el soporte debía acceder.

Con el procedimiento que demostraremos alcanza con que el usuario pida ayuda al soporte de cualquier forma humana de comunicarse, ya sea telefónicamente o cualquier otro medio.

Tanto los nombres de máquina utilizados como las direcciones IP pueden ser cambiados con tal que se respete el procedimiento. La configuración inicial de partida es muy simple, ya que se trata de un Controlador de Dominio Windows Server 2008R2 Enterprise Edition, y dos clientes Windows Vista 7 Ultimate unidos al dominio.

1.- Procedimientos Iniciales

En el controlador del dominio  en nivel funcional Nativo Windows 2008R2. Igualmente el nivel funcional del Bosque. Por supuesto, tiene instalado el servicio DNS y es Catálogo Global ya que es el único controlador de dominio del dominio en un único Bosque.

Preparación de la Estructura del Dominio

  • Abrimos Active Directory Users and Computers
  • Creamos una Unidad Organizativa “Clientes” donde tendremos la cuenta de máquina “cl1” que recibirá el soporte y una cuenta de usuario normal que pedirá luego ayuda, y yo llamaré “User Uno” . Esta cuenta de usuario podría estar creada en otra Unidad Organizativa

  • Creamos otra Unidad Organizativa “Soporte” donde crearemos la cuenta de máquina “cl2” desde donde se brindará el soporte
  • Dentro de esta última Unidad Organizativa, creamos una cuenta de usuario normal, que para este caso yo llamaré “Soporte Uno”  y un grupo global que yo llamaré “SoporteUsuarios-GG”. El usuario “s1″ pertenece al grupo “SoporteUsuarios-GG” Este usuario y el grupo podrían estar en cualquier otra Unidad Organizativa

Creación y Configuración de Directiva de Grupo para Asistencia Remota No Solicitada

  • Desde Group Policy Management creamos una directiva enlazada a la Unidad Organizativa Clientes, que yo llamaré “Clients-GPO” y configurando las siguientes opciones
    • Computer Configuration / Policies / Administrative Templates / System / Remote Assistance
      • Solicited Remote Assistance: Enabled
        Offer Remote Assistance de acuerdo a la figura

Verificación de Configuración por Omisión y Aplicación de Directivas

  • Debemos verificar que en “cl1” está permitida la Asistencia Remota; esto es así por omisión

  • Como medida precautoria debemos estar seguros que cada cuenta de máquina se encuentra en la respectiva Unidad Organizativa, y además que está recibiendo la directiva de grupo, por lo cual no es mala idea que reiniciemos el equipo “cl1”.

2.- Demostración

Para esta demostración, vamos a suponer que User Uno tiene dificultad en ejecutar una tarea y se comunica telefónicamente con Soporte  para que lo asista.

Desde “cl2” que es donde está trabajando Soporte Uno, lo único que tiene que conocer es el nombre de máquina del usuario que pide ayuda, “cl1” en nuestro caso. A partir de ese momento, en el cuadro de búsqueda del menú inicio escribeMSRA y ejecuta Microsoft Remote Assistance, seleccionando las opciones:

  • Help someone who has invited you
  • Advanced conection option for help desk (es un enlace)
  • Ingresar el nombre del equipo al cual se quiere acceder
  • En el equipo que solicita ayuda, en nuestro caso “cl1” se mostrará un cuadro de diálogo, preguntando si deja acceder al soporte a ver el escritorio
  • A partir que el usuario acepte que el soporte vea el escritorio, éste podrá observar en forma directa la pantalla del otro equipo
  • Y si fuera necesario, puede tomar control remoto del mismo, previa aprobación del usuario
Material de: Guillermo DelPlato

Muchas veces necesitamos una metodología para solucionar los problemas de nuestros clientes. Hace algunos años atrás, miembros del grupo de soporte de escalación para Latinoamérica se reunieron y crearon una metodología que usa las mejores prácticas basadas en la experiencia del grupo y en el método científico para la solución de problemas.

Son varios los beneficios que se obtienen al utilizar una metodología para solucionar los problemas, entre ellos llegar a una solución lo más rápido posible. Hemos querido compartir con todos nuestros clientes estas mejores prácticas para que sean aplicadas no solamente en los casos de soporte de Microsoft, sino en general en cualquier escenario de solución de problemas técnicos.

El método científico parte de la definición de un problema, crea una hipótesis, recolecta los datos necesarios, analiza estos datos, entrega un reporte de lo que en los datos se encontró y valida o rechaza la hipótesis.

Estos mismos conceptos los podemos aplicar como metodología para la solución de los problemas de soporte técnico. De esta manera surgieron las cuatro etapas utilizadas por los ingenieros del grupo de soporte de Microsoft de Latinoamérica.

Estas cuatro etapas son:

· Defining.

· Gathering.

· Analyzing.

· Fixing.

image

Fig. 1. Metodología de resolución de problemas

Estas están representadas en la figura 1. Su representación es cíclica porque el proceso de resolución se mueve a través de las cuatro fases en secuencia con el objetivo de que en cada interacción el problema sea acotado más y más hasta llegar a la solución. La recomendación es seguir las fases en secuencia y no omitir ninguna.

Es muy difícil llegar al lugar a donde queremos ir si no definimos cual es dicho lugar. El proceso de resolución de problemas debe siempre comenzar con la definición del problema. A continuación vamos a hablar de cada una de las etapas en detalle.

Fase 1: Defining (Definición)

El primer paso es elaborar una buena definición del problema. Depende de cómo definamos el problema, va a ser más fácil o más difícil solucionarlo exitosamente. La definición del problema nos ayuda a definir también el criterio de solución del mismo. Esto es lo que llamamos scope del problema.

A menos que el problema este correctamente definido, es poco probable que sea encontrada una solución satisfactoria.

Existen varias técnicas que pueden ser utilizadas durante esta etapa y que ayudan a nuestros ingenieros a definir un problema, entre ellas tenemos:

· Escuchar activamente.

· Realizar preguntas precisas.

· Parafrasear.

El objetivo es capturar la mayor cantidad de detalles e información que nos ayude a definir el problema de una manera precisa.

Con base en la definición del problema y el conocimiento de cómo el producto debería funcionar, el siguiente paso  es crear una hipótesis acerca de que podría ser la causa del problema.

Recordemos que una hipótesis es una declaración que aún no se ha establecido como cierta. En el caso de los ingenieros de soporte, diríamos que es una aproximación educada basada en experiencia, conocimiento, habilidades e intuición.

El crear una hipótesis nos ayuda a darle un enfoque a nuestro pensamiento y continuar con las siguientes fases.

La fase de defining o definición, nos debe dar como resultados:

· Una definición clara del problema.

· El criterio bajo el cual se define la solución del problema.

· Una o más hipótesis.

Fase 2: Gathering (Recolección)

Con base en la hipótesis creada, ahora sí podemos comenzar a recolectar los datos que son necesarios para comprobar o refutar la hipótesis. Muchas veces tendemos a capturar información sin antes haber definido el problema y puede ser frustrante invertir tiempo en recolectar información que no será usada. El primer objetivo de esta fase es definir un plan de acción efectivo para la recolección de los datos de tal manera que todos los datos necesarios sean recolectados en la primera vez. El segundo objetivo de esta fase es garantizar que la calidad de los datos es óptima antes de pasar al análisis.

Un buen plan de acción debe ser detallado, incluir información específica de lo que se necesita y si es el caso, incluir explicaciones detalladas de como recolectar la información. Actualmente existen herramientas de soporte remoto que facilitan esta labor, caso que se necesite de ayuda para recolectar los datos.

Después de definir el plan de acción de cuales datos se necesitan y cómo van a ser recolectados, el siguiente paso es recolectar dicha información siguiendo el plan creado. Una buena práctica es tomar una pequeña muestra de los datos para estar seguros que se está recolectando correctamente. Un ejemplo de este escenario son los logs del performance monitor. Se puede tomar una muestra por un periodo corto de tiempo para garantizar que los contadores están trabajando como se espera.

Antes que los datos sean analizados deben ser validados. La validación consiste en responder las siguientes preguntas:

· ¿Es leíble la información? Por ejemplo un dump de memoria. El cliente puede revisar que es válido antes de enviarlo al ingeniero usando herramientas como el dumpchk.exe.

· ¿Los datos contienen información relevante? Por ejemplo en una captura de red. El cliente puede revisar con en Network Monitor que la captura incluye tráfico entre las maquinas relevantes al problema.

Estas pequeñas acciones evitan invertir tiempo innecesario tanto del cliente como del ingeniero.

La fase de gathering o recolección, nos debe dar como resultados:

· Un plan de acción detallado para recolectar los datos necesarios.

· Validación de los datos recolectados.

Fase 3: Analyzing (Analisis)

El objetivo de esta fase es analizar la información recolectada en la fase anterior. Esta información es estudiada para confirmar o rechazar la hipótesis o hipótesis generadas en la primera fase.

Analizar el problema implica aprender sobre el mismo lo más que se pueda. En esta fase la experiencia en el tema es crítica así como también las herramientas usadas para el análisis.

Dentro de las acciones que un ingeniero de soporte realiza durante esta fase de análisis están:

· Separar los datos que son relevantes para el análisis basado en la definición del problema y en el conocimiento y experiencia sobre el tema.

· Buscar por evidencia obvia primero antes de invertir tiempo en un análisis más profundo. Para clarificar este punto, un ejemplo es revisar los logs de Event Viewer antes de tomar un dump completo de la máquina.

· Buscar por contenido ya existente en las bases de datos de conocimiento. Nuestros clientes podrían realizar este paso buscando en el sitio de soporte de Microsoft y también revisando sus bases de datos de problemas internos.

· Realizar un análisis más profundo. Esto es, investigar los datos recolectados en detalle, intentar reproducir el problema, comparar los datos recolectados con relación a un ambiente que esté trabajando normalmente.

Como resultado de este análisis, debemos ser capaces de confirmar la hipótesis, hay suficiente evidencia que confirme la hipótesis y soporte un diagnostico; o por el contrario tenemos que rechazar la hipótesis.

En caso que la hipótesis sea rechazada, tendremos que comenzar un ciclo, esto es, ir a la fase de definición nuevamente. En este punto se debe considerar colaboración o escalación del problema al siguiente nivel.

La fase de analyzing o análisis, nos debe dar como resultados:

· Hipótesis confirmada por el análisis de los datos.

· Resultado del análisis de los datos.

· Posible causa raíz identificada.

· Comunicación a nivel de las personas involucradas informando el progreso.

Fase 4: Fixing ( Solución)

En esta fase con base al análisis realizado previamente, necesitamos elaborar un plan de acción para solucionar el problema. Este plan de acción de solución debe considerar el impacto y los riesgos de las acciones sugeridas. De ser necesario se recomienda probar el plan de acción en un ambiente de pruebas y de no ser posible, incluir las medidas necesarias tales como tener un respaldo (backup), planes de contingencia, en caso que el plan de acción deba ser aplicado directamente a producción.

Como mejores prácticas para la solución de problemas técnicos, la experiencia nos enseña a:

· Si hay varias maneras de solucionar el problema o una solución involucra varios pasos, aplicar un cambio cada vez y observar los resultados.

· Seguir los pasos de acuerdo a las instrucciones dadas y al orden recomendado.

· En caso de dudas sobre el plan de acción, preguntar antes de ejecutar.

Aquí podemos tener varias situaciones, que veremos a continuación.

· Si después de aplicar el plan de acción, los síntomas desaparecen, podemos considerar el problema como resuelto.

· Si el problema original está resuelto pero aparece un problema diferente, esto se debe manejar como un nuevo incidente de soporte e iniciar nuevamente con el ciclo de solución.

· Si el problema continúa, no hay cambio en los síntomas, debemos retornar a la fase de definición y comenzar nuevamente. Escalación al siguiente nivel debe ser considerara en esta situación.

· Si el problema empeora (esta condición es la menos deseada por supuesto!), escalación al siguiente nivel debe ser considerada a este punto.

La fase de fixing o solución, nos debe dar como resultados la solución al problema originalmente definido o la decisión de volver a la fase de defining o definición nuevamente; obviamente considerando la posibilidad de involucrar recursos adicionales que nos ayuden a llegar a una solución.

Esperamos que este contenido les sea de utilidad y les ayude a solucionar los problemas siguiendo esta metodología que hemos compartido con ustedes y que si de ser necesario tienen la necesidad de interactuar con nuestro grupo de ingenieros de soporte se les facilite el trabajo y puedan llegar a una solución satisfactoria en conjunto lo más rápido posible.