Tag Archive: windows server


En este post veremos como configurar políticas de contraseñas granuladas por grupo o usuario. Por ejemplo si por políticas de seguridad necesitamos que el área de Ingenieros, tenga una contraseña mínima de 10 caracteres, que caduque cada 7 días, que solo se permitan 2 bad logons… Entre otras cosas

Para mas info: http://technet.microsoft.com/en-us/library/cc770842(WS.10).aspx

-Entramos a “Active Dirctory Administrative Center”

– Luego navegamos el Active directory seleccionamos un usuario y en la derecha seleccionamos “View Resultant Password Settings”

windows-server-password-policy-e-2012-ad-2012-000032

Nos responde que el usuario test no tiene asignada ninguna política de password granulada: windows-server-password-policy-e-2012-ad-2012-000033

Luego sobre la derecha expandimos el dominio en mi caso es morettimaxi.local luego vamos a “system”

windows-server-password-policy-e-2012-ad-2012-000034

Luego a “Password Setting COntainer”windows-server-password-policy-e-2012-ad-2012-000035

Seleccionamos new Password Setting

windows-server-password-policy-e-2012-ad-2012-000036

Por ultimo seleccionamos la política y en Directly apply to, colocamos el grupo al cual queremos que se aplique la política.windows-server-password-policy-e-2012-ad-2012-000037

Este es el primer Post sobre Windows Server 2012. Hace un tiempo que lo vengo probando pero estoy con poco tiempo para subir material.

Hoy veremos como activar la Papelera de Reciclaje para Elementos del AD de Windows server 2012.

EL primer Paso es abrir el ¨Active Directory Administrative center¨

windows-server-papelera-reciclaje-2012-ad-2012-000020

Para que funcione es necesario que el Domain  y el Forest level sea 2012, vamos a realizar el Raise:

windows-server-papelera-reciclaje-2012-ad-2012-000021

Nos dice que teníamos el nivel funcional del forest en 2008 r2, seleccionamos el Raise a 2012:

 

 

windows-server-papelera-reciclaje-2012-ad-2012-000024

 

windows-server-papelera-reciclaje-2012-ad-2012-000025

Seleccionamos  enable Recicly BIn

 

windows-server-papelera-reciclaje-2012-ad-2012-000026

 

Confirmamos windows-server-papelera-reciclaje-2012-ad-2012-000027

 

Nos pide que refresquemos la consola:

windows-server-papelera-reciclaje-2012-ad-2012-000028

 

Nos aparece “Deleted Objects” windows-server-papelera-reciclaje-2012-ad-2012-000029

Para verificar su funcionamiento, elimine un usuario llamado test y el mismo ahora aparece en la papelera:

windows-server-papelera-reciclaje-2012-ad-2012-000030

 

Para restaurarlo botón derecho y luego restore. windows-server-papelera-reciclaje-2012-ad-2012-000031

Con este comando de Powershell podran obtener un reporte de todas sus computadores y servidores y su sistema operativo, como asi tambien Services Packs y demas.

Get-ADComputer -Filter * -Properties * | Select-Object name, operating* | fl

Ejemplo de  Output:

name                       : SERVER2 OperatingSystem            : Windows Server 2003 OperatingSystemHotfix      : OperatingSystemServicePack : Service Pack 2 OperatingSystemVersion     : 5.2 (3790)

name                       : server3 OperatingSystem            : Windows Server 2008 R2 Enterprise OperatingSystemHotfix      : OperatingSystemServicePack : Service Pack 1 OperatingSystemVersion     : 6.1 (7601)

En este post veremos como con un entorno de Windows 2008 R2, poder unir una computadora al dominio sin conexión. Es decir no es necesario que exista conectividad entre el equipo y el Domain Controller .  Esto es ideal, cuando por ejemplo instalamos computadoras que luego seran enviadas a otra sucursal, site….

Este procedimiento puede ser llevado a cabo entre equipos con: Windows 7 y Windows 2008 R2, para poder realizarlos con DC anteriores a Windows Server 2008 R2  debe usarce el siguiente parámetro : /downlevel

1- EN el DC, deberemos crear la cuenta, con el siguiente comando:

djoin /provision /domain <domain_name> /machine <destination computer> /savefile <filename.txt> [/machineou <OU name>] [/dcname <name of domain controller>] [/reuse] [/downlevel] [/defpwd] [/nosearch] [/printblob]

Luego debemos copiar el archivo TXT , generado en el paso anterior, al equipo con Windows 7.

Y por ultimo ejecutar en WIndows 7 el siguiente comando:

djoin /requestODJ /loadfile blob.txt /windowspath %SystemRoot% /localos

En este post veremos, como redireccionar a una especifica OU, a las nuevas computadoras incorporadas al dominio.

Esto es  de gran utilidad, ya que  en el contenedor de default, no se pueden linkear group policies. Con este metodo , toda nueva computadora ,podra tener una gpo basica, hasta que se lo redirrecione (o no) a una OU definida.

Laboratorio:

DC: Windows Server 2008 R2

DOminio: morettimaxi.local

  1. Lo primero que tenemos que hacer es crear una OU,
  2. Luego saber el Distingueshed Name, el mismo lo encontramos en el “atribute Editor”

Luego abrimos un CMD, y colocamos la siguiente linea:

redircmp.exe “OU=Computers,OU=morettimaxi,DC=morettimaxi,DC=local”

De esta manera, todas las computadoras que agreguemos iran a la OU predefinida, donde por GPO, cumplira con los requisitos de seguridad de la empresa.

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

En esta se utilizará un ambiente de dominio con Windows Server 2008 y Vista, donde se desarrollará una configuración simple demostrando las posibilidades de NAP (Network Access Protection) en relación al servicio DHCP (Dynamic Host Configuration Protocol).

A tal fin se mostrará lo que sucede cuando se conecta a la red, un cliente que no cumple con los requerimientos de NAP, luego con un cliente que sí cumple, y por último con un cliente que cumple al conectarse, pero luego no tiene los requerimientos exigidos por la directiva de NAP.

Para esto dispondremos inicialmente de una infraestructura como muestra el siguiente diagrama:

Tanto los nombres de máquina utilizados como las direcciones IP pueden ser cambiados con tal que se respete el procedimiento.

NPS1 pertenece al dominio. En cambio, inicialmente, CL1 no pertenece al dominio existente.

Tanto en DC1 como en NPS1 vamos a deshabilitar el cortafuegos y deshabilitar Ipv6, para evitar que interfiera con los resultados de NAP.

El equipo NPS1 cumplirá ambas funciones (NPS y DHCP) para simplificar el desarrollo.

Introducción

El equipo NPS1 controlará determinadas configuraciones de seguridad de CL1, y de acuerdo al estado reportado, el servicio DHCP le suministrará diferentes parámetros de configuración limitando su conectividad.

Las configuraciones que el NPS puede controlar en el cliente Vista son:

·Cortafuegos instalado y funcionando

·Antivirus funcionando y actualizado

·Antispyware funcionando y actualizado

·Configuradas las actualizaciones automáticas

Las posibilidades de NPS sobre los clientes son:

·Acceso total

·Acceso limitado

·Acceso total por un tiempo limitado

Además existe la posibilidad de permitir al cliente el contacto con “Remediation Servers” que corrijan su configuración para cumplir con los requerimientos. En esta demostración, sólo por simplicidad, el Remediation Server será DC1

SHAs (System Health Agents): es el agente que se ejecuta en los clientes, que se encargará de reportar el estado del mismo

SHVs (System Health Validators): es el componente del NPS encargado de recibir los reportes del SHA del cliente y notificar al mismo

Health Policies: definen cuáles SHVs deben ser utilizados (DHCP, VPN, IPSec, etc.) para evaluar los SHAs enviados por el cliente, y cómo son estos considerados (cumple, no cumple o no es capaz de cumplir)

Network Policies: determinan condiciones, configuraciones y restricciones para determinar si puede conectarse a la red. Deben existir por lo menos dos: una para los que cumplen, y otra para los que no cumplen.

Connection Request Policies: son las condiciones y configuraciones que validan el requerimiento de acceso a la red

Remediation Server Groups: permite especificar un grupo de servidores que el cliente que no cumple podrá contactar, para poder corregir su configuración, y pasar al estado requerido.

Procedimientos Iniciales

DC1

Ya es controlador de dominio de “contoso.msft” en nivel funcional Nativo Windows 2003. 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.

Crearemos un grupo Global de Seguridad llamado “NAP Computers” que permitirá luego filtrar la aplicación de la GPO que hace las configuraciones necesarias en los clientes.

NPS1

Este servidor ya es miembro del dominio. Desde Server Manager instalaremos el servicio DHCP y NPS.

Instalación de DHCP y NPS en NPS1

Tener en cuenta que NPS es un componente de Network Policies and Access Services, y en el asistente de instalación marcar solamente Network Policy Server.

Dejaremos todos los valores por omisión, salvo:

Y lo siguiente:

Configuración de Network Policy Server

Abrimos Administrative Tools / Network Policy Server, y seleccionamos Configure NAP

Y luego

En este caso:

·No usaremos RAIDUS (Next)

·No hace falta especificar el scope de DHCP porque será el único

·Tampoco hace falta seleccionar grupos para esta demostración

·No seleccionemos Remediation Server, lo haremos luego

Verifiquemos que la pantalla de Health Validators esté así:

·Y seguir hasta llegar a Finish

Ahora configuraremos el SHV (System Health Validator)

·En la consola NPS, expandimos Network Access Protection y buscamos System Health Validators

Sobre la derecha (Detalles) hacemos botón derecho sobre Windows Security Health Validator y elegimos Properties y el botón Configure

Lo dejamos como se muestra en la figura, ya que para este ejemplo consideraremos sólo si el cliente tiene el cortafuegos activo.

·Notemos que hay una ficha específica para XP. Atención es para XP-SP3

·Cerramos las ventanas abiertas eligiendo Ok

Configuración de DHCP

Desde Administrative Tools abrimos la consola DHCP

Creamos un ámbito IPv4, yo lo llamaré NAP Scope con direcciones 192.168.0.50 al .99 con máscara de subred 255.255.255.0, tomando el resto de las opciones por omisión, salvo lo siguiente:

Simulación de un router para acceso a Internet por ejemplo

Y esta:

·Estas opciones son las que recibirán los clientes que cumplen con los requerimientos (Compliant)

Ahora configuraremos el Scope para su uso con NAP, para lo cual vamos a las Propiedades del Scope, y en la ficha Network Access Protection, seleccionamos Enable for This Scope

  • El paso siguiente es configurar las opciones que recibirán los clientes No-Compliant. Para esto, sobre Scope Options con botón derecho entramos a Configure Options, ficha Advanced y en User Class, elegimos Default Network Access Protection Class

·Para estos clientes elegimos, por ejemplo:

oEl mismo DNS (006): 192.168.0.1

oDiferente sufijo (015): “restricted.contoso.msft”

oY no le proporcionamos Router (003)

Finalmente quedará como muestra la figura

Configuración de GPOs para Clientes

No es la única posibilidad, pero lo haré configurando una GPO a nivel de dominio, y filtrándola para que aplique únicamente al grupo NAP Computers, y que llamaré NAP Settings Policy. Vamos entonces a DC1 y con Group Policy Management la creamos y configuramos.

Las configuraciones son:

·Computer Configuration / Policies / Windows Settings /Security Settings / System Services /

Network Access Protection Agent definido con Startup Automatic

·Computer Configuration / Policies / Windows Settings /Security Settings / Network Access Protection / NAP Client Configuration / Enforcement Clients /

DHCP Quarantine Enforcement Client configurado Enabled

·Computer Configuration / Policies / Administrative Templates / Windows Components / Security Center

Turn on Security Center (Domain PCs only) configurado en Enabled

Estas tres configuraciones nombradas, son necesarias, ya que el Security Center notifica, el Network Access Protection Agent por omisión no está arrancado, y el SHA (NAP Client Configuration) no está configurado.

Como configuración final de la GPO, modificamos su alcance para que se aplique únicamente al grupo NAP Computers.

Demostración de Funcionalidad NAP

Cliente que no está en el dominio (Grupo de Trabajo – Workgroup)

Primero vamos a ver qué sucede cuando se conecta a la red una máquina cliente que no forma parte del dominio, simulando el equipo de alguien externo a nuestra red. Recordemos que CL1 está en grupo de trabajo, con el cortafuegos bajo, y la siguiente configuración de red:

Procedimientos en CL1

Si hacemos un IPCONFIG /ALL observamos que

·El sufijo es “restricted.contoso.msft”

·No tiene configurado Default Gateway

·La máscara de subred es 255.255.255.255

Esta máscara de subred implica que cualquier dirección IP, la verá como remota, y como no tiene Default Gateway configurado, la consecuencia es que no podrá acceder a otro equipo.

Esto lo podemos verificar porque PING 192.168.0.1 no responderá.

Puede acceder únicamente a NPS1 (192.168.0.2) porque existe una Host Route específica que podemos ver si hacemos ROUTE PRINT -4

Además, tengamos en cuenta que como CL1 no pertenece al dominio, no le está aplicacando la GPO que hemos configurado, por lo tanto lo considera No-capable (que no es lo mismo que No-compliant)

Configuración de DC1 como Remediation Server

En NPS1 volvamos a la consola NPS:

·Seleccionemos Policies / Network Policies / NAP DHCP Non NAP-Capable, botón derecho Properties

·Ficha Settings, seleccionamos NAP Enforcement y botón Configure (para los Remediation Servers)

Creamos un nuevo Remediation Group y agregamos a nuestro Remediation Server. Elegí DC1 para simplificar la demostración

Ahora volvemos a CL1, hacemos un IPCONFIG /RELEASE, luego IPCONFIG /RENEW y vemos que ahora sí podemos hacer PING 192.168.0.1 que simula ser el Remediation Server.

Si hacemos un ROUTE PRINT vemos que se crea una host-route a DC1

Cliente del dominio

Ahora procedemos a unir a CL1 al dominio. El procedimiento es el habitual para unir máquinas al dominio. Para ahorrar tiempo, una vez unido el cliente al dominio, pero antes de reiniciar, incluyamos a CL1 en el grupo NAP Computers.

El valor por omisión del cortafuegos de Vista, es que esté activo, por lo tanto en este caso el cliente cumplirá con los requerimientos.

Una vez que CL1 arranca iniciamos sesión con CONTOSO\Administrator, abrimos el CMD.EXE y observamos que:

·Podemos hacer PING 192.168.0.1

·Podemos hacer PING 192.168.0.2

Y si hacemos IPCONFIG /ALL obtenemos:

·Observen el estado de System Quarantine State, Máscara de subred y Default Gateway. Noten además la salida de un ROUTE PRINT

·Si ejecutamos NETSH NAP CLIENT SHOW STATE podemos observar información detallada

Veamos ahora qué sucede si una vez que cumplimos con los requerimientos queremos dejar de cumplirlos. Para eso vamos a deshabilitar el cortafuegos en CL1

¿Pudieron? A que no pudieron, apenas lo ponemos en Off (Not recommended) y damos al botón Ok en el cuadro se vuelve a poner verde, y el cortafuegos se vuelve a habilitar. Eso lo está produciendo el Remediation Server (DC1)

Inclusive cuesta un poco verlo pero junto al reloj puede aparecer un icono que si lo pulsamos mostrará primero uno de las figuras que sigue y luego la otra.

Por último, veamos qué sucede si el Remediation Server no puede “remediar” el problema. Podemos hacer la prueba, poniendo como requisito que el cliente además del cortafuegos, tenga instalado un antivirus. En este caso DC1 no podrá solucionar el problema y CL1 quedará restringido.

En NPS1 abrimos la consola Network Policy Server, y vamos a Network Access Protection, System Health Validators y con botón derecho a las Properties de Windows System Health Validator, botón Configure y marcamos la opción de requerir un antivirus.

Luego en CL1 forzamos la renovación de dirección con IPCONFIG /RELEASE & IPCONFIG /RENEW, y vemos que junto al reloj, aparece el icono que avisa que no cumplimos con los requerimientos y si lo pulsamos, obtenemos:

Y además un IPCONFIG /ALL mostrará que el cliente está restringido:

Como en este caso, el Remediation Server no puede suministrar un antivirus, el cliente queda restringido.

Resumen

Hemos verificado que a través del uso de NAP con DHCP

·Cliente que no reconoce NAP

Queda restringida su comunicación en la red

·Cliente que reconoce NAP, y cumple los requerimientos

Tiene conectividad completa

·Cliente que reconoce NAP y no cumple los requerimientos

oSi se puede remediar, pasa a cumplir requerimientos

oSi no se puede remediar, queda restringido

Fuente: windowserver.wordpress.com (guillermo Del plato)

Que es Web Matrix?

WebMatrix es una nueva herramienta de desarrollo de Microsoft que incluye todo lo necesario para el desarrollo de sitios web. Comenzar a partir de aplicaciones web Open Source, plantillas predefinidas o simplemente empezar escribiendo código desde cero.  para mas info: http://www.microsoft.com/web/webmatrix/

 

-**-*-*-*-*

En  WebMatrix Beta  el sitio web por defecto, así como los nuevos que se crean están obligados a localhost. En otras palabras, solo se puede acceder de forma local.

image

La dirección que aparece arriba se puede editar para que pueda tratar de reemplazar localhost por el nombre del equipo (en mi caso vaidesg1 e). Sin embargo IIS Developer Express tirara un error ya que se que necesita derechos de administración :

image

 

Se peude evitar este eror reiniciando el WebMatrix como administrador, pero esto es una muy mala idea por razones de seguridad, especialmente para las páginas externas que expone. Entonces haremos lo siguiente:

Step 1 – Configure HTTP.SYS (requires elevation)

El archivo: HTTP.SYS es el componente del sistema operativo que tanto IIS e IIS Developer Express utiliza para manejar las peticiones HTTP. Por defecto, HTTP.SYS no permite una aplicación que se ejecuta como un usuario estándar para escuchar a través de la red. Es posible configurar de forma explícita HTTP.SYS para permitir el tráfico externo, como se muestra a continuación.Sin embargo, se debera ser un administrador. . Los comandos que se necesitan son:

En Vista , Win7, w08,  en un cmd:

netsh http add urlacl url=http://vaidesg:8080/ user=everyone

En XP, Instalar: Windows XP Service Pack 2 Support Tools. y correr:

httpcfg set urlacl /u http://vaidesg1:8080/ /a D:(A;;GX;;;WD)

Obviamente reempalaza vaidesg1:8080 por el nombre de tu pc.

En el HTTP.SYS, se va a agregar una reserva de espacio de nombres para la dirección URL. Si alguna vez  queremos deshacernos de la reserva . Hay que ahcer lo siguiente:  lo cual sirve para eliminar el sitio, cambiar a un puerto diferente o decidir que se ejecutan localmente.

Vista and Win7,:

netsh http delete urlacl url=http://vaidesg1:8080/

En XP,

httpcfg delete urlacl /u http://vaidesg1:8080/

Paso 2 – Configurar la  URL binding en WebMatrix

Si no lo ha hecho, seguir adelante y editar la URL de su unión a utilizar el nombre del equipo en lugar de localhost. Ahora debería ser capaz de iniciar con éxito el sitio web y navegar a la misma desde su máquina local. Hay un paso adicional para ir a su sitio web desde una máquina diferente.

Paso 3 – Abrir el firewall

Como les sea mas comodo, por el firewall de entorno grafico, para mi es mas comodo por consola:

netsh advfirewall firewall add rule name=”IIS Express (non-SSL)” action=allow protocol=TCP dir=in localport=8000

netsh advfirewall firewall add rule name=”IIS Express (SSL)” action=allow protocol=TCP dir=in localport=44300

Microsoft Virtual Academy (MVA)

 


Microsoft Virtual Academy (MVA) es una iniciativa de Microsoft TechNet, gracias a la cual, podemos acceder de forma gratuita a diferentes cursos OnLine (cursos, carreras, y especializaciones) de tecnologías Microsoft variadas (y en español), como SQL Server, MOSS, Exchange Server, Virtualización, Seguridad, Visual Studio, Microsoft Dynamics CRM, y mucho más. Sin duda, una iniciativa muy interesante.

 

Microsoft Virtual Academy (MVA) es gratuito, de tal modo, que una vez nos registramos en esta plataforma de formación de Microsoft TechNet, podremos iniciar distintas alternativas de estudios (Cursos, Carreras, Especializaciones), en formato de cursos OnLine.

Su formato es muy sencillo, y por resumirlo brevemente, nos podremos descargar los contenidos de los distintos capítulos. Así, primero nos descargaremos todos los contenidos del capítulo primero, nos los prepararemos, y tendremos que realizar un examen de dicho capítulo, que una vez aprobado, nos desbloqueará y nos permitirá poder descargar los contenidos del siguiente capítulo, y así hasta la finalización del correspondiente curso.

Además, según avancemos iremos sumando puntos en nuestro perfil, pudiendo conseguir subir de nivel a nuestro usuario, lo cual, por ejemplo, nos puede facilitar obtener descuentos al adquirir Subscripciones TechNet Plus Direct.

Otro detalle, es que una vez que finalicemos los estudios que iniciemos, estos aparecerán en la página de nuestro perfil. Esto, en cierto modo, permite mostrar públicamente que Microsoft TechNet reconoce que has finalizado el correspondiente curso en Microsoft Virtual Academy (MVA).

n.

Por último (que ya se me olvidaba), aquí va la URL: Microsoft Virtual Academy (MVA)

 

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.